PLEX86  x86- Virtual Machine (VM) Program
 Plex86  |  CVS  |  Mailing List  |  Download  |  Linux  |  Newsgroups

How to investigate sucked up RAM 3131


Your Ad Here

Your Ad Here

As others have said, it is supposed to use up most of the memory available.

I would have suggested you may have forgotten to include any swap on your machine, but I notice from your "top" listing that you have some.

Here is a machine I have with 512K RAM and RHL9; it does have X and GNOME in it, but I am logged in only through the LAN, so they are not doing anything. $ free total used free shared buffers cached Mem: 513228 472880 40348 0 44232 258852 --+ buffers-cache: 168 plus 1796 343432 Swap: 1052216 52640 999576

15:47:49 up 7 days, 1:55, 2 users, load average: 2.02, 2.02, 2.00 68 plus 1 processes: 65 sleeping, 4 running, 0 zombie, 0 stopped CPU0 states: 99.1% user 0.2% system 99.0% nice 0.0% iowait 0.1% idle CPU1 states: 99.0% user 0.1% system 99.3% nice 0.0% iowait 0.0% idle Mem: 513228k av, 472848k used, 40380k free, 0k shrd, 44160k buff 297900k actv, 51032k ind, 9220k inc Swap: 1052216k av, 52640k used, 999576k free 258840k cached

How to investigate sucked up RAM 3132
That says your memory is doing just fine. You have 517Mb available, and 9Mb is...

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM CTIME COMMAND 28014 boinc 39 19 43364 42M 596 R N 99.1 8.4 186:45 mfoldB1254.24 18707 boinc 39 19 46100 39M 3200 R N 99.9 7.8 2760m hadsm3um4.04i 27070 gdm 15 0 13424 13M 1360 S 0.0 2.6 2:58 gdmgreeter 27061 root 15 0 22932 5048 224 S 0.0 0.9 2:22 X ...

Do not even try. Back in the old days there was a saying, "The more you try to outsmart an operating system, the more it will outsmart you."

If your system crashes when you run a memory intensive program, you will just have to debug that somehow. One thing you might do is arrange to run the free command once a second in the background, logging its output to a file. Then start up the suspect program and see how the memory useage builds up. You might also wish to look atvar-log-messages (just before the reboot entries start) to see what the system was thinking just before the crash. Because you should not run out of memory, you should just start paging, perhaps slowing down your machine unacceptably, but it should not crash.

At the moment, you are nowhere near out of memory, and I do not recall ever crashing the machine running ghostscript (or whatever the printer spooler runs when confronted with postscript files).

I was not happy with Fedora Core 2, but it never crashed. Have you run memtest-86 to be sure your memory, especially the new memory, is operating correctly?

How to interpret "top" output
Michael and Barry, thank you for your thoughts. I think you must be right in that my...

-- .~. Jean-David Beyer Registered Linux User 85642. V PGP-Key: 9A2FC99A Registered Machine 241939. ^^-^^ 15:40:00 up 46 days, 23:57, 4 users, load average: 4.03, 4.08, 4.09



Your Ad Here

List | Previous | Next

How to investigate sucked up RAM 3132

Linux groups from Newsgroups

The #1 Usenet Provider on the Internet

How to investigate sucked up RAM