On Tue, 26 Aug 2008 17:10:46 +0300 (EEST) "Ilpo Järvinen" <ilpo.jarvinen@xxxxxxxxxxx> wrote: > There is more than one TCP flow in your workload btw (so using > "connection" is a bit more blurry from my/TCP's pov). Some stall and never > finish, some get immediately through without any stalling and proceed ok. > So far I've not seen any cases with mixed behavior. Interesting. > It could be userspace related thing. Hmmm. I'll try to report this to the dovecot and inn lists. > It seems that there could well be more than one problem, with symptoms > similar enough that they're hard to distinguish without a packet trace. Yes, exactly! I think the same. > Did it solve in this particular case? At least for 995 nothing Yes. nmap -sS always solves the problem. Very strange. nmap -sS for me is kind of brute force attempt to restablish the normal behaviour of the server... Anyway, I disabled htb and frto and everything is fine for now. I'll keep investigating this. > ListenOverflows might explain this (it can't be ListenDrops since it's > equal to ListenOverflows and both get incremented on overflow). Are you > perhaps short on workers at the userspace server? It would be nice to I use dovecot por mail. I'll post on the dovecot list. If it's an userspace issue, better. > capture those mibs often enough (eg., once per 1s with timestamps) during > the stall to see what actually gets incremented during the event because > there's currently so much haystack that finding the needle gets impossible > (ListenOverflows 47410) :-). Also, the corresponding tcpdump would be > needed to match the events. Ok. If I had more useful information, I'll reply. Thank you very much! -- -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
