Are you completely _sure_ that it's held by Kannel and not the underlying OS? Linux doesn't free unused memory unless needed by other processes.
Also, if you have in-memory DLR's or a huge retry queue, it could consume lots of memory. Unless you get OOM errors, I wouldn't be concerned by the amount of memory being used. Regards, Alex On Tue, Aug 10, 2010 at 5:26 PM, sangprabv <[email protected]> wrote: > Regarding this performance benchmarking. I still got memory problem. Kannel > fails to release buffered or cached memory. Does anybody has tips to avoid > this problem? Thanks. > > > > sangprabv > [email protected] > http://www.petitiononline.com/froyo/ > > > On Aug 10, 2010, at 10:12 PM, Rene Kluwen wrote: > > Why don’t you try it on your own system. Test with a MyIsam table and with > InnoDB. > It will be easy to determine which one works faster for you. > > == Rene > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *brett skinner > > *Sent:* Tuesday, 10 August, 2010 11:56 > *To:* Alejandro Guerrieri > *Cc:* Users > *Subject:* Re: Kannel performance benchmarking > > Thanks for your feedback. > > Guess it is the age old tao of computer science. Space vs Time, always > space vs time. :) > > > Regards, > On Tue, Aug 10, 2010 at 11:52 AM, Alejandro Guerrieri < > [email protected]> wrote: > Oh yes, I read that blog quite frequently :) There's a lot of stuff to say > about optimizing InnoDB, but it's definitely off-topic here and wouldn't fit > on a single email of course. > > We've gone thru a series of optimization cycles on our platform and, with > respect to Kannel, ended up using MyIsam for DLR's. We don't have any > locking issues, the only detail is we need to be careful when expiring old > entries to do it in small batches and not on peak hours. > > For the rest of our applications, except for small and mostly read-only > tables, we use InnoDB and while seems "slower" when you do a couple of > requests, it's a _lot_ faster if you are under heavy traffic because of the > row locking instead of table locking. > > Anyway, there's no a one-size-fits-all solution and if you really need to > sustain heavy traffic I'd recommend you do a lot of profiling and find the > bottlenecks either on the DB and the rest of your platform. > > Regards, > > Alex > > On Tue, Aug 10, 2010 at 11:15 AM, brett skinner <[email protected]> > wrote: > Hi Alex > > That is why I have chosen Innodb for the tables we use for the application > that surround Kannel. MyISAM definitely beat Innodb out the box but Innodb > does seem to be better in terms of the issues you have pointed out. The > other thing that I have read is that Innodb is incredibly slow with the > stock standard configuration. I read through the following blog and followed > their advice which increased its performance quite drastically. > > > http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ > > If you have a moment you can give that a read. Or if you have any other > good references please send them a long. I am still rather new to MySql. > Thanks :) > > Regards, > > > On Tue, Aug 10, 2010 at 10:56 AM, Alejandro Guerrieri < > [email protected]> wrote: > Well, if it weren't for the SELECT COUNT(*) slowness would be my preferred > option here as well. Despite seeming "slower" at first (specially on small > tables) InnoDB performs row-locking on index-based queries, which indeed > improves things quite a bit on big tables with lots of simultaneous reads > and writes. > > Regards, > > Alex > > > 2010/8/10 Nikos Balkanas <[email protected]> > Indeed. InnoDB is much slower overall compared to MyIsam. However, it has > its use for some jobs (archive_logs, hot backups, etc.) > > The figures I gave were sustained rates simulated with a 10000-SMS batch. > Count was sufficient to reach sustainability and reproducibility, yet short > enough to get results fast. > > When i submitted fakesmpp, I also released similar data from a 64bit > Solaris 10 server. > > BR, > Nikos > ----- Original Message ----- From: [email protected] > To: brett skinner ; [email protected] ; us...@kannel. [email protected] > Sent: Tuesday, August 10, 2010 11:21 AM > > > Subject: Re: Kannel performance benchmarking > > Brett, > > The DLR engine uses SELECT COUNT(*) from the admin interface, which is > painfully slow on InnoDB for moderately big tables. > > While InnoDB would theoretically be the best option, MyIsam performs quite > better in this case. > > Regards, > > Alex > BlackBerry de movistar, allν donde estιs estα tu oficin@ > > > > > From: brett skinner <[email protected]> > Sender: [email protected] > Date: Tue, 10 Aug 2010 10:13:54 +0200 > To: Users<[email protected]> > Subject: Re: Kannel performance benchmarking > > > Hi Nikos > > > Thanks for the extra information. What was the motivation for using MyISAM? > My reading lead me to believe that MyISAM was not that well suited for > interleaved reads and writes due to table locking which is why I opted to > use InnoDB. From what I assumed about how Kannel worked is that > reading/writing to the DLR table would be interleaved. I may be quite badly > mistaken and might perhaps need to switch to MyISAM as a few others have > recommended. > > > In your opinion what should Kannel be able to handle sustained (assuming > normal business hours)? And what should Kannel be able to burst to? I know > some of these questions are a bit like how long is a piece of string but I > really do value all and any of your feedback. > > > Regards, > > > 2010/8/10 Nikos Balkanas <[email protected]> > > Try valgrind in linux. > > BR, > Nikos > ----- Original Message ----- From: "sangprabv" <[email protected]> > To: "Nikos Balkanas" <[email protected]> > Cc: "brett skinner" <[email protected]>; "kannel users" < > [email protected]> > Sent: Tuesday, August 10, 2010 3:35 AM > > Subject: Re: Kannel performance benchmarking > > > Yeah I understand that. But when the there is no traffic. Kannel doesn't > release the cached or buffered memory it used. Do you have any solution? > What command to list down or trace the memory usage by Kannel? So maybe we > can investigate which function or module in Kannel is eating the memory. > Thanks > > > > > sangprabv > [email protected] > http://www.petitiononline.com/froyo/ > > > On Aug 9, 2010, at 11:19 PM, Nikos Balkanas wrote: > > > No memory problems. It is reasonable that kannel will use more memory in > higher traffic, since all queues are in memory, as long as it drops to > nominal levels once the traffic is gone. > > BR, > Nikos > ----- Original Message ----- From: sangprabv > To: brett skinner > Cc: Nikos Balkanas ; kannel users > Sent: Monday, August 09, 2010 5:59 PM > Subject: Re: Kannel performance benchmarking > > > Hi Nikos, > Do you experience memory problem? In my case Kannel is eating the memory on > high load traffics. I always need to restart the box to get more memory. I > even give 3 on /proc/sys/vm/drop_caches but still Kannel eat the memory :( > > > > > > > sangprabv > [email protected] > http://www.petitiononline.com/froyo/ > > > > > On Aug 9, 2010, at 9:42 PM, brett skinner wrote: > > > Hi Nikos > > Out of curiosity can you go into more detail regarding what hardware you > were running and your setup for MySql? Were you using Innodb or MyIsam. If > you were using Innodb did you make any other configuration changes to MySql > to accommodate Innodb. > > From the user guide it is implied that the bottle neck for Kannel is the > number of messages that the SMSC can accommodate per second. Is this still > the case? > > Regards, > > > 2010/8/8 Nikos Balkanas <[email protected]> > > Hi, > > I have run some benchmarking for a client using fakesmpp. Using the default > service for MO's I got: > > MO's: 1400 SMS/s > MT + DLRs (internal): 747 SMS/s > MT + DLRs (MySql): 434 SMS/s > > BR, > Nikos > ----- Original Message ----- From: [email protected] > To: kannel users > Sent: Sunday, August 08, 2010 4:22 PM > Subject: Kannel performance benchmarking > > > > Hi, > > > I am interested to know about the kannel performance benchmarking, > especially in terms of speed (msgs/sec), MO or MT. I assume that multiple > smsboxes does not have any effect over kannel performance, since the > front-end talking to SMSC is the main bearerbox. What is the max speed that > could be attained by kannel and/or bearerbox? > > > Regards, > > > Hamza > > > > > > >
