10 Nov
2009
10 Nov
'09
6:26 a.m.
On Dienstag, 10. November 2009, Robin Vleij wrote:
Hey Robin,
yes, and normally only a small fraction of the memory is used.
Ok, i understand. So its more a temporary over load condition that you face.
Yes, its a lot of information to parse. But if you do a mem dump (as described
e.g. here: http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:memory)
with enabled memory debugging you could see where the allocations come from.
We did an upgrade to 1.5 in the last months on some of our production systems,
without any notable problems. Some other systems we've needs some more time
before they can run on 1.5, especially because of the database changes you
also mentioned. If you update make sure that you use the latest 1.5 version/
stable branch. 3.0 will be indeed interesting, looking forward to this.
Regards,
Henning
With today
memory sizes/ prizes you could use for example 512 MB, which
should give you plenty of room even in really abnormal load conditions.
And as its shared, you'll have still plenty of room for e.g. the
database.
Yep. It's basically to just use a huge amount and then normally you
wouldn't hit it. I understand from all of this that the memory "growing"
is really something that is not specific to my setup here. You mentioned
the the loops a few times, normally they should be pretty
fast detected by max forward counter checks and additionally by
diversion header checks?
Well, it's more like this. A customer sends an invite, which is really
to himself (failboat). So I send it to him (directly or via a PSTN
gateway, depending on the routing setup). Which causes (for example when
their PBX has a forwarding) a new invite to me, new call leg. Untill one
of both sides dies or is congested. That's normally not Kamailio, so
that's the good news. Only thing then is the memory usage after this
spike. I'm also running spike, so in the end I just send them 480's back. With the
memory debugging you could dump all the allocations during
runtime, but they are a bit hard to read for a non-developer. But this
way you could reproduce "call by call" how your server behave and how
the situation develops.
I had this on and it was a LOT of info. :) I made some calls and it
showed that there's lots of stats and init stuff, for the rest nothing
shocking. But as you said, I'm not a dev so I might have missed shocking
errors. :) If you'd
have a leak in a common used code path, then you'll run out of
memory pretty fast, like in a few days. If your servers are stable (like
some weeks or month) with the setting you use at the moment, i don't
think there is much to worry.
OK, I'll keep an eye on it. Will run with 128MB for now and see how it
grows with the load. I was looking at a 1.4.4 -> 1.5.0 upgrade, but that
was a bit more complicated than 1.3 -> 1.4 because of the database
layout and some changed modules. Have to write a failback plan before I
upgrade. Might also wait for 3.0.0, which sounds interesting.