MySQL Performance CPU 100%

Hallo Newsgroup,

ich habe Probleme mit dem Mysld-Dämon.

Ich betreibe eine Flirtsite. Da Besucherzahlen immer weiter stiegen
reichte, der Server nicht mehr aus. Das lag hauptsächlich am Apache.
Dieser lastete den Server stark aus.

Nach dem Serverumzug ist nun auf dem neuen System der Apache nicht
mehr derjenige Dienst der am meisten CPU-Last frisst:
AMD Opteron 1218 Dual Core
4 GB DDR2-667 RAM

Dafür aber der Mysql-Server (htop):
MySQL-Dienst: ca 90% CPU Auslastung
Apache-Dienst ca. 5%

Zu meinem System:
Debian Etch, Apache2.2, Mysql-Server5.0

Das gleiche Problem hatte ich vor 2 Monaten bereits, damals konnte ich
das durch setzen von Indizes lösen. Diesmal klappt es leider nicht.

So wirkt sich das aus: Nach einem Restart hat der Server einen
"normalen" Serverload von 0.10. Dieser steigt nach ca. 15 Minuten
koninuierlich an. Bei nem Load von 30.00 starte ich derzeit den Dienst
immer neu.

Wäre nett, wenn mir jemand Tipps geben könnte. wie ich das in den
Griff bekomme bzw. was ich für Möglichkeiten zur Diagnose habe.

Re: MySQL Performance CPU 100%

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: MySQL Performance CPU 100%

> EXPLAIN wurde für *exakt* diesen Zweck erfunden.


Das ganze habe ich schon durch. Soweit ich das sehe liegt es nicht an
Indizes. Es gibt nur noch wenige Abfragen, bei denen keine Indizes
verwendet werden. Allgemein habe ich slow-query-logging aktiviert und
keine Logging-Einträge erhalten. Ausser halt wenn ich die, die keine
Indizes benutzen mitlogge.

Re: MySQL Performance CPU 100%

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: MySQL Performance CPU 100%

Kostja wrote:
>
> ich habe Probleme mit dem Mysld-Dämon.

Nein.

> Ich betreibe eine Flirtsite. Da Besucherzahlen immer weiter stiegen
> reichte, der Server nicht mehr aus. Das lag hauptsächlich am Apache.
> Dieser lastete den Server stark aus.
>
> Nach dem Serverumzug ist nun auf dem neuen System der Apache nicht
> mehr derjenige Dienst der am meisten CPU-Last frisst:
> AMD Opteron 1218 Dual Core
> 4 GB DDR2-667 RAM
>
> Dafür aber der Mysql-Server (htop):
> MySQL-Dienst: ca 90% CPU Auslastung
> Apache-Dienst ca. 5%
>
> Zu meinem System:
> Debian Etch, Apache2.2, Mysql-Server5.0
>
> Das gleiche Problem hatte ich vor 2 Monaten bereits, damals konnte ich
> das durch setzen von Indizes lösen. Diesmal klappt es leider nicht.

Du hast kein "Problem". Außer vielleicht daß du keine Ahnung hast
(nicht persönlich gemeint).

Auf einem belasteten Server wird nun mal CPU-Zeit verbraucht. Das ist
ganz normal und überhaupt kein Problem. Ab einer bestimmten Last ist
irgendeine Resource (allerdings eher selten die CPU) eben zu 100%
ausgelastet und der Server läuft im Durchsatzmaximum. Weitere Last
führt dann zumindest zur Verlangsamung (gleicher Durchsatz, mehr
Zugriffe -> mehr Zeit pro Zugriff) irgendwann auch zum Absacken der
Durchsatzleistung.

> So wirkt sich das aus: Nach einem Restart hat der Server einen
> "normalen" Serverload von 0.10. Dieser steigt nach ca. 15 Minuten
> koninuierlich an. Bei nem Load von 30.00 starte ich derzeit den Dienst
> immer neu.

Ganz tolle Idee. Und was glaubst du, bringt das? Neustarten ist *kein*
Mittel zur Problemlösung. Auch nicht auf Windows.

> Wäre nett, wenn mir jemand Tipps geben könnte. wie ich das in den
> Griff bekomme bzw. was ich für Möglichkeiten zur Diagnose habe.

Such dir jemanden, der sich mit dem Tuning eines LAMP-Systems auskennt.


XL

Re: MySQL Performance CPU 100%

>
> Ganz tolle Idee. Und was glaubst du, bringt das? Neustarten ist *kein*
> Mittel zur Problemlösung. Auch nicht auf Windows.
>
> > Wäre nett, wenn mir jemand Tipps geben könnte. wie ich das in den
> > Griff bekomme bzw. was ich für Möglichkeiten zur Diagnose habe.
>
> Such dir jemanden, der sich mit dem Tuning eines LAMP-Systems auskennt.
>
> XL

Danke für die unprofessionelle Antwort. Den Neustart habe ich gemacht,
um den Server überhaupt einigermaßen erreichbar zu machen. Mir geht es
darum etwas zu lernen. Ich suche niemanden der mir das fertig macht
und das Problem löst. Vor einer Woche hatte ich das Problem noch nicht
- jetzt schon. Ich würde nicht sagen, dass die Datenbank oder die
Verbindungen zur Datenbank gigantisch gestiegen sind. Es ist also DOCH
ein Problem, wenn auf einmal die CPU-Last von max. 15% auf 100%
ansteigt.

Re: MySQL Performance CPU 100%

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: MySQL Performance CPU 100%

> Hint: das 'M' für MySQL ist in einem LAMP-System nur 1/4 des Ganzen.

Hmm dann ist es doch möglich, dass es z.b. am Apachen liegt, auch wenn
nur der Mysqld die hohe Last erzeugt? Apache Auslastung ist ja
niedrig. Sorry, dass ich den Tipp nicht erkannt habe :) Ich brauche
halt irgendwelche Ansatzpunkte. Ich habe jetzt langsam genug Zeit in
my.cnf-Optimierung verschwendet und würde gerne mal wieder was
programmieren. tuning-primer.sh habe ich auch bereits genutzt und
dementsprechend angepasst.

Wie bzw. mit welchen Tools kann ich denn erkennen wodurch der Fehler
entsteht bzw. wodurch die hohe Load genau verursacht wird?

Re: MySQL Performance CPU 100%

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: MySQL Performance CPU 100%

> Da Du lernrestistent bist, bin ich
> nun schreibfaul.

Bin nicht lernresistent - nur brauche ich wenigstens nen Ansatz.

Das Thema zu I/O Messung habe ich mir angeschaut. per dstat habe ich
mir die Statistiken anzeigen lassen - leider bringt mich das nicht
weiter :(

Gib mir was zu lesen oder weitere Tipps zu der Problemstellung und ich
informiere mich.

Dstat Ausgabe:
Server:/# dstat -all
[code]
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---
system-- ---load-avg--- ---load-avg---
usr sys idl wai hiq siq|_read _writ|_recv _send|__in_ _out_|_int_
_csw_|_1m_ _5m_ 15m_|_1m_ _5m_ 15m_
43 7 49 0 0 0| 10k 395k| 0 0 | 0.5 1B| 758 4927
| 5.5 5.5 5.2| 5.5 5.5 5.2
88 10 0 0 0 0| 0 224k| 17k 51k| 0 0 | 499
16k| 5.5 5.5 5.2| 5.5 5.5 5.2
86 9 4 0 1 0| 0 0 | 41k 290k| 0 0 | 910
12k| 5.5 5.5 5.2| 5.5 5.5 5.2
91 8 0 0 0 0| 0 0 | 44k 261k| 0 0 | 806
15k| 5.5 5.5 5.2| 5.5 5.5 5.2
88 8 4 0 0 0| 0 0 | 52k 216k| 0 0 | 723
14k| 5.5 5.5 5.2| 5.5 5.5 5.2
87 10 1 0 1 0| 0 1088k| 52k 324k| 0 0 | 993
15k| 5.5 5.5 5.2| 5.5 5.5 5.2
91 8 0 0 0 0| 0 16k| 42k 132k| 0 0 | 641
16k| 5.5 5.5 5.2| 5.5 5.5 5.2
87 11 1 0 0 0| 72k 0 | 44k 212k| 0 0 | 698
15k| 5.5 5.5 5.2| 5.5 5.5 5.2
83 11 6 0 0 0| 64k 576k| 66k 360k| 0 0 | 987
14k| 5.5 5.5 5.2| 5.5 5.5 5.2
89 10 1 0 0 0| 64k 0 | 74k 398k| 0 0 | 972
14k| 5.5 5.5 5.2| 5.5 5.5 5.2
91 8 0 0 0 1| 76k 976k| 36k 274k| 0 0 | 820
12k| 5.5 5.5 5.2| 5.5 5.5 5.2
88 8 3 0 0 0| 16k 0 | 41k 418k| 0 0 |1037
14k| 5.6 5.5 5.2| 5.6 5.5 5.2
90 9 0 0 0 0| 56k 0 | 20k 353k| 0 0 | 787
14k| 5.6 5.5 5.2| 5.6 5.5 5.2
88 10 2 0 0 0| 64k 0 | 12k 79k| 0 0 | 511
14k| 5.6 5.5 5.2| 5.6 5.5 5.2
87 8 4 0 0 0| 0 0 |8778B 164k| 0 0 | 563
15k| 5.6 5.5 5.2| 5.6 5.5 5.2^X
89 9 1 0 0 1| 64k 1208k| 28k 306k| 0 0 | 903
15k| 5.6 5.5 5.2| 5.6 5.5 5.2

[/code]

Re: MySQL Performance CPU 100%

> Das Thema I/O-Messung hatten wir erst kürzlich hier. Der Rest ist
> normales Handwerkszeug eines Admins. Da Du lernrestistent bist, bin ich
> nun schreibfaul.

Bin nicht lernresistent - nur brauche ich wenigstens nen Ansatz.

Das Thema zu I/O Messung habe ich mir angeschaut. per dstat habe ich
mir die Statistiken anzeigen lassen - leider bringt mich das nicht
weiter :(

Gib mir was zu lesen oder weitere Tipps zu der Problemstellung und ich
informiere mich. Ich weiß einfach nicht, wie ich genau darauf kommen
soll, warum die CPU so ausgelastet ist.

Re: MySQL Performance CPU 100%

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: MySQL Performance CPU 100%

> Wie XL schon schrieb: laß es jemanden machen. Für Geld.

Nur weil du für Sachen zahlst, die du sonst nicht kostenlos bekommst,
muss ich das nicht auch machen. Es gibt hilfsbereite Menschen im
Internet - zu denen zähle ich mich auch - die gerne helfen und von
anderen auch Hilfe empfangen möchten. Wenn du es nicht bist, dann lass
deine komischen Kommentare hier. Danke

> Dein Code Obfuscator erzeugt noch halbwegs lesbaren Output. Das nur als
> Hinweis.

Beitrag war schon längst gelöscht...

Re: MySQL Performance CPU 100%

Kostja wrote:

>> Hint: das 'M' für MySQL ist in einem LAMP-System nur 1/4 des Ganzen.
>
> Hmm dann ist es doch möglich, dass es z.b. am Apachen liegt, auch wenn
> nur der Mysqld die hohe Last erzeugt?

Man muß auf jeden Fall das Gesamtkunstwerk betrachten. mysqld macht
CPU-Last ja nicht von sich aus, sondern wahrscheinlich um Anfragen aus
dem PHP-Code zu beantworten. Es kann natürlich auch sein, daß gerade
ein Recovery-Thread läuft, aber nix genaues weiß man nicht.

Aber wenn mysqld signifikant CPU-Zeit verbraucht, dann ist das eher ein
Fehler im Datenbankdesign oder in den Queries. Das slow-log *kann*
helfen, insbesondere wenn man sich mit --log-queries-not-using-indexes
alle tablescans loggen läßt. Hohe CPU-Last bedeutet meistens daß die
Daten zwar ins RAM passen, MySQL wegen fehlener Indexes oder unsinniger
Queries aber viele Tablescans macht.

An erster Stelle steht halt erst mal eine *Analyse* des Systemverhal-
tens. Slow-query-log, SHOW GLOBAL STATUS, SHOW PROCESSLIST, iwostat und
vmstat sind *Bausteine* - verknüpfen muß das ein Mensch, vorzugsweise
einer mit Erfahrung.

Bis vor ca. 3 Jahren war das mein täglich Brot, ich weiß also halbwegs,
wovon ich rede :)


XL

Re: MySQL Performance CPU 100%

> Aber wenn mysqld signifikant CPU-Zeit verbraucht, dann ist das eher ein
> Fehler im Datenbankdesign oder in den Queries. Das slow-log *kann*
> helfen, insbesondere wenn man sich mit --log-queries-not-using-indexes
> alle tablescans loggen läßt. Hohe CPU-Last bedeutet meistens daß die
> Daten zwar ins RAM passen, MySQL wegen fehlener Indexes oder unsinniger
> Queries aber viele Tablescans macht.

Ich wollte es beim letzten Performance Problem schon nicht glauben,
dass es am Datenbankdesign liegt. Aber diesmal habe ich nur wenige (3
oder 4) neue Tabellen hinzugefügt, seitdem Load ständig ansteigt. Die
Scriptteile bzw. die Seiten habe ich auch schon Testweise
rausgenommen, um zu sehen ob es daran liegt - Negativ :(


> An erster Stelle steht halt erst mal eine *Analyse* des Systemverhal-
> tens. Slow-query-log, SHOW GLOBAL STATUS, SHOW PROCESSLIST, iwostat und
> vmstat sind *Bausteine* - verknüpfen muß das ein Mensch, vorzugsweise
> einer mit Erfahrung.

Ein Mensch passt schonmal...

Slow Query Log wird ausser einigen wenigen Abfragen, die keine Indizes
benutzen, nichts geloggt.

Bei Show global status ist mir aufgefallen, dass da so einige
"Aborted_connects" aufgeführt sind. Ist das normal? Habe gelesen, dass
es Einbruchsversuche sein könnten...(MySQL ist in my.cnf nur konf.,
dass nur lokal erreichbar)

mytop sagt aus:
Queries: 8.3M qps: 2674 Slow: 0.0 Se/In/Up/De(%):
05/00/00/00
qps now: 3822 Slow qps: 0.0 Threads: 7 ( 4/ 8) 04/00/00/00
Key Efficiency: 100.0% Bps in/out: 4.6/843.3 Now in/out: 7.0/
14k

Re: MySQL Performance CPU 100%

Kostja wrote:
> Slow Query Log wird ausser einigen wenigen Abfragen, die keine Indizes
> benutzen, nichts geloggt.

Hast Du log-queries-not-using-indexes aktiviert? Wenn nein, ist obiges nicht
so praktisch. Was fuer Tabellentypen verwendest Du denn? Und was heisst
wenig (jede Sekunde? jede Minute? jede Stunde?)?

Zeig einfach mal Deinen SHOW GLOBAL STATUS.

> mytop sagt aus:
> Queries: 8.3M qps: 2674 Slow: 0.0 Se/In/Up/De(%):
> 05/00/00/00
> qps now: 3822 Slow qps: 0.0 Threads: 7 ( 4/ 8) 04/00/00/00

3822 Queries per Second sind eigentlich nicht schlecht, je nachdem, wie hoch
Dein Read-/Write-Verhaeltnis ist.

Re: MySQL Performance CPU 100%

> Hast Du log-queries-not-using-indexes aktiviert? Wenn nein, ist obiges ni=
cht
> so praktisch.

Ja es ist aktiviert, dass Queries, die keine Indexe verwendet geloggt
werden. Ist es nicht aktiviert, erhalte ich keine Queries, die länger
als 1 Sek. benötigen.


>Was fuer Tabellentypen verwendest Du denn?
MyISAM und INNoDB - INNODB bei einigen Tabellen für
Entfernungsberechnungen zwischen 2 Orten. Rest halt MyISAM

> Und was heisst
> wenig (jede Sekunde? jede Minute? jede Stunde?)?
Habe eben nochmal nachgeschaut. Also eine komplexe Query wird doch
recht häufig geloggt(Jede 2. Sekunde ca.). Wenn ich diese in MySQL
eingebe benötigt sie 0.0024 Ausführungszeit. Ist recht wenig oder
nicht? Ich habe schon versucht sie zu optimieren aber die ist doch
recht lang:

Hier die Abfrage (ist Abfrage für das Profil) Aber in dieser habe ich
schon länger nichts verändert. Würde mich wundern, wenn es daran
liegt:
SELECT (SELECT COUNT(*)AS anz_besitz FROM besitz AS b WHERE
bu_id=3D12116) AS anz_besitz, u.username, u.geschlecht, u.guthaben,
uadmin, u.foto, u.fotofreigabe, u.plz, DATE_FORMAT(u.anmeldedatum,
'%d.%m.%Y') AS anmeldedatum_format, u.anmeldedatum AS anmeldedatum, IF
(
DATE_FORMAT( CURDATE( ), '%m%d' ) >=3D DATE_FORMAT( u.geburtsdatum , '%m
%d' ) , DATE_FORMAT( CURDATE( ) , '%Y' ) -
DATE_FORMAT( u.geburtsdatum, '%Y' ) , DATE_FORMAT( CURDATE( ) , '%Y' )
- DATE_FORMAT( u.geburtsdatum, '%Y' ) -1
) AS geburtsdatum, DATE_FORMAT(u.geburtsdatum, '%d.%m.%Y') AS tag,
DATE_FORMAT(u.geburtsdatum, '%d') AS day, DATE_FORMAT(u.geburtsdatum,
'%m') AS monat,
ukommentar, u.anz_login, u.lastlogin, u.colm1, u.colm2, u.colm3,
ucolm4, u.verheiratet, u.kriminell, u.verh_seit, u.friends, u.nofake,
ugeburtsland, u.flirtstatus, f.u_id AS gruender, f.name AS
freundeskreisname,
(
SELECT ort.text_val
FROM geodb_textdata AS ort, geodb_textdata AS t1
WHERE ort.loc_id=3Dt1.loc_id AND ort.text_type=3D'500100000' /*
NAME */ AND t1.text_type=3D'500300000' AND t1.text_val=3Du.plz
LIMIT 1
) AS wohnort,
(
SELECT bl.text_val
FROM geodb_textdata AS bl, geodb_hierarchies AS h,
geodb_textdata AS t2
WHERE h.loc_id=3Dt2.loc_id AND h.id_lvl3=3Dbl.loc_id AND
t2.text_type=3D'500300000' AND t2.text_val=3Du.plz
LIMIT 1
) AS bundesland,
(
SELECT
DEGREES(
ACOS(
SIN(RADIANS(c1.lat)) * SIN(RADIANS(c2.lat))
+ COS(RADIANS(c1.lat)) * COS(RADIANS(c2.lat))
* COS(RADIANS(c1.lon - c2.lon))
) * 60 * 1.85201
)
FROM
geodb_textdata t1,
geodb_textdata t2,
geodb_coordinates c1,
geodb_coordinates c2
WHERE
t1.text_type =3D 500300000
AND t2.text_type =3D 500300000
AND t1.text_val =3D u.plz
AND t2.text_val =3D '30159'
AND c1.loc_id =3D t1.loc_id
AND c2.loc_id =3D t2.loc_id
LIMIT 1
) AS distance,
(
SELECT u_id AS dings_id
FROM dingsda
ORDER BY datum DESC
LIMIT 1
) AS dings_id
FROM `user` AS u
LEFT JOIN user AS u2 ON u.verheiratet=3Du2.username
LEFT JOIN friends AS f on u.friends=3Df.id
WHERE u.id =3D 2768
LIMIT 1;

> Zeig einfach mal Deinen SHOW GLOBAL STATUS.
Ok - allerdings musste ich vor kurzem Dienst neu starten, da wieder
nen Load von über 10 erreicht wurde :(

Aborted_clients 0
Aborted_connects 3
Binlog_cache_disk_use 0
Binlog_cache_use 0
Bytes_received 1173452
Bytes_sent 1731793
Com_admin_commands 2
Com_alter_db 0
Com_alter_table 69
Com_analyze 0
Com_backup_table 0
Com_begin 0
Com_change_db 1335
Com_change_master 0
Com_check 88
Com_checksum 0
Com_commit 0
Com_create_db 0
Com_create_function 0
Com_create_index 0
Com_create_table 14
Com_create_user 0
Com_dealloc_sql 0
Com_delete 93
Com_delete_multi 0
Com_do 0
Com_drop_db 0
Com_drop_function 0
Com_drop_index 0
Com_drop_table 0
Com_drop_user 0
Com_execute_sql 0
Com_flush 1
Com_grant 0
Com_ha_close 0
Com_ha_open 0
Com_ha_read 0
Com_help 0
Com_insert 88
Com_insert_select 0
Com_kill 0
Com_load 0
Com_load_master_data 0
Com_load_master_table 0
Com_lock_tables 0
Com_optimize 0
Com_preload_keys 0
Com_prepare_sql 0
Com_purge 0
Com_purge_before_date 0
Com_rename_table 0
Com_repair 0
Com_replace 0
Com_replace_select 0
Com_reset 0
Com_restore_table 0
Com_revoke 0
Com_revoke_all 0
Com_rollback 0
Com_savepoint 0
Com_select 4641
Com_set_option 1352
Com_show_binlog_events 0
Com_show_binlogs 0
Com_show_charsets 6
Com_show_collations 6
Com_show_column_types 0
Com_show_create_db 0
Com_show_create_table 2
Com_show_databases 2
Com_show_errors 0
Com_show_fields 4
Com_show_grants 1
Com_show_innodb_status 0
Com_show_keys 1
Com_show_logs 0
Com_show_master_status 0
Com_show_ndb_status 0
Com_show_new_master 0
Com_show_open_tables 0
Com_show_privileges 0
Com_show_processlist 0
Com_show_slave_hosts 0
Com_show_slave_status 0
Com_show_status 1
Com_show_storage_engines 0
Com_show_tables 8
Com_show_triggers 0
Com_show_variables 13
Com_show_warnings 0
Com_slave_start 0
Com_slave_stop 0
Com_stmt_close 0
Com_stmt_execute 0
Com_stmt_fetch 0
Com_stmt_prepare 0
Com_stmt_reset 0
Com_stmt_send_long_data 0
Com_truncate 0
Com_unlock_tables 0
Variable_name Value
Com_update 826
Com_update_multi 1
Com_xa_commit 0
Com_xa_end 0
Com_xa_prepare 0
Com_xa_recover 0
Com_xa_rollback 0
Com_xa_start 0
Compression OFF
Connections 1335
Created_tmp_disk_tables 78
Created_tmp_files 5
Created_tmp_tables 1240
Delayed_errors 0
Delayed_insert_threads 0
Delayed_writes 0
Flush_commands 1
Handler_commit 4
Handler_delete 6
Handler_discover 0
Handler_prepare 0
Handler_read_first 164
Handler_read_key 164435
Handler_read_next 215676
Handler_read_prev 43
Handler_read_rnd 2659
Handler_read_rnd_next 146776
Handler_rollback 0
Handler_savepoint 0
Handler_savepoint_rollback 0
Handler_update 11474
Handler_write 53181
Innodb_buffer_pool_pages_data 501
Innodb_buffer_pool_pages_dirty 3
Innodb_buffer_pool_pages_flushed 21
Innodb_buffer_pool_pages_free 0
Innodb_buffer_pool_pages_latched 0
Innodb_buffer_pool_pages_misc 11
Innodb_buffer_pool_pages_total 512
Innodb_buffer_pool_read_ahead_rnd 83
Innodb_buffer_pool_read_ahead_seq 81
Innodb_buffer_pool_read_requests 2303739
Innodb_buffer_pool_reads 3335
Innodb_buffer_pool_wait_free 0
Innodb_buffer_pool_write_requests 71
Innodb_data_fsyncs 26
Innodb_data_pending_fsyncs 0
Innodb_data_pending_reads 0
Innodb_data_pending_writes 0
Innodb_data_read 85626880
Innodb_data_reads 3687
Innodb_data_writes 36
Innodb_data_written 697856
Innodb_dblwr_pages_written 21
Innodb_dblwr_writes 5
Innodb_log_waits 0
Innodb_log_write_requests 4
Innodb_log_writes 9
Innodb_os_log_fsyncs 15
Innodb_os_log_pending_fsyncs 0
Innodb_os_log_pending_writes 0
Innodb_os_log_written 6656
Innodb_page_size 16384
Innodb_pages_created 0
Innodb_pages_read 5093
Innodb_pages_written 21
Innodb_row_lock_current_waits 0
Innodb_row_lock_time 0
Innodb_row_lock_time_avg 0
Innodb_row_lock_time_max 0
Innodb_row_lock_waits 0
Innodb_rows_deleted 8
Innodb_rows_inserted 3
Innodb_rows_read 2246270
Innodb_rows_updated 0
Key_blocks_not_flushed 0
Key_blocks_unused 426604
Key_blocks_used 2086
Key_read_requests 568744
Key_reads 2700
Key_write_requests 54290
Key_writes 1325
Last_query_cost 0.000000
Max_used_connections 5
Ndb_cluster_node_id 0
Ndb_config_from_host
Ndb_config_from_port 0
Ndb_number_of_data_nodes 0
Not_flushed_delayed_rows 0
Open_files 163
Open_streams 0
Open_tables 104
Opened_tables 222
Prepared_stmt_count 0
Qcache_free_blocks 49
Qcache_free_memory 16638072
Qcache_hits 364
Qcache_inserts 3324
Qcache_lowmem_prunes 0
Qcache_not_cached 1365
Variable_name Value
Qcache_queries_in_cache 104
Qcache_total_blocks 275
Questions 10256
Rpl_status NULL
Select_full_join 0
Select_full_range_join 0
Select_range 1078
Select_range_check 0
Select_scan 1080
Slave_open_temp_tables 0
Slave_retried_transactions 0
Slave_running OFF
Slow_launch_threads 0
Slow_queries 1032
Sort_merge_passes 0
Sort_range 315
Sort_rows 24258
Sort_scan 1199
Ssl_accept_renegotiates 0
Ssl_accepts 0
Ssl_callback_cache_hits 0
Ssl_cipher
Ssl_cipher_list
Ssl_client_connects 0
Ssl_connect_renegotiates 0
Ssl_ctx_verify_depth 0
Ssl_ctx_verify_mode 0
Ssl_default_timeout 0
Ssl_finished_accepts 0
Ssl_finished_connects 0
Ssl_session_cache_hits 0
Ssl_session_cache_misses 0
Ssl_session_cache_mode NONE
Ssl_session_cache_overflows 0
Ssl_session_cache_size 0
Ssl_session_cache_timeouts 0
Ssl_sessions_reused 0
Ssl_used_session_cache_entries 0
Ssl_verify_depth 0
Ssl_verify_mode 0
Ssl_version
Table_locks_immediate 8723
Table_locks_waited 21
Tc_log_max_pages_used 0
Tc_log_page_size 0
Tc_log_page_waits 0
Threads_cached 4
Threads_connected 1
Threads_created 5
Threads_running 1
Uptime 108

Re: MySQL Performance CPU 100%

Kostja wrote:
>> Zeig einfach mal Deinen SHOW GLOBAL STATUS.
> Ok - allerdings musste ich vor kurzem Dienst neu starten, da wieder
> nen Load von über 10 erreicht wurde :(

Oeh, gerade das ist ungeschickt, denn so sind die Counter alle
unrepraesentativ niedrig. SHOW GLOBAL STATUS nach 1h typischen Betrieb ist
aussagekraeftiger.

Re: MySQL Performance CPU 100%

> Oeh, gerade das ist ungeschickt, denn so sind die Counter alle
> unrepraesentativ niedrig. SHOW GLOBAL STATUS nach 1h typischen Betrieb ist
> aussagekraeftiger.

Habs mir gedacht :). Also der Server lief jetzt die Nacht durch. Das
einzige, was mir da jetzt an den Statistiken auffällt sind, die
abgebrochenen Verbindungen, wobei ich nicht weiß ob die bei der Anzahl
der Versuche nicht normal sind. (?)

Aborted_clients 0
Aborted_connects 1293
Binlog_cache_disk_use 0
Binlog_cache_use 0
Bytes_received 18906545136
Bytes_sent 18911218699
Com_admin_commands 7
Com_alter_db 0
Com_alter_table 69
Com_analyze 0
Com_backup_table 0
Com_begin 0
Com_change_db 292492
Com_change_master 0
Com_check 88
Com_checksum 0
Com_commit 0
Com_create_db 0
Com_create_function 0
Com_create_index 0
Com_create_table 14
Com_create_user 0
Com_dealloc_sql 0
Com_delete 16156
Com_delete_multi 0
Com_do 0
Com_drop_db 0
Com_drop_function 0
Com_drop_index 0
Com_drop_table 0
Com_drop_user 0
Com_execute_sql 0
Com_flush 2
Com_grant 0
Com_ha_close 0
Com_ha_open 0
Com_ha_read 0
Com_help 0
Com_insert 17655
Com_insert_select 0
Com_kill 0
Com_load 0
Com_load_master_data 0
Com_load_master_table 0
Com_lock_tables 3
Com_optimize 0
Com_preload_keys 0
Com_prepare_sql 0
Com_purge 0
Com_purge_before_date 0
Com_rename_table 0
Com_repair 0
Com_replace 0
Com_replace_select 0
Com_reset 0
Com_restore_table 0
Com_revoke 0
Com_revoke_all 0
Com_rollback 0
Com_savepoint 0
Com_select 130492078
Com_set_option 292347
Com_show_binlog_events 0
Com_show_binlogs 1
Com_show_charsets 23
Com_show_collations 23
Com_show_column_types 0
Com_show_create_db 0
Com_show_create_table 98
Com_show_databases 5
Com_show_errors 0
Com_show_fields 112
Com_show_grants 6
Com_show_innodb_status 0
Com_show_keys 7
Com_show_logs 0
Com_show_master_status 0
Com_show_ndb_status 0
Com_show_new_master 0
Com_show_open_tables 0
Com_show_privileges 0
Com_show_processlist 0
Com_show_slave_hosts 0
Com_show_slave_status 0
Com_show_status 2
Com_show_storage_engines 0
Com_show_tables 32
Com_show_triggers 88
Com_show_variables 48
Com_show_warnings 0
Com_slave_start 0
Com_slave_stop 0
Com_stmt_close 0
Com_stmt_execute 0
Com_stmt_fetch 0
Com_stmt_prepare 0
Com_stmt_reset 0
Com_stmt_send_long_data 0
Com_truncate 0
Com_unlock_tables 3
Variable_name Value
Com_update 219635
Com_update_multi 1
Com_xa_commit 0
Com_xa_end 0
Com_xa_prepare 0
Com_xa_recover 0
Com_xa_rollback 0
Com_xa_start 0
Compression OFF
Connections 292837
Created_tmp_disk_tables 11402
Created_tmp_files 5
Created_tmp_tables 84269
Delayed_errors 0
Delayed_insert_threads 0
Delayed_writes 0
Flush_commands 1
Handler_commit 3056
Handler_delete 2233
Handler_discover 0
Handler_prepare 0
Handler_read_first 25907
Handler_read_key 190930007
Handler_read_next 142093340
Handler_read_prev 46123
Handler_read_rnd 1028719
Handler_read_rnd_next 24581337
Handler_rollback 0
Handler_savepoint 0
Handler_savepoint_rollback 0
Handler_update 2624941
Handler_write 7590711
Innodb_buffer_pool_pages_data 509
Innodb_buffer_pool_pages_dirty 0
Innodb_buffer_pool_pages_flushed 6146
Innodb_buffer_pool_pages_free 0
Innodb_buffer_pool_pages_latched 0
Innodb_buffer_pool_pages_misc 3
Innodb_buffer_pool_pages_total 512
Innodb_buffer_pool_read_ahead_rnd 105
Innodb_buffer_pool_read_ahead_seq 1759
Innodb_buffer_pool_read_requests 73437272
Innodb_buffer_pool_reads 175106
Innodb_buffer_pool_wait_free 0
Innodb_buffer_pool_write_requests 25231
Innodb_data_fsyncs 9011
Innodb_data_pending_fsyncs 0
Innodb_data_pending_reads 0
Innodb_data_pending_writes 0
Innodb_data_read 3242627072
Innodb_data_reads 179282
Innodb_data_writes 11353
Innodb_data_written 204881920
Innodb_dblwr_pages_written 6146
Innodb_dblwr_writes 1931
Innodb_log_waits 0
Innodb_log_write_requests 1701
Innodb_log_writes 3523
Innodb_os_log_fsyncs 5137
Innodb_os_log_pending_fsyncs 0
Innodb_os_log_pending_writes 0
Innodb_os_log_written 2670592
Innodb_page_size 16384
Innodb_pages_created 7
Innodb_pages_read 197781
Innodb_pages_written 6146
Innodb_row_lock_current_waits 0
Innodb_row_lock_time 0
Innodb_row_lock_time_avg 0
Innodb_row_lock_time_max 0
Innodb_row_lock_waits 0
Innodb_rows_deleted 2352
Innodb_rows_inserted 2340
Innodb_rows_read 20252207
Innodb_rows_updated 0
Key_blocks_not_flushed 0
Key_blocks_unused 417490
Key_blocks_used 11202
Key_read_requests 2940961137
Key_reads 92494
Key_write_requests 7873665
Key_writes 335707
Last_query_cost 0.000000
Max_used_connections 61
Ndb_cluster_node_id 0
Ndb_config_from_host
Ndb_config_from_port 0
Ndb_number_of_data_nodes 0
Not_flushed_delayed_rows 0
Open_files 308
Open_streams 0
Open_tables 280
Opened_tables 398
Prepared_stmt_count 0
Qcache_free_blocks 4
Qcache_free_memory 160184
Qcache_hits 5397983
Qcache_inserts 130312503
Qcache_lowmem_prunes 51629608
Qcache_not_cached 179672
Variable_name Value
Qcache_queries_in_cache 16201
Qcache_total_blocks 32397
Questions 137021797
Rpl_status NULL
Select_full_join 36
Select_full_range_join 7
Select_range 129829656
Select_range_check 0
Select_scan 43049
Slave_open_temp_tables 0
Slave_retried_transactions 0
Slave_running OFF
Slow_launch_threads 0
Slow_queries 42896
Sort_merge_passes 0
Sort_range 66140
Sort_rows 5674358
Sort_scan 84930
Ssl_accept_renegotiates 0
Ssl_accepts 0
Ssl_callback_cache_hits 0
Ssl_cipher
Ssl_cipher_list
Ssl_client_connects 0
Ssl_connect_renegotiates 0
Ssl_ctx_verify_depth 0
Ssl_ctx_verify_mode 0
Ssl_default_timeout 0
Ssl_finished_accepts 0
Ssl_finished_connects 0
Ssl_session_cache_hits 0
Ssl_session_cache_misses 0
Ssl_session_cache_mode NONE
Ssl_session_cache_overflows 0
Ssl_session_cache_size 0
Ssl_session_cache_timeouts 0
Ssl_sessions_reused 0
Ssl_used_session_cache_entries 0
Ssl_verify_depth 0
Ssl_verify_mode 0
Ssl_version
Table_locks_immediate 129897282
Table_locks_waited 1473669
Tc_log_max_pages_used 0
Tc_log_page_size 0
Tc_log_page_waits 0
Threads_cached 7
Threads_connected 46
Threads_created 1484
Threads_running 29
Uptime 42359

Re: MySQL Performance CPU 100%

Okay bin ein wenig weiter gekommen. Habe mich weiter zu Indizes
informiert und dabei ist mir aufgefallen, dass Update-Befehle
teilweise 0.1 Sec brauchen bei 15.000 Datensätzen. Das is recht lange
finde ich. Beispiel für ein update:

UPDATE user
SET col=3Dcol+1
WHERE id=3D1
LIMIT 1;

Die Abfrage ist recht simple und sollte den Primary INDEX nutzen
soweit ich das verstanden habe.

Re: MySQL Performance CPU 100%

Am 04.10.2007 14:35 schrieb Kostja:
> Okay bin ein wenig weiter gekommen. Habe mich weiter zu Indizes
> informiert und dabei ist mir aufgefallen, dass Update-Befehle
> teilweise 0.1 Sec brauchen bei 15.000 Datensätzen. Das is recht lange
> finde ich. Beispiel für ein update:
>
> UPDATE user
> SET col=col+1
> WHERE id=1
> LIMIT 1;
>
> Die Abfrage ist recht simple und sollte den Primary INDEX nutzen
> soweit ich das verstanden habe.
>

Warum fragst Du nicht einfach "EXPLAIN"? Dann brauchst Du nix zu
"verstehen", sondern siehst, was MySQL tut.

BTW: Warum LIMIT in diesem Zusammenhang? Das ergibt doch ohne ORDER BY
überhaupt keinen Sinn, schon gar nicht, wenn ID ein PK ist.

--
Christian

Re: MySQL Performance CPU 100%

Kostja wrote:
>
> Also der Server lief jetzt die Nacht durch. Das
> einzige, was mir da jetzt an den Statistiken auffällt sind, die
> abgebrochenen Verbindungen, wobei ich nicht weiß ob die bei der Anzahl
> der Versuche nicht normal sind. (?)
>
> Aborted_clients 0
> Aborted_connects 1293
> Connections 292837

Etwa 0.3% - vermutlich nicht relevant. Trotzdem seltsam.

> Bytes_received 18906545136
> Bytes_sent 18911218699

Das finde ich seltsam angesichts

> Com_delete 16156
> Com_insert 17655
> Com_update 219635

vs.

> Com_select 130492078

Allerdings - seit ich die eine Query letztens gesehen habe, wundert
mich das nicht mehr ganz so. Wer hat dieses SQL denn verbrochen?

Und da oben: sind das Mass-Inserts? Oder liefern deine SELECTs immer
nur sehr wenig Daten?

> Created_tmp_disk_tables 11402
> Created_tmp_tables 84269

Das sieht nicht zu schlecht aus.

> Handler_read_first 25907
> Handler_read_key 190930007
> Handler_read_next 142093340
> Handler_read_prev 46123
> Handler_read_rnd 1028719
> Handler_read_rnd_next 24581337

Das sieht sogar ausgesprochen gut aus: die weitaus meisten Zugriffe
gehen über einen Index und liefern auch nur einen Wert.

> Innodb_buffer_pool_pages_total 512

Das ist der Default von 8MB, der typischerweise viel zu klein ist, aber

> Innodb_buffer_pool_read_requests 73437272
> Innodb_buffer_pool_reads 175106

.... offensichtlich hast du nicht viel Daten in InnoDB-Tabellen, so daß
das trotzdem für >99% hitrate reicht.

> Key_blocks_unused 417490
> Key_blocks_used 11202

Der key_buffer ist dafür deutlich überdimensioniert (allerdings ist das
nicht schlimm, weil der on-demand alloziert wird)

> Open_tables 280
> Opened_tables 398

Der table_cache ist auch groß genug.

> Qcache_hits 5397983
> Qcache_inserts 130312503

Der Query-Cache funktioniert anscheinend gar nicht. Würde ich
abschalten (Größe auf 0 setzen)

> Slow_queries 42896

Huch? Hattest du nicht was von 0 erzählt?

> Questions 137021797
> Uptime 42359

Macht nach Adam Riese 3234 Queries pro Sekunde. Das ist ne Menge Holz.
Kann ich dem MySQL nicht übelnehmen, daß es dafür ordentlich an der CPU
saugt. Insbesondere weil der Query-Cache so gar nicht wirkt.

Kannst du sagen, zu wieviel Pageviews pro Sekunde das korrespondiert?
Oder anders gefragt: wieviele Queries macht denn deine Applikation pro
ausgelieferter Seite? Vermutlich ist das ein zu hoher Wert (10-20 würde
ich als normal bezeichnen).

Mit SQL-Optimierung wird man sicher noch das eine oder andere heraus
holen können, aber mehr als Faktor 2 bringt das kaum (es sei denn, da
sind noch fette Klopper a'la ... LIKE '%foo%' ... drin).
Die Strategie sollte jetzt sein, möglichst wenig Daten aus der Daten-
bank zu holen und statt dessen mehr statischen Content zu haben.
Memcache eignet sich z.B. prima, um häufig gebrauchte Daten zu cachen.
Die allereinfachste Variante wäre, dynamischen Content mit geeigneten
Expires: Headern zu versehen und einen caching Proxy vor den Webserver
zuu stellen. Kommt aber alles sehr auf die Applikation an.

Man könnte auch überlegen, Daten so aufzuteilen, daß der Query-Cache
nicht so viel Ergebnisse invalidieren muß. Also häufig geänderte Daten
von den eher statischen trennen (verschiedene Tabellen).

Angesichts der anscheinend kleinen Datenmenge (in Relation zum verfüg-
baren RAM) könnte man auch überlegen, alles auf InnoDB umzustellen.
Das ist aber ein zweischneidiges Schwert. Würde ich erst sehr gründlich
auf einem separaten System testen wollen. Wenn genügend RAM da ist, ist
InnoDB sauschnell.

Der nächste Schritt zum Wachstum wäre dann Replikation. Eine Variante
die mir besonders zusagt, ist Webserver und Replikat jeweils auf eine
Maschine zu packen und mehrere davon (bis mittlere zweistellige Zahlen
sind machbar) parallel zu betreiben. Dann gehen alle Lesezugriffe auf
die lokale Datenbank und die Skalierung ist automatisch gegeben -
zumindest so lange bis der Master das Bottleneck wird.


XL

Re: MySQL Performance CPU 100%

Wow, danke für die ausführliche Antwort. Ich schreibe jetzt erstmal ne
Teil-Antwort - später noch was konkretes, aber erstmal muss ich was
handfestes haben, bevor ich hier groß was veröffentliche :).

Zu Slow-Queries: Das sind so "viele", weil da auch Queries geloggt
werden, die keine Indizes benutzen. Schalte ich dieses aus und lasse
nur Queries loggen, die mehr als 1 Sek. benötigen, wird nichts
geloggt.

Ich saß gestern mit nem Kumpel nochmal an dem Server. Was uns
aufgefallen ist: Bei nem Load von über 20 (!) ist die Seite immer noch
sehr gut ansprechbar und flottes surfen ist problemlos möglich. Kann
es sein, dass htop bzw. top nen Problem beim Auslesen der
Informationen aus /proc/ hat? Fanden wir ungewöhnlich, dass die Seiten
so schnell ausgeliefert wurden.

> Das ist der Default von 8MB, der typischerweise viel zu klein ist, aber
> ... offensichtlich hast du nicht viel Daten in InnoDB-Tabellen, so daß
> das trotzdem für >99% hitrate reicht.

InnoDB verwende ich für Entfernungsberechnung zwischen 2 Orten.
Hiervon gibt es 4 Tabellen mit insgesamt ca. 230.000 Einträgen. Diese
werden auch häufig genutzt (bei jedem Aufruf eines Profils) Allerdings
habe ich daran innerhalb des letzten Monats nichts geändert.

Zum Query-Cache:

Ich habe beim DB-Design nen so finde ich kleinen Schnitzer gehabt. In
der User-Tabelle befinden sich Spalten mit Statistiken zum Profil.
Diese werden auch häufig aktualisiert - dagegen die restlichen Daten
wie z.B. E-Mails relativ selten. Jetzt habe ich in der MySQL-Doku
gelesen, dass bei jedem Update gecachte Queries wieder verloren gehen
- deswegen vielleicht auch die niedrige Hitzahl der gecachten
Queries(??!?)

Werde als nächstes die Statistiken auslagern müssen in eine eigene
Tabelle. Habe das auch probeweise schon gemacht. Die UPDATE-Query von
oben hatte dann 0.0005 sec. benötigt. Weiß nicht ob man das jetzt
gleich so unterschreiben kann, weil auf die neue Statistik-Tabelle ja
sonst nicht weiter zugegriffen wurde, während der UPDATE-Ausführung.

Noch was:

Irgendwie werde ich das Gefühl nicht los, dass irgendein Cache voll
läuft. Nach einem Neustart läuft der Server 20 Minuten bis zu einer
Stunde super, auch bei vielen Usern (Load von 0.05 - 0.1) Irgendwann
aber dann steigt auf einmal die Prozessorlast sofort an und versucht
eine immer weiter steigende Load.

> Die Strategie sollte jetzt sein, möglichst wenig Daten aus der Daten-
> bank zu holen und statt dessen mehr statischen Content zu haben.

Da wo es mir sinnvoll erschien habe ich bereits auf Smarty umgestellt.

Weiteres später. :)

Re: MySQL Performance CPU 100%

So jetzt habe ich noch was gefunden. Habe jetzt 1 Stunde lang htop
laufen haben und gleichzeitig MySQL-Administrator und mal die Anzahl
an Abfragen angeschaut. Derzeit sind ca. 90 User online. Nicht
besonders viel. Der Server lief jetzt ca. 1 Stunde mit niedriger
Auslastung. (Denke mal Durchschnitt ca. 0.10)

Die Abfragen, die durchgeführt wurden, lagen bei 5 bis 20 laut MySQL-
Administrator, die ganze Stunde lang. Dann auf einmal extremer Anstieg
der Abfragen auf ca. 2000(!) Abfragen und der dementsprechende Load.

Ich hab mal die Grafik hochgeladen. Da sieht man das richtig gut:
http://i20.tinypic.com/xap1sp.jpg (ca. 98 kB)
Aktuell so ca. 10 Minuten später zeigt mir MySQL-Adminsitrator ca.
3000 Abfragen und nen Traffic von 600kB nur mal zum Vergleich wie das
jetzt steigt.

Wie würdet ihr das deuten - habe da ne Vorahnung, möchte euch aber
nicht beeinflussen :) Langsam kommen wir dem Problem näher :)

Re: MySQL Performance CPU 100%

Kostja wrote:
> So jetzt habe ich noch was gefunden. Habe jetzt 1 Stunde lang htop
> laufen haben und gleichzeitig MySQL-Administrator und mal die Anzahl
> an Abfragen angeschaut. Derzeit sind ca. 90 User online. Nicht
> besonders viel. Der Server lief jetzt ca. 1 Stunde mit niedriger
> Auslastung. (Denke mal Durchschnitt ca. 0.10)
>
> Die Abfragen, die durchgeführt wurden, lagen bei 5 bis 20 laut MySQL-
> Administrator, die ganze Stunde lang. Dann auf einmal extremer Anstieg
> der Abfragen auf ca. 2000(!) Abfragen und der dementsprechende Load.

Ist denn auch die Anzahl der Datenbankverbindungen angestiegen? Was
zeigt SHOW FULL PROCESSLIST?

Welcher der COM_* Zähler von SHOW GLOBAL STATUS tickt jetzt am
schnellsten?

> Wie würdet ihr das deuten - habe da ne Vorahnung, möchte euch aber
> nicht beeinflussen :) Langsam kommen wir dem Problem näher :)

Das kann alles mögliche sein. Wenn das SELECTs sind, könnte es ein
Backup-Cronjob sein, den (ana)cron zur Unzeit startet. Oder es ist
ein Programmierfehler, der die Datenbank in einer Endlosschleife mit
Queries zumüllt. Oder es ist ein Angriff von außen. Zieht gerade
jemand deine Datenbank ab?

Es sprich aber vieles dafür, daß der Verursacher *auf* deinem Server
läuft. Das ist so, weil dein Server praktisch an seine Leistungsgrenze
gefahren wird, sich der Verursacher des Query-Storms quasi selber die
CPU-Ressourcen abgräbt und sich so letztendlich ein stabiler Zustand
einstellt.

Ich würde ja auch mal in top schauen, ob es außer mysqld und httpd
noch andere Prozesse mit nennenswerter Aktivität gibt. Oder ob ein
bestimmter httpd Worker besonders aktiv ist.


XL

Re: MySQL Performance CPU 100%

> Das kann alles mögliche sein. Wenn das SELECTs sind, könnte es ein
> Backup-Cronjob sein, den (ana)cron zur Unzeit startet. Oder es ist
> ein Programmierfehler, der die Datenbank in einer Endlosschleife mit
> Queries zumüllt. Oder es ist ein Angriff von außen. Zieht gerade
> jemand deine Datenbank ab?

Das ist richtig :-) Habe es gerade gehabt. Ich habe bei den
Auswirkungen sofort an eine Endlosschleife gedacht. Ich habe im ganzen
Script nur eine Schleife, wo ich ein SELECT innerhalb der Schleife
aufgeführt ist und genau da war der Fehler. Wenn ich mir das jetzt
überlege passt alles perfekt zusammen.

1 Anzahl der extrem hohen Abfragen
2 Verhältnismässig sehr viele SELECT-Abfragen(97%) zu UPDATES oder
INSERTs
3 Anstieg der Last in unregelmässigen Abständen

Das fiese war auch noch, dass die Endlosschleife im PHP-Script nur
aufgerufen wird, wenn man NICHT eingeloggt ist. Ich hatte nämlich die
eine Variable beim kopieren aus einer anderen Schleife nicht
abgeändert und dadurch wurde eine Endlosschleife ausgeführt, da beide
Variablen genau dann keinen Inhalt hatten.

Blöder Fehler. Aber immerhin hat es mich weitergebracht - habe mich
mit Datenbankdesign und speziell mit Indizes gut befasst.

Besten Dank für die Unterstützung hier. Ich denke mal, dass hier vor
allem der Beitrag oben von dir Axel so einigen, die Probleme haben,
noch weiterhelfen wird. (Suchbegriff "MySQL Performance CPU" Ranking
auf 1) :-D

Re: MySQL Performance CPU 100%

On Fri, 05 Oct 2007 02:51:47 -0700 Kostja wrote:
> Ich habe bei den Auswirkungen sofort an eine Endlosschleife gedacht.
> Ich habe im ganzen Script nur eine Schleife, wo ich ein SELECT
> innerhalb der Schleife aufgeführt ist und genau da war der Fehler.
> Wenn ich mir das jetzt überlege passt alles perfekt zusammen.

Fuer solche Probleme hat sich bei mir ein (voruebergehendes!) Aktivieren
von

| log = /var/log/mysql.log

recht gut bewaehrt. Wenn die Last ins uferlose geht, dreht man das
System ab und guckt, was sich zu allerletzt getan hat. Dann sieht man
sehr schnell, _ob_ das Programm in einer Endlosschleife haengt und auch
gleich noch, _wo_ das ist. Das geht meist um Groessenordnungen
schneller, als Rateversuche ueber die Lastwerte.

Man sollte bloss tunlichst nicht vergessen, das Log hinterher wieder zu
deaktivieren, sonst bekommt man recht schnell ein ganz anderes Problem.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan: Der göttliche Funke in uns.
(Sloganizer)

Re: MySQL Performance CPU 100%

> recht gut bewaehrt. Wenn die Last ins uferlose geht, dreht man das...

Das hatten wir gemacht. Allerdings wird genau die Abfrage, die
betroffen war auch so sehr häufig durchgeführt. Deswegen ist uns da
nichts aufgefallen. Mit ein wenig mehr Konzetration darauf wäre das
sicherlich aber möglich gewesen.

> Man sollte bloss tunlichst nicht vergessen, das Log hinterher wieder zu
> deaktivieren, sonst bekommt man recht schnell ein ganz anderes Problem.

Ja, das ist dann wieder deaktiviert worden.