Yes, but how ?
As I said, I have installed Piwik 1.5.1 from new, that means deleting all tables and files first.
The issue is the same as with 1.5
I tried the 3 fixes suggested in ticket 2574 http://dev.piwik.org/trac/ticket/2574
but i’m sorry to say it is worse.
Very slow to load the dashboard (when loaded), and with same widgets errors at the end.
The ticket should’nt be closed for me.
Same problem. I applied the changeset 5052[/url] and it does not solve the problem. Can anyone please reopen [url=http://dev.piwik.org/trac/ticket/2574]bug 2574 on dev.piwik.org?
If you’re still encountering a problem, please try the nightly QA build at http://qa.piwik.org:8080/nightly/
Sorry, the QA build doesn’t solve the issue.
If the QA build doesn’t solve the issue, then you probably have a new issue. In which case, please email matt (at) piwik.org with your ftp server login/password, with a link to this forum thread.
[quote=Anthon]
If the QA build doesn’t solve the issue, then you probably have a new issue. [/quote]
Another way of saying that we identify the problem wrongly in the first place? 
QA build doesn’t work for me either.
The real test would be if it actually solved the problem for anyone. Maybe we were just on wrong tracks with the file/session problem.
PS: installed QA build on fresh install (fresh database, etc.): same problem.
I’m sorry to confirm that the patchset 5052 indeed does not solve the problem. I applied each one separately on a per file basis, logged out, restarted httpd to kill sessions, removed session files. It still happens with all three patches applied.
I’m not going to try the QA build. One of the things that I love about Piwik is the easy way to upgrade. I’m happy to try and replace certain files with newer code, but I don’t want to do a manual upgrade. Also, as it appears the QA build doesn’t solve the problem. Which is not a surprise as 5052 is supposed to fix the problem and doesn’t. As long as the QA build doesn’t have other fixes for this exact problem then it obviously can’t fix it.
I agree with Peutch that the cause of the problem may have been misidentified. Starting from square one, where is that try … catch error handler, so I could try to uncomment and see if I get a usable error? However, if I understand correctly, the second case cannot happen after applying the patches, as we now use file-based sessions again and for instance hitting the limit of concurrent sessions is not an issue anymore?
So, there either might be a third occasion where you branch out to the installer or there really is an issue with reading the config file, e.g. the path randomly getting corrupted? Or a problem with the bundled Ajax library?
I’d be happy to follow any troubleshooting hints you can provide to solve this mystery.
The QA build seems to make things going worse for me.
When i open the dasboard (with sone widgets going wrong as described) and try then to open the Settings page, I get now an error saying:
"SQLSTATE[42000] [1203] User xxx already has more than ‘max_user_connections’ active connections"
Refreshing after a while makes it desappear.
Also, the widget “Visitor in real time” (when it gets to be loaded) slowly turns out of function.
Those 2 things did not happen with 1.51.
So i think Peutch is right and the patches are misdirected.
PS: I sent my ftp codes to Matt, as Anthon suggested it.
This error indeed points to the no. 1 cause mentioned in 2574. Upping user connections is not a solution. The widgets should not all try to access the database at once each one with a new connection id. I’ll up the connection limit temporary to see if the behavior goes away.
10 minutes later …
Yes, I can confirm that upping max_user_connections fixes the problem. Apparently, the QA build has some additional error logging, that’s why you were pointed there, not because it fixes the issue.
As written above I can see this only as a temporary workaround, upping the connection limit should not be the solution.
So even when using File based session the code still connects to mysql all at once? I thought the patch was supposed to change to file sessions which should fix the problem. Are you seeing recent records in piwik_session table?
I have only one record in piwik_session, and if I’m correct, it dates from before applying the changeset 5052. (I have connected numerous times since then)
The piwik_session table is empty.
I had several sessions with a time right before the applying of the patch in that table. I deleted them and they don’t come back when using Piwik. So, it’s definitely using files for sessions. When I’m fast enough I can see up to 7 simultaneous mysql connections initiated by the piwik user. The actual simultaneous connection count is probably higher. The default limit we have is 5.
I think you will need to queue up the Ajax requests, so that they are carried out sequentially, at least partly. Maybe so, that widgets that tend to get more data/run longer than others are processed last, so that they can’t block others.
The problem are not db-based sessions, but the simultaneous Ajax requests that don’t know about each other and open each a new connection. You may have streamlined some portion of code in 1.5.1 (or earlier? I jumped from 1.4 to 1.5.1), so that the widget requests are coming in faster all at once and are not gracefully spread over a few milliseconds.
Hello
to all who have issues, can you please post PHP version + OS used + steps to replicate (it seems a more or less random issue?) directly in the related bug: mysql max user connection reached, triggers errors in widgets · Issue #2574 · matomo-org/matomo · GitHub
NOTE: the but was reopened after all feedback from here, thx
Strange thing is that the problem is not happening on all my websites, although they have same kind of hosting, same php version and same max_user_connections.
Could it be a problem with some mysql servers ?
(talking about 1.51, not the QA build).
Problem can be influenced by load or processing speed of the machine. e.g. if it’s quite loaded incoming requests may need longer processing and the MySQL calls may get spread over a larger time range (we are talking about milliseconds here 
and the limit is less likely to be hit. Or, on the other side, if it’s quite fast, the requests may either get processed almost at the same time (= limit hits) or the processing of each one is so fast that some requests come in sequentially (= the limit doesn’t hit). It’s hard to predict.
It also depends on the baseline of your user connections. e.g. on a Piwik server that gets a lot of traffic you have a higher baseline and may already hit the limit sometimes without knowing (apparently, errors are caught by Piwik, so you won’t know!) or may nearly hit it. Then the chance to go over the limit is much higher then on a server that does much less processing.
What are your limits? If you can set them manually decrease them until the problem becomes apparent. I’m sure you can provoke it this way.
I Cannot change limits. (for as far as i know).
max_user_connections is set to 10.
Can’t test the new fix as it apparently relies on other changes. e.g. the method isFileBasedSessions() doesn’t exist here. And I also see that the variable $sessionStarted has been removed, so I might get inconsistent results if I keep it (as I don’t know where else it is referenced).
If this really fixes the problem then the next “automatic” update to 1.5.2 (or what it gets called) should fix the problem, right? So, I wait for that.
Tested the new fix with the QA build previously installed, don’t know if other changes are required.
The result is that there is no more error in widgets, but some are waiting to be loaded for a very long period (several minutes).
But at least, i succeded in displaying all dasboard widgets at once.
roosevelt: If you’re using file-based sessions, then it’s expected to take longer to load. PHP uses a lock file, so:
- each dashboard user corresponds to 1 database connection per session (rather than per widget, and hence, running out of mysql connections)
- a widget has to finish loading before the next one can load