Zeus,<br>
<br>
Thanks for the info. I did change that config.h define and now it works well. <br>
<br>
My newest problem is the ser start time. In my very non-scientific test
it took ser about 25 minutes before it began serving requests because
it was loading usrloc information.<br>
<br>
That was using 500000 records in the location table. The MySQL server
was running on the same box as SER, which is also my workstation, so
stuff like Firefox, X, etc, were in use.<br>
<br>
But this does bring up an interesting problem namely - how can ser
service SIP clients while loading large number of usrloc records? I'm
kind of thinking that this could be a big problem. When dealing with
massive user bases there is no such thing as a "quick restart".<br>
<br>
We do have LVS fully "sip-aware" so we are doing true UDP load
balancing based on the Call-ID header, but this is still a problem
[potentially] with replication ucontact records while the server is
starting up.<br>
<br>
I wonder if it is possible to modify the behaviour of usrloc so that it
loads in the background while ser is processing SIP messages. And when
lookup("location") is executed, usrloc searching the the ser cache and
then MySQL if no hit is found in cache -- or something like that.<br>
<br>
Can anyone on serusers give some tips as to how to get ser to load
usrloc entries optimized? I know the usual stuff like faster MySQL
disks, faster network connection, dedicated app servers, etc, etc. But
I'm looking for ser and/or MySQL tweaking hacks.<br>
<br>
Regards,<br>
Paul<br><br><div><span class="gmail_quote">On 5/24/05, <b class="gmail_sendername">Zeus Ng</b> <<a href="mailto:zeus.ng@isquare.com.au">zeus.ng@isquare.com.au</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Paul,<br><br>Like you, I'm not totally familiar with SER's memory management. I just<br>happened to bookmark that link which I think is useful.<br><br>Before we jump into conclusion that SER memory management is at flaw, can
<br>you just recompile SER and confirm that change fix your problem. I would<br>like to know the result too.<br><br>The loading of location table is done in the mod_init() function, not<br>child_init() function. Base on that information, I would assume that only
<br>the master process has to allocate that much memory. The child processes<br>need only know the pointer to that list. Thus, there is no need of 4G as in<br>your example. Again, this is only my assumption. It's better to raise
<br>another thread to ask the maintainer.<br><br>Regards,<br><br>Zeus<br><br><br>><br>> Zeus...thanks for the post.<br>><br>> However, it does a raise new (and possibly disturbing)<br>> question about SER's memory usage architecture.
<br>><br>> Here is the question; If I have 500000 records in the<br>> location table and for the sake of this example, let's assume<br>> that each usrloc contact occupies 1024 bytes of memory. To<br>> load all 500000 usrloc records we would need (500000 x 1024)
<br>> bytes of memory plus the structure overhead. So let's just<br>> estimate it to be a total of 512MB of memory for discussions<br>> sake. (I realize that the actual memory requirements will be<br>> much lower).
<br>><br>> Now when SER starts up it needs to load all usrloc records in<br>> to memory. Per the email in the archives, SER will do this in<br>> private memory space. I assume that after all usrloc records<br>
> are loaded in to private memory that they are then copied to<br>> shared memory. The amount of private memory is specified in<br>> config.h as PKG_MEM_POOL_SIZE and affects __ALL__ ser processes.<br>><br>> This then implies that in order to load a large number of
<br>> usrloc records I need to increase PKG_MEM_POOL_SIZE to<br>> approximately 512MB which then affects __ALL__ ser processes.<br>> If I specify ser to use 8 child processes in my ser.cfg file<br>> then will ser attempt to allocate 512MB x 8 or (4GB) of
<br>> memory just to start up???<br>><br>> If this is the case when the fundamental architecture is<br>> flawed as it would make much more sense to have a single<br>> process load usrloc records in to shared memory and then fork
<br>> the children with a much smaller amount of private memory.<br>><br>> Am I totally missing something here?<br>><br>> Regards,<br>> Paul<br>><br>><br>><br>> On 5/23/05, Zeus Ng <<a href="mailto:zeus.ng@isquare.com.au">
zeus.ng@isquare.com.au</a>> wrote:<br>><br>> This may help.<br>><br>><br>> <a href="http://mail.iptel.org/pipermail/serusers/2004-December/013593.html">http://mail.iptel.org/pipermail/serusers/2004-December/013593.html
</a><br>><br>> > -----Original Message-----<br>> > From: <a href="mailto:serusers-bounces@iptel.org">serusers-bounces@lists.iptel.org</a><br>> > [mailto:<a href="mailto:serusers-bounces@iptel.org">
serusers-bounces@lists.iptel.org</a>] On Behalf Of Java Rockx<br>> > Sent: Tuesday, 24 May 2005 11:09 AM<br>> > To: serusers<br>> > Subject: [Serusers] SER Reports "out of memory"<br>
> ><br>> ><br>> > Hi All.<br>> ><br>> > I'm using ser-0.9.2 and testing how it works when the<br>> > location table has many thousands of rows.<br>> >
<br>> > ser will not start when the location table has many rows. SER<br>> > loads the first 1344 records and then pukes on the 1345th<br>> > record with an out of memory error. I've started ser with "-m
<br>> > 512" but that doesn't seem to make any difference.<br>> ><br>> > Am I doing something wrong?<br>> ><br>> > Also, for my "test" data I simply created a bunch of bogus
<br>> > records in the location table. I did not do anything with the<br>> > subscriber table. Does this matter? If so, what needs to be<br>> > done in order to create a large number of "registered" users?
<br>> ><br>> > Regards,<br>> > Paul<br>> ><br>> ><br>><br>><br>><br>><br>><br><br></blockquote></div><br>