[Malvern] Memory Reliability

[Matthew Wild]

Hi Guy!

I have made some replies to your points below...

On 8/12/07, Guy Inchbald <guy at steelpillow.com> wrote:

> The main problem with long 'on' times is not the RAM chips themselves,
> but a software problem called memory leak. When an application finishes
> a task or closes, it should release all the RAM it used back to the OS,
> ready to be used again. But this does not always happen. The OS keeps a
> memory allocation table, of which apps are using which bits of RAM. If
> an entry is not erased when it should be, the OS thinks the memory is
> still in use and will not free it up for re-use.


Memory is always freed when  the process exits. At least Windows and Linux
do, and spare me from the OS that doesn't :)

In its early days, Linux used to suffer this problem. So too did many
> GNU and Linux-based apps. The Linux world got free of this problem some
> time ago.
> Some Windows apps, notably IIS and SQL Server, also used to suffer badly
> from this. Windows itself also used to suffer other problems with huge
> temporary files building up on the hard disk, in a very tangled and
> piecemeal way until it lost track of them.


Temporary files are another matter, and much easier to fix in an application
than memory leaks. There is not too much that an OS can do about temporary
files. Unless they are in a pre-allocated place that gets cleaned at
startup, a reboot will have no effect on these.

There is only one cure for a sick box whose RAM has all leaked away to
> where the OS cannot find it, and/or whose temporary files have got in a
> hopeless twist - reboot the OS.


Actually restarting the process should free the RAM, and I explained the
temp files above.

A lesser problem is an application that leaks memory within its own code
> and keeps asking the OS for more and more. Here, you need only restart
> the app regularly. But if you don't know which one it is, or it has a
> customised boot sequence which is set to kick in when the OS is booted,
> then you will probably reboot the OS anyway.
>
> The issue with openMosix clusters is a different one. Here, the OS is
> first copied into RAM on one box, and then cloned across to the many
> other boxes. The RAM in the first box must be perfect, and the OS must
> be copied in there without any glitches creeping in. Otherwise, the
> error would be copied across to every box in the cluster. For such
> high-reliability needs, various special types of error-checking or even
> error-correcting RAM chips are available. These are more costly, and
> usually slower, than the consumer RAM found in everyday PC's.


I think you know more about openMosix than I do :)

Sorry I never have time these days to make the meetings. Ubuntu is cool,
> but still no decent vector graphics package or click'n'run .exe install
> under WINE, so Win98SE soldiers on alongside.


I find Inkscape a great application for vector graphics. I am also able to
double-click .exe files in Ubuntu for WINE to run them (and I have used this
with setup exe's too).

--
> Cheers,
> Guy
>
> _______________________________________________
> Malvern mailing list
> Malvern at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/malvern
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.lug.org.uk/pipermail/malvern/attachments/20070813/206c34f9/attachment.html