tcp traag, maar niet altijd

[Sjonny]

Ik heb een raar probleem waar ik niet meer uitkom.
Het makkelijkst te herpoduceren is het uploaden van grote mails naar postfix.
Op port 25 red de server dan maar net 700-800 Kb/s over localhost. Maar als ik met scp een file van 100 Mb/s naar localhost kopieer, dan gaat dat wel met 50 Mb/s ...
Wanneer ik een tcpdump maak van de smtp upload, dan zie je een heel raar verschijnsel:

code:

13:59:02.092347 IP localhost.40118 > localhost.smtp: . 32769:49153(16384) ack 0 win 265 <nop,nop,timestamp 57371582 57371582>
13:59:02.134367 IP localhost.smtp > localhost.40118: . ack 49153 win 91 <nop,nop,timestamp 57371592 57371582>
13:59:02.262640 IP localhost.smtp > localhost.40118: . ack 49153 win 219 <nop,nop,timestamp 57371624 57371582>
13:59:02.262651 IP localhost.40118 > localhost.smtp: P 49153:65537(16384) ack 0 win 265 <nop,nop,timestamp 57371624 57371624>
13:59:02.302378 IP localhost.smtp > localhost.40118: . ack 65537 win 91 <nop,nop,timestamp 57371634 57371624>
13:59:02.408159 IP localhost.smtp > localhost.40118: . ack 65537 win 219 <nop,nop,timestamp 57371661 57371624>
13:59:02.408167 IP localhost.40118 > localhost.smtp: . 65537:81921(16384) ack 0 win 265 <nop,nop,timestamp 57371661 57371661>
13:59:02.450391 IP localhost.smtp > localhost.40118: . ack 81921 win 91 <nop,nop,timestamp 57371671 57371661>
13:59:02.553678 IP localhost.smtp > localhost.40118: . ack 81921 win 219 <nop,nop,timestamp 57371697 57371661>

iedere keer dus maar 16 Kb, dan na 40 ns pas een ack, dan na 1 ms (100 ns) weer een ack, waarna er direct het volgende block van 16kb.
Waarom zit ie op een ack te wachten? en waarom duurt ie zolang? en waarom werkt ie niet? (want er moet een 2e komen).

Ik heb /proc/sys/net/ipv4 met een andere server vergeleken, maar kan eigenlijk geen verschil ontdekken.

De server is Debian Etch, met alles standaard van debian. 2.6.8-4-686 smp kernel.
Iemand enig idee wat ik zou moeten checken?

[Verwijderd]

Wellicht je hardware (netwerkkaarten / kabel). Zo'n geintje heb ik ook gehad. Het vervangen van een (blijkbaar dus brakke) netwerkkaart heeft geholpen.

[Sjonny]

het is localhost .. gewoon lo, niet eth0.

edit:
het probleem is al opgeschoven.
schrijven in /var/spool/postfix/incoming/ is POEPtraag ..
echter .. ik heb maar 1 partitie, dus die directory staat nogsteeds op dezelfde harddisk die 50-60 mb/s kan ...

[ Voor 72% gewijzigd door Sjonny op 03-08-2007 15:40 ]

[Sendy]

Kijk eens in de logs. Misschien zitten er bad sectors of andere problemen in files in die directory?

[Sjonny]

\o/ opgelost!

een of andere fratser had met chattr het S bit op de directory aangezet (en andere postfix directories), waardoor er na iedere write een sync wordt aangeroepen.
Veilig, maar om daar nou zo'n bagger trage server van de krijgen

[deadinspace]

Sjonny schreef op vrijdag 03 augustus 2007 @ 16:07:
Veilig, maar om daar nou zo'n bagger trage server van de krijgen

Nouja, dat het traag is is niet zo verrassend. Als een write synchronous uitgevoerd wordt, dan keert de write() pas terug naar het aanroepende process als het OS er zeker van is dat de data op de harddisk is aangeland. 800 KB/sec en 16 KB writes betekend 50 writes per seconde, en dat lijkt me voor typische harddisk latency (~ 10ms) niet heel vreemd.

Het is trouwens ook knap overbodig; een mailserver hoort sowieso een ontvangen mail te syncen voordat hij bevestigt de mail ontvangen te hebben. Ontvangen mail wordt dus sowieso gesynct, alleen pas als de mail helemaal binnen is, niet bij iedere write.

[Sjonny]

dat postfix een sync zou aanroepen omdat de mail _compleet_ binnen is zou ik wel accepteren. (maar geen idee of ie dat echt doet?) echter gaat het hier nu dus steeds om 16k chunk van een mailtje. een incompleet mailtje in de queue vind ik erger als een mailtje wat helemaal niet in de queue komt omdat de server op een rot moment uit zou gaan. want dat is het excuus dat die optie in debian erin zit.
als je dus dpkg-reconfigure postfix doet, komt die sync vraag voorbij, met die reden als argument.
zou er bijna een bug report van maken