Hi Sebastian,

Thank you very much for this additional information.
It will definitely help us address the issue. :)

Romeu


On Mon, Jun 9, 2014 at 6:03 PM, Sebastian Schildt <schildt@ibr.cs.tu-bs.de> wrote:
Hello

Am 09.06.2014 um 02:05 schrieb Romeu Monteiro <romeumonteiro7@gmail.com>:

> 2) When you say dtnd was memleak checked, that refers only to real memory, right? Did you make some measurements regarding virtual memory as well? We are currently working with industry partners on a huge testbed, with hundreds of vehicles equipped with small memory devices that can host IBR-DTN. It is an extremely sensitive testbed running multiple services and experiments, and so we are required to be extremely careful with everything that may cause any kind of malfunction of the devices. We were alerted of the very high values of virtual memory by dtnd and asked if we could check and solve that issue. It may not be really an issue, but neither we nor our partners are familiar enough with issues of virtual memory to guarantee that such high values will not pose a risk to the testbed.

According to my understanding, the max virtual memory is the maximum addressable space per process. So as a rule of thumb on a 32 bit architecture you will hit the limit between 3 and 4 GB (depending how much is reserved for kernel address space). Theoretically (I have never tested this), if a process requests more, it will be killed (or the allocation fails, and if it is not programmed carefully the program will die a horrible death shortly after). This should not pose a risk to other processes. So if the virtual memory stays well below the address space limitations of the machine you should have no problem whatsoever (How much IBR-DTN will take over a longer time I do not know, we never consciously checked this).  Also the 3-4 GB is sort of a lower border, for example a x86 machine with PAE kernel would be able to use almost 16 GB per process. 64 bit system will handle "enough".


There might be per-process limits for virtual memory, check

ulimit -v

if it sys "unlimited", it goes as far as the machine can go. You might set it to a lower (too low) value to check how IBR-DTN behaves, and whether other processes are affected, see
http://unix.stackexchange.com/questions/28678/how-to-limit-available-virtual-memory-per-process



Good luck and don't destroy you testbed :)

Sebastian
--
!! This message is brought to you via the `ibr-dtn' mailing list.
!! Please do not reply to this message to unsubscribe. To unsubscribe or adjust
!! your settings, send a mail message to <ibr-dtn-request@ibr.cs.tu-bs.de>
!! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.