>>> On 7/13/2009 at 8:17 AM, in message <e6ccb7f50907130717i2f3dfd5fi1c69dbd4124a7...@mail.gmail.com>, utopia zh <utopia...@gmail.com> wrote: > Hi, > > While trying to use gmond to monitor our applications, we found some issues: > - Metric collecting may take long time to finish, such examples > include collecting master/slave status from LDAP, parsing web pages to > get statistics. > - Receiving metrics updating from other node may fail due to blocking > metric collecting. > > To avoid this blocking behavior, we tried to change gmond to multithread: > - Main thread to collect metrics, we also have the metric collection > python script changed to be non-blocking > - Dedicate thread to receive updates from other nodes. > - Dedicated thread to server clients (gmetad/telnet, etc). > > Could you help review the patch? We'd like to contribute the patch to > the community if multi-thread is a generally required features. > > Any comments will be appreciated. Thanks. > > p.s. Just to be curious, why ganglia was changed from multi-thread > into single thread from 2..5.7 to 3.0? > > > Cheers, > Hang
I haven't reviewed the patch yet but in most cases this issue can be solved within the python module itself. The tcpconn.py module is an example of this. Basically what it does is create it own thread that simply gathers the metrics on some module defined interval. This thread updates a metrics cache within the module itself. Then whenever gmond queries the module for its metrics, the metric values are simply read from the module's metric cache rather than actually performing the gathering process on the main gmond thread. This method ensures that nothing is blocking the main gmond thread when querying the data from any module that might take a lot of time actually acquiring the metric value from the metric source. I haven't looked that closely at the 2.5.x code so I have no idea what level of threading it may have supported or why it might have been changed in 3.0. If multithreading gmond 3.1.x is something that would increase the performance of gmond, then I am sure that this patch should be something we should add to the code base. thanks, Brad ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers