That depends on your client load and uplink bandwidth. You have a satellite uplink, right? What speed is it? And there is a secondary land line, or is the land link just for outbound requests?
Beware that if your client load is too high for your bandwidth, you might find that a lot of very low throughput, long lasting connections could cause the problems you're seeing--and no amount of threads will solve this problem. Squid with delay pools for bandwidth limiting might be your best bet in that case (can Oops do per-client bandwidth limiting?). If I'm remembering correctly, you don't have a large enough link to make a 350MHz box sweat on either Squid or Oops with any configuration. And 900+ simultaneous connections seems a little high (not incredibly high--I have clients that are running up to 2000-3000 simultaneous connects on Squid, but that is for 15-20Mbits of bandwidth and a few thousand dialup clients). Satellites do have high latency, which leads to longer lasting connects, so if the bandwidth is then insufficient, it might lead to runaway requests as more and more requests get opened and they take longer and longer to complete. So, if you can give us an idea of what your number of clients is and what bandwidth they have to share...If this is the problem, then Squid will handle it pretty effectively (Squid has a number of options to prevent overloads of this sort--where it isn't a machine overload, but a link overload). Anyway, just a guess. Edward Millington wrote: > 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 -- 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/
