usrloc loading (was Re: [Serusers] Re: Fw: [Users] TM : retransmission timers

[Jiri Kuthan]

At 16:00 30/11/2006, Andrei Pelinescu-Onciul wrote:
>I think they mean the number listed on the web page were obtained with
>tcp & tls disabled and if they would have  enabled them you would get
>higher numbers due to tcp & tls internal memory use (unrelated to
>usrloc).

I see.


>I haven't looked at the details, but it sounds good to me. It is much
>more convenient not to have to increase manually the private memory
>size and to recompile if you have large usrloc and keep them in the
>database. 

Agreed, that's where my curiosity came from.

>A nice side effect is that it probably causes faster startup
>times in such sitations.

That's what I'm struggling with.

I mean in the end there is some quantity of data which needs to
be downloaded, so either you do spend long time with downloading it
in advance to cut later request processing latency or you start
quickly and download the data on demand with some latency penalty
for cache misses.

Where is the time saving coming from then?

>However there is a mistake: it does not decrease memory usage by the
>numbers claimed (very very far from them). 
>This is because usrloc loads
>the database content _only_ from the main ser process (when the
>registrar fixup functions for the save & lookup family are called --
>from the main process before forking). All the children processes will
>inherit all the memory of their parent, however memory pages that are
>not modified will point to the parent's memory space and will not take
>_any_ system memory (this is because most unixes have a copy-on-write
>policy - after a fork a page is allocated & copied only if somebody
>attempts to write in it). So the children will not use any extra memory
> then normal (the initial db loading and the initial private memory size
> do not cause extra memory being used/allocated by the system for the
> children processes).
>To get the real memory used by a process look at the resident set size
>(RSS) and not at the virtual size (VSZ), which at least in ser's case
>tells the maximum memory that ser would ever use (and thus it's not that
>usefull).
>I will try to give a correct example, supposing that the fetch fix
>doesn't  use any private memory at all on startup (or uses negligible
>ammounts). Let's take the numbers published on the web page: non-fixed
>usrloc would need 32Mb of private memory to load the whole location
>table => in the end the fetch-fixed usrloc version would end up using
>32Mb less system memory then the non-fixed version (because of the main
>process which really used the private memory to load the db usrloc).
>There is a big difference from the 1Gb claimed...

Thanks!

-jiri


--
Jiri Kuthan            http://iptel.org/~jiri/