MySQL Optimierung habe keinen Plan mehr:(

V-T

New Member
Sehr geehrte Community,

ich haben einen Server

Intel E2620 mit 12 Cores inkl der Virtuellen Threads.
64 GB DDR3 ECC RAM
1 Gbit Leitung

Plesk 12 ist Installiert sowie Debian 7.7

Die Anbindung zum Storage ist mit 4x 1 Gbit angebunden.
Dann ist ein Storage mit Nexenta und 16 x 2 TB Festplatten zzgl. SSD als CACHE Platten.

Die Performance ist soweit ok.

Code:
#
# 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]
local-infile=0
#
# * 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		= 512M
max_allowed_packet	= 64M
sort_buffer_size = 1M
read_buffer_size = 1M
read_buffer = 4M
read_rnd_buffer_size = 1M
myisam_sort_buffer_size = 512M
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
join_buffer_size = 2M

open_files_limit        = 1024000
table_cache             = 256000
table_open_cache        = 128M
table_definition_cache  = 64M
thread_concurrency     = 18
#low_priority_updates=1
concurrent_insert=2

myisam_sort_buffer_size=128M


#
# * Query Cache Configuration
#
query_cache_type = 1
query_cache_limit	= 4M
query_cache_size        = 320M
query_cache_min_res_unit = 8K
#
# * 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 logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf.
#
# 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
#
innodb_flush_log_at_trx_commit = 0
low_priority_updates=1
innodb_buffer_pool_size=4G
innodb_thread_concurrency = 12
# 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



[mysqldump]
quick
quote-names
max_allowed_packet	= 256M

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

[isamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

#
# * 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/

Wir haben einen Online Shop mit ca 200000 T. (CSV Datei knapp 350MB) Artikel wenn wir den CSV Import machen dauert der Import knapp 4 Stunden

Die I/O Waits sind nicht einmal bei 1
aber das dauert einfach, ist zu Langsam.

Ich habe diese Werte nach langen hin und her mit Tuningprimer angepasst aber irgendwas übersehe ich oder ist das normal und MYSQl kann nicht schneller. Der Shop ist ein Gambio GX2 angepasst Version

Code:
MySQL Version 5.5.40-0+wheezy1-log x86_64

Uptime = 1 days 0 hrs 2 min 30 sec
Avg. qps = 141
Total Questions = 12279596
Threads Connected = 1

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 2.000000 sec.
You have 1061397 out of 12279617 that take longer than 2.000000 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 7
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 151
Current threads_connected = 1
Historic max_used_connections = 12
The number of used connections is 7% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

INNODB STATUS
Current InnoDB index space = 14 M
Current InnoDB data space = 110 M
Current InnoDB buffer pool free = 97 %
Current innodb_buffer_pool_size = 4.00 G
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 4.92 G
Configured Max Per-thread Buffers : 1.20 G
Configured Max Global Buffers : 4.82 G
Configured Max Memory Limit : 6.03 G
Physical Memory : 15.71 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 422 M
Current key_buffer_size = 512 M
Key cache miss rate is 1 : 7363
Key buffer free ratio = 18 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 320 M
Current query_cache_used = 125 M
Current query_cache_limit = 4 M
Current Query cache Memory fill ratio = 39.35 %
Current query_cache_min_res_unit = 8 K
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 1 M
Current read_rnd_buffer_size = 1 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 2.00 M
You have had 104 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 1024000 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_open_cache = 524288 tables
Current table_definition_cache = 524288 tables
You have a total of 1324 tables
You have 2547 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 16 M
Of 56738 temp tables, 27% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 4 M
Current table scan ratio = 67134 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 5078
Your table locking seems to be fine
 
TuningPrimer und Konsorten liefern eher Empfehlungen, die auf Read ausgelegt sind. Für maximalen Write-Durchsatz kann das schon komplett anders aussehen.

Für große Importe lohnt es sich ggf. für den Zeitpunkt des Imports Indice / Contraints / ... abzuschalten und diese dann nach dem Import manuell zu erstellen.
 
Wurden Sie mir das etwas näher erläutern habe die Begriffe noch nicht gehört

wie wurden die Werte den aussehen wenn wir sagen wir mal eine mittelmaß finden können ich könnte auch weitere 64 GB RAM dazu stecken wenn es sein muss
 
Anstatt mit Unmengen an überflüssiger teurer Hardware um Dich zu werfen, solltest Du lieber das Geld in einen Datenbankadministrator investieren, welcher Dir sowohl das DBMS als auch die Queries optimiert. Den Rest investierst Du in einen vernünftigen System-Administrator und lässt ihn als Erstes ein vernünftiges OS installieren, dann ein Sicherheitskonzept erstellen und natürlich ein Desasterrecovery umsetzen...

BTW: Deine Hardware übersteigt Deinen Bedarf um ein Vielfaches, wie willst Du das jemals wieder erwirtschaften? Wer auch immer Dich da beraten hat, hat Dich geschmeidig über den Tisch gezogen...
 
Dein Problem kann vielerlei sein, leider beschreibst du nicht was wo läuft.
Läuft auf dem Storage Mysql oder wird der auch auf dem Frontend betrieben?
Wie ist der Storage im Server gemounted und welche Mount-Optionen gibt es (auch im Backend falls zutreffend, bspw NFS)
Was cached die SSD im Storage. Reads, oder auch writes?

Als Anschauung:
* Mysql ist bspw sehr lahm wenn es auf einer EXT4-Partition liegt welche mit den Default-Parameter "barrier=1" gemountet ist. Bei Imports habe ich Unterschiede um den Faktor 30 gesehen.
* Über Gigabit angesprochene Mysql-Server sind ebenfalls um den Faktor 5 langsamer im reinen Query-Durchsatz als lokale Installationen.
* Das Einspielen über jeweils einzelne Queries gegenüber wenigen Queries mit mehreren Datenwerten ist je nach Größe der Queries bis Faktor 20 schneller.

Unter dem Strich: ich hoffe die Hardware wurde mit einem besseren Grund angeschafft als um poppelige 200k Zeilen unter zu bringen. Das kann ein einzelner süßer Hetzner EX4 mit SSD vermutlich sogar schneller als dieses aktuelle Setup mit dutzenden möglichen Fehlerquellen und verlangsamenden Faktoren. Nichts trumpft gut gewählte lokale Hardware in Leistung, ausser besser ausgewählte lokale Hardware.
 
Welches Filesystem wäre den hier am besten bzw welches OS.
Es gibt ja nicht gerade wenige davon.

Wir haben schon einige hundert Euros in die Administration gesteckt.

Die Daten liegen auf dem Storage und werden von den Nodes jeweils abgerufen und berechnet. Der Storage übernimmt keine Rechenaufgaben.

Lokal habe ich das auch probiert ist nur ein wenig schneller.
 
Welches Filesystem wäre den hier am besten bzw welches OS.
Es gibt nicht "das beste OS" für solche Sachen. Sowohl UNIX-Derivate inkl. alle Linux-Distros und OsX Server als auch Windows Server sind tauglich sofern man sie entsprechend vorbereitet und verwaltet.

Wir haben schon einige hundert Euros in die Administration gesteckt.
Ohne jetzt dich oder den Administrator angreifen zu wollen - aber was genau hat es geholfen? Geld auf ein Problem werfen reicht nicht immer, es muss richtig eingesetzt werden. Dazu gehört auch dass der Admin ggf mit entsprechenden Umgebungen vertraut ist.

Die Daten liegen auf dem Storage und werden von den Nodes jeweils abgerufen und berechnet
Evtl solltest du mal deutlich mehr Eckdaten angeben damit das Bild klarer wird, hier kann dir sonst leider niemand helfen. Mehrere Nodes klingt trotz anderer Beschreibung nach einem zentralen Mysql-Server. Oder verwendet ihr etwa read-only Slaves mit einem zentralen Update-Master? Oder doch etwa ein Multi-Master Setup? Fragen über Fragen...

Der Storage übernimmt keine Rechenaufgaben.
Definieren wir "keine Rechenaufgaben" gleich, also dass da NUR die Platzverwaltung läuft? Generell würde ich stark davon abraten Mysql's Datenspeicher über Netzwerk zu holen, das ist sogar nochmal deutlich langsamer als nur die Queries über Netzwerk zu pumpen - je nach Setup ist es aber ggf nicht vermeidbar.

Ich bräuchte ein (hypothetisches) Setup welches beschreibt welche Rechner mit Clients in Verbindung sind, welche Dienste auf den Rechner laufen und wie sie untereinander verkabelt sind und kommunizieren. Sobald das deutlich ist kann man ggf anfangen die Schwachpunkte zu suchen welche die Verlangsamung verursachen.
 
Back
Top