Chris, "Live monitoring is the only way to go, unless you want your customers to surprise you with performance problems on your own site. :)"
Monitoring, ok, but alerting is critical for large scale production environments. You mention JMX callbacks for alerting, but it would be worth that you mention SNMP since it's very easy to set up and efficient. We also can raise alerts on deltas with this method, and see a problem before the CPU says something bad is going to happen. Just my feedback ;) regards 2015-10-08 19:27 GMT+02:00 Christopher Schultz <ch...@christopherschultz.net >: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Aurélien, > > On 10/7/15 5:59 PM, Aurélien Terrestris wrote: > > when this happens you can do a thread-dump (kill -3 pid on Linux > > platforms) and you would see if there is a lock on JDBC objects, or > > anything else synchronized (from the Collections like Hashtable). > > Not easy for beginners to understand a dump, but worth learning. > > +1 > > This is the only way to find out what's going on. All other monitoring > solutions will just tell you that *something* is wrong, but this will > give you details. > > > Very often an application will slow down because Garbage > > Collection, and the GC thread will be the only one working at that > > time. Please use the verbose settings to have all your Tomcats log > > GC activity. This is useful for both live and after time analysis. > > This is pretty unlikely for the reported observations, since Tomcat > slows down and stops responding (presumably until restarted). That is > more likely to be something like database connection pool being > exhausted due to poor resource management rather than out-of-control > GC activity. > > > You won't monitor mod_proxy, this has no sense. > > I disagree. The connection can go down for various reasons. But I > suspect that's not the problem in this case. > > > If you suspect a network flood, do a 'netstat -an' to see how many > > connections are used by your Apache (both ESTABLISHED and > > TIME_WAIT). However, you might need to set timeout and flushpacket > > on your proxypass directive when your application has such > > requirements (see HTTPD doc for this settings). To know if you're > > flooded, you can do a 'ps -eaf | grep [h]ttp' and you would see > > many httpd process, it is similar to the netstat result more or > > less. > > +1 > > > If you enjoy live monitoring, you need to have a look on > > Christopher's presentation ( > > http://events.linuxfoundation.org/sites/events/files/slides/Monitoring > %20Apache%20Tomcat%20with%20JMX.pdf > > > > > ) who posts many answers to this mailing list. > > Live monitoring is the only way to go, unless you want your customers > to surprise you with performance problems on your own site. :) > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJWFqd5AAoJEBzwKT+lPKRYi9AQAIpHkOgXoz2Ntfdf8aH1mjTB > gdKDu1B5fEgpTYRhV+mQ5rEegkszJ0jUEQdCVjwp2ZjldgsLPP6wXaBw6LdUG3UB > l63K4tCkDwIiVI8rB0syAeQQ/4uUS7SmiJaLZAwLHl08mDZHs9e/LiKJ47rJjh3+ > 4pkejtbHhobF2fcH61ZM7M5qxPKlzP49dDzXyppbvEG/kk7T9FkIl2TVOT349zkP > c1jrtC19fKDhbz72c/03/Z1V/clZ+Q3BScYHddlRw0ZXuOEu8LQJRD0VPmEY4pM5 > DTPH+z5spnYUO0hH0FHx/WGHgQ5iCrQHYG8pdkfhDEqSaDnqm4qIFxC4fChIFSuh > c9eqor7axyOcacHvTCwPudXGuWBxK0LCnigikd83OM/EaKdRwR0ahMqXKEQkRdTn > QW3vfsOQXXuy0vAFz6fphOkWXCr4SJWVOsAG3f1vlStMs2to4q66hpNQpLFJpcdN > ectoRaCRvQMLdw9UhdG3z5wTCvPPj9RP8IA/Lxi48QisYOMZwABgh7mMh2+mE7pH > tTHun4fE2HhdVPqORonHhTWldvu4xYqWav9FNBgg2ywyekAWVcrcFZRLgYhG+T37 > 0neZbSdwd/iLdsZ+sKhGY04CSwAsUZdTh87pZ+8NWH7tvi71JIt7nlI0JgRI5ipw > Jdty982ew2WiaY0rhspW > =Ra47 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
