Unterschied default config mysql <> mariadb

etron770 · 4. Apr. 2019

nachdem Debian mit Stretch auf Mariadb gewechselt hat kommt bei manchmal bei diversen Drupal Seiten:
General error: 2006 MySQL server has gone away

die gleichen Seiten auf einer alten Jessie Installation laufen ohne Probleme

Weiß jemand, was der Unterschied bei der default config zwischen den beiden Systemen ist, bzw wie ich am schnellsten finden kann warum das so ist.
Alles was ich bisher gefunden habe bringt keine Abhilfe, zumal dieser Fehler nur Sporadisch auftritt, das nachvollziehen also schwierig ist.
Lagere ich Datenbanken der Seiten auf einen reinen Mysql Server aus, so geht es gut, solange nicht zu viele Seiten darauf zugreifen.
Aber auf jessie ging das auf dem Webserver mit viel mehr Datenbanken im System

Till · 4. Apr. 2019

nichts dazu in den mysql logs oder im syslog? Vielleicht einfach nur max connections erreicht? ich nutze seit einigen Jahren nur noch MariaDB und habe keine Probleme damit auf meinen Servern.

etron770 · 4. Apr. 2019

Das Problem sind meines Erachtens die Drupal Installationen die nicht immer optimierte Datenbankzugriffe haben.
Da habe ich aber keinen Einfluss drauf.

Netzwerk-Datenverkehr seit Start: 588 GiB
Dieser MySQL-Server läuft bereits 36 Tage, 5 Stunden, 27 Minuten und 25 Sekunden. Er wurde am 27. Feb 2019 um 08:39 gestartet.

Netzwerkverkehr	#	ø pro Stunde
Empfangen	68,6 GiB	80,8 MiB
Gesendet	519,4 GiB	611,7 MiB
Insgesamt	588 GiB	692,5 MiB

Verbindungen	#	ø pro Stunde	%
Max. gleichzeitige Verbindungen	15	---	---
Fehlversuche	476	0,55	0,19%
Abgebrochen	235	0,27	0,10%
Insgesamt	246 k	283,37	100,00%

max_open_files ist 1048576

Aborted clients 39,2 k
Aborted connects 280
Binlog cache disk use 235
Created tmp disk tables 242,3 k
Handler read rnd 417,1 k
Handler read rnd next 43,1 M
Innodb buffer pool reads 55 k
Innodb row lock time avg 36
Innodb row lock time max 3,7 k
Innodb row lock waits 841
Opened tables 14,4 k
Qcache lowmem prunes 1,3 M
Select full join 3,6 k
Slow queries 441,8 k
Table locks waited 76

Till · 4. Apr. 2019

Zitat von etron770:
Das Problem sind meines Erachtens die Drupal Installationen die nicht immer optimierte Datenbankzugriffe haben.

Das sollte kein Problem darstellen, MariaDB ist meines Erachtens nicht weniger leistungsfähig als MySQL. Ich kenne viele ISP die MariaDB als Standard einsetzen.

Und Du hast keine weiteren fehlermeldunegn in den logs?

etron770 · 4. Apr. 2019

Ich muss mal warten bis es wieder auftritt. Leider kann ich es nicht auslösen.
eine Meldung ist z.B die kam seit mindestens 28 März alle 5 Minunten, was das ausgelöst hat weiss ich nicht. Da hören die syslog auf.

Code:

 postfix/proxymap[31467]: warning: mysql query failed: MySQL server has gone away
Apr  4 16:00:01 web12 postfix/trivial-rewrite[32451]: warning: virtual_mailbox_domains: proxy:mysql:/etc/postfix/mysql-virtual_domains.cf: table lookup problem
Apr  4 16:00:01 web12 postfix/proxymap[31467]: warning: mysql query failed: MySQL server has gone away
Apr  4 16:00:01 web12 postfix/trivial-rewrite[32451]: warning: proxy:mysql:/etc/postfix/mysql-virtual_transports.cf lookup error for "root@xyt.de"

Es fällt aber auch nicht auf, wenn kleine Webseiten die Datenbank abfragen. Deshalb habe ich auch die Syslogs nicht angeschaut. Heute habe ich Wartung an einer großen Webseite durchführt, die auch long-queries auslöst, und die hing dann.
Nach einem Neustart von Mysql ist alles wieder OK.
Ich such da schon seit Wochen :-(

Till · 4. Apr. 2019

Das schon versucht?

https://matomo.org/faq/troubleshooting/faq_183/

etron770 · 5. Apr. 2019

Zitat von Till:
Das schon versucht?

Ich hab schon etliches probiert, da hab ich den Überblick verloren. ich probiere es noch mal.

Nur um das zu verstehen, was bedeutet "Mysql Server has gone away"?
Ist das temporär für die jeweilige Anfrage, gibt es Mechanismen bei MariaDB den Server automatisch wieder zu aktivieren/neu zu starten?
Was ich dabei nicht verstehe ist dass nicht alle Anfragen scheitern. Aber nach dem Neustart der DB alles wieder läuft.

Es scheint auch ein Zusammenhang mit der Häufigkeit des Isp Cronjobs server.sh zu geben. Wenn ich ihn alle Minute ausführen lasse hängt die DB öfter, als wenn ich ihn alle 10 Minuten ausführen lasse.
Insgesamt ist der Server wenig ausgelastet Top zeigt max 0.5 bei einer 6/2 Kerne Cpu, Swap tritt nicht auf

etron770 · 5. Apr. 2019

Zitat von etron770:
Ich hab schon etliches probiert, da hab ich den Überblick verloren. ich probiere es noch mal.
Seit dem Neustart gestern läuft wieder alles und ich kann es nicht prüfen. gibt es irgend Belastungstest für DB Server?

Nur um das zu verstehen, was bedeutet "Mysql Server has gone away"?
Ist das temporär für die jeweilige Anfrage, gibt es Mechanismen bei MariaDB den Server automatisch wieder zu aktivieren/neu zu starten?
Was ich dabei nicht verstehe ist dass nicht alle Anfragen scheitern. Aber nach dem Neustart der DB alles wieder läuft.

Es scheint auch ein Zusammenhang mit der Häufigkeit des Isp Cronjobs server.sh zu geben. Wenn ich ihn alle Minute ausführen lasse hängt die DB öfter, als wenn ich ihn alle 10 Minuten ausführen lasse.
Insgesamt ist der Server wenig ausgelastet Top zeigt max 0.5 bei einer 6/2 Kerne Cpu, Swap tritt nicht auf

etron770 · 5. Apr. 2019

Ergänzung: Mit sysbench hatte ich es probiert:

Code:

sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --mysql-password=yourrootsqlpassword --max-time=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run

Da war dann in top mysql mit knapp 400% CPU trotzdem hat sich der DB Server nicht aufgehängt
ein

Code:

sysbench –test=fileio –file-total-size=20G prepare
sysbench --test=fileio --file-total-size=20G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run

gibt (bei prepare
top - 09:25:43 up 43 days, 13:22, 2 users, load average: 11,09, 5,76, 2,68
Tasks: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3,3 us, 2,5 sy, 0,0 ni, 65,1 id, 29,1 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem : 12582912 total, 4997104 free, 3091788 used, 4494020 buff/cache
KiB Swap: 4194304 total, 3762576 free, 431728 used. 9491124 avail Mem

Wenn ich dann noch so viel wie möglich Webseiten aufrufe komme ich eventuell auf 50% id und 60wa Aber die DB bekomme ich nicht in den gone away status.

etron770 · 5. Apr. 2019

Ergebnisse (beide Tests paralell:

Code:

sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root
--mysql-password=xyz --max-time=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

No DB drivers specified, using mysql
Running the test with following options:
Number of threads: 8

Doing OLTP test.
Running mixed OLTP test
Doing read-only test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Threads started!
Time limit exceeded, exiting...
(last message repeated 7 times)
Done.

OLTP test statistics:
    queries performed:
        read:                            839090
        write:                           0
        other:                           119870
        total:                           958960
    transactions:                        59935  (998.84 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 839090 (13983.69 per sec.)
    other operations:                    119870 (1997.67 per sec.)

Test execution summary:
    total time:                          60.0049s
    total number of events:              59935
    total time taken by event execution: 479.7672
    per-request statistics:
         min:                                  1.69ms
         avg:                                  8.00ms
         max:                                618.84ms
         approx.  95 percentile:               9.90ms

Threads fairness:
    events (avg/stddev):           7491.8750/58.84
    execution time (avg/stddev):   59.9709/0.00

Code:

 sysbench --test=fileio --file-total-size=20G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from timer.


Extra file open flags: 0
128 files, 160Mb each
20Gb total file size
Block size 16Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  25364 Read, 16909 Write, 54016 Other = 96289 Total
Read 396.31Mb  Written 264.2Mb  Total transferred 660.52Mb  (2.2017Mb/sec)
  140.91 Requests/sec executed

Test execution summary:
    total time:                          300.0041s
    total number of events:              42273
    total time taken by event execution: 293.1294
    per-request statistics:
         min:                                  0.00ms
         avg:                                  6.93ms
         max:                               1223.32ms
         approx.  95 percentile:              25.83ms

Threads fairness:
    events (avg/stddev):           42273.0000/0.00
    execution time (avg/stddev):   293.1294/0.00

etron770 · 5. Apr. 2019

Zitat von Till:
nichts dazu in den mysql logs oder im syslog? Vielleicht einfach nur max connections erreicht? ich nutze seit einigen Jahren nur noch MariaDB und habe keine Probleme damit auf meinen Servern.

ja habe schon lange geändert, die Werte sind:
wait_timeout = 28800 # could cause problems if too strict (default: 28800) war 180
innodb_log_file_size = 512M
max_allowed_packet = 512M

Unterschied default config mysql <> mariadb

etron770

Member

Till

Administrator

etron770

Member

Till

Administrator

etron770

Member

Till

Administrator

etron770

Member

etron770

Member

etron770

Member

etron770

Member

etron770

Member

Werbung

Wir schützen deine Privatsphäre