Some of those are extremely high, and probably cause negative impact 
rather than positive.  But they shouldn't cause a 1000 thread limit, 
that I can see.

I doubt RLIMIT_NOFILE is a problem.  8196 is plenty (probably a lot more 
than plenty).

I think I would lower some of those values to something a little more 
reasonable, just to make sure the kernel doesn't do something 
pathological when configured with such extreme limits.  I would go for a 
startup script something like this:

ulimit -HSn 8192
echo 8192 > /proc/sys/kernel/threads-max
echo 8192 > /proc/sys/fs/file-max
echo 1024 32768 > /proc/sys/net/ipv4/ip_local_port_range
echo 3072 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 1 > /proc/sys/net/ipv4/ip_forward

Leave out the other stuff, as it is probably counter productive or not 
useful in this situation (the other ulimits are already the defaults, 
why set them explicitly?).  Even the kernel threads-max value at 8192 is 
probably too high--you've only got 1000 right now, and probably only 
30-50 other processes on the machine.  You aren't going to hit the 
default 4079 limit, ever.

I don't know that this will fix your problems.  Linux may still have 
problems with a huge number of threads, or Oops may not be able to 
sustain the kind of traffic you're seeing--and it just reaches that 
limit at a certain client load.  Threads aren't exactly the ideal way to 
handle a large client population--and this may be the limit of the Linux 
threading implementation.  It would be a kernel bug if it is, but I just 
don't know how much the threads implementation gets pushed up over 1000 
threads in common usage.

Out of curiosity, what does CPU usage look like when you start seeing 
problems?  How about interrupts?  (To find this information, run 'vmstat 
1'--if you'd like to send me about 100 lines of the output from this via 
private mail next time you begin to hit this limit, I might be able to 
spot other problems that would lead to the trouble you're seeing.)

Edward Millington wrote:
> my socket was default under squid. 8192. Now set to 12288
> 
> Here is my default config. for over3 months.
> 
> ulimit -HSn 12288
> ulimit -HS -d unlimited
> ulimit -HS -s unlimited
> ulimit -HS -c unlimited
> ulimit -n 32768
> echo 100000 > /proc/sys/kernel/threads-max
> echo 32768 > /proc/sys/fs/file-max
> echo 4096 32768 > /proc/sys/net/ipv4/ip_local_port_range
> echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
> echo 1 > /proc/sys/net/ipv4/ip_forward
> 
> But looks what happens when it starts:
> 
> Fri Mar  8 09:10:10 2002  [0x400]report_limits(): RLIMIT_DATA: 4294967295
> Fri Mar  8 09:10:10 2002  [0x400]report_limits(): RLIMIT_NOFILE: 8196
> Fri Mar  8 09:10:10 2002  [0x400]report_limits(): RLIMIT_CORE: 4294967295
> Fri Mar  8 09:10:10 2002  [0x400]report_limits(): RLIMIT_NPROC: 4294967295
> 
> Could RLIMIT_NOFILE be the problem?
> 
> ----- Original Message ----- 
> From: "Vladimir Ivaschenko" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, March 08, 2002 8:41 AM
> Subject: Re: [OOPS] increasing the number of threads on linux
> 
> 
> 
>>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)
-- 
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/

Дати відповідь електронним листом