Hi, IMO, the extra thread overhead, if it is efficiently designed, is minimal, especially the more threads you already have. This is of course OS-depended, Solaris being more efficient with threads than linux. But again it should be minimal.
With respect to redundant filesystem dlr srorage, I would like to point out that sometime ago, with Alej G, we discussed the need for a more robust dlr handling. I don't remember ending up anywhere, but filesystem storage would introduce additional delays for the need to be synchronized. DLR redundancy needs to be examined in terms of global kannel redundancy. Right now, kannel offers a single level of redundancy in critical operations (SMS filesystem, dlrs DB). I that light, I find it an overkill to add 2 layer redundancy to dlrs. If 2 layers redundancy is needed for kannel, a more overall architecture needs to be considered. BR, Nikos ----- Original Message ----- From: Mathieu Bruneau To: Alexander Malysh Cc: [email protected] Sent: Wednesday, July 29, 2009 6:51 PM Subject: Re: Mysql with short wait_timeout On Wed, Jul 29, 2009 at 3:33 AM, Alexander Malysh <[email protected]> wrote: Hi, Am 28.07.2009 um 22:18 schrieb Mathieu Bruneau: On Tue, Jul 28, 2009 at 12:03 PM, Alexander Malysh <[email protected]> wrote: just add store support to inmemory DLR and you are done... but I'm --1 to keep DLRs in memory _and_ in storage. You choosed to use external storage to keep memory footprint low... If you say: I will keep DLRs in memory while DB not available then you should start thread to check DB availability and add DLRs to DB. What will you do if kannel will told to shutdown but some DLRs still in memory and DB not available? I don't like the idea of dual storage either. That could be interesting if you want to have some kind of cache in memory but in case you want to preserve data you need to write it anyway... I don't think the DLR would benefit much from this approach. In fact, my issue is simply that MySQL drops connections too fast for the usage Kannel gets (If I had a DLR to write every 5 sec I wouldn't have spot this issue). The reconnect could happen on a another server every 1h if it was not receiing much dlr. Since the wait_timeout is there in all MySQL instance and cannot be deactivated (It's just the value it's set at that change), maybe having a timer send a mysql_ping to maintain the connection is actually the valid fix... Basically it's adding an option to send keepalive through the mysql connection for Kannel, effectively turning this in a persistent connections, which would be valid since Kannel use only a controlled number of connections. This very much resemble the keep-alive on a SMPP connections (or any other type of keep-alive) so I don't see what is really wrong with this. I'm ready to hear other thought before I put my head into what could be needed to add this :) because to mantain keep-alive you need one thread to be running -> wasting resources. This thread can be avoided (and already avoided) with Well, let's take my case and check some of the logs. I must say I don't know the core details of how much waste a thread is but if I look at my current Kannel i have this: [mbrun...@xxxxx backup]$ ps ax -T | grep bearerbox | wc -l 66 So my bearerbox handle ~60 threads already. I don't think that adding a thread that wake up every N seconds would add significant overhead on the system? Guess it depends... Let's look a bit more. My servers get some DLR but just not enough to be very 10 seconds. So in the current setup it reconnects everytime DLR come in but wasn't in the last 10 seconds. Let's check how many time we reconnected [mbrun...@xxxxxx backup]$ zcat bearerbox.log.2.gz | grep 'database check failed' | wc -l 2072 So there was ~2000 reconnects per 24h to the database that could be avoided. Now the questions is which one would have been more overhead. (I leave this to purist) simple approach, check and reconnect connection only before connection use. The only issue you have, is max allowed connections in mysql and not kannel itself. Of course, I know that the issue is all coming from the fact that Kannel couldn't reconnect to the database. I was just thinking that having this "persistent" connections would be something nice to allow user to decide to use or not, it would have cleared the log on a "error" not really an error too... -- Math aka ROunofF [email protected]
