From: Michal Suchanek <hramrach@...>
Date: 2007-05-14T23:13:34+09:00
Subject: Re: DRb connection error with more than 250+ DRb services

On 14/05/07, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> On 5/13/07, Michal Suchanek <hramrach@centrum.cz> wrote:
> >
> >
> > I wonder why such limits are imposed. It is probably some workaround
> > for a flaw in UNIX design that introduces possible DoS by exhausting
> > kernel memory/structures. Maybe it was fixed in some kernels (if
> > that's even possible) but nobody cared to fix the limit as well.
>
>
>
> Such limits have been around long before inhibiting DoS attacks became an
> important design goal. Every process has a "descriptor table" which defaults
> to a certain size but can sometimes be increased. However, the per-process
> descriptor table is nothing but an array of pointers to data structures
> maintained by the kernel. (That's why in Unix, a file descriptor is always a
> low-valued integer: it's just an offset into the pointer array.) What this
> means is that the system resources consumed by the file descriptor (which is
> owned by a process) must be considered in distinction to the *kernel*
> resources consumed by an actual open file or network connection, which are
> managed separately and obey very different constraints. It's normal in Unix
> for the same kernel object representing an open file to appear in the
> descriptor tables of several different processes. Just having the ability to
> represent 50,000 different file descriptors in a single process, however,
> doesn't automatically mean you have that much more I/O bandwidth available
> to your programs. Think about IBM mainframes, which are designed for
> extremely high I/O loads. You can have 500 or more actual open files on an
> IBM mainframe, all performing real live I/O. Intel-based servers can't come
> anywhere near that kind of capacity. If your per-process tables are large
> enough for thousands of open file descriptors, that says something about the
> size of your I/O data structures (which are constrained primarily by memory,
> a medium-inexpensive resource), but nothing at all about the real throughput
> you'll get.
>

Of course, the FDs are only to organize your IO. You can use TCP ans
the OS provided sockets, or you can use a single UDP socket and
maintain the connection state yourself.

Similarly the FDs to open files give you organized access to space on
a disk drive, and you can always open the partition device and manage
the storage yourself.

The throughput of the structured IO would be usually lower because the
OS does already some processing on the data to organize it neatly for
you.

Limiting the number of FDs per process does not do much to protect the
kernel memory. Maybe a single process cannot exhaust it but forking
more processes is easy. It is only a workaround for the poor design
after all.

Thanks

Michal