30 Nov
2006
30 Nov
'06
10:51 a.m.
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/