PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Performance von MySQL optimieren - wo überall?



marce
24.11.04, 10:54
Liebe Gemeinde,

folgende Situation:
Server mit Suse 8.2, MySQL von Suse, Doppel-Xeon 2.8, 2GB Speicher. Die DB hat ca. 500MB (konstante Daten, da ändert sich vermutlich nichts mehr)

16 Clients (Application-Server), die auf die DB nur lesend zugreifen.

Load momentan ca. 2

System ist noch nicht kritisch, aber im Moment sind die Zugriffe auf einen jahreszeitlichen Tief, werden ab Januar ansteigen und vermutlich um ca. 50% zunehmen.

Gefunden habe ich bisher folgende Tipps:
- MySQL selber kompilieren mit --static
- external locking abschalten

my.cnf ist die my-huge.cnf, die SuSE mitliefert.

An der DB rumschrauben und Tabellen optimieren ist nicht möglich - zahlt keiner.


Frage nun: an welchen Stellen lohnt es sich zu schauen? Doku zu MySQL gibt leider nicht allzuviel her (selber kompilieren mit static und locking ausschalten habe ich von dort).

Sollten noch Infos nötig sein, kein Problem...

die my.cnf:


[client]
port = 3306
socket = /var/lib/mysql/mysql.sock

[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
set-variable = key_buffer=384M
set-variable = max_allowed_packet=1M
set-variable = table_cache=512
set-variable = sort_buffer=2M
set-variable = record_buffer=2M
set-variable = thread_cache=8
set-variable = thread_concurrency=8
set-variable = myisam_sort_buffer_size=64M
log-bin
server-id = 1

[safe_mysqld]
err-log=/var/lib/mysql/mysqld.log

[mysqldump]
quick
set-variable = max_allowed_packet=16M

[mysql]
no-auto-rehash

[isamchk]
set-variable = key_buffer=256M
set-variable = sort_buffer=256M
set-variable = read_buffer=2M
set-variable = write_buffer=2M

[myisamchk]
set-variable = key_buffer=256M
set-variable = sort_buffer=256M
set-variable = read_buffer=2M
set-variable = write_buffer=2M

[mysqlhotcopy]
interactive-timeout


Danke schon mal für Tips ;-)

Edit: Freundlichkeit: "Danke" vergessen

Tomek
24.11.04, 11:15
Ein paar Tipps für die my.cnf:

thread_cache=8
Setze die Variable höher, z.B. auf den Wert 64.

thread_concurrency=8
Die Faustregel lautet Anzahl der CPUs multipliziert mit 2. Wenn die eingesetzten Xeon CPUs Hyperthreading unterstützen und diese Funktion auch aktiviert ist, dann ist der Wert 8 in Ordnung, wenn nicht, dann auf 4 heruntersetzen.

Aktiviere den Query-Cache (geht nur ab MySQL 4.0):

[mysqld]
query_cache_limit = 1M
query_cache_size = 32M
query_cache_type = 1

Wenn du keine MySQL-Replikation benutzt, dann kommentiere die Zeile mit log-bin aus. Die ist in diesem Fall überflüssig und kostet Leistung.

MySQL neu kompilieren wird wahrscheinlich nichts bringen. Ich würde weiterhin die Pakete von SuSE verwenden.

Ich weiss nicht, wie und womit sich die Clients zum MySQL-Server verbinden. Aber ein weiterer Versuch wäre es, persistente MySQL-Verbindungen abzuschalten, wenn nicht schon geschehen und wenn das möglich ist.

Wie sieht es mit der SWAP-Nutzung aus? Woher kommt die höhere Load genau? Vielleicht kannst du mal die Ausgaben von top/free hier pasten.

marce
24.11.04, 12:01
danke schon mal.

HyperThreading ist an - habe 4 CPUs ;-)

top sagt gerade (momentan gemütliche Mittagspausenlast):


top - 12:50:46 up 95 days, 21:45, 1 user, load average: 1.13, 1.34, 1.23
Tasks: 91 total, 3 running, 88 sleeping, 0 stopped, 0 zombie
Cpu(s): 32.0% user, 8.2% system, 0.0% nice, 59.8% idle
Mem: 2068660k total, 2054772k used, 13888k free, 216724k buffers
Swap: 1052216k total, 0k used, 1052216k free, 1029928k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ Command
82 mysql 19 0 18128 17m 2192 S 37.1 0.9 1:09.57 mysqld
32 mysql 17 0 18128 17m 2192 R 28.8 0.9 2:24.60 mysqld
110 mysql 16 0 18128 17m 2192 R 27.8 0.9 0:30.53 mysqld
53 mysql 17 0 18128 17m 2192 S 19.5 0.9 2:09.89 mysqld
32686 mysql 16 0 18128 17m 2192 S 12.5 0.9 6:18.74 mysqld
83 mysql 16 0 18128 17m 2192 S 8.6 0.9 1:04.68 mysqld
26 mysql 16 0 18128 17m 2192 S 7.0 0.9 2:38.22 mysqld
32700 mysql 16 0 18128 17m 2192 S 6.1 0.9 5:22.74 mysqld
122 root 16 0 896 896 696 R 5.1 0.0 0:00.38 top
344 snort 15 0 9392 9336 1376 D 1.3 0.5 148:20.14 snort
32735 root 15 0 151m 151m 7964 S 1.0 7.5 0:08.92 java
24212 mysql 15 0 18128 17m 2192 S 0.6 0.9 5:28.08 mysqld
72 root 15 0 151m 151m 7964 S 0.6 7.5 0:01.79 java
80 root 15 0 151m 151m 7964 S 0.6 7.5 0:02.08 java
109 root 15 0 151m 151m 7964 S 0.6 7.5 0:01.07 java
119 root 15 0 151m 151m 7964 S 0.6 7.5 0:00.44 java
114 root 15 0 151m 151m 7964 S 0.3 7.5 0:00.85 java
117 root 15 0 151m 151m 7964 S 0.3 7.5 0:00.81 java
121 root 15 0 151m 151m 7964 S 0.3 7.5 0:00.24 java
1 root 15 0 248 248 212 S 0.0 0.0 0:42.71 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration_CPU0
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration_CPU1
4 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration_CPU2
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration_CPU3
6 root 15 0 0 0 0 S 0.0 0.0 0:00.28 keventd
7 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd_CPU0
8 root 34 19 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd_CPU1
9 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd_CPU2

free meint

total used free shared buffers cached
Mem: 2068660 2056940 11720 0 216740 1030024
-/+ buffers/cache: 810176 1258484
Swap: 1052216 0 1052216


swappen tut die Kiste also nicht. Die Java-Prozesse kommen von einem kleinen App-Server, der dabei noch separat läuft (und auch die MySQL-DB benutzt. Ob ich den von der Kiste runter bekommen, muss ich mal schauen...)

Über die Schnittstelle der App-Server auf die MySQL habe ich mal die Entwicklung hier im Haus gefragt, was sie da genau reingebastelt haben...

die anderen Geschichten werde ich mal ausprobieren - leider geht das erst heute Nacht oder morgen früh, da ich die Kiste nicht aus dem prod. Betrieb heraus nehmen kann... [und es leider gerade noch kein 100%-Backup dafür gibt - nur eine Notlösung mit 2x1.4 GHz PIII) - und der kackt mir wahrscheinlich ab...

MySQL-Version ist "mysql Ver 11.18 Distrib 3.23.55" - daher leider nichts mit Query-Cache... - würde aber vermutlich nicht viel bringen, da jede Anfrage "fast" unique ist... (Abfrage, ob zu einem Geocode ein Eintrag existiert...)

marce
25.11.04, 06:12
so, habe nun mal das Log deaktiviert und den thread-cache mal auf 16 gesetzt.

Tabellen habe ich gar nicht so viel - in der DB, die benutzt wird (abgesehen von der mysql-db) sind gerade mal 4 Tabellen drin...

mal beobachten, wie sich die Kiste nun verhält...

marce
29.11.04, 09:27
Abschliessend: Danke nochmals für den Tipp. Die load ist - soweit man das sagen kann (Userverhalten und so - sind "Tage" vergleichbar) - deutlich runter gegangen auf ca. 1.3