[mysql] veel SELECT commando's en hoge load, reden onbekend

[M4RTiN]

Ik heb een productie mysql server op ubuntu, versie: MYSQL: 5.7.26-0ubuntu0.16.04.1

Vanaf woensdag neemt de CPU veel resources in door mysql.

MySQL draait alleen lokaal, de poort is niet benaderbaar via internet.


Wat ik al gevonden of geprobeerd heb


Ik heb diverse cli applicaties in php gemaakt die normaal verbonden zijn. Die heb ik allemaal eens uitgezet.

In PHPmyadmin zie ik maar 1 active connection en 1 of weinig threads verbonden.

SHOW PROCESLIST geeft af en toe een normale query aan, soms alleen de commando SHOW PROCESLIST zelf.

Wat mij erg opvalt is onder tabblad query statistieken dat er alsnog enorm veel SELECT commando's worden uitgevoerd:

Opdrachten # ø per uur %
select 276 k 1,181,2 k 90,80

=============================

Questions sinds opstart: 327,826 Documentatie
ø per uur: 1,299,751
ø per minuut: 21,663
ø per seconde: 361

(zolang geleden heb ik hem vanochtend nog niet opgestart)

================================================

Wat kan ik doen om de oorzaak achter deze load te achterhalen ? Het is een Ubuntu server die recentelijk nog een apt-get update heeft gehad. Volgens mij zijn er toen ook tabellen geupdated naar een nieuw format.

[GlowMouse]

Kijk eens naar pt-query-digest.

[CAPSLOCK2000]

361 queries per seconde? Dat is inderdaad nogal veel.
Je zou query logging even aan kunnen zetten om een betere indruk te krijgen van wat voor queries dat zijn.

[GlowMouse]

CAPSLOCK2000 schreef op donderdag 27 juni 2019 @ 18:25:
361 queries per seconde? Dat is inderdaad nogal veel.

Dat kun je zo niet zeggen zonder de queries nader te bestuderen. Het is op zichzelf geen reden voor een hoge load.

[Hero of Time]

Deze server luistert niet op z'n internet IP. Waar staat het precies? En na de update, heb je nog gecontroleerd of je configuratie niet alsnog is aangepast?
Wat draait er nog meer op? Kan je via SSH de server wel direct via het internet benaderen? Zie je logins van andere systemen komen op SSH in bijvoorbeeld audit.log? Welke gebruiker voert die select queries uit?

[M4RTiN]

Ik kan morgen uitgebreider antwoorden hoop ik.

Ik ben nog niet heel veel verder behalve:

Het probleem lijkt in principe heel erg hierop:
https://stackoverflow.com...hile-processlist-is-empty

Ik heb ook weinig in mijn proceslijst en toch een hoge load. Daarbij heb ik via strace gekeken wat mysql aan het doen is, en ik zie ook enorm vele FUTEX meldingen.

Qua gebruikers zie ik alleen actief de gebruiker ingelogd en doet query's die daarvoor bedoeld is.

Er staat geen SSH op internet, wel bereikbaar via VPN maar dit wordt niet misbruikt tot zover ik kan zien.

Als ik apache stop, zakt de load. Dit geeft dus te kennen dat het toch aan mijn script/systeem lijkt te liggen, en zou ik er simpelweg achter moeten komen welke pagina dan zo vaak wordt aangeroepen. (Helaas draai ik meerdere vhosts, waarbij ik dan nog voor elke vhost een access.log moet aanmaken, dit stond nog op de todo lijst).

pt-query-digest gaf me tot zover niet heel veel inzicht, ik kreeg het ook nog niet echt voor elkaar om het goed te gebruiken.

Ik had nog een tool mytop geinstalleerd, die geeft hetzelfde beeld als phpmyadmin; wel veel querys maar hij toont maar enkele query's die normaal zijn. Het lijkt net of het om handelingen gaat die niet echte query's zijn. (bijvoorbeeld alleen connectie opstarten en direct weer stoppen o.i.d.)

Ik weet helaas ook niet of de config gewijzigd is na de update, maar ik vermoed van niet. Ik kies zelf altijd dat ik de bestaande config wil handhaven.

Ik heb ook nog een volledige dump gemaakt van de database en die daarna direct weer geimporteerd, dit hielp ook niet.

mysql tool Repair all databases hielp ook niet

[ Voor 5% gewijzigd door M4RTiN op 27-06-2019 22:54 ]

[GlowMouse]

Pt-query-digest laat precies zien welke queries vaak draaien en welke queries langzaam zijn. Daar zou ik toch wat meer moeite in steken. Loop ook alle statusvariabelen eens door die MySQL bijhoudt.

[ Voor 18% gewijzigd door GlowMouse op 27-06-2019 23:05 ]

[Hero of Time]

Wat heb je in Apache draaien? Als daar PHP bij zit met connectie naar de database, is al je invoer wel veilig gemaakt? Kan je niet zomaar wat random queries uitvoeren via bekende lekken?

[M4RTiN]

Ik zal het uitzoeken en o.a. de binaire log uitlezen. Stel dat je gelijk hebt. Waarom is mijn proceslijst zo rustig? Wanneer ik zelf load genereer zie ik ze direct op de proceslijst komen.

Ik heb met netstat op adressen gefilterd op een rustig moment, terwijl de load op MySQL hoog was zag ik voornamelijk een paar bekende (meeste intern) ip adressen.

[CurlyMo]

Kan je eens wat meer vertellen over je database inrichting? Hoe groot zijn je tabellen (aantal rijen), welke query's draai je (graag voorbeelden)?

[M4RTiN]

Ik ben er achter wat het is. SHOW PROCESLIST is maar zo beknopt omdat query's te snel zijn voor zo'n moment opname.

Het probleem is een groter worden van de database + niet goed gebruik maken van optimalisatie en verkeerd en niet cachen van data in ons eigen geschreven applicatie. Als je database nog wat kleiner is dan geeft het allemaal niet zo veel.

In mijn geval ben ik als 18 jarige in 2002 begonnen met een soort orderadministratie pakket voor een printbedrijf. Dit programma heeft zich enorm ontwikkeld tot vrij geavanceerd pakket, het programmeren heb ik met behulp van deze community en internet mijzelf aangeleverd. Maar nooit met het oog op performance aangezien het niet nodig was. Het probleem is er echt ingeslopen zeg maar.

Inmiddels draait het pakket op 250 tabellen en ~2,573,835 rows, 13 CLI-PHP workers en 1 NodeJS server.

Verder doet de interne order/workflow applicatie nog veel requests om de 5 seconden om een status veld bij te werken en soms doet een specifieke module dit daarna ook om de 5 seconden om een werkwachtrijen bij te werken. Hier wordt nog niet gecached naar bijvoorbeeld een tijdelijk bestand zodat alle clients hiervan profiteren.

Ik heb de "zware" load weten terug te brengen door alles uit te zetten en stapsgewijs te kijken wat het deed met de load op de mysql server. CPU usage is nu 3 tot 4 procent.

1 van de grote boosdoeners is mijn relatief nieuw project waarbij een NodeJS server realtime berichten stuurt naar een TV scherm in de productie.

Kortom ik dacht dus dat de reden onbekend was door te vertrouwen op de mysql show proceslist functie, maar ik moet nog maar wat scholing hebben op het gebied van optimalisatie en de correct aangeraden tooltjes om mysql te reviewen op performance!

Bedankt voor het meedenken!

[ Voor 91% gewijzigd door M4RTiN op 28-06-2019 22:14 ]