RE: [ECOS] FreeBSD Netstack EPIPE error

["Lars Povlsen" <lpovlsen at vitesse dot com>]

Tony, Hans, Andrew:

I have been digging into this "characteristic" the last couple of
days...

(Using the ATHTTPD of Tony's - but I guess it's the same on the "stock"
server).

It will hit you rather hard if you are using chunked connections (which
inherently are not persistent).

So your page will update fairly quickly up to <16 times - and then
exhibit the behavior described here - wait ~1 minute - and everything
starts working again. In the meantime, pings works fine - but other
connections (telnet etc.) are not handled either.

I have bumped the socket/nfile's to alleviate the problem, but I still
consider it a major problem. Not very DOS resilient... Off course I can
just stay away from chunked connections and hope the client use
persistent connections...

Is there any way to have FreeBSD to recycle the sockets descriptors
earlier?

Anyhow - thank you for the pointer!

---Lars

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Anthony
Tonizzo
Sent: 11. oktober 2006 01:02
To: ecos-discuss@sourceware.org
Subject: Re: [ECOS] FreeBSD Netstack EPIPE error

Hans:

> I have seen similar behavior with our web server, but so far we have
> ignored the issue as we are using HTTP and could get away with
> occasional connection loss.

I am not sure if this is really apropos, but in the case of HTTP, make
sure that you are not exhausting the total available socket descriptors.

Jonathan from eCosCentric pointed out to me that when you close() a
descriptor the resources are not deallocated immediately by the
netstack.
If in the meantime you continue serving pages, you quickly exhaust
the pool of available sockets as you use them to serve requests.

In this case you would see a freezup for a minute or more, and then
the page you originally requested would be served. After some more
pages are served, the server would again freeze (on select(), if I
remember correctly.)

The solution is to increase CYGNUM_FILEIO_NFILE and
CYGNUM_FILEIO_NFD. Currently they are set to 16, and you might
try some value, say 64, that should clearly tell you if you are in the
right direction. Increasing CYGNUM_FILEIO_NFILE increases
CYGNUM_NET_MAXSOCKETS, which is _really_ what you want.

Cheers
Tony

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss