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

Andrei Pelinescu-Onciul andrei at iptel.org
Thu Nov 30 16:00:25 CET 2006


On Nov 30, 2006 at 14:44, Jiri Kuthan <jiri at iptel.org> wrote:
> Thanks, how could I have missed that! 
> 
> Is what it does it loads usrloc table piece-wise?
> And if so, why does it do only for mysql?
> 
> And also, it is saying that old version would have
> increased memory consumption with TCP/TLS -- does it
> mean that it does not increase with the new version?

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 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. A nice side effect is that it probably causes faster startup
times in such sitations.

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...



Andrei


> 
> 
> -jiri
> 
> At 14:32 30/11/2006, Ovidiu Sas wrote:
> >Maybe you are looking for this one:
> >http://www.openser.org/index.php?option=com_content&task=view&id=48&Itemid=9
> >
> >
> >Regards,
> >Ovidiu Sas
> >
> >On 11/30/06, Jiri Kuthan <jiri at iptel.org> wrote:
> >>At 12:53 22/11/2006, Weiter Leiter wrote:
> >>>I know that OpenSER loads (only?) faster.
> >>
> >>Can folks share with me what the fast-usrloc-loading feature is about?
> >>I was not successful finding it out.
> >>
> >>Thanks!
> >>
> >>-jiri
> >>
> >>
> >>--
> >>Jiri Kuthan            http://iptel.org/~jiri/
> >>
> >>
> >>_______________________________________________
> >>Users mailing list
> >>Users at openser.org
> >>http://openser.org/cgi-bin/mailman/listinfo/users
> >
> >--
> >Jiri Kuthan            http://iptel.org/~jiri/ 
> 
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers




More information about the Users mailing list