7
Prozesse auf MySql-Server hängen, CPU-Auslastung bei Null
Hallo,
wir haben in der Firma Probleme mit der MySql-DB (Version 5.1.57 oder auch 5.1.46) bei einem Kunden.
Nach unbestimmter Zeit (1 bis 2 mal täglich, häufig mittags) überfrisst sich die Dantenbank, alle möglichen Abfragen bleiben hängen, aber die CPU- und die Speicherauslastung des mysqld-Prozesses liegen bei Null. Nach einem Server-Neustart ist erstmal alles wieder ok.
Wir nutzen die innodb-Engine für fast alle Tabellen (rund 500). Es sind ca. 40 User im Programm, jeder hat dabei ca. 3-5 Connections offen, teils mehr..., die DB ist ca. 8 GB groß.
Die Datenbank läuft auf einem Linux-Server...und wir haben schon verschiedene Linux-Versionen auf unterschiedlicher Hardware probiert.
Wir haben nun den Server getauscht und die gleiche Konstellation von Linux- und Mysql-Version und my.cnf-Einstellungen verwendet, wie bei einem anderen Kunden, bei dem die Datenbank doppelt so groß ist und der mit doppelt sovielen Usern arbeitet und noch nie dieses Problem hatte... das Ergebenis ist aber das selbe.
Wir haben auch schon ein Programm eingesetzt, das die Netzlast prüft...alles in Ordnung. Auch das slow-query-log haben wir ausgewertet...nichts konkretes gefunden.
Die Daten wurden gerade noch raus- und reingedumpt, sollten also frisch reorganierst sein.
Hat jemand eine Idee was das sein kann?
Können sich bestimmte Abfragen gegenseitig blockieren, so dass dann alles hängt?
wir haben in der Firma Probleme mit der MySql-DB (Version 5.1.57 oder auch 5.1.46) bei einem Kunden.
Nach unbestimmter Zeit (1 bis 2 mal täglich, häufig mittags) überfrisst sich die Dantenbank, alle möglichen Abfragen bleiben hängen, aber die CPU- und die Speicherauslastung des mysqld-Prozesses liegen bei Null. Nach einem Server-Neustart ist erstmal alles wieder ok.
Wir nutzen die innodb-Engine für fast alle Tabellen (rund 500). Es sind ca. 40 User im Programm, jeder hat dabei ca. 3-5 Connections offen, teils mehr..., die DB ist ca. 8 GB groß.
Die Datenbank läuft auf einem Linux-Server...und wir haben schon verschiedene Linux-Versionen auf unterschiedlicher Hardware probiert.
Wir haben nun den Server getauscht und die gleiche Konstellation von Linux- und Mysql-Version und my.cnf-Einstellungen verwendet, wie bei einem anderen Kunden, bei dem die Datenbank doppelt so groß ist und der mit doppelt sovielen Usern arbeitet und noch nie dieses Problem hatte... das Ergebenis ist aber das selbe.
Wir haben auch schon ein Programm eingesetzt, das die Netzlast prüft...alles in Ordnung. Auch das slow-query-log haben wir ausgewertet...nichts konkretes gefunden.
Die Daten wurden gerade noch raus- und reingedumpt, sollten also frisch reorganierst sein.
Hat jemand eine Idee was das sein kann?
Können sich bestimmte Abfragen gegenseitig blockieren, so dass dann alles hängt?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 239943
Url: https://administrator.de/contentid/239943
Printed on: April 24, 2024 at 20:04 o'clock
7 Comments
Latest comment
Hallo,
Infos zur Software?
Grüße,
Christian
Infos zur Software?
Grüße,
Christian
1
Hallo Christian,
wir entwickeln mit Delphi 7 und nutzen für den Zugriff auf MySql die MyDac-Komponenten von devart.
Es wird eine Exe gestartet die eine Standard-Connection aufbaut. Übers Menü werden dann DLLs gestartet, die jeweils eine eigene Connection aufbauen, damit die Transaktionen getrennt gehandelt werden können. Es werden meist komplexe Datenbankabfragen gestartet, die mit einem Befehl mehrere Datensätze lesen und/oder ändern...
Gruß,
Bernd
wir entwickeln mit Delphi 7 und nutzen für den Zugriff auf MySql die MyDac-Komponenten von devart.
Es wird eine Exe gestartet die eine Standard-Connection aufbaut. Übers Menü werden dann DLLs gestartet, die jeweils eine eigene Connection aufbauen, damit die Transaktionen getrennt gehandelt werden können. Es werden meist komplexe Datenbankabfragen gestartet, die mit einem Befehl mehrere Datensätze lesen und/oder ändern...
Gruß,
Bernd
Hallo Bernd,
dann hast du zumindestens rein theoretisch immer die Problematik, dass es eine komplexe Abfrage zu viel ist. Dann hast du natürlich auch keine hohe Datenlast mehr, wenn sie das Konstrukt kaputt gemacht hat - u.a kann dies natürlich (ohne Einsicht in die SW zu haben) daran liegen, dass Kunde A andere Funktionen nutzt als Kunde b (ist üblich, solange das Programm nicht nur einen "Drück mich Button" beinhaltet).
Grüße,
Christian
dann hast du zumindestens rein theoretisch immer die Problematik, dass es eine komplexe Abfrage zu viel ist. Dann hast du natürlich auch keine hohe Datenlast mehr, wenn sie das Konstrukt kaputt gemacht hat - u.a kann dies natürlich (ohne Einsicht in die SW zu haben) daran liegen, dass Kunde A andere Funktionen nutzt als Kunde b (ist üblich, solange das Programm nicht nur einen "Drück mich Button" beinhaltet).
Grüße,
Christian
1
Hallo,
Du solltest uns eventuell einmal mitteilen wie es denn Hardware seitig bei Euch
und dem Kunden aussieht, also dort wo die Probleme herkommen.
Und dann eventuell noch wie die Hardwareausstattung aussieht bei den
Kunden die keine Probleme haben.
Ich meine mit Hardware die der Server und des Netzwerks.
Eventuell könnte man einmal die HHDs checken ob immer wieder zur selben zeit ein defekter
Sektor auf einer HDD erreicht wird und dann gibt es eben Probleme.
Oder aber wenn alle Eure 40 Leute mittags zu Tisch gehen wollen und dann alle offenen
Verbindungen (Connections) speichern oder schließen.
Arbeitet Ihr irgend wo mit Quotas auf dem Server?
- Der wenige RAM läuft einfach voll
- Kein EEC RAM und es passieren Speicherfehler
- Defekter RAM und es wird mittags genau der fehlerhafte Punkt erreicht
- Die /tmp Partitionen läuft über
- zu wenig oder zu kleine /swap Partitionen bzw. an den falschen Stellen
- zu wenig HDDs verbaut und zu wenig IOPS
- eine andere Partition läuft "über"
- zu langsame HDDs verbaut
- Nur ein RAID1 für alles genommen
- Zu wenig RAID Level angelegt
- Kein RAID Controller Cache Modul installiert
- Software RAID und zu wenig performante Hardware
- langsame SATA statt SAS HDDs
- Switche zu langsam oder zu alt
- Server nicht via LAG (LACP) angebunden und nun kommt es zu Engpässen
- Fehlerhafter oder beschädigter ELKO auf dem Mainboards und Mittags wird es zu heiß
- Gehäuse nicht genug belüftet und es wird gedrosselt weil interne Geräte zu heiß werden und Sensoren drosseln
- Spannungsabfall bei Euch (Dorf oder Land) in der Mittagszeit weil alle Herde angehen und Ihr habt einen Spannungsabfall bzw. keine USVs
Gruß
Dobby
Du solltest uns eventuell einmal mitteilen wie es denn Hardware seitig bei Euch
und dem Kunden aussieht, also dort wo die Probleme herkommen.
Und dann eventuell noch wie die Hardwareausstattung aussieht bei den
Kunden die keine Probleme haben.
Ich meine mit Hardware die der Server und des Netzwerks.
Hat jemand eine Idee was das sein kann?
Nicht genügend IOPS schließe ich hier aus, das es sonst schleppend läuft aber eben läuft!Eventuell könnte man einmal die HHDs checken ob immer wieder zur selben zeit ein defekter
Sektor auf einer HDD erreicht wird und dann gibt es eben Probleme.
Oder aber wenn alle Eure 40 Leute mittags zu Tisch gehen wollen und dann alle offenen
Verbindungen (Connections) speichern oder schließen.
Arbeitet Ihr irgend wo mit Quotas auf dem Server?
Können sich bestimmte Abfragen gegenseitig blockieren, so dass dann alles hängt?
Das kann so wie Du es uns schilderst fast alles sein und dann doch wieder nichts!- Der wenige RAM läuft einfach voll
- Kein EEC RAM und es passieren Speicherfehler
- Defekter RAM und es wird mittags genau der fehlerhafte Punkt erreicht
- Die /tmp Partitionen läuft über
- zu wenig oder zu kleine /swap Partitionen bzw. an den falschen Stellen
- zu wenig HDDs verbaut und zu wenig IOPS
- eine andere Partition läuft "über"
- zu langsame HDDs verbaut
- Nur ein RAID1 für alles genommen
- Zu wenig RAID Level angelegt
- Kein RAID Controller Cache Modul installiert
- Software RAID und zu wenig performante Hardware
- langsame SATA statt SAS HDDs
- Switche zu langsam oder zu alt
- Server nicht via LAG (LACP) angebunden und nun kommt es zu Engpässen
- Fehlerhafter oder beschädigter ELKO auf dem Mainboards und Mittags wird es zu heiß
- Gehäuse nicht genug belüftet und es wird gedrosselt weil interne Geräte zu heiß werden und Sensoren drosseln
- Spannungsabfall bei Euch (Dorf oder Land) in der Mittagszeit weil alle Herde angehen und Ihr habt einen Spannungsabfall bzw. keine USVs
Gruß
Dobby
Wenn so komplexe Anfragen der Clients generiert werden, dann würd ich mir über das DB Design Gedanken machen.
Mit ein paar Views wirds dann gleich leichter und der DB Server hat nicht mehr so den Stress.
Die Tipps vom Dobby bzgl. HW sind auch zum Ansehen.
Mit ein paar Views wirds dann gleich leichter und der DB Server hat nicht mehr so den Stress.
Die Tipps vom Dobby bzgl. HW sind auch zum Ansehen.
1
Hallo,
das Problem scheint gelöst, wir verwenden jetzt MariaDB.
Beim alten MySql-Stand war die Datenbank mit den vielen Threads überfordert und hat diese dann, jede ein bisschen, langsam verarbeitet. Die Bediener unseres Programms sind ungeduldig geworden, haben das Programm abgebrochen und neu gestartet. Beim Neustart allein wurden dann schon wieder zig Connections aufgemacht, weil die Bediener jede Megen Module im Autostartbereich unseres Programms hatten. Fast alle Module haben einen Browser vorgeschaltet, der mindestens 50 Datensätze einliest und im Hintergrund den Rest nachliest. Einige Bediener haben das Programm dann auch gleich mehrfach gestartet, damit sie parallel in verschiedenen Mandanten arbeiten können. Damit haben sie mal eben allein 30 Connections aufgemacht... Das heißt, wenns schon langsam war, dann wurde das System komplett ausgebremst.
Also am Datenbankdesign lag es nicht und der Server langweilte sich, wie gesagt. Wir haben den Usern erstmal die Autostart-Module in die Favoriten geschoben, sie müssen diese nun von Hand starten, damit ist bis jetzt der große Hänger ausgeblieben.
Ich versuche schon lange meinen Kollegen bei zu bringen, dass es keinen Sinn macht, beim Start eines Moduls erstmal Daten zu lesen, die man eigenlich gar nicht braucht...aber man kann dann ja gleich auf jede Spalte filtern...
Damit das Programm erstmal so bleiben kann setzen wir nun MariaDB ein.
Beim neuen MariaDB wurde threadpooling eingeführt.. und nun siehe da, wir kriegen kein Aufhängen/Ausbremsen mehr hin. Beim Test haben wir die CPU-Last auf 400% gekriegt, aber der Server hat 24 Kerne...er langweilt sich weiter.
Vielen Dank für die Unterstützung
das Problem scheint gelöst, wir verwenden jetzt MariaDB.
Beim alten MySql-Stand war die Datenbank mit den vielen Threads überfordert und hat diese dann, jede ein bisschen, langsam verarbeitet. Die Bediener unseres Programms sind ungeduldig geworden, haben das Programm abgebrochen und neu gestartet. Beim Neustart allein wurden dann schon wieder zig Connections aufgemacht, weil die Bediener jede Megen Module im Autostartbereich unseres Programms hatten. Fast alle Module haben einen Browser vorgeschaltet, der mindestens 50 Datensätze einliest und im Hintergrund den Rest nachliest. Einige Bediener haben das Programm dann auch gleich mehrfach gestartet, damit sie parallel in verschiedenen Mandanten arbeiten können. Damit haben sie mal eben allein 30 Connections aufgemacht... Das heißt, wenns schon langsam war, dann wurde das System komplett ausgebremst.
Also am Datenbankdesign lag es nicht und der Server langweilte sich, wie gesagt. Wir haben den Usern erstmal die Autostart-Module in die Favoriten geschoben, sie müssen diese nun von Hand starten, damit ist bis jetzt der große Hänger ausgeblieben.
Ich versuche schon lange meinen Kollegen bei zu bringen, dass es keinen Sinn macht, beim Start eines Moduls erstmal Daten zu lesen, die man eigenlich gar nicht braucht...aber man kann dann ja gleich auf jede Spalte filtern...
Damit das Programm erstmal so bleiben kann setzen wir nun MariaDB ein.
Beim neuen MariaDB wurde threadpooling eingeführt.. und nun siehe da, wir kriegen kein Aufhängen/Ausbremsen mehr hin. Beim Test haben wir die CPU-Last auf 400% gekriegt, aber der Server hat 24 Kerne...er langweilt sich weiter.
Vielen Dank für die Unterstützung
