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 !!!
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.
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:
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.
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
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.
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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 187293
Url: https://administrator.de/contentid/187293
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
5 Kommentare
Neuester Kommentar
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.
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.
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:
Beides sind ohnehin die ersten Dinge, an denen jeder geschraubt hätte:
Kläre zusätzlich in deinem Datenmodell, ob die bedingungen
...so redundant sind, wie zu befürchten ist.
Sprich: gibt es denn z.b einen real existierenden Fall, in dem
und selbst wenn, löse es wie von maretz angeregt, über einen Join auf ein
Grüße
Biber
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)
[!!] 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)
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
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?
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?