MySql optimieren

Unifex

New Member
Hallo, ich hätte gerne etwas Hilfe bei der Optimierung eines MySQL Servers. Letztens hatte ich das erste mal einen Absturz einer Datenbank und da bin ich mal auf die Suche gegangen nach dem möglichen Fehler.

Auf dem Server laufen drei Foren . Eines davon hat so 6000 Besucher am Tag.

Einige Werte von Tuning Primer machen mir ein wenig Sorgen.

Ausgabe Tuning Primer:

Code:
MySQL Version 5.1.58-1ubuntu1 x86_64

Uptime = 2 days 9 hrs 46 min 0 sec
Avg. qps = 47
Total Questions = 9864543
Threads Connected = 1

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.1/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 NOT enabled.
Current long_query_time = 10.000000 sec.
You have 0 out of 9864564 that take longer than 10.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.1/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 16
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 = 150
Current threads_connected = 1
Historic max_used_connections = 17
The number of used connections is 11% of the configured maximum.
Your max_connections variable seems to be fine.

INNODB STATUS
Current InnoDB index space = 0 bytes
Current InnoDB data space = 0 bytes
Current InnoDB buffer pool free = 99 %
Current innodb_buffer_pool_size = 1.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 : 3.24 G
Configured Max Per-thread Buffers : 2.11 G
Configured Max Global Buffers : 3.00 G
Configured Max Memory Limit : 5.11 G
Physical Memory : 31.40 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 398 M
Current key_buffer_size = 1.00 G
Key cache miss rate is 1 : 1344
Key buffer free ratio = 77 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 1.00 G
Current query_cache_used = 225 M
Current query_cache_limit = 4 M
Current Query cache Memory fill ratio = 22.01 %
Current query_cache_min_res_unit = 2 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 8.00 M
You have had 9393 queries where a join could not use an index properly
join_buffer_size >= 4 M
This is not advised
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.

OPEN FILES LIMIT
Current open_files_limit = 10160 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 = 5000 tables
Current table_definition_cache = 2000 tables
You have a total of 992 tables
You have 1050 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 64 M
Current tmp_table_size = 64 M
Of 403900 temp tables, 16% were created on disk
Created disk tmp tables ratio seems fine

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

TABLE LOCKING
Current Lock Wait ratio = 1 : 59
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'

Der Rechner hat Ram ohne Ende sowie 8 Cores und da soll demnächst noch ein großes Forum mit 10.000 Besuchern am Tag rauf aber erst mal die kleinen Probleme lösen.


Hier die my.cnf

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]
#
# * Basic Settings
#

#
# * IMPORTANT
#   If you make changes to these settings and your system uses apparmor, you may
#   also need to also adjust /etc/apparmor.d/usr.sbin.mysqld.
#

user		= mysql
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
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		= 256M
max_allowed_packet	= 64M
thread_stack		= 192K
thread_cache_size       = 16
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
max_connections        = 150
table_cache            = 5000
table_definition_cache = 2000 
thread_concurrency     = 8
read_buffer_size = 4M
join_buffer_size = 8M
concurrent_insert=2
query_cache_min_res_unit = 2K

#
# * Query Cache Configuration
#
query_cache_limit	= 4M
query_cache_size  = 1G

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

log_error                = /var/log/mysql/error.log

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

max_heap_table_size = 64M
tmp_table_size = 64M

#low_priority_updates=1

innodb_buffer_pool_size = 1G
key_buffer_size = 1G


[mysqldump]
quick
quote-names
max_allowed_packet	= 16M

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

[isamchk]
key_buffer		= 16M

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

Mag da einer der Experten mal einen Blick drauf werfen und seine Meinung dazu sagen.

Vielen Dank
 
Hallo!
Keine Experten da oder schon im Wochenende? ;)
Die Experten können leider dein konkretes Problem nicht feststellen.

Hallo, ich hätte gerne etwas Hilfe bei der Optimierung eines MySQL Servers.
Was läuft denn nicht oder schlecht?

Letztens hatte ich das erste mal einen Absturz einer Datenbank und da bin ich mal auf die Suche gegangen nach dem möglichen Fehler.
Auf einen möglichen Fehler wirst du doch bereits hingewiesen:
Code:
JOINS
Current join_buffer_size = 8.00 M
You have had 9393 queries where a join could not use an index properly
join_buffer_size >= 4 M
[COLOR="Red"]This is not advised[/COLOR]
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
mfG
Thorsten
 
Einige Werte von Tuning Primer machen mir ein wenig Sorgen.
Welche genau?

Folgendes würde mir Sorgen bereiten:
Code:
The slow query log is NOT enabled.
Current long_query_time = 10.000000 sec.

The binary update log is NOT enabled.
You will not be able to do point in time recovery

Current max_connections = 150
Historic max_used_connections = 17

Current innodb_buffer_pool_size = 1.00 G

Current MyISAM index space = 398 M
Current key_buffer_size = 1.00 G

Current query_cache_size = 1.00 G
Current query_cache_used = 225 M

Current join_buffer_size = 8.00 M
You have had 9393 queries where a join could not use an index properly
Code:
#
max_allowed_packet	= 64M
max_connections        = 150
join_buffer_size = 8M
concurrent_insert=2
query_cache_size  = 1G
#log_slow_queries	= /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#server-id		= 1
#log_bin			= /var/log/mysql/mysql-bin.log
innodb_buffer_pool_size = 1G
key_buffer_size = 1G
!includedir /etc/mysql/conf.d/
Jede einzelne gequotete Zeile macht mir Sorgen...
 
Hallo!


Auf einen möglichen Fehler wirst du doch bereits hingewiesen:
Code:
JOINS
Current join_buffer_size = 8.00 M
You have had 9393 queries where a join could not use an index properly
join_buffer_size >= 4 M
[COLOR="Red"]This is not advised[/COLOR]
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
mfG
Thorsten


Tja, diese Meldung z.B.
Einerseits join_buffer_size >= 4 M This is not advised

Was sagt mir das? Ist der Wert falsch?

Resultieren daraus die 9393 Queries oder hängt das nicht zusammen?

Weitere Frage ist mit der Meldung "Of 403900 temp tables, 16% were created on disk"

Das ist irgendwie auch nicht so toll. Könnte "tmp_table_size" erhöhen etwas bewirken, um den Wert kleiner zu bekommen oder ganz zu eliminieren. Ram hat die Kiste ja genug?

Am Meisten Sorgen macht mir aber der Wert: Current Lock Wait ratio = 1 : 59
Ich meine, dass ist ein echt schlechter Wert.

Dort wird empfohlen "low_priority_updates=1" anzuwenden aber was hat das für eine Auswirkung auf das gesamte System. Hat das schon mal jemand ausprobiert?

Danke schon mal für eure Antworten.
 
Eins Vorab: Ein bisschen Google und MySQL-Doku lesen hilft Zusammenhänge zu verstehen. Diese Zusammenhänge braucht man um nicht wild irgendwelche Werte hoch zu schrauben. Denn damit belegst Du nur Speicher der nie benutzt wird, und daher nicht als Festplatten-Cache zur Verfügung steht.

Resultieren daraus die 9393 Queries oder hängt das nicht zusammen?
Nein, kommt von "a join could not use an index".

Weitere Frage ist mit der Meldung "Of 403900 temp tables, 16% were created on disk"
Joins über Tabellen mit TEXT/BLOB-Feldern werden immer auf Disk erzeugt. Wobei "Disk" nicht zu 100% "Festplatte" bedeutet da ja auch ein HD-Cache fungiert. Im Idealfall werden die Daten schneller gelöscht als der Cache sie auf die Platte schreiben kann.

Current Lock Wait ratio = 1 : 59
Ich meine, dass ist ein echt schlechter Wert.
Test-Frage, ob Du überhaupt eine Beurteilung des Wertes machen kannst:
Welcher Wert wäre denn besser?

"low_priority_updates=1" anzuwenden aber was hat das für eine Auswirkung auf das gesamte System.
Zitat aus der MySQL-Doku
Code:
Wenn diese Variable den Wert 1 hat, warten alle INSERT-, UPDATE-, DELETE- und LOCK TABLE WRITE-
Anweisungen, bis keine SELECT- oder LOCK TABLE READ-Anweisungen für die betreffende Tabelle mehr
anhängig sind.

Und schau Dir auch den Beitrag von Joe an. Der zeigt einige Buffer auf, die Maßlos überzogen sind.
Lediglich beim innodb_buffer_pool_size liegt er falsch. Da Du offensichtlich keine InnoDB-Tabellen verwendest (warum eigentlich nicht, könnte bei einigen Tabellen sicherlich etwas bringen) ist dieser Wert egal.

huschi.
 
Lediglich beim innodb_buffer_pool_size liegt er falsch. Da Du offensichtlich keine InnoDB-Tabellen verwendest (warum eigentlich nicht, könnte bei einigen Tabellen sicherlich etwas bringen) ist dieser Wert egal.
Jain, wozu einen Buffer alloziieren, wenn er gar nicht benötigt wird? Deutlich runter damit und über weiteren anderweitig nutzbaren RAM freuen.
Oder komplett auf InnoDB umstellen, aber dann muss die my.cnf ebenfalls komplett überarbeitet werden und innodb_buffer_pool_size wäre dennoch um 50% zu hoch.
 
Auf InnoDB habe ich nicht umgestellt, weil ich in einigen Foren gelesen habe, dass es im Zusammenspiel mit der Forumssoftware, die auch hier eingesetzt wird, zu einer Verlangsamung kommen soll, weil InnoDB in meiner MySQL Version sagen wir mal nicht so ganz die Performance haben soll.
 
Hallo!

Von welcher vBulletin Version sprechen wir denn? 3.8 oder 4.1? Den spürbaren Performance Gewinn (reine Datenbankgeschwindigkeit) würde ich nicht überbewerten. Wie groß ist dein Forum (Posts und Benutzer)?

mfG
Thorsten
 
MOD: Fullquote entfernt.

Die Version 4.1

Knapp 250.000 Posts ca. 5000 Benutzer. Immer so um die 200 - 400 Leute gleichzeitig online.

Knapp 5.000 bis 8.000 Besucher am Tag, Tendenz steigend. Habe noch ein anderes Forum, da kann man man so ungefähr die Werte mal zwei nehmen. Es ist also noch größer.

Das zweite Forum soll später auch noch auf den Server umziehen. Darum ist alles auch ein wenig großzügiger in den Werten eingestellt.
 
Last edited by a moderator:
Hallo!

vB4 kann sehr wohl mit InnoDB umgehen. Im Gegensatz zur 3.8er ist es trotzdem ein echter Performance Killer.

Zur technischen Qualität der Artikel kann ich nicht viel sagen, aber schau dir doch beispielsweise mal die Artikel von IBxAnders an. Der hat einiges zum Thema vBulletin und Datenbanken getestet und geschrieben.

mfG
Thorsten
 
Vielen Dank, Den Artikel kenne ich. Ich habe das auch schon mal auf einem Testboard umgesetzt und es gab da leider Probleme. z.B: Massig Doppelposts.

@Huschi

Thema Current Lock Wait ratio = 1 : 59

Wenn ich das richtig lese, bedeutet dieser Wert doch, das bei jeder 59´sten Anfrage an die Datenbank ein Lock stattfindet.

Daher find eich den Wert schlecht, den bei mit gibt es sicherlich hunderttausende Anfragen nur an einem Tag.

Also denke ich ein Ratio 1 : 100 wäre besser. Noch besser allerdings 1:1000
oder noch höher.

Gibt es vielleicht die Möglichkeit herauszufinden, welche Abfragen diese Locks verursachen oder kann.

Ich meine ich habe mir mal die offenen Tabellen angeschaut und da dann auch Name_locked aber der Wert ist immer 0

Vielleicht mache ich mir aber auch einfach nur zu viel Gedanken, denn das Board läuft eigentlich ganz schön schnell.
 
bedeutet dieser Wert doch, das bei jeder 59´sten Anfrage an die Datenbank ein Lock stattfindet.
Bei jedem 60igsten aber wir sind ja nicht kleinlich. :)
Wenn Du das nun weißt, ist die konkrete Frage, wie man die Locks analysiert und sogar vermeidet.
Dazu folgend Fragen und Hinweise:
Was sind Locks, wann entstehen die? (Immer bei Joins und Where-Klauseln)
Wie kommt man den längeren Locks auf die Spur? (Kleiner Wert in long_query_time und einschalten von long_query_log.)
Womit verkürzt man die Lock-Zeiten? (Z.B. InnoDB weil Locks auf einzelne Datensätze ausgesprochen werden können statt auf die ganze Tabelle wie bei MyIsam. Oder mit besseren Indizes.)
Wie vermeidet man einige Locks? (Z.B. mit low_priority_updates.)

huschi.
 
Fein, ich wusste ja hier sind Experten :)

Ich werde mich mal mit diesen Hinweisen auf die Suche machen und ich würde drauf wetten, es ist nur eine Tabelle die da zicken macht.
Vielleicht sogar ein Vbulletin Plugin oder etwas ähnliches.

Vielen Dank für die Hilfe.
 
Back
Top