ha ha ha. > 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?
sat download. lan up/download. lan 256k symmetric sat only <T1 on the down. no up > > 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?). > we have up to 139 stimultaneous dialup + 1 to 2 wireless connect at night since no traffic is seen on the others. > 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. > latency is arpund 200-700ms for both lan & sat > 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/ > ===================================================================== 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/
