Re: File-descriptors - large quantities
Dancer (dancer@brisnet.org.au)
Wed, 08 Jul 1998 15:08:36 +1000
Chris Wedgwood wrote:
>
> On Wed, Jul 08, 1998 at 02:51:08PM +1000, Dancer wrote:
>
> > My predecessor hopped on the linux 2.1.xx bandwagon (2.1.89-96 IIRC),
> > which caused us enormous loss-of-face, as the production servers, hung,
> > rebooted, or crashed in front of everyone. I don't think we can afford
> > to chance _that_ again.
>
> 'nuf said.
>
> > > All this assume, select(2) will suck for 12k FDs, which I've not tested.
> >
> > Well, it doesn't suck badly enough to hurt for 3K. So, assuming we get
> > four times the suckiness for 6K, we might still be cool.
>
> Hmm... is it possible to profile the kernel one of the running squids for a
> day or so and see how long it spends in select?
>
> If your not CPU bound, then it might be OK.
>
> > Aside from basic suck, you can't think of any related problems?
>
> Provided the kernel stack doesn't get trashed and libc is tweaked
> appropriately, then I guess it should work.
>
> As far as sucky performance goes, I'll see if I can get something with 12k
> FDs timing select(2) vs poll(2) later tonight.
That would be much appreciated. My development resources are limited. I
assume your comment re- libc is related to recompiling it with new
values for the size of fd-sets?
D
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@
------END GEEK CODE BLOCK------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu