MySQL zwingt Server in die Knie

Surfme2

New Member
Hallo,

ich weiß echt nicht mehr weiter.
Seit dem ich von Debian 4.0 auf einen neuen Server mit Debian 5.0 umgestiegen bin treibt der MySQL-Server mich in den Wahnsinn.

Schaut euch das bitte mal an, das ist von gerade eben
(mySQL Querys by Day)

Solche Query-Spitzen hab ich immer wieder und sie treiben meinen Server in die Knie.
MySQL ist in der Version: 5.0.51a-24+lenny4 installiert.

Auf dem alten Server war das nie ein Problem.

Ich weiß auch, das die Zugriffe von Bots verursacht werden. Leider kann ich die Bots nicht aussperren. Da diese die Seite ja durchsuchen sollen.

Hier mal die my.cnf die ich aktuell benutze:
PHP:
    #
    # The MySQL database server configuration file.
    #
    # You can copy this to one of:
    # - "/etc/mysql/my.cnf" to set global options,
    # - "~/.my.cnf" to set user-specific options.
    #
    # One can use all long options that the program supports.
    # Run program with --help to get a list of available options and with
    # --print-defaults to see which it would actually understand and use.
    #
    # For explanations see
    # http://dev.mysql.com/doc/mysql/en/server-system-variables.html

    # This will be passed to all mysql clients
    # It has been reported that passwords should be enclosed with ticks/quotes
    # escpecially if they contain "#" chars...
    # Remember to edit /etc/mysql/debian.cnf when changing the socket location.
    [client]
    port        = 3306
    socket        = /var/run/mysqld/mysqld.sock

    # Here is entries for some specific programs
    # The following values assume you have at least 32M ram

    # This was formally known as [safe_mysqld]. Both versions are currently parsed.
    [mysqld_safe]
    socket        = /var/run/mysqld/mysqld.sock
    nice        = 0

    [mysqld]
    #
    # * Basic Settings
    #
    user        = mysql
    pid-file    = /var/run/mysqld/mysqld.pid
    socket        = /var/run/mysqld/mysqld.sock
    port        = 3306
    basedir        = /usr
    datadir        = /var/lib/mysql
    tmpdir        = /tmp
    language    = /usr/share/mysql/english
    set-variable = max_connections=200
    #set global
    set-variable = interactive_timeout=100
    set-variable    = wait_timeout=100


    #set-variable = tmp_table_size=0
    #skip-external-locking
    #
    # Instead of skip-networking the default is now to listen only on
    # localhost which is more compatible and is not less secure.
    #bind-address        = 127.0.0.1
    #
    # * Fine Tuning
    #
    key_buffer        = 24M
    max_allowed_packet    = 12M
    thread_stack        = 128K
    thread_cache_size    = 4
    # This replaces the startup script and checks MyISAM tables if needed
    # the first time they are touched
    myisam-recover        = BACKUP
    #max_connections        = 100
    table_cache            = 128000
    #thread_concurrency     = 10
    #
    # * Query Cache Configuration
    #
    query_cache_limit       = 2M
    query_cache_size        = 24M
    join_buffer_size       = 512K
    max_heap_table_size = 32M
    tmp_table_size = 32K
    low_priority_update=1
    concurrent_insert=2
    #
    # * Logging and Replication
    #
    # Both location gets rotated by the cronjob.
    # Be aware that this log type is a performance killer.
    #log        = /var/log/mysql/mysql.log
    #
    # Error logging goes to syslog. This is a Debian improvement :)
    #
    # Here you can see queries with especially long duration
    #log_slow_queries    = /var/log/mysql/mysql-slow.log
    #long_query_time = 2
    #log-queries-not-using-indexes
    #
    # The following can be used as easy to replay backup logs or for replication.
    # note: if you are setting up a replication slave, see README.Debian about
    #       other settings you may need to change.
    #server-id        = 1
    #log_bin            = /var/log/mysql/mysql-bin.log
    expire_logs_days    = 10
    max_binlog_size      = 100M
    #binlog_do_db        = include_database_name
    #binlog_ignore_db    = include_database_name
    #
    # * BerkeleyDB
    #
    # Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
    skip-bdb
    #
    # * InnoDB
    #
    # InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
    # Read the manual for more InnoDB related options. There are many!
    # You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
    #skip-innodb
    innodb_buffer_pool_size = 3296M
    #
    # * Security Features
    #
    # Read the manual, too, if you want chroot!
    # chroot = /var/lib/mysql/
    #
    # For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
    #
    # ssl-ca=/etc/mysql/cacert.pem
    # ssl-cert=/etc/mysql/server-cert.pem
    # ssl-key=/etc/mysql/server-key.pem



    [mysqldump]
    quick
    quote-names
    max_allowed_packet    = 16M

    [mysql]
    #no-auto-rehash    # faster start of mysql but no tab completition

    [isamchk]
    key_buffer        = 16M

    #
    # * NDB Cluster
    #
    # See /usr/share/doc/mysql-server-*/README.Debian for more information.
    #
    # The following configuration is read by the NDB Data Nodes (ndbd processes)
    # not from the NDB Management Nodes (ndb_mgmd processes).
    #
    # [MYSQL_CLUSTER]
    # ndb-connectstring=127.0.0.1


    #
    # * IMPORTANT: Additional settings that can override those from this file!
    #   The files must end with '.cnf', otherwise they'll be ignored.
    #
    !includedir /etc/mysql/conf.d/

Vielleicht kann mir einer von euch sagen, was ich falsch mache bzw wie ich es verhindern kann, das der Server in die Knie geht.
Der Server selber hat einen Intel® Core™ i7-920 Quad-Core mit 12 GB Ram. Der alte Server war weit weniger gut und hat das trotzdem problemlos gemeistert.

Vielen Dank für eure Hilfe schonmal

Gruss
 

Attachments

  • localhost.localdomain-mysql_queries-day.png
    localhost.localdomain-mysql_queries-day.png
    20.9 KB · Views: 247
die entsprechende Ausgabe kann ich erst in ein paar Stunden posten, da ich vorhin die Datenbank nochmal neu gestartet hatte und somit die 48h Frist nochmal unterbrochen habe die ich benötige um sinnvolles hier posten zu können

reiche ich aber nach :)
 
vielen dank
den habe ich jedoch schon mehrfach ausgeführt und das Problem besteht dennoch ...

Das Problem wird sich durch reines ausführen des Programms nicht beheben lassen! :) Mysqltuner sagt Dir aber, welche Einstellungen nicht sinnvoll sind, und was Du im ersten Step besser machen kannst.

Grüsse
Basti
 
Wir hatten letztens einen vergleichbares Problem. Hier haben Bots auf einem Webkatalog die Kommentarfunktion misbraucht und dort ca. 50000 Kommentare gespamt. Das Problem war, dass beim aufrufen einer Unterseite nicht nur ein Teil der Kommentare angezeigt wurde sondern alle zu dem Thema geposteten Kommentare. Die Webseite an sich hat am Tag ca. 3000 - 5000 Besucher. Jeder Besucher hat also ca. 200 - 300 MySQL Querys ausgeführt, was zu einem Load von 20 geführt hat und zu einer überlastung des Serversystems.

Einzige produktive Lösung hier war das löschen der spam Postings und das optimieren der Webseite.

Die Anzahl der MySQL Querys kannst du über PHPMyAdmin herausfinden, dann kannst du sehen, wieviele Abfragen auf den MySQL Server einprügeln. PHPMyAdmin führt hier eine sehr gute Statistik. Die beste Optimierung hilft hier aber nur bedingt weiter und ob der MySQL Server auf Debian 4 oder Debian 5 läuft spielt hier keine Rolle. Alternative wäre, wenn du dir sicher bist, dass eine optimierung der Webseite nichts mehr hilft, den MySQL Server auf einen Cluster auszuweiten oder einen extra Server nur für den MySQL Dienst anzuschaffen.
 
@IP-Projects.de
1.) PHPmyAdmin führt keine Statistiken, das tut der MySQLd selbst.
2.) Nutzt der OP eine kaputte Debian-Default-Config, welche darum bettelt ersetzt zu werden.
3.) Cluster für die paar Queries? Es ist ja logisch, dass Du als Anbieter möglichst viele und ertragreiche Produkte verkaufen willst, aber den (potentiellen) Kunden derart wissentlich falsch zu beraten, grenzt schon an Vorsatz.
 
@IP-Projects.de
1.) PHPmyAdmin führt keine Statistiken, das tut der MySQLd selbst.
2.) Nutzt der OP eine kaputte Debian-Default-Config, welche darum bettelt ersetzt zu werden.
3.) Cluster für die paar Queries? Es ist ja logisch, dass Du als Anbieter möglichst viele und ertragreiche Produkte verkaufen willst, aber den (potentiellen) Kunden derart wissentlich falsch zu beraten, grenzt schon an Vorsatz.

1) korrekt - aber wenn man PHPMyAdmin sowieso einsetzt, ist es das schönste Tool, wenn man solche Werte auslesen will.
2) Was auch nur bedingten Erfolg bringen wird.
3) Wenn man 24000 Querys in der Minute als ein paar ansieht. Zumal ich gar kein Angebot gemacht habe sondern nur einen Lösungsansatz dargeboten habe.

Fragen wir doch einmal, wie der Serverload aussieht bei diesen paar Querys.
 
2.) Nutzt der OP eine kaputte Debian-Default-Config, welche darum bettelt ersetzt zu werden.
Wäre hilfreiche gewesen dies zu konkretisieren.

Für mich sieht die o.g. my.cnf ebenfalls so aus, als ob die Alte beim Upgrade blind übernommen worden ist, statt sie durch die Original-Config des Paketes zu ersetzten.
Abhilfe sollte "dpkg-reconfigure mysql-server" schaffen.
Danach in die neue my.cnf die vorgeschlagenen Änderungen von mysqltuner einfügen.
Je nach vorhandenen Speicher solltest Du "max_connections=200" überdenken.

Und für die nächste Anfrage hätte ich dann gerne ein paar Fakten. Z.B. über die Hardware (RAM,CPU), die Config (Abschnitt [mysqld]) und natürlich ein Auszug von mysqltuner|tuning-primer.

huschi.
 
2) Was auch nur bedingten Erfolg bringen wird.
3) Wenn man 24000 Querys in der Minute als ein paar ansieht. Zumal ich gar kein Angebot gemacht habe sondern nur einen Lösungsansatz dargeboten habe.
Ich sehe da einen gelangweilten MySQLd, welcher auf Grund einer Fehlkonfiguration und einem bisher undefinierten äusseren Einfluss vier Lastspitzen auszustehen hatte. Mit einer halbwegs vernünftigen Konfiguration hätte er in den Spitzen auch 30k Queries ertragen, denn das schafft die Hardware (i7-920/12GB RAM) locker.
Bleibt nach vernünftiger Konfiguration die Frage nach dem undefinierten äusseren Einfluss. Da kommt bereits auf Grund der Uhrzeiten der Spitzen ein deutsches Scriptkiddie in Frage, zumal der MySQLd nicht an localhost gebunden ist...

Fragen wir doch einmal, wie der Serverload aussieht bei diesen paar Querys.
Unrelevant.
 
Der Server selber hat einen Intel® Core™ i7-920 Quad-Core mit 12 GB Ram.

Die Config-Datei war vom alten Server übernommen. Auf dem Server lief ja alles reibungslos.

Das dpkg-reconfigure bringt keine neue Config. Lese mir aber gerade die Manpage dazu durch.

Wieso sollte ich die Max-Connections überdenken, in welche Richtung?

Die Auszüge von mysqltuner|tuning-primer kann ich dir erst nach der jeweils erforderlichen Wartezeit von 24/48 Stunden posten.

@Joe User:
der Äussereeinfluss sind die Bots von verschiedenen Suchmaschinen, das konnte ich schon eindeutig feststellen. Diese Verursachen diese hohe Serverlast.

Der Serverload geht in dem fall bis auf über 20 hoch, nur damit es mal gesagt. wurde
Trotzdem schonmal Danke für die Hilfe
 
Folgendes in der robots.txt hilft bei einigen Bots:
Code:
Crawl-Delay: 5

Bist Du Dir sicher, das es Bots sind und nicht ein Scriptkiddie, welches sich als Bot ausgibt?
 
Zitat:
Zitat von IP-Projects.de Beitrag anzeigen
Fragen wir doch einmal, wie der Serverload aussieht bei diesen paar Querys.
Unrelevant.

Der hohe Load aufgrund der Menge an Datenbankanfragen sorgt dafür, dass das System immer langsamer wird, RAM und CPU Leistung kann hier ganz normal aussehen, wenn der Load aber sehr hoch ist, wird das System immer langsamer. Der Load hat also in gewisser weise doch etwas damit zu tun.

Normale Suchmaschinenbots lösen dieses Problem aber normalerweise nicht aus.
 
Laut Apache Logs sind es nur Bots. Von Google, Yahoo und sonstigen Anbietern.

Generell sind die Bots ja erwünscht. Aber sie sollten den Server nicht so in die Knie zwingen.
 
Der hohe Load aufgrund der Menge an Datenbankanfragen sorgt dafür, dass das System immer langsamer wird, RAM und CPU Leistung kann hier ganz normal aussehen, wenn der Load aber sehr hoch ist, wird das System immer langsamer. Der Load hat also in gewisser weise doch etwas damit zu tun.
Schon richtig, nur ist der Load hier unrelevant, da er nach dem Beheben des Problems automatisch wieder normal ist.

Normale Suchmaschinenbots lösen dieses Problem aber normalerweise nicht aus.
Eben, und die Uhrzeiten der Spitzen deuten sehr stark auf einen Schüler/Studenten hin.
 
Das dpkg-reconfigure bringt keine neue Config.
Dann kommt es erst mit dem Paket mysql-server-5.0. Ansonsten lad Dir das Paket manuell runter und kopiere die Conf dort raus.

Wieso sollte ich die Max-Connections überdenken, in welche Richtung?
Brauchst Du wirklich so viele Connections? Ist evtl. der MySQL von außen erreichbar?

Die Auszüge von mysqltuner|tuning-primer kann ich dir erst nach der jeweils erforderlichen Wartezeit von 24/48 Stunden posten.
Die Zeitangabe gilt mehr für schwach besuchte Seiten. Wenn gerade ein Bot getanzt hat, reicht diese bereits schon für eine kleine Diagnose.

der Äussereeinfluss sind die Bots von verschiedenen Suchmaschinen
Die meisten braucht man nicht. Google und sonstige freundliche Bots feuert i.d.R. nicht so schnell hintereinander dass es den Server lahm legt.
Aber die Fakten (Logfiles) bleiben weiterhin aus...

huschi.
 
Schon richtig, nur ist der Load hier unrelevant, da er nach dem Beheben des Problems automatisch wieder normal ist.
Grundsätzlich gebe ich Dir damit recht.
Aber aus Mangel an Fakten könnte ein top-Screenshot bereits sagen in welche Richtung die Optimierung gehen sollte. Z.B. sollten bei hoher I/O die Buffer vergrößert werden. Bei kleiner I/O und hoher CPU könnte ein Fehler im DB-Modell (falsche Indexierung) oder ein fehlender Query-Cache die Ursache sein.

Surfme2 lässt uns, was Fakten angeht, relativ im Regen stehen.
Und genauso Ziellos sind hier unsere Spekulationen und Nebendiskussionen.

huschi.
 
Gerade hatte ich wieder entsprechende Zugriffe - die passenden Bilder hierzu füge ich mal an...

und dazu einen kleinen auszug der logs von gestern:
in den logs finden sich verschiedene Bots, msn, google, twenga usw.

PHP:
95.211.115.233 - - [05/Oct/2010:10:46:03 +0200] "GET /advanced_search_result.php?categories_id=0&&keywords=Vorfahren HTTP/1.0" 200 12419 "-" "TwengaBot/1.1 (+http://www.twenga.com/bot.html)"

66.249.71.226 - - [05/Oct/2010:10:46:42 +0200] "GET /products/de/Haus-Wohnen/Bilderrahmen/Shadow-Rahmen-gross.html?XTCsid=498d4ebfb69f4f578cbe95eb6f08407e HTTP/1.1" 200 13777 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

67.195.114.21 - - [03/Oct/2010:18:36:28 +0200] "GET /content/.html HTTP/1.0" 404 10684 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"

Gleichzeitig habe ich folgenden Zugriff über die Database Connections

PHP:
    2779519     sql1     localhost     sql1     Query     00:00:00     SELECT DISTINCT pd.products_name, pd.products_short_description, p.products_id, p.products_price, p.products_tax_class_id, pd.products_id, cd.categories_id, cd.categories_name, ptc.categories_id FROM ((products AS p LEFT JOIN products_description AS pd ON (p.products_id = pd.products_id)) INNER JOIN products_to_categories AS ptc ON (p.products_id = ptc.products_id)) INNER JOIN categories_description AS cd ON (ptc.categories_id = cd.categories_id) INNER JOIN categories AS c ON (cd.categories_id = c.categories_id) WHERE p.products_status = '1' AND pd.language_id = '2' AND ( pd.products_name LIKE ('%versch?tten%')OR pd.products_keywords LIKE ('%versch?tten%') OR pd.products_short_description LIKE ('%verschütten%') OR pd.products_description LIKE ('%verschütten%')) GROUP BY p.products_id LIMIT 2

Davon laufen dann teilweise über 40 Stück.
Beende ich diese läuft der server dann wieder absolut ruhig, hält nur nicht lange - ruck zuck starten diese Zugriffe wieder
 

Attachments

  • localhost.localdomain-if_eth0-day1.png
    localhost.localdomain-if_eth0-day1.png
    19.9 KB · Views: 189
  • localhost.localdomain-processes-day2.png
    localhost.localdomain-processes-day2.png
    20 KB · Views: 193
  • localhost.localdomain-cpu-day3.png
    localhost.localdomain-cpu-day3.png
    22.8 KB · Views: 167
  • localhost.localdomain-interrupts-day4.png
    localhost.localdomain-interrupts-day4.png
    24.9 KB · Views: 192
  • localhost.localdomain-irqstats-day5.png
    localhost.localdomain-irqstats-day5.png
    45.9 KB · Views: 193
Hie noch die fehlenden Bilder
 

Attachments

  • localhost.localdomain-load-day6.png
    localhost.localdomain-load-day6.png
    21.2 KB · Views: 181
  • localhost.localdomain-memory-day7.png
    localhost.localdomain-memory-day7.png
    40.3 KB · Views: 175
  • allmysqlshots.jpg
    allmysqlshots.jpg
    119.6 KB · Views: 166
  • localhost.localdomain-memory-day8.png
    localhost.localdomain-memory-day8.png
    22.4 KB · Views: 172
Last edited by a moderator:
Back
Top