[NBLUG/talk] top output help

Dean A. Roman droman at romansystems.com
Wed Apr 25 09:39:55 PDT 2007

I don't suppose that things will break for a while(swap is filling the 
memory shortage), but you will start to see a slow down as more and more 
memory starts to thrash/swap.
If you can't change the hardware, then change the software.
I'm not sure what the code does, but it might be time to reconsider the 
use of perl...or see if perl can be threaded. (Java and C can use 
threads, and Java has garbage collection).
Each instance/process takes up a chunk of memory whereas using a thread 
aware application could eliminate a lot of the instance/process overhead.
(Assuming by instance, you mean a full process being started ??..if not, 
them maybe a shared memory scheme would work better?)
FYI:  I believe top defaults to reporting in Kbytes. (see "man top" for 
more info  :-) )


Walter Hansen wrote:

>Kyle Rankin wrote:
>>>top - 20:07:49 up 10 days, 23:47,  3 users,  load average: 2.38, 1.67, 1.13
>>>Tasks: 353 total,   8 running, 345 sleeping,   0 stopped,   0 zombie
>>>Cpu(s):  0.7% us,  3.3% sy, 29.1% ni, 63.9% id,  0.0% wa,  0.7% hi,  2.3% si
>>>Mem:    969372k total,   957648k used,    11724k free,      320k buffers
>>>Swap:   522072k total,   199300k used,   322772k free,     6784k cached
>>I'll agree with Dean, your server is using way too much swap and only is
>>able to use 6Mb in the file cache. If the kernel were just swapping out
>>idle pages you wouldn't see such a low file cache. So to get a lower system
>>load you'll want to figure out how to lower the memory footprint of the
>>applications on the system.
>The server runs multiple instances of a perl application that I wrote. I 
>did manage to cut it's memory footprint by almost 10% today, but the 
>bosses just added 100 instances. I cranked it up to see what it would do 
>and things didn't creep, but stuff didn't seem all that happy ether. At 
>the time of this top it was running 295 instances. I think each instance 
>sucks up 5400 (is it k or bytes in top?) of footprint (RES); got that 
>down from 5900. It's run on a 1U server at sonic and I've been told that 
>we can't upgrade the memory.
>I've been thinking about going through the code and optimizing it for 
>memory usage. This would probably be useful, but I don't think I could 
>squeeze it down more than another 10 or 20%.
>talk mailing list
>talk at nblug.org

Dean A. Roman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://nblug.org/pipermail/talk/attachments/20070425/3b5e17b5/attachment.htm 

More information about the talk mailing list