Milter-greylist

On Thu, 2005-10-13 at 14:29 -0400, Matthew S. Cramer wrote:
> Kernel: 2.4.4 SMP (2 processors)
> GLIBC:  2.2.2
>              total       used       free     shared    buffers
> cached
> Mem:       5922468    4568268    1354200          0     600288
> 3237844
> -/+ buffers/cache:     730136    5192332
> Swap:      2097136    2097136          0
> 
> # cat /proc/sys/fs/file-max 
> 32768
> # cat /proc/sys/kernel/threads-max 
> 786432
> 
***snip***

> Our resident C expert thinks I am hitting some kind of max threads per
> user limit or max open files limit (I am running the milter under a
> non-privileged user).  So I wrote a little shell script that counts
> processes with 'ps -ef' and open files with 'lsof -i' and both never
> get above 400 and 300, respectively.  [Unfortunately my distro's
> version of ps does not support the -m flag for ps.]
> 
> Does anyone have any suggestions to resolv this, or has anyone
> experienced similar problems when using sync?
> 

As much as I can recall, the default stack size for a thread (in Linux
and elsewhere) is 2Mbytes. I am not sure what is libmilter setting here
- but if default - then 300 to 400 threads by themselves translate to
600 - 800 Mbytes of virtual memory. Then you also have your sendmail
processes running as well.

>From the kernel's standpoint, each thread is one process. If libmilter
is using the defaults, then each thread reserves 2M of virtual memory
space for its stack as well as your processes (sendmail & the rest).
This allocated space is just reserved; actual memory is allocated for
the stack on demand. But still, on a 32-bit processor, the total virtual
memory space available for the stacks is on the order of 1G, meaning
that more than 500 threads (and processes) will probably have a hard
time fitting in.

So despite of your ~6G of RAM - you may be hitting your (32-bit) system
limits here...

Just my 2c.

R.