Dear list, Karlis and I experienced the "hangup" problem and discussed it last month on the bugs ML ( all the thread at http://marc.info/?l=openbsd-bugs&m=137321082217664&w=2 ).
Claudio had the kindness to point out that having no available clusters (i.e. a kern.maxclusters setting set too low for the machine's network load in a given moment) would bring a state matching our description of the "hangup" problem. Though, it would make sense that the problem (= TCP stack not accepting new incoming connections, and some more) would *self heal* as soon as clusters/mbufs had been freed up, and this was not Karlis' and my experience. So to bring order to this reasoning, I wish to pose the question: Is the TCP stack implemented in such a way that clusters running out [because of a too low kern.maxclusters setting for a particlar network load] may lead to permanent breakdown of its state and thus may require reboot, or should it always self-heal? And then: Now that we see that a too low kern.maxclusters setting for a particular server load may make the TCP stack fail temporarily - or permanently? - , we get to the question: What are the guidelines for choosing kern.maxclusters setting - how should number of incoming TCP connections per second, number of concurrent TCP connections, their throughput, and any other relevant parameters, impact the choice of kern.maxclusters ? Thanks and best regards, Mikael
