Summary: | net-analyzer/cacti-0.8.7e-r2 spams mysql connections | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | Current packages | Assignee: | Peter Volkov (RETIRED) <pva> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | lex.brugman, luckyluke, netmon, thewitness |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Proposed fix |
Description
Dennis Schridde
2010-06-06 22:58:05 UTC
Did you mean "spawn" or yet another new meaning of "spam"? It "spawns" lots and lots of them, either hitting the global mysql connection limit, or the limit for that user. Thus I think "spam" is appropriate, too. Dennis is this regression compared to previous revision. Do you use cacti-spine? Regression: I cannot tell you more than: "It once worked fine", today it makes my mysql server block... So it is a regression from a previous combination of apache,mysql,php,cacti, yes. spine: The issue exists regardless of the poller choice. The issue also exists directly when opening the webinterface, without having to run any poller. I will have a look later whether running just the poller will create the same trouble. (Please remind me, should I not have reported back in a few days!) All this looks like not cacti issue, but something else... Actually I don't have any idea at the moment. Maybe notable: phpmyadmin does not show such issues (but it uses a mysqli connection). Yesterday I upgraded my production cacti-0.8.7e + cacti-spine-0.8.7e to cacti-0.8.7e-r2 and cacti-spine-0.8.7e-r1 with no difference in the number of connections and queries to its MySQL database (gentoo/hardened on amd64). I'm using the spine poller with ~350 data sources on 20 hosts. (In reply to comment #7) > Yesterday I upgraded my production cacti-0.8.7e + cacti-spine-0.8.7e to > cacti-0.8.7e-r2 and cacti-spine-0.8.7e-r1 with no difference in the number of > connections and queries to its MySQL database (gentoo/hardened on amd64). I'm > using the spine poller with ~350 data sources on 20 hosts. Do you have the same issue, or is everything normal on your end? (In reply to comment #8) > Do you have the same issue, or is everything normal on your end? As I said, nothing changed on MySQL after the upgrade. I'm graphing the number of MySQL connections and queries with cacti itself, and you can't "see" any change in the graph. It's keeping the same number of open connections and doing the same number of queries as before. Created attachment 239707 [details, diff]
Proposed fix
The problem is that cacti uses persistent connections to MySQL which is failing when apache is used with the worker MPM.
I've attached a fix for this issue.
Lex, thank you very much for this fix! Have you tried to contact upstream on this issue? If yes, do you have reference at hand? (In reply to comment #11) > Lex, thank you very much for this fix! Have you tried to contact upstream on > this issue? If yes, do you have reference at hand? > No, I didn't. But it looks like some other users have figured this out as well and posted it on the cacti forums ( http://forums.cacti.net/viewtopic.php?t=34235 ), the developers don't seem very interested though. Since upstream doesn't really care, wouldn't it be an idea to include the patch in the ebuild? What do you think? Hi, it's TheWitness here. I'd like to comment on this. Firstly, the reason that we use persistent connections is to speed the web UI. So, this is normal and not harmful to 99% of the LAMP servers out there as they are generally sleeping. What's more of an issue, is if your 'max_connections' in my.cnf is not high enough. That's the bogus issue. Another issue is that spine is taking a mysql connection per thread, so that's the real hog. It's top on my list of spine issues to correct. Regards, Larry Adams aka TheWitness Well, raising the max_connections will only temporarily fix this because the connection count rises infinitely when using the worker MPM with apache. PHP seems to have problems using persistent connections with this setup. The only real solution IMHO is to stop using persistent connections. I think this should be fixed in 0.8.7h. Please check. (In reply to comment #16) > I think this should be fixed in 0.8.7h. Please check. Confirming fix in 0.8.7i (haven't checked 0.8.7h). (In reply to comment #17) > (In reply to comment #16) > > I think this should be fixed in 0.8.7h. Please check. > Confirming fix in 0.8.7i (haven't checked 0.8.7h). P.S: There are still several open connections (about 20), but the number will not grow infinitely anymore. |