On Nov 30, 2006 at 14:44, Jiri Kuthan jiri@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&...
Regards, Ovidiu Sas
On 11/30/06, Jiri Kuthan jiri@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers