Timeout bei Aufruf diverser Seiten via administrator.cgi

  • Im Einsatz ist v4.63 mit 6-0.354 - installiert über ein Reihenupgrade von Reihe 4 auf 6.


    Nach dem Upgrade gibt es derzeit Timeouts beim Aufruf diversen Seiten via administrator.cgi, z.B. Serverkonfiguration.


    Neben den bekannten Logs aus einem anderen Bugreport (Aborted connection) sehe ich keine Fehler.


    Ein SHOW FULL PROCESSLIST um auf Table Locks Hinweise zu bekommen zeigt, dass einige vadmin relevante Prozesse im Sleep mode sind - darunter auch immer jener, wenn

    ich z.B. die Serverkonfiguration öffne => daher kommt dann auch wohl der Timeout.


    1490260 vadmin localhost vadmin Sleep 26680 NULL
    1490265 vadmin localhost vadmin Sleep 26675 NULL
    1504718 vadmin localhost vadmin Sleep 19474 NULL
    1504719 vadmin localhost vadmin Sleep 19479 NULL
    1517383 vadmin localhost vadmin Sleep 12276 NULL
    1517388 vadmin localhost vadmin Sleep 12279 NULL
    1534922 vadmin localhost vadmin Sleep 5075 NULL
    1534925 vadmin localhost vadmin Sleep 5079 NULL
    1535641 vadmin localhost vadmin Sleep 5 NULL
    1545130 vadmin localhost vadmin Sleep 153 NULL
    1545215 root localhost NULL Query 0 starting SHOW FULL PROCESSLIST
    1545216 root localhost NULL Sleep 0 NULL


    Ein SHOW ENGINE INNODB STATUS liefert den Output im Anhang.



    Welche Logs könnten für die Fehlersuche noch hilfreich sein?


    Besten Dank.

  • Die vadmin Prozesse mit dem Command sleep und dem state NULL deuten auf offene und nicht geschlossenen Verbindungen hin. Bei häufiger Ausführung könnte man so an das Verbindungslimit von MySQL kommen, was in einen Timeout resultiert.


    Ich würde daher einmal max_connection, wait_timeout und interactive_timeout anschauen und ggf. die Werte anpassen.


    Hilfreich bei einer Analyse können auch Skripte wie MySQL Tuner sein.

  • Danke für den Hinweis, MySQL Tuner kenne ich und ist bereits im Einsatz.


    Dennoch ist das eine Vanilla mysql 5.7 Konfiguration aus pd-admin heraus, daher verstehe ich nicht ganz

    warum es hier bei Requests zur pd-admin Oberfläche via administrator.cgi zu Timeouts kommt.


    Ich werde weiter analysieren und ein Update geben sobald ich eines habe.

  • Im anderen Thread war

    Derzeit habe ich bei einige Seiten (zB Serverkonfiguration...) ein Timeout - und damit ist die Verwendung eigentlich nicht mehr wirklich gegeben:


    [Thu May 07 20:31:53.522103 2020] [cgid:error] [pid 6164] [client 80.110.117.225:15097] Script timed out before returning headers: administrator.cgi, referer: https://xxx/administrator/sid/…ministrator.cgi?todo=main

    angegeben.


    Naheliegend wäre, dass sich die offenen Verbindungen aufstauen. Bei Aufruf von der administrator.cgi wird dann auf eine freie Verbindung gewartet, bis dann schließlich der Prozess an das konfigurierte RLIMIT_CPU in der httpd.conf stößt und mit o.g. Fehler beendet wird. Man sieht an der Prozessausgabe auch, dass die Verbindungen bis zu 26680 Sekunden bestehen.

    1490260 vadmin localhost vadmin Sleep 26680 NULL

    Dies sind rund 7 Stunden. Der Standardwert bei MySQL für die Timeouts (wait_timeout + interactive_timeout) ist 8 Stunden - ein viel zu hoher Wert wie ich finde.


    Da sich max_connections auch auf den RAM Vebrauch auswirkt, sollte der Wert nur erhöht werden, wenn entsprechend Ressourcen zur Verfügung stehen.


    Von einer Erhöhung von RLIMIT_CPU beim Apache würde ich sogar abraten. Ein höherer Wert würde mehr Probleme bereits als tatsächlich lösen.


    Ich würde daher die Werte für wait_timeout und interactive_timeout deutlich reduzieren und das Verhalten beobachten.

  • Besten Dank für die Infos.


    Ich habe neben wait_timeout und interactive_timeout auch noch ein paar andere InnoDB Optimierungen

    vorgenommen (verwende ausschließlich InnoDB hier), die in Richtung caching und buffer sizes abzielen und

    werde dies weiter beobachten.

  • Das ist jetzt etwas offtopic, aber passt gerade in den thread. Wie nutzt du mysqltuner.pl?
    Ich bekomme immer folgendes:


    perl mysqltuner.pl --user root --pass xxxxxx --mysqladmin /usr/local/pd-admin2/bin/mysqladmin

    >> MySQLTuner 1.7.19 - Major Hayden <major@mhtx.net>

    >> Bug reports, feature requests, and downloads at http://mysqltuner.com/

    >> Run with '--help' for additional options and output filtering


    [--] Skipped version check for MySQLTuner script

    [!!] Couldn't find mysqladmin in your $PATH. Is MySQL installed?

  • Der Fehler ist, dass mysqladmin nicht gefunden wird. Offenbar fehlt


    /usr/local/pd-admin2/bin


    bei Ihnen in der PATH Variable. Ich habe dazu irgendwann auf meinem Server

    Bash
    cat /etc/environment
    PATH="/usr/local/pd-admin2/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

    angelegt. Auch habe ich

    Bash
    cat /root/.my.cnf
    [client]
    socket=/usr/local/pd-admin2/var/mysql.run/mysql.sock
    user=root
    password=
    ls -al .my.cnf
    -rw-------. 1 root root 90 14. Apr 20:11 .my.cnf

    angelegt, damit das Skript ohne Angabe der Login Daten ausgeführt werden kann.

  • Im November letzten Jahres hatte ich wegen einer my.cnf Optimierung schon mal einen Post geöffnet.

    Performance mySQL 5.7 in SE Reihe6


    Aber da bin ich nicht weiter gekommen. Der vadmin-Timeout kommt auch mit der dort von mir verwendeten Einstellung.


    Der mysqltuner.pl liefert auf einem neu installierten PD-Admin auf centos81 folgende Empfehlungen:

    -------- Recommendations ---------------------------------------------------------------------------

    General recommendations:

    Control warning line(s) into /usr/local/pd-admin2/var/mysql/server10.err file

    Control error line(s) into /usr/local/pd-admin2/var/mysql/server10.err file

    When making adjustments, make tmp_table_size/max_heap_table_size equal

    Reduce your SELECT DISTINCT queries which have no LIMIT clause

    Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: https://bit.ly/2TcGgtU

    Variables to adjust:

    query_cache_size (=0)

    query_cache_type (=0)

    query_cache_limit (> 1M, or use smaller result sets)

    tmp_table_size (> 16M)

    max_heap_table_size (> 16M)

    innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

  • Sowohl die o.g. Werte, als auch die aus dem anderen Thread beeinflussen ja nicht Timeouts in MySQL.

    Das Skript analysiert auch nur das MySQL Log. Dort treten ja keine Fehler auf, sondern der Fehler tritt im Apache Log auf. Und der Fehler ist, dass das Skript beendet wurde, bevor es eine Rückmeldung gab. Und da gilt es anzusetzen...


    Vielleicht hilft dies ja:


    https://dev.mysql.com/doc/refm…communication-errors.html


    Oder Mal die vadmin Tabellen auf Fehler überprüft?

  • Besten Dank Herr Bradler ich werde dies untersuchen.


    Derzeit ist es aber so, dass nach einem Neustart des MySQL Servers diese Seiten eine Zeit lang aufgerufen werden können, dann aber wieder dasselbe Problem auftritt.


    Auf diesem Server laufen einige Projekte, die MySQL verwenden. Keines davon weist abnormales Verhalten, hinsichtlich Timeouts oder höherer Latenz bei Requests auf. Lediglich pd-admin macht hier in der Admin Oberfläche Probleme mit diesem Verhalten.