Trying to understand eggdrop memory usage numbers

[willyw]

Hello,

Using eggdrop v1.6.19+ctcpfix on a linux shell.


A friend has a new virtual private server, and I have a shell via him.
Running an eggdrop bot there now. No problems.

Recently, we were considering various things, and one of them was adding another bot, or bots.

He had concerns, as he has 256M of ram.
So, we are trying to figure out what we can do, and can't do.

I used the .status command, and got (mem: 217k) .
Is that to be taken literally? that the bot is using only 217 kilobytes of memory?
My friend took it to mean 217k of kilobytes.
We're looking to understand just what it means.
Please explain.

Also, today, it is up to (mem: 226k) . And my friend believes that mem usage creeps up, the longer the bot is online. This jives with that idea.
Are there memory issues with eggdrops? leaks, maybe?


Third question:
I went to the command line, via ssh, and ran top.
There is a multitude of info there, and we need some help with understanding that too.
In particular:
We see, up in the header part,
Mem: 262144k total,
and that jives with his 256M of ram.
In the display below, for the eggdrop, I see in a column named: %MEM
, 8.0 for the eggdrop.
That would be around 20.48M .
Is this what the eggdrop is using?

Fourth, and last question:
There is another column, labeled RES
and in that column, for the eggdrop, I see 20M
What is the RES column telling me?


I've looked in man top , and the info there was not enough for me to get it, so I'm asking here for some help in understanding what I'm looking at...
and
for help in learning how to decide what the limits are... number of eggdrops, that the vps can handle, etc. I hope we are on the right track, so far.


Thanks

[nml375]

I'll se if I can't write a more extensive reply once I get back on my workstation..

Roughly though, there are several different kinds of 'used memory', or rather, allocated memory.

First, the 217k number: This is the amount of data memory that has been allocated using nmalloc() (a memory-tracking version of malloc()), that yet has not been nfree()'d. Thus, this only covers dynamically allocated memory.

Next, the 8%: this would be the complete footprint of the process(es), including the dynamically allocated memory. This would also include the machinecode pages (the actual instructions that makes the bot tick), including any external library that has been loaded into the process. As such, this number is usually much larger than the size of a dynamically linked binary.

It would be normal to see some fluctuations of the memory footprint as your eggdrop runs. If, however, you see the amount of used memory constantly increasing over a long period of time, and don't use any 'statistics' script or module, gseen/bseen, AI's, etc that allocates large amount of data based on channel traffic or chatter - that would make for a good concern regarding memory leaks.

[willyw]

I'll se if I can't write a more extensive reply once I get back on my workstation..

...

Great! ... looking forward to it.

And thanks for taking time to explain. We are trying to decide what to do and not do... I suppose you could say we are trying to determine our limits.... and I hope we are asking the right questions.

[nml375]

Well, to dig into the various numbers returned by "top":
%MEM: currently used physical ram (same as RES). Also known as non-swapped memory.
RES: Same as above, but in real numbers rather than a percentage of available physical memory.
CODE: Amount of physical memory used for executable code aka 'text resident set' - TRS.
DATA: Amount of physical memory used for non-executable code aka 'data resident set' - DRS.
SHR: Memory flagged as shared with other processes.
SWAP: Amount of memory currently residing on the swap storage (aka non-physical memory).
VIRT: Total memory footprint, including both physical, swap, and shared memory.


Lots of fancy names, but what does this all mean?
Simply put, most OS'es these days try to be smart 'bout memory usage. All processes don't need all their memory at the very same time, so by using a swap device, we can store some of the currently not-in-use data there, freeing that area of the physical memory for other data. This, unfortunately, leads to performance impact whenever a process tries to read a "memory page" (the mechanics used to move sections of data in and out of ram is called page swapping, the virtual memory is divided into several memory pages which gets moved into an available ram slot whenever it's needed) that's not currently in the physical ram - since it first has to be retrieved from the swap device. Thus, linux tries to keep as much data as possible in ram at all times - keeping rather high numbers of used ram and low numbers of used swap.

So, is 256Mb the limit? If you've got a swap device, no. Though using a 4Tb swap would perhaps not be favorable... The larger the swap-to-physical ratio, the more often your system will have to swap pages, slowing down execution. One way to see how much memory you've currently got at your disposal, would be to execute this (shown with sample output):

Code: Select all

[root@linux /]# free -t
             total       used       free     shared    buffers     cached
Mem:        904624     887492      17132          0     201256     186504
-/+ buffers/cache:     499732     404892
Swap:      2031608        124    2031484
Total:     2936232     887616    2048616
[root@linux /]#

This is a system with 1Gb of ram, and an additional 2Gb of swap. As you can see, only 124kb of the swap device is used, while there's only 17Mb of ram free - virtually the swap is unused. However, I could easily use another 1Gb of memory without notable performance impact.

Now, the linux kernel has another trick up it's sleeve. In addition to swap memory pages, it can also shrink it's buffers and caches to free ram when another process needs it. Which way is determined by some half-advanced logic for the kernel to try and guess which will be more favorable.