could an Intel PII350 be the problem? Thank you very much.
Best regards, Edward Millington. BSc, Network+ Systems Administrator Cariaccess Communications Ltd. Palm Plaza Wildey St. Michael Barbados 1-246-430-7435 Fax : 1-246-431-0170 [EMAIL PROTECTED] www.cariaccess.com ----- Original Message ----- From: "Joe Cooper" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 08, 2002 9:50 AM Subject: Re: [OOPS] increasing the number of threads on linux > I don't think Oops uses either poll or select, actually, which is why I > said I don't know that file descriptor limits of this type will hit Oops > at all (as each thread might be viewed as a separate process and only > subject to the system-wide file-max, rather than a per-process > file-max). But then, maybe threads get the same process file descriptor > pool that the parent can choose from--my knowledge of threads is to > limited to know. > > I don't have an Oops source tree handy to check on it, but I can't think > of anything Oops would need to use poll for, since it uses a > thread-per-client model. Squid on the other hand uses a non-blocking > state machine model which uses poll/select for everything. > > Still the problem remains, with or without the semantic > arguments--Edward's box is blowing up when reaching 1000 threads. The > question is, why? > > Vladimir Ivaschenko wrote: > > Hi, > > > > You're right. This limit is related to sockets as it blocks (or > > used to block) the maximum number of sockets select() can handle. > > If OOPS uses poll(), there shouldn't be problems. > > > > But the limit still exists, at least still in the glibc. You > > either have to patch type.h manually, as shown in > > http://devel.squid-cache.org/hno/linux-lfd.html. > > > > Joe Cooper wrote about "Re: [OOPS] increasing the number of threads on linux": > > > > > >>Actually, modern glibc and the Linux kernel imposes no hard FD_SETSIZE > >>limits. They can be raised from the shell using ulimit. > >> > >>But you might be right about that being Edwards problem--Linux defaults > >>to 1024. Try adding a line like this to your Oops startup script: > >> > >>ulimit -HSn 8192 > >> > >>BTW-FD is file descriptors, not sockets--related but not the same thing. > >> Network sockets (user ports actually) are increased by modifying the > >>values in /proc/sys/net/ipv4/ip_local_port_range. I use the following > >>to set this on all of my Squid boxes: > >> > >>echo 1024 32768 > /proc/sys/net/ipv4/ip_local_port_range > >> > >>Actually, I'll just post the whole limits raising part of my Squid init > >>file--it might be useful: > >> > >># More file descriptors > >>ulimit -HSn 8192 > >>echo 8192 > /proc/sys/fs/file-max > >> > >># More user ports for squid to use > >>echo 1024 32768 > /proc/sys/net/ipv4/ip_local_port_range > >> > >>echo 3072 > /proc/sys/net/ipv4/tcp_max_syn_backlog > >> > >>Let us know what you find out, Edward. > >> > >>Actually, now that I'm thinking of it, Oops might look very different to > >>the OS than Squid. Because the file descriptor limit is a per-process > >>limit, it may not hit Oops at all--because each thread is a 'Light > >>Weight Process'...I don't know if a thread is limited by it's parent > >>file descriptor limits. > >> > >>Vladimir Ivaschenko wrote: > >> > >>>Probably it is a problem not with threads, but with sockets. You need to > >>>increase number of maximum sockets (__FD_SETSIZE) in glibc (types.h) and > >>>in kernel. > >>> > >>>Edward Millington wrote: > >>> > >>> > >>> > >>>>HI there! Does anyone knows how I can increase the number of thread > >>>>linux can handle for oops? I find that linux could handle up to 950+ > >>>>thread fairly well. At around 980 threads, oops stops working. Is > >>>>there a way to solve this? With this big problem, I am thing of going > >>>>back to squid. > >>>>Thank you very much. > >>>> > >>>>Best regards, > >>>> > >>>>Edward Millington. BSc, Network+ > >>>>Systems Administrator > >>>>Cariaccess Communications Ltd. > >>>>Palm Plaza > >>>>Wildey > >>>>St. Michael > >>>>Barbados > >>>>1-246-430-7435 > >>>>Fax : 1-246-431-0170 > >>>>[EMAIL PROTECTED] > >>>>www.cariaccess.com > >>>> > >>>> > >>>-- > >>>Best Regards > >>>Vladimir Ivaschenko > >>>Certified Linux Engineer (RHCE) > >>> > >>> > >>> > >>>===================================================================== > >>>If you would like to unsubscribe from this list send message to > >>>[EMAIL PROTECTED] with "unsubscribe oops-eng" in message body. > >>>Archive is accessible on http://lists.paco.net/oops-eng/ > >>> > >>> > >>> > >>> > >> > >> > >>-- > >>Joe Cooper <[EMAIL PROTECTED]> > >>http://www.swelltech.com > >>Web Caching Appliances and Support > >> > >>===================================================================== > >>If you would like to unsubscribe from this list send message to > >>[EMAIL PROTECTED] with "unsubscribe oops-eng" in message body. > >>Archive is accessible on http://lists.paco.net/oops-eng/ > >> > > > > > > -- > Joe Cooper <[EMAIL PROTECTED]> > http://www.swelltech.com > Web Caching Appliances and Support > > ===================================================================== > If you would like to unsubscribe from this list send message to > [EMAIL PROTECTED] with "unsubscribe oops-eng" in message body. > Archive is accessible on http://lists.paco.net/oops-eng/ > ===================================================================== If you would like to unsubscribe from this list send message to [EMAIL PROTECTED] with "unsubscribe oops-eng" in message body. Archive is accessible on http://lists.paco.net/oops-eng/
