[Tipps] MySQL Optimierungen

    Neben den Standard-Optimierungen von Query Cache o.ä. habe ich heute etwas entdeckt, das für viele interessant sein dürfte, falls sie es nicht eh schon kennen: Eine aktivierte InnoDB Unterstützung benötigt bis zu 100MB Ram, egal ob sie aktiv genutzt wird oder nicht. Wer also InnoDB sowieso nicht benötigt, schaut bitte einmal in die /etc/mysql/my.cnf und sucht dort nach skip-innodb. Dort stehen auch noch weitere Erklärungen darüber. Die genannte Zeile kann dann bei Bedarf einfach aktiviert werden. Danach MySQL mit /etc/init.d/mysql restart neustarten.


    Vielleicht wollen hier ja auch noch andere Benutzer ihre Optimierungstipps veröffentlichen, ich werde sie dann immer im ersten Beitrag mit einem Hinweis zusammenfassen ;)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Zitat von killerbees19;2586

    Die genannte Zeile kann dann bei Bedarf einfach auskommentiert werden.


    Eher andersrum, oder? Also wenn sie auskommentiert ist, wird InnoDB nicht übersprungen, sondern geladen. Da das mehr Speicher braucht, kann man die Einstellung anschalten.

    Ich sitze wieder einmal zu lange vor dem PC, danke für den Hinweis! War ein Tippfehler :)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Aufjedenfall supi Idee das mal nieder zu schreiben auch wenn eigentlich Google zudem Thema schon ne Menge verrät für alle die sich nich so zu helfen wissen.
    Hab da auch bissl was nettes in den 2 Minuten grad gefunden. Obs brauchbar ist oder nicht könnt Ihr da selbst Entscheiden ;) dem ein oder andern hilfts garantiert.


    http://www.day32.com/MySQL/tuning-primer.sh runterladen ausführen und das script soll einem nützliche Hinweise zum Feintunning des MySQL Servers geben. Bei mir hat er jedenfalls bei nix rum gemeckert :D


    MfG
    Andre


    P.S.: Als ich mir das ding grad von dort geladen habe war Alles okay. Keine Viren keine Spyware oder sonst was.

    Bei einigen Anwendungen macht es sinn sie über InnoDB laufen zu lassen auch wenn mehr Speicher verbraucht wird. Bei bestimmen abfragen bringt es nämlich einen erheblichen Geschwindigkeitsvorteil. Wie z.B. die HLStatsX, wenn man da bestimmte Tabellen in InnoDB konvertiert werden die Abfragen wesentlich schneller ausgeführt. Das ganze macht aber nur sinn wenn man mehrere Server am laufen hat oder der MySQL anderweitig viel zu tun hat.


    Außerdem bringt es auch was den MySQL mit den "Google Performance Tools" zu beschleunigen (die haben nichts mit Google zu tun außer das sie da gehostet werden). Siehe Project Seite und hier für fertiges deb Paket und hier für Anleitung.

    Neun von zehn stimmen in meinem Kopf sagen ich bin nicht verrückt, die zehnte summt die Melodie von Tetris.

    Mal was aktuelles auch von mir :)


    Da ich sowieso einen zweiten Beta-Test-vServer immer laufen habe, habe ich seit ca. einem Monat übrigens die MySQL Replikation aktiviert und sehr aufwändige Select's auf den anderen vServer verschoben. Auch die meisten externen Zugriffe auf MySQL laufen jetzt über den anderen vServer. Das spart zur Zeit einiges an Ressourcen ein, kann ich nur empfehlen, wenn man irgendwo eine ungenutzten vServer "rumstehen" hat. Die gewonnen Rechenzeiten sind weit aus höher als die verlorenen IO-Waits durchs Replikations-Log, lohnt sich also auf jeden Fall ;)


    Außerdem macht es Sinn für Tabellen mit unwichtigen Daten welche vom Typ MEMORY zu verwenden. Dabei werden die Tabellendaten nur im Arbeitsspeicher gespeichert (und gehen bei einem Neustart/Absturz von MySQL auch verloren!), was bei Session oder Captcha Daten sehr nützlich ist und zu enormen Geschwindigkeitsvorteilen führt ;)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Parameter =Erklärung


    [LEFT]max_connections = Wieviele Connections (und damit auch Threads) sind generell erlaubt?
    (Dieser Wert kann deutlich kleiner als die Apache-Einstellung MaxClients sein.)


    table_cache = Der Table-Cache reserviert Speicher für die häufiger gebrauchten Tabellen. query_cache_size
    In dem Speicherbereich werden die SQL-Statements mit einer Ergebnissliste gespeichert um bei einem neuen Zugriff die Daten sofort parat zu haben. Bei Updates/Inserts/Deletes wird der gespeicherte Query gelöscht.


    key_buffer_size = Der Speicher, der für die referenziellen Keys reserviert wird. Dieser Wert gilt pro Connection.


    sort_buffer_size = Der Speicher, der für die Sortierung reserviert wird.
    Dieser Wert gilt pro Connection.


    read_buffer_size = Der Speicher, der für das Lesen von Festplatte reserviert wird. Dieser Wert gilt pro Connection.[/LEFT]

    Ist vielleicht auch gut zu wissen was welche Parameter in der my.cnf bedeuten da das für einige schon chinesisch ist ;) sind natürlich nur ein Paar und in meinen Augen die wichtigsten Parameter in der my.cnf


    Dazu kommen natürlich die Performance-Fresser schlechthin:
    Die Logfiles: log_slow_queries (evtl. sogar als log_long_format) und das Replikations-Log: log-bin.
    Alle unnötigen Festplattenzugriffe sollten unterbunden werden. Und wer nicht gerade die Slow-Queries bzgl. dem Tuning braucht und auch keine Datenbank-Replikation (log-bin) fährt, sollte diese abschalten.



    MfG
    Andre

    Man sollte sich mit der Technik auseinander setzen und nicht einfach sagen das ist schneller als das. Die Entscheidung welche Storage Engine man benutzen möchte ist auf jeden Fall eine wichtige, da man sich bei z.B. InnoDB sehr viel mehr mit der Technik beschäftigen muss als bei MyISAM. Also was braucht man, was bieten die unterschiedlichen System und dann entscheiden und optimieren.


    Ich persönlich setze nur MyISAM/MEMORY Tabellen ein und komme damit super klar, auch bei Datenbanken über 20GB. ARCHIVE wäre auch interessant, aber der fehlende Key Support macht die Benutzung leider schwer.

    Zitat von kostaki;8205

    auch bei Datenbanken über 20GB.


    20GB? :eek:
    Und da laufen die Abfragen wirklich noch schnell genug? Wie groß hast denn dabei die Variablen für den Tabellencache von MySQL gesetzt? Und wie stark war/ist der Server worauf das läuft/lief? Entschuldige meine Neugierde, interessiert mich einfach, da ich DB's mit ~1GB laufen habe, die jedes Jahr um mindestens 500MB größer werden. Ist zwar noch weit von solchen Werten entfernt, aber man plant ja für die Zukunft :)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Will den Thread hier nicht zumüllen, aber ich antworte trotzdem mal. table_cache ist nicht das Problem. Wichtig war in meinem Fall der key_buffer (2GB). Wichtig ist das Verständnis der Keys und auf was für Spalten man diese setzt. Ich hatte anfänglich eine Tabelle mit 2GB Daten und 3GB Index. Nach ein bisschen Optimierung ist das Verhältnis ohne Einbußen auf 1/5 Index/Daten gesunken. Der Server hat 8GB RAM.