"max_user_connections" probleem

[yosibeck]

Hoi Huub,

Max van Dam heeft sinds een korte tijd een probleem met onstabiele verbinding van HG met de database.
Het lijkt willekeurig - soms werkt alles gewoon en soms krijg je de rode regels van HuMo-genealogie die in EN en NL aangeven dat er geen verbinding met de database is.

Ik heb toen in zijn db_login.php bestand de echo $e->getMessage() regel aangezet.
Iedere keer wanneer het mis ging kwam er nu boven de rode regels te staan:
SQLSTATE[42000] [1203] User vandam_....... already has more than 'max_user_connections' active connections

Maar wanneer ik dan in de database keek bleken er maar een paar actieve verbindingen te zijn, terwijl bHosted de MySQL variabele max_user_connections op 30 heeft staan (wat redelijk is op een shared server).

Het is belangrijk te vermelden dat het probleem begon in een periode waar Max niets op zijn site had veranderd, d.w.z. geen HuMo-genealogie updates/upgrades of wat dan ook. Hij gebruikte nog versie 6.5.1. Voor alle zekerheid heb ik de versie geupdated naar de laatste, maar dat helpt niet met het probleem.

We hebben ook de bHosted support aangeschreven.
Die zeiden hetzelfde wat je ook op het internet kunt lezen. Dit probleem komt doorgaans voort uit een van twee oorzaken:

• Er zijn tegelijkertijd te veel gebruikers online die een mysql verbinding initiëren, meer dan de max_user_connections. In zo'n geval is de enige oplossing over te gaan van een shared server naar een veel duurdere dedicated server.
• Er zijn problemen in het script waardoor de verbinding openblijft van het moment dat een gebruiker de site binnenkomt tot hij hem verlaat. Er wordt dan aanbevolen alleen de database verbinding te maken net voor een query wordt gemaakt en meteen daarna te sluiten.

Dat klinkt allemaal logisch maar in het geval van Max, kan ik beide oorzaken moeilijk plaatsen.
Zoals ik al schreef, wanneer de verbinding niet werkt kan ik in PhpMyAdmin zien dat er maar een paar actieve verbindingen zijn. Ik zag het ook gebeuren om 1 uur 's nachts wanneer er echt geen 30 gebruikers zijn...
En wat het HuMo-genealogie script betreft, zoals gezegd was dat precies hetzelfde voordat het probleem begon en daarna, zonder enige verandering, dus is het moeilijk te concluderen dat het daaraan ligt.

We zitten er dus een beetje mee.
Misschien heb jij een idee waar het aan kan liggen of wat er geprobeerd kan worden om het op te lossen?

Yossi

[Huub]

Dit probleem heb ik niet eerder gehad.

Er is 1 scherm die vermoedelijk meerdere mysql verbindingen opent: het muteerscherm bij personen en gezinnen.
Dat komt door de iframes die gebruikt worden voor bronnen. Ik probeer al langzamerhand zoveel mogelijk iframes te verwijderen.

Ik heb al gezocht op internet: in principe is het niet nodig om een mysql/ PDO verbinding zelf te sluiten (dat doen we dus ook niet), maar het kan wel.
Het zou dus kunnen helpen om zelf de PDO verbinding te sluiten. Bijvoorbeeld onderaan het bestand: views/layout.php.

Ik heb dit code voorbeeld gevonden om de database verbinding altijd te sluiten (ik heb dit nog niet getest):

Code: Select all

//Kill the connection with a KILL Statement.
$dbh->query('KILL CONNECTION_ID()');

//Set the PDO object to NULL.
$dbh = null;

En ik hoop dat Max een beetje kan wennen aan de nieuwe look, ik ben nogal veel aan het wijzigen

[Contributor]

"There are issues in the script that keep the connection open from the time a user enters the site until they leave"
This is not possible with PDO, once the request is returned the db closes and there is no 'cron job' as far as I know in humogen.

Do you use your database for other applications?


@huub I don't know where you found this code, but it is completely useless..

[Contributor]

max_user_connections does not mean how many users there are connected to the application
but how many times the application is connected to the mysql server simultaneously..

[yosibeck]

Hi,

max_user_connections does not mean how many users there are connected to the application but how many times the application is connected to the mysql server simultaneously..

I am aware of that. What I meant to say is that when a site has a large number of user connections there is much more chance of the occurence of over 30 simultaneous mysql server connections. In this case there were so few users that it is hard to understand how they could cause this overload.

I also checked threads_connected in the mysql status and other connection indicators, but all showed minimal use and load and nothing that could explain the max_user_connections problem.

There are issues in the script that keep the connection open from the time a user enters the site until they leave

This was a quote from an article on a respectible site where it was claimed that in certain cases faulty scripts can cause interference with the default PDO behaviour that you mentioned.
As I said in my previous post, this can't really be the case with our problem, because it started out-of-the-blue without any change in HuMo-genealogy, that worked perfectly before.

[Contributor]

I talked about this issue a few months ago at @Huub.
I think this is the problem I caught without having the error but knowing it was going to happen.
I think he needs to work on it right now.

Can you give us the urls (just after your domain) where this poses a problem?

[Huub]

Many years ago I also had a lot of (hidden) visitors at my HuMo-genealogy website.
I discovered the problem was several search / indexing robots.

Because of that I made a few options in HuMo-genalogy to (partial) block these robots, then my problem was over.
Only my front page is now accessible for robots.

I'm not sure if this is a problem, but it's easy to block some robots and see the results.

I think this is the problem I caught without having the error but knowing it was going to happen.
I think he needs to work on it right now.

I did a test and generated a very large descendant report including sources, children etc.
It was just 2 user connections. The second connection was another website I opened.

[yosibeck]

Hoi Huub,

Het blijft bij Max nog steeds helemaal misgaan. Zijn site is soms bereikbaar en vaak voor tijden niet.
Ik heb geprobeerd in de instellingen om de robots tegen te houden, maar dat hielp ook niet.

Wanneer het mis is, kan je de site niet binnen. Ik weet dus niet waar het probleem ontstaat.
Ik heb uitgebreid op het internet gezocht, maar kan nog niets vinden dat dit verklaart.
Doordat ik de error weergeving in db_login.php heb aangezet zie ik dus de regel: "SQLSTATE[42000] [1203] User ..... already has more than 'max_user_connections' active connections".

maxerror.jpg (59.62 KiB) Viewed 701 times

Hier is een MySQL status rapport over alles wat met connections en threads te maken heeft. Ik maakte dit terwijl het mis is. Er zijn hier meer gegevens dan nodig zijn en sommigen zijn totaal-gegevens sinds het begin, maar ik laat ze maar allemaal zien.

maxstatus.jpg (23.41 KiB) Viewed 700 times

Zijn site met meer dan 180,000 personen is belangrijk voor ieder wie research doet in Nederlands-Joodse genealogie en ik wil hem hier graag mee helpen, maar ik weet gewoon niet meer waar aan te sleutelen...

Yossi

[ron]

Hallo,

Misschien dat je hier iets mee kunt:
https://developers.google.com/search/do ... bots/intro

Je kunt ook een los robots.txt bestand aan maken om zoek machines tegen te houden.
Dit als aanvulling op wat Huub al heeft geïmplementeerd.

En verder staat op de hoofdpagina aan dat Robots wel mogen indexeren:
view-source:https://www.maxvandam.info/

<meta name="robots" content="index, follow">
Misschien kun je dat aanpassen in:
META NAME="robots" CONTENT="noindex,nofollow"

[yosibeck]

Ja, ik zie wat je bedoelt.
Ik heb in HuMo-genealogie (HG) de robots uitgezet en dat staat er ook als je de source page van de voorpagina van zijn HG installatie inkijkt (https://www.maxvandam.info/humo-gen/index.php).
Maar de hoofdpagina van zijn site (www.maxvandam.info), die niet bij HG hoort (geen HG CMS pagina dus), heeft inderdaad de robots aanstaan.
Ik zal het eens proberen met dat uit te zetten en zien wat er gebeurt...

Bedankt.