Performanceprobleme mit MySQL 4.0.18

[skyrunner]

Hallo,
ich habe hier ein mittelschweres Problem. Ich betreibe einen relativ großen Dienst mit über 10000 Nutzern. Diese loggen sich in das System bestehend aus PHP und mysql ein. Ab 200 eingeloggten Usern treten erhebliche Wartezeiten auf. (17s+)

Nun sehe ich grade bei ca. 200 eingeloggten Spielern, dass einige mySQL Prozesse ziemlich lange laufen:

Code: Select all

top - 11:13:38 up 65 days, 18:59,  1 user,  load average: 6.27, 4.61, 3.57
Tasks: 310 total,   1 running, 309 sleeping,   0 stopped,   0 zombie
Cpu(s):  57.0% user,  35.2% system,   0.0% nice,   7.8% idle
Mem:   1550596k total,   843412k used,   707184k free,    97320k buffers
Swap:  2096472k total,        0k used,  2096472k free,   545572k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28407 root      14   0  1068 1068  728 R  7.2  0.1   0:48.37 top
24794 mysql     11   0  101m 101m 2876 S  4.3  6.7   2:26.76 mysqld
24908 mysql     11   0 96068  93m 2876 S  4.0  6.2   2:41.90 mysqld
24897 mysql      9   0 96068  93m 2876 S  3.7  6.2   2:32.35 mysqld
24914 mysql      9   0 96068  93m 2876 S  3.4  6.2   2:10.86 mysqld
24959 mysql      9   0 96068  93m 2876 S  3.3  6.2   2:20.22 mysqld
24892 mysql      9   0 96524  94m 2876 S  3.1  6.2   2:18.41 mysqld
24913 mysql      9   0 96068  93m 2876 S  3.1  6.2   1:57.21 mysqld
24881 mysql     14   0 96524  94m 2876 S  2.5  6.2   2:09.00 mysqld
24997 mysql      9   0 96068  93m 2876 S  2.5  6.2   3:09.02 mysqld
24890 mysql     11   0 96524  94m 2876 S  2.4  6.2   2:15.30 mysqld
24973 mysql      9   0 96068  93m 2876 S  2.4  6.2   2:21.58 mysqld
24804 mysql      9   0  101m 101m 2876 S  2.3  6.7   2:13.03 mysqld
24894 mysql      9   0 96524  94m 2876 S  2.3  6.2   2:21.03 mysqld
25129 mysql      9   0 96068  93m 2876 S  2.2  6.2   2:15.98 mysqld
24940 mysql      9   0 96068  93m 2876 S  2.1  6.2   2:57.93 mysqld
25040 mysql      9   0 96068  93m 2876 S  1.9  6.2   1:40.17 mysqld
25097 mysql      9   0 96068  93m 2876 S  1.8  6.2   2:24.59 mysqld
24809 mysql      9   0  101m 101m 2876 S  1.7  6.7   1:54.61 mysqld
24822 mysql     11   0 98812  96m 2876 S  1.7  6.4   2:17.73 mysqld
24815 mysql      9   0 98812  96m 2876 S  1.6  6.4   2:37.04 mysqld
24829 mysql      9   0 96068  93m 2876 S  1.6  6.2   2:11.44 mysqld
24970 mysql      9   0 96068  93m 2876 S  1.6  6.2   2:38.05 mysqld
24977 mysql      9   0 98792  96m 2876 S  1.6  6.4   2:22.14 mysqld
25127 mysql      9   0 96068  93m 2876 S  1.6  6.2   2:18.37 mysqld
24807 mysql      9   0  101m 101m 2876 S  1.5  6.7   2:28.85 mysqld
24998 mysql      9   0 96068  93m 2876 S  1.5  6.2   2:08.06 mysqld
25039 mysql      9   0 96068  93m 2876 S  1.5  6.2   2:56.07 mysqld
24811 mysql      9   0  101m 101m 2876 S  1.3  6.7   2:11.31 mysqld
24963 mysql      9   0 96068  93m 2876 S  1.3  6.2   2:19.02 mysqld
25079 mysql      9   0 96068  93m 2876 S  1.3  6.2   2:06.53 mysqld
25007 mysql      9   0 96068  93m 2876 S  0.8  6.2   2:13.24 mysqld
25078 mysql      9   0 96068  93m 2876 S  0.5  6.2   2:29.34 mysqld
24939 mysql      9   0 96068  93m 2876 S  0.3  6.2   3:07.89 mysqld
24833 mysql      9   0 96068  93m 2876 S  0.2  6.2   2:16.28 mysqld
24817 mysql      9   0 98812  96m 2876 S  0.1  6.4   2:25.57 mysqld
24965 mysql      9   0 96068  93m 2876 S  0.1  6.2   2:02.47 mysql

Zu Spitzenzeiten steigt dann die Load auch bis auf 30 an.
Ich habe bereits alle von mysql als langsam gekennzeichnete querys untersucht und abgeändert, sodass es jetzt keine slow querys mehr gibt. Ich habe durchschnittlich 2000 mysql Anfragen pro Sekunde. Ich dachte es könne eventuell daran liegen, wolte aber vorher nochmal egrn die Expertenmeinungen anhören.

Meine my.cnf sieht übrigens so aus:

Code: Select all

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock
#skip-locking
set-variable    = key_buffer=512M
set-variable    = max_allowed_packet=2M
set-variable    = table_cache=6048
set-variable    = sort_buffer=12M
set-variable    = record_buffer=12M
set-variable    = thread_cache=1024
set-variable    = max_connections=4000
set-variable    = wait_timeout=100000
set-variable    = interactive_timeout=100000
#set-variable   = query_cache=256M

# Try number of CPU's*2 for thread_concurrency
set-variable    = thread_concurrency=2
set-variable    = myisam_sort_buffer_size=8M
#log-bin
server-id       = 1
#skip-networking

Ich betreibe einen Webserver und einen Datenbankserver als 2 physikalische Maschinen. Zwischen beiden steht zwar zur zeit nur eine Verbindung von 100MBit, was aber meiner Meinung nicht der Hauptgrund für die Performanceprobleme sein kann.

ich würde mich sehr freuen wenn Ihr mal eure Configs posten würdet, damit ich einen Anhaltspunkt habe, was ich anders einstellen muss, damit das System wieder stabil läuft. Achja ich verwende debian woody mit einem amd athlon xp 2800 und 1,5gb ram

Danke
Skyrunner

[oxygen]

Query Cache aktivieren, persistent connections deaktivieren.

[skyrunner]

Query Cache aktivieren, persistent connections deaktivieren.

Wie aktiviere ich den Query cache?
Und warum persistent connections deakivieren? Wenn jedes mal eine neue verbindung aufgebaut werden muss, dann verlangsamt das doch alles oder sehe ich das falsch? Habe ich zumindest iirgendwo mal gelesen.

Danke für deine Schnelle Antwort!

/edit:
./mysqld: variable prefix 'query_cache=256M' is not unique

Was ahbe cih da falsch eingetippert?

[oxygen]

Eine Konfiguration für dem Query Cache sähe z.b. so aus:

query_cache_size = 12M
query_cache_limit = 512K
query_cache_type = 1


http://dev.mysql.com/doc/mysql/de/Query_Cache.html
http://de.php.net/features.persistent-connections

[Joe User]

Und warum persistent connections deakivieren?

http://www.php.net/manual/en/function.m ... onnect.php
http://www.php.net/manual/en/features.p ... ctions.php

[skyrunner]

So, hab alles erstmal geändert.
Jetzt sind es sichtbar weniger mysql prozesse. Demnach ist auch die Load geringer. Ich werde heute Abend nochmal posten wie es dann aussieht wenn mehr los ist - fürs erste hats schonmal geklappt, wofür ich mich bei euch bedanke.

Skyrunner

[skyrunner]

So, nun bei ca. 330 eingeloggten mitgliedern folgender top-Auszug vom DB Server:

Code: Select all

top - 15:38:46 up 65 days, 23:25,  1 user,  load average: 23.27, 16.68, 16.93
Tasks: 155 total,   9 running, 146 sleeping,   0 stopped,   0 zombie
Cpu(s):  70.1% user,  29.9% system,   0.0% nice,   0.0% idle
Mem:   1550596k total,   899064k used,   651532k free,    97328k buffers
Swap:  2096472k total,        0k used,  2096472k free,   546808k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
29321 root      17   0   972  972  728 R 16.3  0.1   0:00.96 top
28649 mysql     15   0  151m 151m 2856 R 11.3 10.0   3:07.52 mysqld
28877 mysql     11   0  143m 143m 2856 S  9.0  9.5   1:24.68 mysqld
28591 mysql     13   0  156m 156m 2856 R  8.6 10.3   3:49.23 mysqld
28740 mysql     18   0  143m 143m 2856 S  8.3  9.5   2:25.47 mysqld
28667 mysql     12   0  143m 143m 2856 S  8.0  9.5   2:56.98 mysqld
28887 mysql     10   0  145m 145m 2856 S  8.0  9.6   1:21.38 mysqld
28595 mysql     13   0  156m 156m 2856 R  7.6 10.3   3:28.73 mysqld
28890 mysql     13   0  145m 145m 2856 S  7.6  9.6   1:21.60 mysqld
28652 mysql      9   0  148m 148m 2856 S  7.3  9.8   3:07.06 mysqld
28669 mysql      9   0  143m 143m 2856 S  7.3  9.5   2:51.89 mysqld
28919 mysql     11   0  145m 145m 2856 S  7.3  9.6   1:15.60 mysqld
29035 mysql     11   0  151m 151m 2856 S  7.3 10.0   0:48.86 mysqld
28618 mysql     12   0  156m 156m 2856 R  7.0 10.3   3:35.58 mysqld
28881 mysql      9   0  143m 143m 2856 S  7.0  9.5   1:21.87 mysqld
28888 mysql      9   0  145m 145m 2856 S  7.0  9.6   1:22.17 mysqld
28914 mysql     14   0  145m 145m 2856 S  7.0  9.6   1:15.29 mysqld
29030 mysql     16   0  149m 149m 2856 S  7.0  9.9   0:53.82 mysqld
28635 mysql     12   0  156m 156m 2856 S  6.6 10.3   3:20.57 mysqld
28648 mysql     11   0  145m 145m 2856 S  6.6  9.6   3:55.43 mysqld
28904 mysql     10   0  145m 145m 2856 S  6.6  9.6   1:18.77 mysqld
29045 mysql     10   0  148m 148m 2856 S  6.6  9.8   0:50.19 mysqld
28650 mysql     10   0  151m 151m 2856 S  6.3 10.0   3:10.21 mysqld
28666 mysql      9   0  148m 148m 2856 S  6.3  9.8   2:59.01 mysqld
28903 mysql      9   0  145m 145m 2856 S  6.3  9.6   1:20.97 mysqld
28911 mysql      9   0  146m 146m 2856 S  6.3  9.7   1:21.63 mysqld
29014 mysql      9   0  145m 145m 2856 S  6.3  9.6   0:52.61 mysqld
29034 mysql     13   0  151m 151m 2856 S  6.3 10.0   0:51.69 mysqld
29054 mysql      9   0  151m 151m 2856 S  6.3 10.0   0:49.31 mysqld
28588 mysql      9   0  156m 156m 2856 S  6.0 10.3   3:46.74 mysqld
28617 mysql     14   0  156m 156m 2856 R  6.0 10.3   3:31.55 mysqld
28633 mysql     10   0  156m 156m 2856 S  6.0 10.3   3:46.33 mysqld
28875 mysql      9   0  143m 143m 2856 S  6.0  9.5   1:28.14 mysqld
28883 mysql      9   0  143m 143m 2856 S  6.0  9.5   1:22.40 mysqld
28907 mysql      9   0  145m 145m 2856 S  6.0  9.6   1:21.36 mysqld
29020 mysql      9   0  143m 143m 2856 S  6.0  9.5   0:53.14 mysqld
29028 mysql      9   0  151m 151m 2856 S  6.0 10.0   0:48.29 mysqld
29040 mysql     12   0  151m 151m 2856 S  6.0 10.0   0:51.12 mysqld
29051 mysql      9   0  143m 143m 2856 S  6.0  9.5   0:48.20 mysqld
28651 mysql      9   0  148m 148m 2856 S  5.6  9.8   3:01.52 mysqld
28668 mysql      9   0  143m 143m 2856 S  5.6  9.5   2:51.10 mysqld
28876 mysql     10   0  143m 143m 2856 S  5.6  9.5   1:25.09 mysqld
29027 mysql      9   0  154m 154m 2856 S  5.6 10.2   0:50.72 mysqld
28589 mysql      9   0  156m 156m 2856 S  5.3 10.3   4:03.20 mysqld
28880 mysql     15   0  143m 143m 2856 S  5.3  9.5   1:23.02 mysqld
28913 mysql      9   0  145m 145m 2856 S  5.3  9.6   1:14.75 mysqld
28920 mysql      9   0  145m 145m 2856 S  5.3  9.6   1:19.55 mysqld
29015 mysql     13   0  145m 145m 2856 S  5.3  9.6   0:48.52 mysqld
29024 mysql      9   0  146m 146m 2856 S  5.3  9.7   0:52.11 mysqld
29038 mysql      9   0  151m 151m 2856 S  5.3 10.0   0:49.74 mysqld
29044 mysql     15   0  148m 148m 2856 S  5.3  9.8   0:49.90 mysqld
28587 mysql      9   0  156m 156m 2856 S  5.0 10.3   3:48.32 mysqld

Das System lahmt merklich und jeder Seitenaufbau dauert zwischen 10 und 20 Sekunden. Ich habe immernoch die Einstellungen von vorhin.

Skyrunner

[kase]

Ich vermute stark, dass einfach dein mysql Server zu schwach ist. Ich meine, das Problem zeigt dir ja eigentlich top schon an, die CPU (und ich vermute stark auch die hdd, wegen des rießigen Disk IOs des mysql Servers) sind total überlastet.

Ich würde allerdings mal eine andere config Probieren, evtl die MAX, da dein mysql Server nur 150 MB Ram frisst, und dies im Vergleich zur Auslastung deines Servers ziemlich wenig ist.

[oxygen]

Ja vielleicht mal die Werte der huge Beispiel Konfiguration ausprobieren, die sehen so aus:

Code: Select all

key_buffer = 384M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache = 8
query_cache_size = 32M
thread_concurrency = 8

Edit: Wobei, deine Werte sind ja noch höher, hm.

[skyrunner]

Ja vielleicht mal die Werte der huge Beispiel Konfiguration ausprobieren, die sehen so aus:

Edit: Wobei, deine Werte sind ja noch höher, hm.

Genau deswegen wundere ich mich ja.
Kann es evtl. auch sein, dass die hardware nciht (mehr) ausreicht?
Ab ca. 220 Usern online hat mysql derbe probleme. Dann ist die Load auf 100% und die Prozesse müssen scheinbar zu lange aufeinander warten.

Ist wirklich nur neue Hardware die Lösung des Problems?

Skyrunner

[outofbound]

Querries optimieren.

Indices sinnvoll setzen. (Auch nicht zu viele)...

mysqladmin proc
mysqladmin var
mysqladmin ver

[hannes]

Wir haben ganz ähnliche Probleme mit unserem DB Server. Der geht uns momentan ab 150 Usern ein und liefert nur mehr Querytime > 7s.
Auch wir haben auf die huge Config umgestellt.
Hier mal unser top nach nem MySQL Restart:

Code: Select all

 18:13:03 up 49 days, 11:10,  1 user,  load average: 2,69, 3,32, 3,62
54 processes: 47 sleeping, 7 running, 0 zombie, 0 stopped
CPU states:  83,8% user,  11,7% system,   0,0% nice,   4,5% idle
Mem:    513316K total,   404160K used,   109156K free,    29624K buffers
Swap:   257032K total,     2268K used,   254764K free,   285732K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
26324 mysql      9   0 19352  18M  3260 S    16,7  3.7   0:04 mysqld
26317 mysql      9   0 19352  18M  3260 S    14,1  3.7   0:06 mysqld
26278 mysql     15   0 19352  18M  3260 R    13,0  3.7   0:15 mysqld
26327 mysql     10   0 19352  18M  3260 S    11,9  3.7   0:01 mysqld
26304 mysql     12   0 19352  18M  3260 R     8,7  3.7   0:10 mysqld
26281 mysql      9   0 19352  18M  3260 S     8,2  3.7   0:15 mysqld
26315 mysql     10   0 19352  18M  3260 R     7,6  3.7   0:04 mysqld
26326 mysql      9   0 19352  18M  3260 S     6,3  3.7   0:01 mysqld
26329 mysql     10   0 19352  18M  3260 R     5,0  3.7   0:00 mysqld
26333 mysql     14   0 19352  18M  3260 R     3,1  3.7   0:00 mysqld
26273 mysql      9   0 19352  18M  3260 S     0,1  3.7   0:00 mysqld

Ich weiß nicht ob es nun mit dem Restart zusammenhängt, jedoch scheint unser DB Server nur 18M Ram zu fressen, sehe ich das richtig?

Hier ist nochmal unsere DB Config:

Code: Select all

key_buffer = 384M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache = 8
thread_concurrency=2
query_cache_size = 12M
query_cache_limit = 512K
query_cache_type = 1
max_connections=200

Das System ist übrigens ein P4 mit 3Ghz und 512 RAM.

@Skyrunner: Welche Hardware setzt ihr da ein? Um welches Projekt handelt es sich?

[skyrunner]

@Skyrunner: Welche Hardware setzt ihr da ein? Um welches Projekt handelt es sich?

Bei mir handelt es sich um einen AMD Athlin XP 2800+ mit 1,5GB Ram.

Um welches Projekt es sich handelt kann ich nicht sagen, da das ein Sicherheitsrisiko wäre. Es geht um ein Browsergame.

Skyrunner

edit:
Aber an der CPU, wie ich erst vermutete kann es ja nciht liegen, da die ihr ja eine 3ghz cpu habt (wenn auch kein ht ) und ich so gesehen nur 2ghz. Ich denk also mal es kann nur ein Softwareproblem sein.

PS: kann hier mal jemand schildern, wie man indizes am sinnvollsten einsetzt bzw. ob man nur die spalten indiziert, die man mit where oft abfragt oder ähnliches

[hannes]

Einen guten Ansatz für die Index Optimierung findest du hier: http://dev.mysql.com/doc/mysql/de/Optim ... cture.html

[andreask2]

Naja, das ist ein komplexes Thema. Ich empfehle Dir:

http://dev.mysql.com/doc/mysql/de/MySQL ... ation.html, da findest Du unter anderem: http://dev.mysql.com/doc/mysql/de/MySQL_indexes.html.
Ich würde darüber hinaus auch mal mit "EXPLAIN" ( http://dev.mysql.com/doc/mysql/de/EXPLAIN.html ) kontrollieren, ob ein Index den Du verwendets überhaupt verwendet wird, wei Du es erwartest.

Und Du bist Dir definitiv sicher dass es an MySQL liegt? Wieviel % der Last verursachen denn MySQL und Apache? Vielleicht lohnt es sich mal die PHP-Scripte mit einem Profiler unter die Lupe zu nehmen, um hier Engpässe zu finden. Hier habe ich gute Erfahrungen mit http://www.xdebug.org/ gemacht. Verwendest Du einen Opcode-Cache?

Noch ein paar Ideen die Dir vielleicht helfen könnten: http://www.rootforum.org/forum/viewtop ... 572#183572

Grüße
Andreas

[odysseus]

Meine my.cnf sieht übrigens so aus:

Code: Select all

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock
#skip-locking
set-variable    = key_buffer=512M
set-variable    = max_allowed_packet=2M
set-variable    = table_cache=6048
set-variable    = sort_buffer=12M
set-variable    = record_buffer=12M
set-variable    = thread_cache=1024
set-variable    = max_connections=4000
set-variable    = wait_timeout=100000
set-variable    = interactive_timeout=100000
#set-variable   = query_cache=256M

# Try number of CPU's*2 for thread_concurrency
set-variable    = thread_concurrency=2
set-variable    = myisam_sort_buffer_size=8M
#log-bin
server-id       = 1
#skip-networking

Ich halte das für einen totalen Overkill. Du lässt MySQL Anfragen für mehrere zigtausend Sekunden in der Schleife, da ist es ja klar, dass immer mehr und mehr dazu kommen.
Versuch mal folgendes:

Code: Select all

set-variable    = key_buffer=512M
set-variable    = max_allowed_packet=2M
set-variable    = table_cache=4069
set-variable    = sort_buffer=12M
set-variable    = record_buffer=12M
set-variable    = thread_cache=512
set-variable    = max_connections=800
set-variable    = wait_timeout=10
set-variable    = interactive_timeout=100
set-variable    = query_cache_size=64M 
set-variable    = query_cache_limit=512K 
set-variable    = query_cache_type=1 

Du musst auf jeden Fall persistente Verbindungen verhindern.

Es sieht außerdem so aus, als würde dein System unter Deadlocks leiden. Gib mal mit phpMyAdmin eine Process List aus, wenn der Server mal wieder auf Ã?berlast läuft. So kannst du ermitteln, welche Tabelle den Deadlock erzeugt.

Ein klassisches Beispiel für Deadlocks sind bei Foren die Anweisung, dass bei jeder einzelnen Threadanzeige der View-Counter um 1 erhöht wird. Wenn einige hundert Luete gleichzeitig surfen, sind das zahllose Zugriffe auf die Thread-Tabelle, was dann in einen Deadlock läuft.

Vielleicht hast du ja bei deinem Browserspiel etwas Ã?hnliches vorliegen.

[andreask2]

Nochwas zu statischen und dynamischen Inhalten:

Man sieht es oft, dass einzelne Seiten extrem viele statische Resourcen verwenden, z.B. Bilder, CSS, JS... das sind oft über 100 Dateien, also über 100 Requests.

Selbst bei Verwendung von HTTP-Caching Headern fallen diese vielen Requests bei jedem neuen User an, bei jedem neuen Browser, bei jedem geleerten Cache, bei jedem abgelaufenen Cache, bei jedem Reload... an.

Dazu kommt oft, dass für jeden dieser 100 Requests eine neue TCP/IP-Verbindung aufgebaut werden muss, wenn Du kein keep-alive verwendest.
Für jeden dieser Requests wird ein kompletter Apache-Prozess verwendet/belegt, das heißt mit allen Modulen die Du eigentlich hierfür gar nicht brauchst (mod_php, mysql...). Das bindet eine Menge Resourcen, die Du an anderer Stelle besser gebrauchen könntest. Daher würde ich drüber nachdenken 2 Webserver-Instanzen laufen zu lassen, oder am besten einen effizienteren Webserver für statische Inhalte einsetzen, sowas wie lighttpd, oder auch einen Cache wie Squid. Die statischen Inhalte sollten keep-alive verwenden, die dynamischen nicht. Selbst wenn Du eine 2. Apache-Instanz für statische Inhalte einsetzt, könnte man dessen Konfiguration für statische Inhalte optimieren, und auch nur die Module laden, die man hierfür benötigt, genauso anders herum.

Aber wie relevant das ist, kann man nur beurteilen wenn man weiß wieviel % der Last Apache, und wieviel MySQL verursacht.

Die Datenbank zu optimieren ist da erheblich aufwändiger, da man das pauschal nicht beantworten kann. Du musst Dir mit einem Profiler (xdebug) die Scripte angucken, um zu sehen wo die Knackpunkte zu finden sind, so findst Du z.B. auch die besondes langsamen/aufwändigen SQL-Queries.

Hier weißt Du dann wo Du ansetzen musst. Ich kenne Deine Queries nicht, daher kann ich da nicht viel zu sagen. Wie schon gesagt wurde - Indices optimieren(EXPLAIN!, http://jan.kneschke.de/projects/mysql/ ), evtl. auch die Anfragen/Algorithmen selber optimieren, nicht dass Du so Sachen machst wie SQL-Abfragen in einer Schleife absenden...

2000 Anfragen pro Sekunde bei 200 Usern ist schon wirklich happich. Wieviele Anfragen kommen denn pro Request? Bzw. Wieviele Requests pro Sekunde? Ist alles schwer zu sagen, wenn Deine Abfragen sehr ineffektiv sind, kann es sein dass Du durch "vernünftige" Optimierung Zugriffszeiten um einige 10er-Potenzen verbessern kannst, oder aber die Abfragen sind so komplex, dass irgendwann das Ende der Fahnenstange erreicht ist. Vielleicht hilft dann ein anderes RDBMS, wie PostgreSQL, welches Dir bessere/effizientere Möglichkeiten bietet komplexere Daten abzufragen, und so deutlisch schneller sein kann.

Was sehr hilft ist Cachen, Cachen und nochmal Cachen. Nach Möglichkeit auch dynamische Inhalte, evtl. schon auf HTTP-Ebene mit entsprechenden Caching-Headern, das geht aber nur wenn sich die Daten nicht sooo schnell ändern, das kann ich nicht beurteilen. Sonst halt auf PHP-Ebene cachen, versuche Abfragen wo sich das Ergebnis nicht ständig ändert z.B. per PEAR::Cache_Lite zu cachen, so dass Du Abfragen sparst.
Bedenke immer, dass Du selbst wenn Du nur 1 Minute oder wenige Sekunden cachest, dass Du Dir alle wie auch immer gecachten Anfragen an die DB in diesem Zeitfenster sparst. Das hängt natürlich sehr von der Anwendung ab wo man da ansetzen kann.

Ich kann Dir an dieser Stelle nochmal lighttpd empfehlen, der hat ein Modul für "application based caching": http://incremental.de/products/lighttpd/cache/ , was hier vielleicht helfen könnte. lighttpd ist ein sehr schlanker und performanter Webserver, der genau für dieses Problem geschrieben wurde, und speziell für den Einsatz von PHP, in diesem Fall über fcgi. Vielleicht lohnt sich ja mal ein Test hiermit. Ich finde das Teil echt gut.

Grüße
Andreas

[outofbound]

wie schon gesagt:

mysqladmin ver var und proc
werden dir ganz schnell helfen können, wenn
die SQLs nicht in Ordnung sind.

Ansonsten musst du dir Gedanken machen, wie du
optimieren kannst. Vielleicht die ganzen Bilder als
Grafikpack zum Download anbieten und dann
Konfigurierbar machen (Also unter "Profiles"
sowas wie "Bilderverzeichnis") und das dann
in die Seiten der User einbinden.
Buttons in Menüs? CSS nehmen.

Letzte Alternative: Clustering.

Aber ohne das Projekt gesehen zu haben:
Alles Glaskugel.
Gruss,

Out

[fǃ$chg3w3hr]

Hallo,

ich habe bei einem Browsergame im Moment auch sehr große Probleme mit meine MySQL- DB.

Allerdings scheint auch bei mir der Fehler unabhängig von den Einstellungen nur mit der Größe der einzelnen Tabellen zusammenzuhängen.

Ich hatte teilweise Queryzeiten jenseits der 30s und bin dann die ganze DB einmal durchgegangen. Dabei ist mir eine Tabelle mit Statusnachrichten aufgefallen, die > 350k Einträge hatte.

Nachdem ich die etwas "verschlankt" hatte, war der Perfomance-lag verschwunden. Das Problem trat bei mir auch schon bei kleineren Benutzerzahlen auf, so dass das hier ggf. auch zum tragen kommen kann.

Ich meine mich auch zu entsinnen, schon mal was über Probleme mit zu großen DBs unter MySQL gelesen zu haben, nur der Link ist mir entfallen.

Cu

F!$chg3w3hr

[outofbound]

Hi,

Dazu gibt es passend noch einen Thread hier, vielleicht einfach die Tabellenstrkturen zu überdenken....

Meistens (!) ist es eben nicht die Hardware, und nicht die MySQL- Einstellungen, sondern einfach das Tabellendesign.

Datenbankdesign ist ein Gut bezahlter Job und setzt einiges an Gespür und Erfahrung voraus.
Es geht auch viel weiter als stumpfes Normalisieren von Daten und gut ist.

Dementsprechend kommen die Leute immer wieder an Performance- Grenzen, die sie sich
selbst setzen.

Die nötigen Infos um zu helfen bekommt man leider nicht, weil ja alles "top secret" ist.
(Tabellenstrukturen, Indices, benutzte Querries)

Und so kaufen sich die Leute immer mehr Hardware, immer stärkere Server und basteln immer
mehr an Einstellungen rum... hört sich für mich wie Windows an.

Natürlich kommt man ab einem Gewissen Punkt nicht mehr drum rum Eingriffe in den Core des Systems zu machen, aber das sollte meiner Meinung nach der LETZTE Schritt sein, nicht der ERSTE.

Gruss,

Out

[fǃ$chg3w3hr]

Ja, den anderen Thread habe ich schon gesehen.

Zum Thema "Geheimhaltung" kann ich nur sagen, dass es bei meinem Projekt zumindest einfach um eine Tabelle geht, die "nur" 8 Felder hat mit einfachen Inserts und einfachen Selects mit einer(!) Bedingung handelt.

Bei Bedarf kann ich Dir das auch gerne per Mail genauer schicken.

Cu

F!$chg3w3hr

[outofbound]

Das liegt an dir, ob du eine Lösung willst oder nicht ;)

Gruss,

Out

[blaufalke]

Es sieht außerdem so aus, als würde dein System unter Deadlocks leiden. Gib mal mit phpMyAdmin eine Process List aus, wenn der Server mal wieder auf Ã?berlast läuft. So kannst du ermitteln, welche Tabelle den Deadlock erzeugt.

Ein klassisches Beispiel für Deadlocks sind bei Foren die Anweisung, dass bei jeder einzelnen Threadanzeige der View-Counter um 1 erhöht wird. Wenn einige hundert Luete gleichzeitig surfen, sind das zahllose Zugriffe auf die Thread-Tabelle, was dann in einen Deadlock läuft.

Was Du da beschreibst, sind keine Deadlocks.

Deadlocks kommen nur im Zusammenhang mit Transaktionen vor (beim MySQL-Server setzt das den Einsatz von InnoDB oder BerkeleyDB voraus), wenn zwei Transaktionen aufeinander warten müssen.
Beispiel: Transaktion A besitzt eine exklusive Sperre für Tabelle 1 und verlangt eine Sperre für Tabelle 2. Die zeitgleich ablaufende Transaktion B besitzt eine Sperre für Tabelle 2 und verlangt eine Sperre für Tabelle 1. Folge: Keine der beiden Transaktionen kann beendet werden; beide würden, wenn der Server nicht eine der beiden Transaktionen beendete, auf den Stromausfall warten.

Da nur sehr wenige MySQL-Anwendungen (schon gar nicht frei erhältliche Forensysteme) auf InnoDB oder BerkeleyDB setzen, haben die meisten PHP/MySQL-Benutzer noch nie einen Deadlock gesehen: Wo keine Transaktionen, da kein Deadlock.

Wenn aber tatsächlich Deadlocks vermutet werden, hilft z.B.

Code: Select all

SHOW INNODB STATUS;

an der MySQL-Befehlszeile, um dem auf die Spur zu kommen.

[odysseus]

Was Du da beschreibst, sind keine Deadlocks.

Hm. Nach genauerem Nachdenken muss ich zugeben, dass du da Recht hast.

Allerdings ist der Endeffekt auch nicht viel besser: Durch extrem häufige Anfragen auf eine einzelne Tabelle entstehen I/O-Probleme. Ein Update-Query "blockiert" die Tabelle und zig andere müssen deswegen warten. Wenn die Timeouts zu hoch sind, versucht der Server, alle abzuarbeiten und kommt doch nicht mit der Arbeit hinterher, weil die Platte das nicht packt.