Problem s pomalym SENDMAILem

[Dan Lukes]

Břetislav Kubesa napsal/wrote, On 04/22/04 23:31:
>> >>>mam takovy (alespon pro me) zahadny problem se sendmailem. Z nejakeho
>> >>>neznameho duvodu trva posilani emailu z klienta neumerne dlouho -

>> Jine MUA s timtez sendmailem tyto problemy maji nebo nemaji ?

> Outlooky jsou ruznych ruznych Win (98,98SE,XP), vykazuji vsak stejne
> problemy. Nainstaloval jsem ted Bat 2.10 pod WinXP a svete div se, odesilani
> v poradku.
> Takze na vine je Outlook, ale proc... ;o( Jen nechapu, co se tak rychle
> pokazilo, kdyz vse pred tydnem fungovalo.

> Udelal jsem tedy >
>  tcpdump -s1600 -w tcpdumpoutlook
>  tcpdump -s1600 -w tcpdumpbat 

	No, rozdil mezi dumpy je jasne viditelny (vybral jsem z nej vzdy 
nejcharakteristictejsi pasaz, v obou pripadech preskakuji uvodni 
hanshaking a soustreduji se na prenos velkych dat behem DATA faze, obe 
vybrane casti jsou pripojeny dole, aby se nam nepletly tady v textu).

	Nejdriv tedy Outlook (priloha A). Ten prenese vzdy 7200B dat a posledni 
paket teto "davky" opatri "PUSH" flagem. Ten znamena, ze TCP/IP stack 
prijemce ma tato a vsechna predchozi data predat vyssim vrstvam. Outlook 
ceka na potvrzeni tohoto posledniho paketu a dalsi data neposila. 
Sendmail (respektive TCP/IP stack stroje, na kterem sendmail bezi) na 
druhe strane preda 7200B vyssim vrstvam a teprve pak prijem potvrdi. 
Teprve pak zahaji Outlook posilani "dalsi rundy". Zpracovani dat na 
strane prijemce trva neco okolo 0,09s. Preneseni 7kB dat kazdych 0,09s - 
to zhruba odpovida vami pozorovane prenosove rychlosti.

	No a ted BAT. Ten ma sice "rundy" ctyrkilove (presneji 4143B) a mezi 
nimi take vysila PUSH flag, jenze, neceka s odesilanim dalsich dat na 
to, az prijde potvrzeni o zpracovani tech predchozich. Coz je take 
"normalni" chovani, jak by se TCP/IP stack mel chovat, kdyz aplikace nad 
nim proste odesila hromady a hromady dat.

	Vkladani PUSH flagu obvykle odpovida jednotlivym zapisovym "write()" 
operacim. Cekani na odesilani dat odpovida spis operaci "flush()", 
nicmene, TCP/IP stack je obvykle do znacne miry konfigurovatelny - 
podobneho chovani bychom docilili i jinak, napriklad tak, ze "low 
watermark" hodnotu nastavime stejne velkou jako velikost odesilaciho 
bufferu.

	Podle toho, ze BAT funguje, se zda, ze pozorovana vlastnost neni 
"defaultni" vlastnosti TCP/IP stacku ve tvych Windows - jde o projev 
specificky pro Outlook. Znamena to tedy, nejspis, ze si Outlook neco 
specialne nastavuje, pripadne, ze se (vzhledem k prenosu velkych dat) 
chova nejak neobvykle - jinymi slovy, je to vlastnost kodu (i kdyz 
nevylucuji zcela i moznost, ze toto chovani lze "zapnout" respektive 
"vypnout" nejakym nastavenim).

	Duvod, proc se chovani objevilo az ted je nejasny - jako perspektivni 
kandidat me napada napriklad instalace opravek (pokud vim, ctyri, z 
nichz jedna zrovna pro Outlook se objevila 13.4; nicmene, nemusi jit 
primo o opravku Outlooku - ten pro odesilani patrne odesila nejake k 
tomu urcene knihovny, a vymemeny mohly byt ty) - samozrejme 
predpokladam, ze peclivy spravce site instalace opravek nebezpecnych 
chyb nezanedbava.

	Kazdopadne se zda, ze chyba je zcela mimo dosah FreeBSD a obavam se, ze 
s Outlookem uz prilis poradit nedokazu. A ani by to do konference 
nepatrilo (i tenhle prispevek jsem poslal do konference spis proto, ze 
by se do podobne situace mohl dostat i leckdos dalsi, kdo by mohl 
stravit, zbytecne, spoustu casu hledanim problemu na nespravne strane).

	Nejspis se budete muset obratit spis na jinak zamerene konference 
a/nebo radce. Nebo na technickou podporu, ktera vam, pokud vim, k 
produktu nalezi. No a v nejhorsim pripade musite uzivatelum vysvetlit, 
ze email NENI urcen k prenaseni velkych objemu dat (nejvetsi jeste 
zarucena velikost je 64kB) - a ze nevhodne pouzivany produkt nefunguje 
dobre preci neni divne ... ;-)

					Dan
























-------- Priloha A, vybrana cast prenosu Outlook -> sendmail ------
22:11:01.387990 192.168.0.250.3194 > 192.168.0.1.smtp: P 7296:8288(992) 
ack 316 win 17109 <nop,nop,timestamp 587565 2721658>
22:11:01.485592 192.168.0.1.smtp > 192.168.0.250.3194: . ack 8288 win 
33120 <nop,nop,timestamp 2721670 587565> (DF)
22:11:01.487745 192.168.0.250.3194 > 192.168.0.1.smtp: . 8288:9728(1440) 
ack 316 win 17109 <nop,nop,timestamp 587566 2721670>
22:11:01.489147 192.168.0.250.3194 > 192.168.0.1.smtp: . 
9728:11168(1440) ack 316 win 17109 <nop,nop,timestamp 587566 2721670>
22:11:01.489349 192.168.0.1.smtp > 192.168.0.250.3194: . ack 11168 win 
32400 <nop,nop,timestamp 2721670 587566> (DF)
22:11:01.490194 192.168.0.250.3194 > 192.168.0.1.smtp: . 
11168:12608(1440) ack 316 win 17109 <nop,nop,timestamp 587566 2721670>
22:11:01.490513 192.168.0.1.smtp > 192.168.0.250.3194: . ack 12608 win 
33120 <nop,nop,timestamp 2721670 587566> (DF)
22:11:01.491507 192.168.0.250.3194 > 192.168.0.1.smtp: . 
12608:14048(1440) ack 316 win 17109 <nop,nop,timestamp 587566 2721670>
22:11:01.493011 192.168.0.250.3194 > 192.168.0.1.smtp: . 
14048:15488(1440) ack 316 win 17109 <nop,nop,timestamp 587566 2721670>
22:11:01.493190 192.168.0.1.smtp > 192.168.0.250.3194: . ack 15488 win 
32400 <nop,nop,timestamp 2721670 587566> (DF)
22:11:01.493730 192.168.0.250.3194 > 192.168.0.1.smtp: P 
15488:16480(992) ack 316 win 17109 <nop,nop,timestamp 587566 2721670>
22:11:01.585576 192.168.0.1.smtp > 192.168.0.250.3194: . ack 16480 win 
33120 <nop,nop,timestamp 2721680 587566> (DF)
22:11:01.587731 192.168.0.250.3194 > 192.168.0.1.smtp: . 
16480:17920(1440) ack 316 win 17109 <nop,nop,timestamp 587567 2721680>
22:11:01.588977 192.168.0.250.3194 > 192.168.0.1.smtp: . 
17920:19360(1440) ack 316 win 17109 <nop,nop,timestamp 587567 2721680>
22:11:01.589154 192.168.0.1.smtp > 192.168.0.250.3194: . ack 19360 win 
32400 <nop,nop,timestamp 2721680 587567> (DF)
22:11:01.590186 192.168.0.250.3194 > 192.168.0.1.smtp: . 
19360:20800(1440) ack 316 win 17109 <nop,nop,timestamp 587567 2721680>
22:11:01.590354 192.168.0.1.smtp > 192.168.0.250.3194: . ack 20800 win 
33120 <nop,nop,timestamp 2721680 587567> (DF)
22:11:01.591499 192.168.0.250.3194 > 192.168.0.1.smtp: . 
20800:22240(1440) ack 316 win 17109 <nop,nop,timestamp 587567 2721680>
22:11:01.592848 192.168.0.250.3194 > 192.168.0.1.smtp: . 
22240:23680(1440) ack 316 win 17109 <nop,nop,timestamp 587567 2721680>
22:11:01.593025 192.168.0.1.smtp > 192.168.0.250.3194: . ack 23680 win 
32400 <nop,nop,timestamp 2721680 587567> (DF)

-------- Priloha B, vybrana cast prenosu Bat -> sendmail ------
23:12:04.527420 192.168.0.250.3231 > 192.168.0.1.smtp: P 
11263:12527(1264) ack 425 win 17000 <nop,nop,timestamp 624195 3087969>
23:12:04.528669 192.168.0.250.3231 > 192.168.0.1.smtp: . 
12527:13967(1440) ack 425 win 17000 <nop,nop,timestamp 624195 3087969>
23:12:04.529936 192.168.0.250.3231 > 192.168.0.1.smtp: . 
13967:15407(1440) ack 425 win 17000 <nop,nop,timestamp 624195 3087969>
23:12:04.530953 192.168.0.250.3231 > 192.168.0.1.smtp: P 
15407:16671(1264) ack 425 win 17000 <nop,nop,timestamp 624195 3087969>
23:12:04.531018 192.168.0.1.smtp > 192.168.0.250.3231: . ack 11263 win 
33120 <nop,nop,timestamp 3087970 624195> (DF)
23:12:04.531122 192.168.0.1.smtp > 192.168.0.250.3231: . ack 13967 win 
32400 <nop,nop,timestamp 3087970 624195> (DF)
23:12:04.531207 192.168.0.1.smtp > 192.168.0.250.3231: . ack 15407 win 
33120 <nop,nop,timestamp 3087970 624195> (DF)
23:12:04.533165 192.168.0.250.3231 > 192.168.0.1.smtp: . 
16671:18111(1440) ack 425 win 17000 <nop,nop,timestamp 624196 3087970>
23:12:04.533329 192.168.0.1.smtp > 192.168.0.250.3231: . ack 18111 win 
32400 <nop,nop,timestamp 3087971 624195> (DF)
23:12:04.534382 192.168.0.250.3231 > 192.168.0.1.smtp: . 
18111:19551(1440) ack 425 win 17000 <nop,nop,timestamp 624196 3087970>
23:12:04.534584 192.168.0.1.smtp > 192.168.0.250.3231: . ack 19551 win 
33120 <nop,nop,timestamp 3087971 624196> (DF)




-- 
Dan Lukes     tel: +420 2 21914205, fax: +420 2 21914206
root of  FIONet, KolejNET,  webmaster  of www.freebsd.cz
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz