Ich habe ein kleines Problem mit der Optimierung der MySQL-Einstellungen meines VPS (Linux / Cpanel). Ich weiß nicht viel über MySQL und verwende diesen VPS für etwa 50 verschiedene Websites. Sie alle hatten weniger als 100 Besucher täglich, also ist der Verkehr nicht so sehr mein Problem. Mein VPS funktioniert im Moment gut, aber ich mache mir Sorgen über [!!] Warnungen in mysqltuner.pl. Muss ich mir Sorgen machen?
=> Meine VPS-Informationen:
Processor Information
**Total processors: 6**
Processor #1
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #2
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #3
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #4
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #5
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #6
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Memory Information
Memory: 30789880k/**32505856k** available (5336k kernel code, 1050056k absent, 665920k reserved, 7016k data, 1288k init)
System Information
Linux xl.xlxlxl.com 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Current Memory Usage
total used free shared buffers cached
Mem: 30812400 30064332 748068 244 3883652 17129112
-/+ buffers/cache: 9051568 21760832
Swap: 0 0 0
Total: 30812400 30064332 748068
=> Meine.cnf:
[mysqld]
max_allowed_packet=268435456
open_files_limit=10000
query_cache_type=1
query_cache_size=768M
query_cache_limit=2048M
sort_buffer_size=4M
join_buffer_size=26M
read_rnd_buffer_size = 1M
max_heap_table_size = 1024M
tmp_table_size = 1024M
table_open_cache = 15000
innodb_log_buffer_size = 64M
max_connections=200
wait_timeout=26000
interactive_timeout=26000
innodb_buffer_pool_size=256M
=> Mysqltuner.pl:
>> MySQLTuner 1.4.0 - Major Hayden <[email protected]>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
[OK] Currently running supported MySQL version 5.6.23
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 3G (Tables: 3156)
[--] Data in InnoDB tables: 183M (Tables: 1455)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 52)
[!!] Total fragmented tables: 5
-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned
-------- Performance Metrics -------------------------------------------------
[--] Up for: 2d 20h 23m 59s (11M q [45.850 qps], 381K conn, TX: 85B, RX: 2B)
[--] Reads / Writes: 82% / 18%
[--] Total buffers: 2.1G global + 31.4M per thread (200 max threads)
[OK] Maximum possible memory usage: 8.2G (27% of installed RAM)
[OK] Slow queries: 0% (4/11M)
[OK] Highest usage of available connections: 7% (14/200)
[OK] Key buffer size / total MyISAM indexes: 8.0M/432.3M
[OK] Key buffer hit rate: 99.6% (493M cached / 1M reads)
[OK] Query cache efficiency: 59.6% (5M cached / 8M selects)
[!!] Query cache prunes per day: 143463
[OK] Sorts requiring temporary tables: 0% (16 temp sorts / 434K sorts)
[!!] Joins performed without indexes: 2610
[!!] Temporary tables created on disk: 83% (458K on disk / 550K total)
[OK] Thread cache hit rate: 99% (36 created / 381K connections)
[!!] Table cache hit rate: 13% (1K open / 12K opened)
[OK] Open file limit used: 1% (324/30K)
[OK] Table locks acquired immediately: 99% (4M immediate / 4M locks)
[!!] Connections aborted: 18%
[OK] InnoDB buffer pool / data size: 256.0M/183.9M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Increasing the query_cache size over 128M may reduce performance
Adjust your join queries to always utilize indexes
Temporary table size is already large - reduce result set size
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
Your applications are not closing MySQL connections properly
Variables to adjust:
query_cache_size (> 768M) [see warning above]
join_buffer_size (> 26.0M, or always use indexes with joins)
table_open_cache (> 15000)
Antwort1
Die Idee von mysqltuner ist es, Maßnahmen zur Leistungsverbesserung zu empfehlen. Die optimierte Tabelle berücksichtigt die Fragmentierung. Die Optimierung großer Tabellen dauert jedoch einige Zeit, während die zu optimierende Tabelle gesperrt ist. Im Allgemeinen [!!]werden die Warnhinweise mit dem vorangestellten Wort im General recommendationsAbschnitt kommentiert.
Bevor Sie die Standardparameter von MySQL anpassen, sollten Sie Ihre SQL-Anweisungen und Ihre SQL-Verbindungen überprüfen. Verknüpfungen ohne Indizes führen zu erheblichen Leistungseinbußen. Versuchen Sie, slow_querieszu ermitteln, welche Abfragen optimiert werden müssen.
Auch die Ergebnismenge ist oft viel zu groß. Denken Sie an ein Shopsystem mit einer Datenbank.
Beispiel
Angenommen, Sie haben 10.000 Artikel im Shop-System, dann select * from items;gibt ein Aufruf alle 10.000 Artikel zurück, Ihre Ergebnismenge beträgt also 10.000. Es ist jedoch ziemlich unwahrscheinlich, dass Sie wirklich alle 10.000 Artikel auf einmal benötigen.
Der Hauptzweck von SQL besteht eigentlich darin, die Ergebnismenge mithilfe von Filtern zu reduzieren, die am effektivsten auf Indizes wirken. Wenn Sie beispielsweise nach allen Elementen suchen, die eine gelbe Farbe haben, reduzieren Sie die Größe der Ergebnismenge umselect * from items where color="yellow";
Aber wenn Sie mehrere hundert gelbe Einträge haben, sind das immer noch zu viele, um sie auf einer Webseite anzuzeigen. Sie schränken also Ihre Ergebnisse ein.
select * from items where color="yellow" limit 1,10
für die erste Seite mit 10 Einträgen
select * from items where color="yellow" limit 11,20
für die nächste Seite und so weiter ... .
Ich würde daher empfehlen, Ihre Anweisungen zu optimieren, bevor Sie Ihre Datenbank optimieren, da Sie eine viel bessere Leistung erzielen, wenn Sie Tabellenindizes korrigieren und große Ergebnismengen begrenzen. Aus diesem Grund gibt mysqltuner diese Warnungen aus.
Eines der nützlichsten Tools zum Debuggen von Joins und Indizes ist die Verwendung explainvor Ihren Select-Anweisungen:
explain select i.name, l.address
from items i
inner join location l on i.location = l.id
where l.description like '%universe%';
zeigt Ihnen die Anzahl der Tabellenzeilen mit und ohne Indizes an, die zur Zusammenstellung Ihres Ergebnisses verwendet werden.