Server zeitweise unerreichbar über http

[manarak]

Liebe Forummitglieder: ich brauche eure Hilfe, um ein Problem mit meinem Server zu diagnostizieren.

Der Server ist jetzt über 2 Jahre lang sehr gut gelaufen.
Die Last und der Traffic sind in dieser Zeit nicht wesentlich angestiegen.

Problembeschreibung:
Seit ca. einem Monat kommt jetzt immer öfter vor, dass der Server für eine Zeit lang keine Internetseiten ausgibt. Während dem Rest der Zeit, antwortet er schnell.
Bemerkenswert ist, dass der Server jedoch über Konsole ansprechbar bleibt, wenn auch leicht verzögert.
TOP ergab, dass in Zusammenhang mit diesen Problemen, MySQL zu diesen Zeitpunkten eine sehr hohe CPU-Last verursacht: zwischen 80 und 100%.
Der Load des Servers steigt dann von ca. 0.5 auf 4 bis 6, bis er wieder runterkommt.
Während des Problems werden auch keine reinen HTML-Seiten ausgegeben.
TOP zeigte keine httpd prozesse während des Problems an.
MySQL meldet keine SLOW QUERIES oder ähnliches, es waren ca. 40 queries aktiv, alle weniger als 120 sek. alt.
Die HD-mounts sind alle zu weniger als 60% voll.
Es findet kein ungewöhnlicher Traffic statt.
Das Problem kann jederzeit, unabhängig von einer bestimmten Uhrzeit auftreten.
Ich habe auch überprüft, wieviele Connections zum Server offen waren, bin auf 24 gekommen.
Es laufen zu diesen Zeiten auch keine CRON-jobs

Konfiguration des Servers:
2 x 2.8 GHz Xeon
1.5 GB RAM
edit: 2 HDD mit RAID 1 gespiegelt
edit 2: server swappt nicht!

PHP4
MySQL4
Qmail
Plesk 7.5.4
Apache 2


Ich würde gerne herausfinden, was diese "Hänger" verursacht.
Was muss ich überprüfen?

[daemotron]

Könnte sein, dass Deine Festplatte am abnippel ist... wenn noch genügend freier Speicher da ist, wird normalerweise versucht, defekte Blöcke zu umgehen. Das kostet aber ziemlich Zeit, was die I/O-Waits hochtreiben kann. Wenn also bei hoher Load eine Menge Wait dabei ist, würde ich mal mit Smartmontools und/oder IOZone auf die Platte losgehen.

[manarak]

danke, ich werde Mal die Platten prüfen.

ah so, habe noch vergessen zu sagen, dass die 2 platten mit RAID 1 gespiegelt sind

gibt es sonst noch Dinge, die ich heute Abend prüfen könnte?


P.S.
warum würde ein Plattenproblem die CPU-Last durch MySQL auf 100% treiben?
müsste das denn nicht eher irgendein i/o Prozess oder RAID Verwaltungs-Prozess sein?

[daemotron]

ah so, habe noch vergessen zu sagen, dass die 2 platten mit RAID 1 gespiegelt sind

OK, das macht ein Hardware-Problem (zumindest mit den Platten) deutlich unwahrscheinlicher.

gibt es sonst noch Dinge, die ich heute Abend prüfen könnte?

- Du könntest mit mytop mal gezielt den mysqld beobachten, wenn er sich wieder "festfrisst".
- Welche DB-Engine(s) setzt Du denn ein? Wie ist diese konfiguriert/optimiert?
- Wie sieht die RAM-Verfügbarkeit aus, wenn es passiert? Muss der Kernel vielleicht swappen?

warum würde ein Plattenproblem die CPU-Last durch MySQL auf 100% treiben?
müsste das denn nicht eher irgendein i/o Prozess oder RAID Verwaltungs-Prozess sein?

Den eigentlichen Schreibvorgang übernimmt natürlich ein Kernel-Prozess (Dateisystem und/oder Device Mapper). Allerdings fordert der (MySQL-)Prozess den Schreibvorgang beim Kernel an und wartet auf das Ergebnis der Operation. Und warten (wait) ist für den Scheduler etwas anderes als schlafen (sleep), womit die Wartezeit als aktive Prozesszeit gewertet wird. Wait ist aber separat auslesbar, wodurch top z. B. die aktuelle CPU-Nutzung auf User, Kernel ("sys"), Wait etc. aufgeteilt darstellen kann. Ein Prozess mit Status Wait beansprucht also auch weiterhin CPU-Zeit und blockiert dadurch Ressourcen. Dieses Verhalten ist aber "richtig", da bis zum Abschluss einer Kernel-Operation (syscall) diese Ressource für andere Prozesse blockiert bleiben muss.

[manarak]

- Du könntest mit mytop mal gezielt den mysqld beobachten, wenn er sich wieder "festfrisst".

ok, mache ich Mal

- Welche DB-Engine(s) setzt Du denn ein? Wie ist diese konfiguriert/optimiert?

ich glaube Inno DB
optimiert... hmmm... wie die meisten... performance tipps auf dem Netz gesucht, ein wenig an der my.conf rumgedoktert...
Ich kann gerne die Konfiguration aus my.conf, phpMyAdmin Laufzeit Variablen sowie eine phpinfo posten wenn's hilft.
Bisher hatte ich wie gesagt keine Probleme, und die DB conf hat sich seit Monaten nicht mehr geändert.
Ich möchte auch hinzufügen, dass der Server auch unter Last schnell läuft, wenn dieses Hänger-Problem nicht auftritt.

- Wie sieht die RAM-Verfügbarkeit aus, wenn es passiert? Muss der Kernel vielleicht swappen?

RAM-Verfügbarkeit sieht gut aus (ca. 80% used, 20% frei)
Der Server swappt so gut wie gar nicht (80k vom Swap sind beschrieben)

[manarak]

Mist - Du hast Recht, es ist eine Platte - mein RAID Verbund funktioniert nur noch mit einer Platte.

na denn... nix wie ins Datacenter Platte austauschen :-(
mist.


aber vielen Dank für die Tipps!

[daemotron]

ich glaube Inno DB

Da wäre mal interessant, wie Du innodb_data_file_path, innodb_log_file_size und innodb_log_buffer_size gesetzt hast. Wenn InnoDB ständig das Data File vergrößern muss, wäre das eine mögliche Ursache.

Edit: Zu lange nebenher rumgemurkst, sorry. Hoffentlich war's dann wirklich nur die Platte...

[manarak]

habe mich geirrt. DB engine ist MyISAM

Ausserdem gibt cat /proc/mdstat folgendes aus:

Code: Select all

Personalities : [raid1]
md4 : active raid1 sda2[0]      15357952 blocks [2/1] [U_]
md3 : active raid1 sda3[0]      15357952 blocks [2/1] [U_]
md1 : active raid1 sda5[0]      10241280 blocks [2/1] [U_]
md2 : active raid1 sda6[0]      5116416 blocks [2/1] [U_]
md5 : active raid1 sda8[0]      30924800 blocks [2/1] [U_]
md0 : active raid1 sda1[0]      104192 blocks [2/1] [U_]

und fdisk -l

Code: Select all

 
Disk /dev/sda: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   fd  Linux raid autodetect
/dev/sda2              14        1925    15358140   fd  Linux raid autodetect
/dev/sda3            1926        3837    15358140   fd  Linux raid autodetect
/dev/sda4            3838        9726    47303392+   f  W95 Ext'd (LBA)
/dev/sda5            3838        5112    10241406   fd  Linux raid autodetect
/dev/sda6            5113        5749     5116671   fd  Linux raid autodetect
/dev/sda7            5750        5876     1020096   83  Linux
/dev/sda8            5877        9726    30925093+  fd  Linux raid autodetect

Disk /dev/sdb: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          13      104391   fd  Linux raid autodetect
/dev/sdb2              14        1925    15358140   fd  Linux raid autodetect
/dev/sdb3            1926        3837    15358140   fd  Linux raid autodetect
/dev/sdb4            3838        9726    47303392+   f  W95 Ext'd (LBA)
/dev/sdb5            3838        5112    10241406   fd  Linux raid autodetect
/dev/sdb6            5113        5749     5116671   fd  Linux raid autodetect
/dev/sdb7            5750        5876     1020096   82  Linux swap
/dev/sdb8            5877        9726    30925093+  fd  Linux raid autodetect

ich habe Mal folgendes probiert:
mdadm --manage /dev/md5 -add /dev/sdb8

jetzt läuft ein mdadm resync


Ich habe aber trotzdem das ungute Gefühl dass die Performance Probleme vielleicht doch nicht auf die fehlerhafte Disk zurückzuführen sind?
Warum sollte eine defekte Disk den Server aufhalten, wenn diese bereits aus dem RAID Array rausgeflogen ist?
Warum ist die überhaupt rausgeflogen anstelle mit (F)ail gekennzeichnet zu werden??

Es gab auch noch sehr viele Einträge in var/log/messages

leider kann ich mich nicht genau an die Einträge erinnern, und jetzt läuft der resync und der server ist nicht über SSH ansprechbar.
Es hatte mit IP_connections und IP Tables zu tun, "Table Full" 250 frames dropped oder so etwas.

[manarak]

Redundanz ist jetzt wieder hergestellt.

Server läuft jetzt normal - aber es ist ja erst 6:50, Mal sehen, ob das so bleibt.

[manarak]

scheint alles in Butter:

Code: Select all

Personalities : [raid1]
md4 : active raid1 sdb2[1] sda2[0]
      15357952 blocks [2/2] [UU]

md3 : active raid1 sdb3[1] sda3[0]
      15357952 blocks [2/2] [UU]

md1 : active raid1 sdb5[1] sda5[0]
      10241280 blocks [2/2] [UU]

md2 : active raid1 sdb6[1] sda6[0]
      5116416 blocks [2/2] [UU]

md5 : active raid1 sdb8[1] sda8[0]
      30924800 blocks [2/2] [UU]

md0 : active raid1 sdb1[1] sda1[0]
      104192 blocks [2/2] [UU]

unused devices: <none>

Server Load is bei 0.5 und mir scheint, dass er viel schneller ist.

[manarak]

hier sind meine MySQL settings:

Code: Select all

[mysqld]
old_passwords=1
thread_concurrency=2
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
skip-locking
skip-innodb
query_cache_limit=1M
query_cache_size=32M
query_cache_type=1
max_connections=250
interactive_timeout=100
wait_timeout=15
connect_timeout=10
thread_cache_size=64
key_buffer=128M
table_cache=512
sort_buffer_size=1M
read_buffer_size=1M
read_rnd_buffer_size=768K
join_buffer=1M
max_allowed_packet=16M
record_buffer=1M
max_connect_errors=10
skip-show-database
myisam_sort_buffer_size=64M
#log-bin=/opt/mysql_log/
log_slow_queries=/opt/mysql_log/mysqld.slow.log
long_query_time=2

[manarak]

Server läuft immer noch rund.

Ich nehme an, das Problem ist gegessen