Hi list, I have problems when kannel has one releases message queue. The change of store-spool maybe can help me. This change is ready in the present cvs?
Thanks Mario ----- Original Message ----- From: "Alexander Malysh" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, September 08, 2006 1:03 PM Subject: Re: Problematic Kannel behaviour with large message stores Hi, will try todo it next week. I have it up to 80% ready with possibility to select store file or store spool... Thanks, Alex Vincent CHAVANIS wrote: Alex, Could you please review you patch to fit the actual CVS tree, as we can test it. Then, how it comes this patch does not have been commited as it was ++2 regards Vincent -- Telemaque - 06200 NICE - (FR) Service Technique/Reseau - NOC Developpement SMS/MMS/Kiosques <http://www.telemaque.fr/> http://www.telemaque.fr/ [EMAIL PROTECTED] Tel : +33 4 93 97 71 64 (fax 68) ----- Original Message ----- From: "Alexander Malysh" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, September 08, 2006 12:06 PM Subject: Re: Problematic Kannel behaviour with large message stores Hi, you can search for my patch ( <http://article.gmane.org/gmane.comp.mobile.kannel.devel/20690/match=spool> http://article.gmane.org/gmane.comp.mobile.kannel.devel/20690/match=spool) that replaces store file with store spool directory. This works with similar performance when you put your store dir on reiserfs or tmpfs under linux. It would be great to hear test results for this patch. Please note that patch is very old and could not apply that you should fix manually. Thanks, Alex Giulio Harding wrote: We've been doing some more stress-testing of Kannel, this time under high-load over long periods of time, an we've encountered some problems when the message store grows large, of the order of hundreds of thousands of messages (in our case, because we're delivering MTs slower than we are receiving MOs, and due to the use of synchronous responses to MO HTTP requests, the MTs are queuing at the bearerbox). We understand that this is an extreme situation, and unlikely to be encountered in normal usage, but we want to cover all our bases (worst-case scenarios) and make sure that Kannel behaves correctly/ predictably in bad situations. - It seems that reading from the message store during Kannel startup is single-threaded, and CPU bound - for large stores (several hundred thousand messages), this can result in very long start-up times, since Kannel seems to not process any messages in the store until it has finished reading them *all* into memory from disk. - Why can't they simply be processed from disk? (i.e. read message from disk, process message, read next message from disk) Given that the messages are in a persistent store, why do they need to be in memory as well? - The bearerbox memory usage grows by around 100MB per hundred thousand messages in the store, as the messages are read from the store, which leads to VM thrashing under extreme circumstances, as the bearerbox footprint grows beyond the RAM size of the server... For one test, after the initial loading of ~634,000 MTs from the store, and bearerbox was using ~780M of RAM. 1+ KB per message seems a lot, given that messages seems to be occupying more space in memory than on disk (that number of MTs was consuming about 255MB on disc) - Once messages are read into memory, they seem to be copied into another queue (this exacerbates the problem above) - why is this?
