freaky-boy
Goto Top

MySQL-Server richtig einstellen

Ich bin vor kurzen mit meinem Server umgezogen und habe mit dem neuen SQL-Server Probleme. Er ist meiner Meinung nach zu langsam.

Hallo Zusammen,

ich habe ein Browsergame programmiert, dieses jetzt auf einen Strato VServer gelegt und somit veröffentlicht. Allerding bin ich der Meinung, dass irgendetwas mit den Einstellungen des MySQL-Servers nicht stimmen kann. Vorher ging die Abarbeitung der Befehle wesentlich schneller.
Für diesen Befehl, der zwar von der Zeit her wirklich aufwendig ist, braucht mein MySQL-Server 50 Sekunden !!!
<?
	$query = "UPDATE `pcs` SET `score` =   
	(
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`case` AND `market`.`TYPE_ID` = 1) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`power` AND `market`.`TYPE_ID` = 2) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`fan1` AND `market`.`TYPE_ID` = 7) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`fan2` AND `market`.`TYPE_ID` = 7) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`fan3` AND `market`.`TYPE_ID` = 7) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`fan4` AND `market`.`TYPE_ID` = 7) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`cooling` AND `market`.`TYPE_ID` = 7) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`board` AND `market`.`TYPE_ID` = 3) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`cpu` AND `market`.`TYPE_ID` = 5) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`ram1` AND `market`.`TYPE_ID` = 4) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`ram2` AND `market`.`TYPE_ID` = 4) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`ram3` AND `market`.`TYPE_ID` = 4) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`ram4` AND `market`.`TYPE_ID` = 4) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`ram5` AND `market`.`TYPE_ID` = 4) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`ram6` AND `market`.`TYPE_ID` = 4) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`hdd1` AND `market`.`TYPE_ID` = 6) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`hdd2` AND `market`.`TYPE_ID` = 6) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`hdd3` AND `market`.`TYPE_ID` = 6) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`hdd4` AND `market`.`TYPE_ID` = 6) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`hdd5` AND `market`.`TYPE_ID` = 6) +
	(SELECT `price` FROM `market` WHERE `market`.`PART_ID` = `pcs`.`hdd6` AND `market`.`TYPE_ID` = 6) +
	(SELECT `price` FROM `os` WHERE `os`.`ID` = `pcs`.`system`) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`OB` AND `calculations`.`PRG_ID` = 1) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`BM` AND `calculations`.`PRG_ID` = 2) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`FW` AND `calculations`.`PRG_ID` = 3) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`AV` AND `calculations`.`PRG_ID` = 4) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`HT` AND `calculations`.`PRG_ID` = 5) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`AO` AND `calculations`.`PRG_ID` = 6) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`DT` AND `calculations`.`PRG_ID` = 7) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`CK` AND `calculations`.`PRG_ID` = 8) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`SM` AND `calculations`.`PRG_ID` = 9) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`DM` AND `calculations`.`PRG_ID` = 10) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`SC` AND `calculations`.`PRG_ID` = 11) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`RT` AND `calculations`.`PRG_ID` = 12) +
	(SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`BC` AND `calculations`.`PRG_ID` = 13)
	) / 1000
	WHERE `USER_ID` != 0;";  
	$response = $db->query($query);
?>

Auch wenn ich hier viele Einzelabfragen habe, ist eine Zeit von 50 Sekunden wohl sehr weit weg von der Realität.
Was mich an der ganzen Sache noch stutzig macht, ist dass mein Server kaum Arbeitsspeicher benutzt, dafür aber eine relativ hohe CPU-Auslastung aufweist. Der Rechner hat 4GB RAM die ich sicher auch gern nutzen möchte.
6c192e1b02235214a4f2d1d9420178be

Leider kenne ich mich mit der Konfiguration eines MySQL-Servers nicht aus deswegen bin ich hier her gekommen.
Zudem ärgern mich die roten Einträge im phpmyadmin-Stutus:
Slow_queries 73
Innodb_buffer_pool_reads 36
Handler_read_rnd 120,2 k
Handler_read_rnd_next 542,4 M
Created_tmp_disk_tables 24,5 k
Key_writes 30,2 k
Select_full_join 832
Sort_merge_passes 2
Opened_tables 5,9 k
Table_locks_waited 20,5 k 
Leider kann ich davon nichts verstehen und habe auch keine Ahnung ob eines davon der Grund ist warum meine Datenbank so langsam ist. Oder einfach nur eine Folge einer falschen Einstellung

Als letztes hätte ich dann noch die config-Datei vom MySQL-Server im Angebot. Ich vermute, mit meinem wenigen Wissen, dass darin der Fehler liegen könnte. Nur leider fehlt mir, wie schon erwähnt, das Wissen wie MySQL im Hintergrund funktioniert.
#
# 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		= 16M
max_allowed_packet	= 16M
thread_stack		= 256K
thread_cache_size       = 32
# 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            = 512
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit	= 5M
query_cache_size        = 32M
#
# * 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



[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/

Ich würde mich sehr freuen, wenn mir jehmand mit dem Problem helfen kann. Wenn irgendwelche Daten fehlen, werde ich die natürlich nachliefern.

Vielen Dank und freundliche Grüße
Freaky-Boy

Content-Key: 187293

Url: https://administrator.de/contentid/187293

Ausgedruckt am: 29.03.2024 um 00:03 Uhr

Mitglied: maretz
maretz 30.06.2012 um 21:44:35 Uhr
Goto Top
Ich uerde mal dein sqlstatement optimieren.... Es kann nicht das optimum sein das statement (z.b. Unterer bereich) 13 mal nur mit einem geaenderten parameter auszufuehren... Da darfst nochmal druebergucken....
Mitglied: dog
dog 01.07.2012 aktualisiert um 02:22:24 Uhr
Goto Top
Es gibt ein Script was dir automatisch Optimierungen anbietet:

http://mysqltuner.pl/mysqltuner.pl

4GB RAM auf einem vServer heißen auch gar nichts.
Das ist der Maximalwert, wirklich relevant ist nur was in deinem Vertrag garantiert ist.
Mitglied: Freaky-Boy
Freaky-Boy 01.07.2012 um 17:58:50 Uhr
Goto Top
Der hier aufgezeigt Befehl ist nur ein Beispiel und in dem Fall das krasseste Beispiel.
Eine normale Abfrage mit einem einfachen Join dauert auch schon 0,2 Sekunden. Das ist mir zu lang. Da bin ich anderes gewohnt.

 >>  MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering  

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.63-0ubuntu0.10.04.1
[!!] 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: 3M (Tables: 475)
[--] Data in InnoDB tables: 320K (Tables: 20)
[!!] Total fragmented tables: 82

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 2d 6h 1m 38s (1M q [10.065 qps], 136K conn, TX: 710M, RX: 538M)
[--] Reads / Writes: 50% / 50%
[--] Total buffers: 74.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 489.2M (11% of installed RAM)
[OK] Slow queries: 0% (115/1M)
[OK] Highest usage of available connections: 31% (48/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/2.1M
[OK] Key buffer hit rate: 100.0% (48M cached / 939 reads)
[OK] Query cache efficiency: 40.9% (363K cached / 889K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (2 temp sorts / 215K sorts)
[!!] Joins performed without indexes: 1239
[OK] Temporary tables created on disk: 20% (27K on disk / 133K total)
[OK] Thread cache hit rate: 99% (51 created / 136K connections)
[!!] Table cache hit rate: 6% (512 open / 8K opened)
[OK] Open file limit used: 47% (558/1K)
[OK] Table locks acquired immediately: 99% (3M immediate / 3M locks)
[OK] InnoDB data size / buffer pool: 320.0K/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Adjust your join queries to always utilize indexes
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    join_buffer_size (> 128.0K, or always use indexes with joins)
    table_cache (> 512)
Das mit der automatischen Optimierung ist zwar schön aber bringt mir nicht wenn ich mit der Konfiguration nicht auskenne.
Zugesichert sind mir 2 GB.
Mitglied: Biber
Biber 01.07.2012 aktualisiert um 19:17:07 Uhr
Goto Top
Moin Freaky-Boy,

was erwartest du denn, was wir auf Grund der paar Infos hier an tollen Tipps liefern können?
Die offensichtlichen und banalen Klemmer tauchen ja auch - nicht weiter überraschend - in dem Optimize-Ratgeber auf:
[!!] Joins performed without indexes: 1239
[!!] Table cache hit rate: 6% (512 open / 8K opened)

Beides sind ohnehin die ersten Dinge, an denen jeder geschraubt hätte:
  • unterstütze deine Join- und erst recht die FK-Beziehungen durch entsprechende Indizes
  • setz den table_cache hoch von 512 auf 2048

Kläre zusätzlich in deinem Datenmodell, ob die bedingungen
...WHERE `market`.`PART_ID` = `pcs`.`fan1` AND `market`.`TYPE_ID` = 7) + 

-- und --
..SELECT `cost` FROM `calculations` WHERE `calculations`.`level` = `pcs`.`DM` AND `calculations`.`PRG_ID` = 10)
...so redundant sind, wie zu befürchten ist.
Sprich: gibt es denn z.b einen real existierenden Fall, in dem calculations.level = pos.DM ist, aber calculations.PRG_ID nicht gleich 10 ?? Ich denke nein.

und selbst wenn, löse es wie von maretz angeregt, über einen Join auf ein SELECT sum(cost) as cost , level, PRG_ID from calculations group by level, PRG_ID und mach das WHERE (level = 'DM' AND PRG_ID = 10) or (level='XY' and PRG_ID=99..) in der WHERE-Clause am Ende.

Grüße
Biber
Mitglied: maretz
maretz 02.07.2012 um 08:01:03 Uhr
Goto Top
Moin,

bevor du aber die ganze Konfig umwirfst wäre es besser deine Abfragen zu optimieren... Hast du z.B. bei den ganzen Formulierungen nur "Varchar" oder ähnliche Typen drin? Gibt es zwingende Gründe warum du keinen Index verwendest?

Ich würde mal sagen das deine cache-hit-rate soweit weg von gut und böse ist das es da definitiv noch optimierungspotential gibt.

Erst wenn du die Abfragen optimiert hast kann man sich die Konfig angucken. Vorher ist es Zeitverschwendung da was zu ändern. Ist ja schön wenn die Konfig (einmalig) verbessert wird - dafür aber 10 Abfragen pro Sekunde reinhageln die durch mangelnde Optimierung zuviel Zeit kosten... Einmal Sparen, Zehnmal verschwenden - hört sich das für dich optimal an?