Beste Optimierung für my.cnf

Olli_

New Member
Guten Morgen zusammen,

ich benötige die beste Optimierung/Konfiguration für meine my.cnf - MySQL 5.5 - Debian Jessie - 8 GB RAM

Derzeit habe ich folgendes in der my.cnf

Code:
[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
lc-messages-dir = /usr/share/mysql
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              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
# 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            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 16M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
#slow_query_log_file = /var/log/mysql/mysql-slow.log
#slow_query_log      = 1
#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
#
# * 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!
#
# * 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

Prozessor Information:

Code:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 42
Model name:            Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
Stepping:              7
CPU MHz:               1839.121
CPU max MHz:           3200.0000
CPU min MHz:           1600.0000
BogoMIPS:              5786.55
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              6144K
NUMA node0 CPU(s):     0-3

Kann mir jemand bei der Optimierung helfen?
 
Ohne Infos über die Daten/Strukturen/Zugriffe kann man hier nix pauschales sagen. Lass die DB mal einige Zeit laufen und werte die Performance-Variablen von mysql aus. (MysqlTuner oder PHPMyadmin helfen hier)

Thomas
 
Wie Thomas schon richtig sagte, gibt es die "beste Optimierung" nicht pauschal, da zu viele Faktoren da reinspielen. Außerdem nützen dir die besten Konfig-Einstellungen nur bedingt etwas, wenn schlecht programmierte Software die DB-Performance in den Keller zieht.

Zwei Tage sind auch sehr kurz, um vom Tuningscript schon wirklich aussagekräftige Infos zu bekommen oder läuft der DB-Server schon unter voller Last?
Was du auf jeden Fall noch machen solltest, ist das slow_query_log zu aktivieren, um dadurch mögliche Flaschenhälse ausfindig zu machen.

Ganz wichtig bei der richtigen Optimierung ist auch, daß man weiß und versteht, was man mit den Änderungen der einzelnen Parameter bewirkt. Also auf jeden Fall in der Zwischenzeit schon mal die MySQL-Doku etwas intensiver durchlesen ;)
 
... und nicht glauben, daß man nach 1x schon durch ist - so eine DB-Optimierung ist ein Prozess, der bis zum "1. wir-sind-erst-mal-zufrieden-Release" durchaus mal 1,2 Monate dauern - und dann halt andauernd weiter...

... und nicht vergessen, wenn man mal so einigermaßen wo angekommen ist - dann immer nur einen Parameter ändern, 2 Tage produtiv laufen lassen, prüfen, ändern, 2 Tage prod. laufen lassen...
 
...und auch nicht vergessen, jede Änderung und ihre Auswirkungen zu dokumentieren, damit man später noch weiß, wie der Grundzustand war, was man alles geändert hat und welche Auswirkung jede Änderung gebracht hat.
 
Ja ich bin am lernen. Ein Backup mache ich natürlich immer bevor ich was ändere. ;)

Hier die Ausgabe von mysqltuner:

Code:
 >>  MySQLTuner 1.3.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] Logged in using credentials from debian maintenance account.
[OK] Currently running supported MySQL version 5.5.52-0+deb8u1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 1G (Tables: 188)
[--] Data in InnoDB tables: 1M (Tables: 77)
[--] Data in MEMORY tables: 624K (Tables: 2)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 83

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 59m 24s (788K q [110.129 qps], 59K conn, TX: 47B, RX: 258M)
[--] Reads / Writes: 84% / 16%
[--] Total buffers: 192.0M global + 2.7M per thread (500 max threads)
[OK] Maximum possible memory usage: 1.5G (19% of installed RAM)
[OK] Slow queries: 0% (0/788K)
[OK] Highest usage of available connections: 2% (12/500)
[OK] Key buffer size / total MyISAM indexes: 16.0M/437.0M
[OK] Key buffer hit rate: 99.0% (24M cached / 242K reads)
[OK] Query cache efficiency: 58.8% (365K cached / 621K selects)
[!!] Query cache prunes per day: 156578
[OK] Sorts requiring temporary tables: 1% (1K temp sorts / 60K sorts)
[!!] Joins performed without indexes: 377
[OK] Temporary tables created on disk: 8% (523 on disk / 6K total)
[OK] Thread cache hit rate: 99% (13 created / 59K connections)
[OK] Table cache hit rate: 93% (400 open / 430 opened)
[OK] Open file limit used: 20% (505/2K)
[OK] Table locks acquired immediately: 99% (671K immediate / 672K locks)
[OK] InnoDB buffer pool / data size: 128.0M/1.2M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Enable the slow query log to troubleshoot bad queries
    Adjust your join queries to always utilize indexes
Variables to adjust:
    query_cache_size (> 16M)
    join_buffer_size (> 128.0K, or always use indexes with joins)
 
Code:
Up for: 1h 59m 24s

Das ist eindeutig zu wenig für nur annähernd aussagekräftige Infos. Als Richtwert wird ein Minimum von 2-3 Tagen Laufzeit des DB-Daemons angegeben.
 
Ja mist, hätte den Server vorhin nicht neu starten sollen. :eek:

Aber er gibt mir die Warnung heraus:
Code:
Total fragmented tables: 83

...obwohl ich die Tabellen Optimiert habe:
Code:
mysqlcheck -uUSER -pPASS -hlocalhost --optimize --all-databases
 
MySQL 5.5 erreicht demnächst sein EoL, somit lohnt sich hier eine Optimierung nicht mehr.l]
Dec. 2018 ist von "demnächst" aber noch ein wenig entfernt.

Im Rahmen von z.B. CentOS ist die 5.5 auch noch bis 2020 / 2024 gepflegt.
 
Dec. 2018 ist von "demnächst" aber noch ein wenig entfernt.
Oops, habe ich mit den von Oracle bereitgestellten Binary-Paketen verwechselt, die laufen demnächst alle aus.
Der Source wird tatsächlich noch bis 12.2018 mit Security-Fixes versorgt.

Im Rahmen von z.B. CentOS ist die 5.5 auch noch bis 2020 / 2024 gepflegt.
Echt jetzt? Müssen wir dieses antike Stück noch so lange ertragen? 6 Jahre nahezu ohne Security-Fixes?


Bin ich froh, dass ich seit über 10 Jahren auf Rolling-Releases setze und so sowohl alle Securty-Fixes als auch Bugfixes zeitnah erhalte. Gerade in Zeiten wo Security-Fixes immer seltener als solche gekennzeichnet werden und deshalb nicht bei den Binary-Distros gefixt werden, ist das ein enormer Vorteil.


OK, genug OT ;)
 
Dann bleibe ich noch bei v5.5.

Hier mal die Ausgabe von MySQLTuner:

Code:
 >>  MySQLTuner 1.7.0 - Major Hayden <[email protected]>
 >>  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
[OK] Logged in using credentials from debian maintenance account.
[OK] Currently running supported MySQL version 5.5.52-0+deb8u1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Data in MEMORY tables: 914K (Tables: 2)
[--] Data in InnoDB tables: 2M (Tables: 77)
[--] Data in MyISAM tables: 2G (Tables: 262)
[OK] Total fragmented tables: 0

-------- Security Recommendations ------------------------------------------------------------------
[OK] There are no anonymous accounts for any database users
[OK] All database users have passwords assigned
[--] There are 612 basic passwords in the list.

-------- CVE Security Recommendations --------------------------------------------------------------
[!!] CVE-2016-6662(<= 5.5.52) : "Oracle MySQL through 5.5.52
[--] False positive CVE(s) for MySQL and MariaDB 5.5.x can be found.
[--] Check careful each CVE for those particular versions
[!!] 1 CVE(s) found for your MySQL release.

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 3d 23h 20m 56s (19M q [57.703 qps], 1M conn, TX: 1080G, RX: 6G)
[--] Reads / Writes: 83% / 17%
[--] Binary logging is disabled
[--] Physical Memory     : 7.7G
[--] Max MySQL memory    : 1.5G
[--] Other process memory: 775.6M
[--] Total buffers: 192.0M global + 2.7M per thread (500 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 226.9M (2.86% of installed RAM)
[OK] Maximum possible memory usage: 1.5G (19.38% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (1/19M)
[OK] Highest usage of available connections: 2% (13/500)
[OK] Aborted connections: 0.01%  (114/1526183)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[!!] Query cache may be disabled by default due to mutex contention.
[OK] Sorts requiring temporary tables: 2% (34K temp sorts / 1M sorts)
[!!] Joins performed without indexes: 9658
[OK] Temporary tables created on disk: 7% (12K on disk / 167K total)
[OK] Thread cache hit rate: 99% (36 created / 1M connections)
[OK] Table cache hit rate: 23% (400 open / 1K opened)
[OK] Open file limit used: 22% (557/2K)
[OK] Table locks acquired immediately: 99% (15M immediate / 15M locks)

-------- Performance schema ------------------------------------------------------------------------
[--] Performance schema is disabled.

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is disabled.

-------- MyISAM Metrics ----------------------------------------------------------------------------
[OK] Key buffer used: 100.0% (16M used / 16M cache)
[OK] Key buffer size / total MyISAM indexes: 16.0M/661.1M
[OK] Read Key buffer hit rate: 98.9% (991M cached / 11M reads)
[!!] Write Key buffer hit rate: 72.1% (49M cached / 13M writes)

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[OK] InnoDB buffer pool / data size: 128.0M/2.1M
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (3.90625 %): 5.0M/128.0M should be equal 25%
[OK] InnoDB buffer pool instances: 1
[--] InnoDB Buffer Pool Chunk Size not used or defined in your version
[OK] InnoDB Read buffer efficiency: 99.98% (2164473 hits/ 2165007 total)
[!!] InnoDB Write Log efficiency: 77.19% (12588 hits/ 16308 total)
[OK] InnoDB log waits: 0.00% (0 waits / 28896 writes)

-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is disabled.

-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.

-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.

-------- RocksDB Metrics ---------------------------------------------------------------------------
[--] RocksDB is disabled.

-------- Spider Metrics ----------------------------------------------------------------------------
[--] Spider is disabled.

-------- Connect Metrics ---------------------------------------------------------------------------
[--] Connect is disabled.

-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] This is a standalone server.

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    1 CVE(s) found for your MySQL release. Consider upgrading your version !
    Enable the slow query log to troubleshoot bad queries
    Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
    Adjust your join queries to always utilize indexes
Variables to adjust:
    query_cache_type (=0)
    join_buffer_size (> 128.0K, or always use indexes with joins)
    innodb_log_file_size should be equals to 1/4 of buffer pool size (=32M) if possible.
 
Abgesehen von zwei Dingen schaut es erstmal nicht allzu schlecht aus:

Code:
[OK] Key buffer size / total MyISAM indexes: 16.0M/661.1M
Du solltest die key_buffer_size auf 256 MB setzen.

Noch Besser wäre es, zusätzlich Deine Datenbank-Schemata von MyISAM auf InnoDB umzustellen.


Code:
[!!] Joins performed without indexes: 9658
Das liegt an kaputten WebApps, daran lässt sich auf Seiten von MySQL nix ändern. Aber die verursachenden WebApps sollten dringend aktualisiert oder durch vernünftig gepflegte, aktuelle Alternativen ersetzt werden.


Ich empfehle dennoch die my.cnf komplett zu überarbeiten und wichtige Optionen zu ergänzen. Dafür eignet sich meine Beispiel-my.cnf ganz gut.
 
Du kannst ja auch zusätzlich noch mal tuning-primer drüber laufen lassen - da bekommt man für mein Empfinden noch "bessere" Rückmeldungen.

Zudem auch einfach mal schauen, wie groß die DBs an sich überhaupt sind, was macht der Server noch parallel, evtl. mal noch munin mitlaufen lassen, ...
 
Back
Top