------art_102656_9447386.1179147323737
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.

------art_102656_9447386.1179147323737--