On Mon, Jul 13, 2009 at 11:49 PM, Daniel Pocock<dan...@pocock.com.au> wrote: > Brad Nicholes wrote: >>>>> >>>>> 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. >>> > > This is definitely an issue for some metrics, but not all > > It would be nice to have threading support within the agent rather than > requiring each person who implements a module to re-invent the wheel. > However, it might be best to make it configurable, so that `start a thread' > becomes a config option for each module or metric. There could be some flag > in Ganglia_25metric with which a developer can tell gmond that a metric must > be run in it's own thread, and some configuration file option to allow the > sysadmin to override the default setting of the flag. >>> >>> - 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). >>> > > Do you think one thread should be started to handle every client request (so > requests can be handled in parallel), or a single thread that runs > continuously and handles the requests one at a time? >
Having one thread per client request will be helpful if gmond need to handle large load from client. The tcp communication to get metric data from gmond seems not time-consuming during our testing. So IMHO, having at least one thread to handle client request is a MUST, while have one thread per client requet is a PLUS. >>> 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. >>> > > How many platforms have you tested it on? Linux, Solaris and Windows are > quite popular, and I've found differences in behaviour on each of them when > I added some threading code to gmond. We only tested the patch on Linux platform. > > Here is a previous thread on threads: > > http://mail-archives.apache.org/mod_mbox/apr-dev/200903.mbox/<cc67648e0903261256u7096f67dv44dd449fd512...@mail.gmail.com> > > Depending on how apr was built, and on which platform, the threading support > isn't always active - if threading is needed, the Ganglia configure script > needs to be more aggressive about detecting such cases and telling the > person go and build apr again. > > > > That may be one of the reasons to change threading gmond to non-threaded gmond. ------------------------------------------------------------------------------ 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
