Page 1 of 3
VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 10:16
by schüri
Hallo liebe Rootforum-User,
nach mehreren Tagen Internetsuche (wodurch ich auf dieses Forum gestoßen bin) konnte ich mein Problem mit meinen VServer (von
ispone-business) nicht lösen.
Der Server hat insgesamt 512MB RAM und 15GB Speicherplatz zur Verfügung.
Ich hoste momentan auf dem Server ca. 80 Foren (auf phpbb-Basis). Zu hohen Besucherzeiten (vorallem ab 18 Uhr) kommt es zu extrem langen Ladezeiten. Um dieses Problem zu lösen, habe ich bereits das Tuning-Primer-Skript ausprobiert und folgende my.cnf erstellt:
Code: Select all
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 128K
query_cache_limit = 32M
query_cache_size = 32M
query_cache_type = 1
max_binlog_size = 104857600
long_query_time = 4
thread_cache_size = 8
max_connections = 20
table_cache = 10240
read_buffer_size = 2M
tmp_table_size = 16M
sort_buffer = 2M
record_buffer = 1M
open_files_limit = 25600
join_buffer_size = 512K
log-queries-not-using-indexes = 1
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
[isamchk]
key_buffer = 16M
und hier die momentane Ausgabe des Tuning-Primer-Skriptes:
Code: Select all
SLOW QUERIES
The slow query log is [COLOR="Red"]NOT[/COLOR] enabled.
Current long_query_time = 4 sec.
You have [COLOR="Red"]529[/COLOR] out of [COLOR="Red"]8710[/COLOR] that take longer than 4 sec. to complete
Your long_query_time seems to be fine
BINARY UPDATE LOG
The binary update log is [COLOR="Red"]NOT[/COLOR] enabled.
[COLOR="Red"]You will not be able to do point in time recovery[/COLOR]
[COLOR="Yellow"]See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html[/COLOR]
WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 5
Current threads_per_sec = 0
Historic threads_per_sec = 0
[COLOR="Green"]Your thread_cache_size is fine[/COLOR]
MAX CONNECTIONS
Current max_connections = 20
Current threads_connected = 1
Historic max_used_connections = 6
The number of used connections is 30% of the configured maximum.
[COLOR="Green"]Your max_connections variable seems to be fine.[/COLOR]
MEMORY USAGE
Max Memory Ever Allocated : 81 M
Configured Max Per-thread Buffers : 77 M
Configured Max Global Buffers : 58 M
Configured Max Memory Limit : 135 M
Physical Memory : 512.20 M
[COLOR="Green"]Max memory limit seem to be within acceptable norms[/COLOR]
KEY BUFFER
Current MyISAM index space = 311 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 14
Key buffer fill ratio = 10.00 %
[COLOR="Red"]Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere[/COLOR]
QUERY CACHE
[COLOR="Green"]Query cache is enabled[/COLOR]
Current query_cache_size = 32 M
Current query_cache_used = 2 M
Current query_cache_limit = 32 M
Current Query cache Memory fill ratio = 6.59 %
Current query_cache_min_res_unit = 4 K
[COLOR="Red"]Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere[/COLOR]
[COLOR="Yellow"]MySQL won't cache query results that are larger than query_cache_limit in size[/COLOR]
SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
[COLOR="Green"]Sort buffer seems to be fine[/COLOR]
JOINS
Current join_buffer_size = 512.00 K
You have had 3 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.
[COLOR="Red"]Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.[/COLOR]
OPEN FILES LIMIT
Current open_files_limit = 25600 files
[COLOR="Yellow"]The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.[/COLOR]
[COLOR="Green"]Your open_files_limit value seems to be fine[/COLOR]
TABLE CACHE
Current table_cache value = 10240 tables
You have a total of 4209 tables
You have 4231 open tables.
[COLOR="Green"]The table_cache value seems to be fine[/COLOR]
TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 16 M
Of 362 temp tables, 13% were created on disk
[COLOR="Green"]Created disk tmp tables ratio seems fine[/COLOR]
TABLE SCANS
Current read_buffer_size = 1020 K
Current table scan ratio = 3137 : 1
[COLOR="Green"]read_buffer_size seems to be fine[/COLOR]
TABLE LOCKING
Current Lock Wait ratio = 0 : 8887
Your table locking seems to be fine
Es treten aber trotzdem weiterhin noch lange Ladezeiten auf. Könnt ihr mir weiterhelfen und Verbesserungsschläge für die Einstellungen posten?
Wäre für jede Hilfe dankbar.
MfG
Raphael
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 10:27
by schüri
welche Server würdest du mir denn dafür vorschlagen?
die Foren sind schon aktiv - deswegen kommt es vorallem abends zu diesen langen Ladezeiten.
laut "top" sind angeblich bis zu 80% der CPU frei und auch der Memory wird nicht vollständig benutzt (das waren Werte von gestern - daran konnte ich mich auf jeden Fall noch erinnern)
aber wenn ihr ein Server-Wechsel vorschlägt, dann zeigt mir bitte die richtigen Angebote, die zu meinen Bedürfnissen passen (Hosten von phpbb-Foren, Anzahl: ~100-120 geplant)
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 11:02
by schüri
matzewe01 wrote:Poste doch mal die Ausgabe von top, wenn es wieder diese Probleme gibt.
Ich befürchte, das System swappt.
Leider lassen sich auf vserver Einflüsse von anderen VServer auf dem System nicht unterbinden z.B. sehr intensive Plattenzugriffe.
ok dann werde ich das heute Abend mal posten.
Die Anzahl der betriebenen Foren ist "nicht ausschlaggebend" wichtiger wären die angestrebten Userzahlen.
Wenn man mal grob / Forum mit max. 10 concurrent Usern rechnet zu Spitzenzeiten, dann wären es bei Dir bis zu 1200 Benutzer gleichzeitig, die man zu Spitzenlast abhandeln müsste.
Für mittlere bekannte Foren realistische Werte.
ich hoste Foren für bestimmte Allis (z.B. von verschiedenen Browsergames), da kommen dann schon auf jedes forum ca. 20-30user - schätze so mit 1000-1500 Besuchern
Joe User kann sicherlich einiges zum optimieren der phpbb Foren sagen.
Aber gib uns erstmal mehr zu der tatsächlichen Auslastung auf Deinem System.
-> Tools wie z.B. Serverstats hast Du nicht im Einsatz?
nicht das ich wüsste - das einzige was ich noch zusätzlich einsetze, ist http://www.stats.de. denn damit kontrolliere ich die aktivität der einzelnen foren und lösche ggf. inaktive. ich habe den dazugehörigen code-text in den overall_footer eingesetzt, sodass das skript bei jedem forumaufruf geladen wird. hier der auszug aus den statistiken:
Code: Select all
15 - 16 180
16 - 17 274
17 - 18 434
18 - 19 291
19 - 20 297
20 - 21 238
21 - 22 124
22 - 23 293
23 - 24 94
das sind die seitenzugriffe von einem der aktivsten foren (linke Spalte: Uhrzeit - rechte Spalte: Seitenaufrufe)
ich hatte auch schon den Verdacht, dass es daran liegen könnte - war auch schon auf der suche nach einer anderen Lösung um die aktivität der foren zu kontrollieren, bin bisher aber daran gescheitert :( gibt es stats-skripts, die man mit confixx benutzen kann?[/color]
Zur Mysql Konfiguration:
Die bisherige Konfiguration fordert schon mehr Speicher, als Dir physikalisch garantiert zur Verfügung steht.
D.H. unter normalen Umständen bekommst Du dynamisch sicherlich mehr Speicher zugeteilt als die 512 MB. Zu den Spitzenzeiten allerdings nur diese 520 Mb weil ja "alle auf dem System" mehr Speicher brauchen. Damit wird Dein System gezwungen zu swappen, was natürlich Performance Engpässe bedeutet.
Das würde man wiederum z.B. durch einen hohen IO Wait erkennen können sowie der Ausnutzung des Swap Speichers.
wenn die bisherige konfiguration meinen RAM-Speicher übersteigt, dann sollte ich sie doch wieder zurückstellen oder? weil vielleicht liegt es ja daran und der anbieter will mir einfach nicht mehr RAM geben?!?
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 11:37
by schüri
matzewe01 wrote:http://serverstats.berlios.de/
Also mit diesem PHP Tool, bekommst Du die wesentlichen Informationen über den Systemzustand raus.
-> Zumidnest scheint mir das kuzfristig die schnellste und einfachste Lösung zu sein.
Abhängig von den offnen Versbinungen / tatsächlich benötigten Verbindungen.
mit der Installation von diesem Programm bin ich wohl überfragt :( - krieg das einfach net hin
2 Werte aus der Db interesieren mich:
mysql> show status;
Connection :
15577
Max_used_connections:
8
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 11:47
by schüri
matzewe01 wrote:Also, erstens kannst Du die maxconnection schon mal auf 10 oder 12 von ursprünglich 20 reduzieren.
Wie lange läuft der Server schon?
Siehe Uptime aus show status;
Wenn er mehrere Tage hinter sich gebracht hat, kannst Du die Änderung so übernehmen und mysqld neu starten / reloaden.
also ich hab halt den server erst gestern abend wieder neu gestartet, da ich immer wieder am umstellen der my.cnf war
kann ich also jetzt das runterstellen und gleich neustarten?
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 12:09
by schüri
Code: Select all
top - 12:08:55 up 13:58, 1 user, load average: 0.11, 0.13, 0.10
Tasks: 59 total, 2 running, 57 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.7%sy, 0.0%ni, 98.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st
Mem: 524500k total, 451328k used, 73172k free, 15992k buffers
Swap: 262136k total, 4k used, 262132k free, 229692k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8558 www-data 15 0 27624 9156 4836 S 0.7 1.7 0:00.23 apache2
1331 mysql 16 0 153m 103m 4968 S 0.3 20.3 8:16.79 mysqld
1 root 16 0 1956 644 552 S 0.0 0.1 0:00.39 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/0
5 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
7 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 xenwatch
8 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 xenbus
14 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0
139 root 15 0 0 0 0 S 0.0 0.0 0:00.05 pdflush
141 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
140 root 15 0 0 0 0 S 0.0 0.0 0:00.71 kswapd0
665 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0
666 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
789 root 15 0 0 0 0 S 0.0 0.0 0:00.60 kjournald
1236 root 16 0 2568 932 796 S 0.0 0.2 0:00.14 syslogd
1246 root 16 0 1592 388 312 S 0.0 0.1 0:00.01 klogd
1294 root 25 0 2684 1332 1076 S 0.0 0.3 0:00.00 mysqld_safe
1332 root 25 0 1576 500 432 S 0.0 0.1 0:00.00 logger
1378 root 22 0 2696 888 768 S 0.0 0.2 0:00.00 inetd
1438 root 16 0 4848 1792 1464 S 0.0 0.3 0:00.15 master
1447 postfix 16 0 4992 1824 1380 S 0.0 0.3 0:00.10 qmgr
1475 root 20 0 6308 988 684 S 0.0 0.2 0:00.00 saslauthd
1476 root 18 0 6308 600 296 S 0.0 0.1 0:00.00 saslauthd
1477 root 18 0 6308 544 240 S 0.0 0.1 0:00.00 saslauthd
1478 root 20 0 6308 544 240 S 0.0 0.1 0:00.00 saslauthd
1479 root 20 0 6308 544 240 S 0.0 0.1 0:00.00 saslauthd
1490 root 16 0 4940 1092 760 S 0.0 0.2 0:00.00 sshd
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 12:27
by schüri
matzewe01 wrote:Wenn es dann wieder soweit ist, poste die Ausgaben aus:
Code: Select all
free -ltm
top
mysql> show status; (Max_used_connections, Threads_connected)
ok werde ich machen, aber das wird bis heute abend 17-18uhr dauern
hier der momentane Stand
Code: Select all
free -ltm
total used free shared buffers cached
Mem: 512 481 30 0 10 258
Low: 512 481 30
High: 0 0 0
-/+ buffers/cache: 212 300
Swap: 255 0 255
Total: 768 481 286
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 15:11
by schüri
Code: Select all
total used free shared buffers cached
Mem: 512 495 17 0 21 265
Low: 512 495 17
High: 0 0 0
-/+ buffers/cache: 207 304
Swap: 255 0 255
Total: 768 495 272
Code: Select all
top - 15:08:36 up 16:57, 1 user, load average: 0.09, 0.16, 0.21
Tasks: 81 total, 1 running, 80 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.8%us, 0.4%sy, 0.0%ni, 94.1%id, 1.1%wa, 0.0%hi, 0.0%si, 1.6%st
Mem: 524500k total, 507356k used, 17144k free, 22384k buffers
Swap: 262136k total, 4k used, 262132k free, 271920k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 16 0 1956 644 552 S 0.0 0.1 0:00.39 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/0
5 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
7 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 xenwatch
8 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 xenbus
14 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0
139 root 15 0 0 0 0 S 0.0 0.0 0:00.10 pdflush
141 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
140 root 15 0 0 0 0 S 0.0 0.0 0:01.01 kswapd0
665 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0
666 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
789 root 15 0 0 0 0 S 0.0 0.0 0:00.81 kjournald
1236 root 16 0 2568 932 796 S 0.0 0.2 0:00.20 syslogd
1246 root 16 0 1592 388 312 S 0.0 0.1 0:00.01 klogd
1294 root 25 0 2684 1332 1076 S 0.0 0.3 0:00.00 mysqld_safe
1331 mysql 15 0 153m 104m 5008 S 0.0 20.4 11:43.78 mysqld
1332 root 25 0 1576 500 432 S 0.0 0.1 0:00.00 logger
1378 root 22 0 2696 888 768 S 0.0 0.2 0:00.00 inetd
1438 root 16 0 4848 1792 1464 S 0.0 0.3 0:00.19 master
1447 postfix 16 0 4992 1824 1380 S 0.0 0.3 0:00.12 qmgr
1475 root 20 0 6308 988 684 S 0.0 0.2 0:00.00 saslauthd
1476 root 18 0 6308 600 296 S 0.0 0.1 0:00.00 saslauthd
1477 root 18 0 6308 544 240 S 0.0 0.1 0:00.00 saslauthd
1478 root 20 0 6308 544 240 S 0.0 0.1 0:00.00 saslauthd
1479 root 20 0 6308 544 240 S 0.0 0.1 0:00.00 saslauthd
1490 root 16 0 4940 1092 760 S 0.0 0.2 0:00.00 sshd
Code: Select all
Connection: 26592
Max_used_connections: 10
Threads_connected: 2
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 15:31
by Joe User
Alles harmlos und OK.
Falls Du noch phpBB2 einsetzt, dann bitte schleunigst auf phpBB3 upgraden!
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 15:33
by schüri
Code: Select all
top - 15:32:25 up 17:21, 2 users, load average: 0.16, 0.24, 0.19
Tasks: 56 total, 2 running, 54 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.7%us, 0.7%sy, 0.0%ni, 95.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.7%st
Mem: 524500k total, 498264k used, 26236k free, 21804k buffers
Swap: 262136k total, 4k used, 262132k free, 286916k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10155 www-data 16 0 27920 10m 5424 S 2.7 2.0 0:06.65 apache2
10353 www-data 16 0 27640 9620 5084 S 1.0 1.8 0:01.21 apache2
1331 mysql 15 0 153m 104m 5008 S 0.7 20.4 11:58.69 mysqld <--------------
1 root 16 0 1956 644 552 S 0.0 0.1 0:00.39 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/0
5 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
7 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 xenwatch
8 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 xenbus
14 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0
139 root 15 0 0 0 0 S 0.0 0.0 0:00.10 pdflush
141 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
140 root 15 0 0 0 0 S 0.0 0.0 0:01.01 kswapd0
665 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0
666 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
was ist damit? was bedeutet die zeit?
mal schauen, wie das heute abend auszieht - hast du dir schon oben meine my.cnf angeschaut?
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 15:48
by schüri
matzewe01 wrote:Das bedeutet, dass der mysql Dämon seit fast 12 Stunden läuft.
ok dann ist das wohl in ordnung so, oder? ;)
hoffe, Joe schaut sich mal die my.cnf an :-D
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 16:51
by schüri
ich poste jetzt mal alle stunde - vllt erkennt ihr eine entwicklung bei irgendeinem wer
Code: Select all
top - 16:49:54 up 18:39, 3 users, load average: 0.24, 0.27, 0.21
Tasks: 65 total, 2 running, 63 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 524500k total, 505576k used, 18924k free, 24120k buffers
Swap: 262136k total, 4k used, 262132k free, 271000k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 16 0 1956 644 552 S 0.0 0.1 0:00.39 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/0
5 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
7 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 xenwatch
8 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 xenbus
14 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0
139 root 15 0 0 0 0 S 0.0 0.0 0:00.10 pdflush
141 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
140 root 15 0 0 0 0 S 0.0 0.0 0:01.05 kswapd0
665 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0
666 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
789 root 15 0 0 0 0 S 0.0 0.0 0:00.87 kjournald
1236 root 16 0 2568 932 796 S 0.0 0.2 0:00.22 syslogd
1246 root 16 0 1592 388 312 S 0.0 0.1 0:00.01 klogd
mir ist aufgefallen, dass ich ja wirklich fast den kompletten RAM benutze^^
werde das wohl mal nen bissl runterschrauben müssen
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 17:05
by schüri
so habe nochmal tuning-primer durchlaufen lassen:
Code: Select all
SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 4 sec.
You have 81299 out of 934602 that take longer than 4 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.0/en/point-in-time-recovery.html
WORKER THREADS
Current thread_cache_size = 8
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 = 20
Current threads_connected = 1
Historic max_used_connections = 10
The number of used connections is 50% of the configured maximum.
Your max_connections variable seems to be fine.
MEMORY USAGE
Max Memory Ever Allocated : 96 M
Configured Max Per-thread Buffers : 77 M
Configured Max Global Buffers : 58 M
Configured Max Memory Limit : 135 M
Physical Memory : 512.20 M
Max memory limit seem to be within acceptable norms
KEY BUFFER
Current MyISAM index space = 312 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 789
Key buffer fill ratio = 99.00 %
[color=#FF0000]You could increase key_buffer_size
It is safe to raise this up to 1/4 of total system memory;
assuming this is a dedicated database server.[/color]
QUERY CACHE
Query cache is enabled
Current query_cache_size = 32 M
Current query_cache_used = 20 M
Current query_cache_limit = 32 M
Current Query cache Memory fill ratio = 63.76 %
Current query_cache_min_res_unit = 4 K
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 = 512.00 K
You have had 26 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.
Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.
OPEN FILES LIMIT
Current open_files_limit = 25600 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_cache value = 10240 tables
You have a total of 4210 tables
You have 4322 open tables.
The table_cache value seems to be fine
TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 16 M
Of 45497 temp tables, 25% were created on disk
[color=#FF0000]Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables[/color]
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.
TABLE SCANS
Current read_buffer_size = 1020 K
Current table scan ratio = 3409 : 1
read_buffer_size seems to be fine
TABLE LOCKING
Current Lock Wait ratio = 1 : 60972
Your table locking seems to be fine
habe daher diese Werte dann so geändert:
key_buffer_size = 32M
max_heap_table_size = 32M
mp_table_size = 32M
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 17:09
by Joe User
schüri wrote:hoffe, Joe schaut sich mal die my.cnf an :-D
Wie bereits geschrieben passt die my.cnf weitestgehend zu Deinem System, das Feintuning machst Du mit Hilfe von tuning-primer.sh
und mysqltuner.pl
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 17:14
by schüri
Joe User wrote:schüri wrote:hoffe, Joe schaut sich mal die my.cnf an :-D
Wie bereits geschrieben passt die my.cnf weitestgehend zu Deinem System, das Feintuning machst Du mit Hilfe von tuning-primer.sh
und mysqltuner.pl
Code: Select all
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.32-Debian_7etch6
[OK] Operating on 32-bit architecture with less than 2GB RAM
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 527M (Tables: 4193)
[!!] Total fragmented tables: 314
-------- Performance Metrics -------------------------------------------------
[--] Up for: 10m 52s (24K q [37.724 qps], 1K conn, TX: 22M, RX: 2M)
[--] Reads / Writes: 80% / 20%
[--] Total buffers: 106.0M global + 3.9M per thread (20 max threads)
[OK] Maximum possible memory usage: 183.3M (35% of installed RAM)
[!!] Slow queries: 7% (1K/24K)
[OK] Highest usage of available connections: 30% (6/20)
[OK] Key buffer size / total MyISAM indexes: 32.0M/312.1M
[OK] Key buffer hit rate: 96.6% (108K cached / 3K reads)
[OK] Query cache efficiency: 59.5% (8K cached / 15K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1K sorts)
[OK] Temporary tables created on disk: 14% (176 on disk / 1K total)
[OK] Thread cache hit rate: 99% (6 created / 1K connections)
[OK] Table cache hit rate: 97% (4K open / 4K opened)
[OK] Open file limit used: 33% (8K/25K)
[OK] Table locks acquired immediately: 100% (15K immediate / 15K locks)
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Enable the slow query log to troubleshoot bad queries
so und was muss ich jetzt genau ändern?
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 17:15
by Joe User
schüri wrote:mir ist aufgefallen, dass ich ja wirklich fast den kompletten RAM benutze^^
Dein System hat zwar ~505MB RAM reserviert, nutzt derzeit aber nur ~234MB. Die restlichen ~271MB werden nur zum dynamischen Zwischenspeichern (cached) verwendet und bei Bedarf freigegeben. Das heisst, dass noch ~270MB RAM zur Verfügung stehen...
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 17:17
by Joe User
schüri wrote:so und was muss ich jetzt genau ändern?
Im Moment gar nichts.
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 17:20
by schüri
Joe User wrote:schüri wrote:so und was muss ich jetzt genau ändern?
Im Moment gar nichts.
ok danke... so langsam kommen wir zur spitzenzeit, wo die meisten online kommen...
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 17:44
by schüri
matzewe01 wrote:Naja, er könnte die 314 Tabellen optimieren.
Am einfachsten geht das über phpMyadmin,
die 7% der long queries könnte man sich mal ansehen und diese ggf. mit Indexen optimieren.
Aber erstmal die DB 24 Stunden laufen lassen.
BTW. hakt das System denn aktuell oder laufen die Foren "performant"?
die meisten Tabellen sind eig optimiert - soll ich jetzt wirklich alle 37 DBs durchsuchen und einzelne Tabellen optimieren?
tja, da liegt mein Problem - wo schau ich mir die long queries an und wie optimiere ich sie mit Indexen?
es hakt jetzt schon - Forum brauchen ca. 5-10 Sek. bis sie aufgebaut sind :(
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 18:01
by Joe User
matzewe01 wrote:Naja, er könnte die 314 Tabellen optimieren.
Die sind wenige Sekunden später wieder "unoptimiert", bringt also nahezu nix ;)
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 18:10
by Joe User
matzewe01 wrote:Jetzt werden die genannten Informationen interesant.
Noch nicht ganz, da wir immer noch nicht wissen, ob phpBB2 oder phpBB3.
Bei phpBB2 müsste er dermassen viel am Source ändern um die meisten Slow-Queries zu eliminieren, dass er auch gleich phpBB2 komplett neu schreiben könnte. Bei phpBB3 sind bereits fast alle Queries optimiert und werden zudem wenn möglich phpBB3-intern gecached, so dass hier nur noch wenig zu optimieren ist.
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-09 18:26
by schüri
matzewe01 wrote:Jetzt werden die genannten Informationen interesant.
-> um die long queries heraus zu finden, musst Du das long_query_log aktivieren siehe hierzu die mysql Doku.
Zudem solltest Du prüfen, welcher der Queries z.B. keine Indexe verwenden.
Die danach ermittelten Abfragen, (landen in einem logfile) kannst Du dann mit explain <siehe ebenfalls die mysql doku> genauer untersuchen.
Je nach abgefragten Spalten und where Bedingungen kann es dann sinnvoll sein Indexe darüber anulegen.
Das optimieren der Tabelen ist leider ein regelmässig notweniger job.
Die Ursache sind z.B. Einträge, die wieder gelöscht werden.
ich werde aber aus der doku net schlau, da steht nirgendwo wie man long_query_log aktiviert...
..und somit kann ich auch nix mit den indexen machen :(
habe jetzt einfach folgendes hinzugefügt:
worauf aber anscheinend die DB ausgefallen ist, deshalb wieder entfernt
außerdem habe ich ja noch folgendes in der my.cnf stehen:
die tabellen lasse ich demnächst jeden morgen optimieren
und ja ich benutze phpbb2 bis auf 3 Foren...
dann bleibt mir wohl nix anderes übrig als zu upgraden - wobei dafür eig keine zeit da wäre
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-10 00:37
by schüri
ich habe das jetzt mehrmals versucht in die my.cnf einzutragen - jedes mal war nach nem neustart die datenbank nicht mehr erreichbar :(
was genau muss ich denn da jetzt eintragen - momentan läuft auch wieder nix ](*,)
//edit:
nachdem ich diesen Thread gefunden habe, konnte ich es erfolgreich aktivieren :-D
http://www.rootforum.org/forum/viewtopi ... 04&t=48961
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-10 01:13
by schüri
sry für doppelpost, aber wie erstelle ich jetzt diese indexe und in welchen tabellen muss das gemacht werden?
in allen die in dem slow-query-log drin sind? :o
Re: VServer macht schlapp - vermute Problem mit MySQL
Posted: 2009-01-10 01:45
by schüri
matzewe01 wrote:Wie Du es im vorher gefunden Thread gesehen hast, kannst Du die Ausgaben in slow-query-log mit mysqldumpslow sortieren.
Code: Select all
# > mysqldumbslow /var/log/mysql/slow-queries.log -t 10 -s c
-bash: /var/log/mysql/slow-queries.log: Das Programm kann nicht ausgeführt oder verändert werden (busy)
hmm geht nicht :(