Hatte diese Frage einige Tage lang ohne Glück auf Serverfault.
Ich habe mysqltuner.pl auf einem VPS ausgeführt und habe einige Fragen zu den Vorschlägen für zu ändernde Variablen. Ich bin mir sicher, dass dies allgemeine Fragen mit komplexen Antworten sind.
Ich bin nicht sachkundig genug, um Abfragen zu schreiben und sie gegen den Server zu testen, aber ich versuche nur, etwas mehr Leistung aus dem Server herauszuholen, auf dem fünf WordPress-Sites mit> 200.000 Seitenaufrufen/Monat ausgeführt werden.
Ich habe die Datenbank über phpmyadmin optimiert (und mache das regelmäßig), aber der Tuner sagt immer noch, dass es fragmentierte Tabellen gibt. Und weil dies WordPress ist, kann ich Abfragen im Kerncode nicht ändern.
Aber um wie viel sollte ich die Variablen wie query_cache_size und innodb_buffer_pool_size erhöhen? Was ist mit den anderen innodb-Variablen?
Einige der vorgeschlagenen Variablen existieren nicht in my.cnf, wie table_cache, und werden im Tuner-Bericht usw. gekennzeichnet. Kann ich sie zu my.cnf hinzufügen?
(Und warum ist dieser Block in my.cnf dupliziert? Kann ich das Duplikat löschen?)
------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.45
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM
-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 133M (Tables: 637)
[--] Data in InnoDB tables: 10M (Tables: 344)
[--] Data in MEMORY tables: 126K (Tables: 2)
[!!] Total fragmented tables: 69
-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned
-------- Performance Metrics -------------------------------------------------
[--] Up for: 1d 6h 24m 13s (2M q [22.135 qps], 116K conn, TX: 4B, RX: 530M)
[--] Reads / Writes: 97% / 3%
[--] Total buffers: 35.0M global + 2.7M per thread (100 max threads)
[OK] Maximum possible memory usage: 303.7M (8% of installed RAM)
[OK] Slow queries: 0% (4/2M)
[OK] Highest usage of available connections: 53% (53/100)
[OK] Key buffer size / total MyISAM indexes: 8.0M/46.1M
[OK] Key buffer hit rate: 99.6% (749M cached / 2M reads)
[OK] Query cache efficiency: 32.2% (685K cached / 2M selects)
[!!] Query cache prunes per day: 948863
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 660K sorts)
[!!] Temporary tables created on disk: 46% (400K on disk / 869K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (64 open / 24K opened)
[OK] Open file limit used: 10% (109/1K)
[OK] Table locks acquired immediately: 99% (2M immediate / 2M locks)
[!!] InnoDB data size / buffer pool: 10.6M/2.0M
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Set thread_cache_size to 4 as a starting value
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (> 8M)
tmp_table_size (> 32M)
max_heap_table_size (> 16M)
thread_cache_size (start at 4)
table_cache (> 64)
innodb_buffer_pool_size (>= 10M)
Tim Brunnen
Ich werde mein Bestes tun, um hier zu helfen. Der MysqlTuner-Bericht impliziert, dass Sie 4 GB RAM in diesem VPS haben, daher basieren meine Vorschläge darauf.
query_cache_size – Dies ist die Menge an RAM, die MySQL verwenden kann, um die Ergebnisse von Datenbankabfragen zwischenzuspeichern. Im Abfrage-Cache gespeicherte Ergebnisse werden viel schneller zurückgegeben als normale Auswahlen, sodass diese Variable die Dinge erheblich beschleunigen kann (mehr als alle anderen vorgeschlagenen Änderungen).
Was genau der richtige Wert für Sie ist, erfordert einige Experimente. Sie haben diesen Wert derzeit auf 8 M festgelegt. Wenn Sie 4 GB RAM in dieser Box haben, würde ich bei 64 MB beginnen und bei Bedarf auf 128 MB und dann auf 256 MB erhöhen. Lassen Sie die Dinge nach jeder Änderung ein paar Tage stehen und führen Sie dann MysqlTuner erneut aus und vergleichen Sie den Prozentsatz für die „Abfrage-Cache-Effizienz“ mit dem vorherigen Wert. Bei einem Server, auf dem hauptsächlich 5 WordPress-Blogs gehostet werden, bezweifle ich, dass Sie eine Verbesserung über 256 MB hinaus sehen würden, und ich würde nicht empfehlen, mehr als ein Achtel Ihres gesamten Arbeitsspeichers zu verwenden.
Persönlich finde ich Munin (ein kostenloses Serverüberwachungstool) ziemlich praktisch, um solche Dinge im Auge zu behalten, da es die Cache-Treffer im Vergleich zu anderen Abfragen grafisch darstellt.
tmp_table_size – Für einige komplexe Abfragen (insbesondere solche, die GROUP BY oder komplexe Sortierung verwenden) muss MySQL zuerst eine temporäre Tabelle erstellen, die die Daten enthält, und dann einige Operationen darauf ausführen, um die Ergebnismenge zu erstellen. Es wird versuchen, diese temporären Tabellen im Speicher zu erstellen, da dies viel schneller ist, als sie auf der Festplatte zu erstellen. aber für große Ergebnismengen ist dies nicht immer möglich. tmp_table_size steuert diesen Schwellenwert.
Ich kann mir nicht vorstellen, dass WordPress sehr komplexe Abfragen durchführt, also würde ich es mit dieser nicht übertreiben. MysqlTuner schlägt einen Wert von mehr als 32 MB vor, beginnen Sie also mit 64 MB und sehen Sie, wie sich dies nach ein paar Tagen auf den Wert „Temporary tables created on disk“ auswirkt. Stellen Sie max_heap_table_size ein, wenn Sie schon dabei sind, wie es vorschlägt.
thread_cache_size – WordPress verwendet standardmäßig keine dauerhaften Verbindungen (was gut ist), sodass jede Anfrage eine neue Verbindung zu Ihrer Datenbank herstellt und diese dann schließt, sobald die Seite generiert wurde. Dieser Overhead ist nicht signifikant, aber die Verwendung von thread_cache_size ermöglicht es MySQL, diese Verbindungsthreads wiederzuverwenden, was ein wenig hilfreich sein wird.
Ich würde mit dem vorgeschlagenen Wert von 4 gehen, was meiner Meinung nach in Ordnung sein wird, es sei denn, Sie erhalten eine hohe Anzahl gleichzeitiger Benutzer.
Tabellencache – Ich bin in dieser Hinsicht etwas verschwommen, es scheint sich auf den MySQL-Cache der Tabellenstruktur zu beziehen. Ich würde dafür 128 nehmen.
innodb_buffer_pool_size – Dies ist die Menge an Speicher, die MySQL verwenden kann, um Indizes und Daten für InnoDB-Tabellen zwischenzuspeichern. Das verwirrt mich ein bisschen, da ich glaube, dass WordPress InnoDB überhaupt nicht verwendet – haben Sie auch einige andere Seiten auf diesem Server?
Um Ihre anderen Fragen zu beantworten, die Konfiguration nach [mysqld_safe] gelten nur für den MySQL-Daemon im abgesicherten Modus und nicht für MySQL insgesamt, daher werden einige der Variablen dupliziert. Wenn Sie innodb_buffer_pool_size ändern, sollten Sie die erste ändern. Die Variablen, die nicht in der Datei sind, können Sie ja hinzufügen, aber fügen Sie sie oben hinzu [mysqld_safe] Sperre aus dem gleichen Grund.
Zu guter Letzt, da Sie in der Stimmung zum Optimieren sind, wenn Sie nicht bereits einen PHP-Bytecode-Cache wie z APC dann lohnt es sich, dies zu erkunden. APC kann PHP-Apps einige deutliche Geschwindigkeitsverbesserungen ohne negative Auswirkungen verleihen.
Danke … Ich werde das alles durchgehen, diese Änderungen ausprobieren und Munin ausprobieren. Auf dem Server ist ioncube installiert.
– markratledge
6. Oktober 2010 um 19:35 Uhr
Hallo… Muss ich join_buffer_size >= 128 K auf my.cnf setzen? Funktioniert das?
In den meisten Fällen müssen Sie keine Abfragen schreiben und sie auf dem Server testen. Aktivieren Sie einfach das Protokoll für langsame Abfragen, um Ihre langsamen Abfragen zu identifizieren, aggregieren Sie sie mit mysqlsla und erklären Sie sie mit maatkit:
Sie könnten die langsamsten Abfragen aus den MySQL-Ergebnissen in eine Textdatei einfügen und sie mit Maatkit ausführen.
Oft ist die Auswahl einer neueren MySQL-Version entscheidend für die Leistung. Ich habe die Erfahrung gemacht, dass die Ausführungspläne für komplexe Abfragen sehr unterschiedlich sind, wenn Sie beispielsweise mysql 5.0.23 mit 5.1.4 vergleichen. Sie werden in unserer Umgebung mit 5.1.4 viel schneller ausgeführt.
Tabellen-Cache:
Laut dem Buch „speichert der Tabellen-Cache Objekte, die Tabellen darstellen. Jedes Objekt im Cache enthält die geparste .frm-Datei der zugeordneten Tabelle sowie weitere Daten, abhängig von der Speicher-Engine der Tabelle.
Das Design des Tabellen-Cache ist ein wenig MyISAM-zentriert – dies ist einer der Bereiche, in denen die Trennung zwischen dem Server und der Speicher-Engine aus historischen Gründen nicht vollständig sauber ist. Der Tabellen-Cache ist für InnoDB etwas weniger wichtig, da InnoDB sich nicht für so viele Zwecke darauf verlässt (z. B. zum Halten von Dateideskriptoren; es hat für diesen Zweck eine eigene Version eines Tabellen-Cache). Aber auch InnoDB profitiert vom Caching der geparsten .frm-Dateien.”.
Wenn Sie den Tabellencache erhöhen, treten möglicherweise Fehler mit dem Limit für offene Dateien auf. Sie müssen auch die Variable open_files_limit auf dem Server und möglicherweise das Limit für offene Dateien des Betriebssystems erhöhen: http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/.
Thread-Cache:
Der Thread-Cache enthält die Threads, die derzeit keiner Verbindung zugeordnet sind, aber bereit sind, neue Verbindungen zu bedienen. Solange MySQL einen freien Thread im Cache hat, kann es sehr schnell auf Verbindungsanfragen reagieren, da es nicht für jede Verbindung einen neuen Thread erstellen muss.
[!!] Auf der Festplatte erstellte temporäre Tabellen: 46 % (400 KB auf der Festplatte / 869 KB insgesamt)
Wenn tmp_table_size und max_heap_table_size noch nicht gesetzt sind, erhöhen Sie sie. Festplattenoperationen sind im Vergleich zu RAM-Operationen sehr langsam. Verwendet WordPress viele Blob-/Textspalten? dann werden Sie nicht viele Vorteile sehen, da BLOB- und Textspalten in Speichertabellen nicht erlaubt sind.
[OK] Höchste Nutzung verfügbarer Verbindungen: 53 % (53/100)
Um RAM zu sparen, können Sie die zulässigen maximalen Verbindungen verringern. Andererseits könnten Ihnen in Spitzenzeiten die Verbindungen ausgehen.
Die Verwendung eines Opcode-Cache für PHP ist eine sehr gute Idee!
Meine Empfehlungen zum Tunen von MySQL für WP:
Datenbanktabellen sollten für eine optimale Leistung regelmäßig optimiert (und gegebenenfalls repariert) werden.
Ich empfehle die Verwendung WP-DBManager Plugin, das diese Funktionalität sowie ein Datenbank-Backup bietet, alles entscheidend für jede Blog-Installation.
Mit WP-DBManager können Sie planen und vergessen, und er kümmert sich automatisch um die gesamte Arbeit.
Eine andere Alternative ist die manuelle Optimierung und Reparatur Ihrer Tabelle durch ein Tool wie phpmyadmin.
Der MySQL Query Cache speichert Ergebnisse von Abfragen für den Fall, dass die Abfrage erneut eintrifft. Es weiß jedoch nur, wie der Bytetext von Abfragen gespeichert wird, nicht ihre kompilierten Versionen, sodass kleine Änderungen an der Abfrage unterschiedliche Cache-Einträge erstellen. Aktivieren Sie diese Option, wenn Sie nicht in jeder Abfrage eindeutige IDs haben. Sie können es aktivieren, indem Sie Folgendes zu /etc/my.cnf hinzufügen:
query_cache_type = 1
query_cache_size = 26214400
Ich erwähne, dass ich mit phpmydmin optimiere/repariere und Backups hier kein Thema sind. Meine Hauptfrage hat mit Variablen zu tun, die derzeit nicht in my.cnf enthalten sind, aber vom Bericht empfohlen werden.
– markratledge
29. September 2010 um 21:28 Uhr
Dies ist keine direkte Antwort auf Ihre Frage, aber meiner Erfahrung nach kann WordPress eine sein sehr gut optimiert durch Caching auf den Frontend-Servern. Auch WordPress scheint auf den Frontend-Rechnern und nicht auf der Datenbank CPU-gebunden zu sein. (Vielleicht möchten Sie noch einmal überprüfen, ob Sie den Engpass tatsächlich optimieren).
Schauen Sie sich zum Beispiel “w3 total cache” an. Die Verwendung mit APC sollte der einfachste Ansatz sein. Stellen Sie sicher, dass Sie sich die Größe von apc.shm_size (in php.ini) und die Cache-Hit-Rate ansehen (einige apc-Info-Dienstprogramme sollten mit w3tc geliefert werden).
Ich habe WordPress-Instanzen gesehen, die mit diesem Setup reibungslos auf einem einzelnen Server liefen und weit mehr als nur 200.000 Seitenaufrufe pro Monat.
14007300cookie-checkMysqltuner-Vorschläge und Änderungen an my.cnfyes
