linux/apache traag, oorzaak niet duidelijk

[B-Man]

Beste mede-linux-gebruikers, ik loop tegen een luxe probleem aan. Ik draai een aantal niet al te zware sites al een jaar of twee op een wat oude(re) server, die geregeld van het ene op het andere moment heel erg traag wordt.
Het is een luxeprobleem, omdat ik net een mooie nieuwe PowerEdge 2950 met een stel 15k SAS schijven en 2 mooie quadcores in het rack heb gehangen, met een niet te schamele 8GB geheugen.
Die server lost de performance issues waar ik nu tegenaanloop op, no doubt about it.

Maar. Er is altijd een maar Ik draai al jaren op linux, heb van alles gedaan en keer aardig wat ins & outs, ik kan het performance probleem in dit geval echter niet duidelijk achterhalen.

Op dit moment is het beestje weer erg traag, wat zich uit in een paar seconden wachten op het openen van een (van de) site(s) die erop draaien. Ik zie de load nooit boven de 20% gaan, iostat meld een zeer lage schijfbelasting, ik zie ook geen hoge % cpu wait (nooit boven de 5%), en er wordt niet geswapt. Kortom: ik zie geen reden waarom het systeem traag zou zijn/is.

Wat specs (niet alles is up to date, dat is een andere discussie):
- P4 2.8 GHz
- 1024 MB geheugen
- 2.6.8.1 SMP kernel
- 80GB sata schijf (of nog gewoon pata, weet ik niet)

Het duurt op momenten zoals dit ook een seconde of 5 voordat ik een command prompt krijg (shell) als ik via ssh inlog. Dit doet me vermoeden dat de schijf het druk heeft (er wordt immers wat gelezen en geschreven naar de schijf bij inloggen), maar de schijf staat uit zijn neus te eten:

code:

root@/usr/src> iostat -x 5
Linux 2.6.8.1-040909 (p15172918)        02/01/08

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.99    0.00    0.83    0.08    0.00   94.10

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
hda               0.01     4.50    0.17    4.78    10.63    93.69    21.05     0.07   14.32   0.90   0.44

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.81    0.00    1.00    0.00    0.00   93.19

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
hda               0.00     2.00    0.00    6.41     0.00   100.20    15.62     0.01    1.72   0.19   0.12

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.19    0.00    0.80    0.00    0.00   97.01

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
hda               0.00    17.33    0.00    6.97     0.00   205.18    29.43     0.01    0.94   0.34   0.24

Op dit moment laat "top" dit zien:

code:

top - 00:49:32 up 71 days, 10:55,  3 users,  load average: 0.00, 0.01, 0.01
Tasks:  67 total,   2 running,  65 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.3% us,  1.0% sy,  0.0% ni, 95.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   1027936k total,  1012524k used,    15412k free,    23648k buffers
Swap:  2048276k total,     3736k used,  2044540k free,   677988k cached

Ook daar niets geks volgens mij.

Er treed ook geen packetloss op, en er zijn op dit moment (volgens netstat) erg weinig verbindingen actief (25?).
Toch is de server dus traaaag. Althans: ik merk het aan de webserver, en aan de snelheid waarmee de command prompt verschijnt als ik via ssh inlog.

Kan dit bijvoorbeeld een etterende schijf zijn? De performance degradation lijkt zich volledig random voor te doen. Er draaien geen intensieve cronjobs, dus ook dat is de oorzaak niet.
Wat kan ik nog doen om hier meer inzicht te krijgen over een mogelijk oorzaak?

Bij voorbaat dank, zou het interessant vinden om hier wat meer duidelijkheid over te hebben.

[Verwijderd]

Staat er nog iets opvallends in de log files van ssh of van apache? Heb je al in dmesg gekeken voor eventuele hardware fouten?

[B-Man]

Verwijderd schreef op vrijdag 01 februari 2008 @ 02:32:
Staat er nog iets opvallends in de log files van ssh of van apache? Heb je al in dmesg gekeken voor eventuele hardware fouten?

Nope, niets raars in de ssh en apache logs. dmesg meld geen rare dingen buiten een keer of 10

code:

TCP: Treason uncloaked! Peer a.b.c.d:12801/80 shrinks window 3048171167:3048173252. Repaired.

(a.b.c.d was uiteraard een IP adres, maar is hier niet relevant).

Die melding(en) verschenen overigens los van de traagheid. Ik heb al eens eerder met Google gezocht naar info over die melding, maar vond tegenstrijdige info. Bottom line was dat het -zeker gezien de geringen hoeveelheid meldingen- geen issue is.

[Verwijderd]

Je zou het loglevel van ssh kunnen veranderen, al is dat niet zo handig op een productieserver (logfiles groeien dan heel erg snel, en er komen mogelijk privacy gevoelige gegevens in te staan). Zo kan je wel vrij snel zien waar SSH zo lang mee bezig is.

[BoAC]

De trage inlog van je ssh zou kunnen komen doordat de resolving van de naam van je server niet helemaal lekker loopt. Zet eens de server van je in de hosts-file van de machine waarvandaan je inlogt.

[zomertje]

Weet je ook zeker dat de traagheid in de server zit en niet in een ander punt van het netwerk? (router, switch, kapotte kabel, enz)

[killercow]

Ik gok op een DNS resolving probleem,

Je machine duurt 5 seconde om in te loggen zeg je, dat komt omdat je machine je hostname probeert te resolven, wellicht dat dit ook voor je normale apache requests nog aan staat?
(logt apache met hostnames in de logfiles voor iedere request?)

[B-Man]

zomertje schreef op vrijdag 01 februari 2008 @ 08:47:
Weet je ook zeker dat de traagheid in de server zit en niet in een ander punt van het netwerk? (router, switch, kapotte kabel, enz)

Daar kan ik helaas weinig over zeggen. Deze server hangt tussen 1000en andere servers bij een van de grootste hosting-toko's in duitsland (1und1). Gewoon via internet bestellen en je krijgt root-toegang. Ik verwacht overigens niet dat het aan een router of switch bij 1und1 ligt, aangezien ze dat soort problemen altijd erg rap oplossen, en dit al een half jaar af en toe speelt. Een kabel met kuren zou kunnen, maar dan zou ik dat toch in de vorm van (bijvoorbeeld) packetloss moeten terugzien?

killercow: goed punt, had ik ook al eens aan gedacht. SSH doet vast een reverse lookup, en ook apache doet dit voor de logs. Een reverse lookup op mijn eigen IP duurt 1msec. Al merk ik wel dat "dig -x [ip]" minstens een seconde nodig heeft om de info op mijn scherm te toveren, veel trager als normaal dus.
Ik heb nog een tweede machine daar draaien, en heb even gekeken hoe snel die een "dig -x" afhandelt. Die reageert instantly. Ik heb de primaire DNS server daar even uit resolv.conf gehaald en op de "trage" server ingesteld, en nu zijn webserver & ssh weer supersnel.
Een trage DNS server lijkt het probleem dus te veroorzaken. De server meld in de response wel leuk "Query time 1 msec", maar doet er een stuk langer over