[Greylist-users] Getting greylisting going on a new Debian
sean at conman.org
Mon Jun 30 22:25:28 PDT 2008
It was thus said that the Great Jose-Marcio Martins da Cruz once stated:
> Sean Conner wrote:
> >It was thus said that the Great Jose-Marcio Martins da Cruz once stated:
> >>Sean Conner wrote:
> >>Hmmm. Threads under linux ... They eat memory. Other OSs (Solaris,
> >>FreeBSD) do it better.
> > Tracking that down took quite a bit of investigation and it involved a
> >trip through the source code for pthreads under Linux.
> Not really... 8-)
> In a Linux box, look for clone(2) - all you need to know is there :
> man clone
Ah, if only. Normally, the stack space for a process (not a thread) is
allocated dynamically as the system runs---fill up a page in the stack, a
segfault, the system then knows to allocate another page or two to the
stack. The fact that I have a 10M limit on the stack doesn't mean it
actually *takes* 10M of space.
Unfortunately, the pthread initialization code (which is run *before*
main() is called) checks setrlimit() for the maximum stack size. Then, each
time a thread is created, it allocates said amount, which wouldn't be all
that bad (since Linux uses overcommit---it basically creates enough entries
in the page tables for the memory without actually allocating the memory)
except that pthreads then *clears* the freshly allocated memory. That
unfortunately, touches the memory, causing the system to *physically*
allocate the memory.
> > Well, I basically ended up doing a "ulimit -s"  and that seems to have
> >sovled for the most part the memory issues (did have to keep tweaking the
> >value between "uses too much" and "too little it crashes").
> man ulimit
> ulimit [-SHacdefilmnpqrstuvx [limit]]
> Provides control over the resources available to the shell
> to processes started by it, on systems that allow such
> The -H and -S options specify that the hard or soft limit is
> -s The maximum stack size
> I understant : "the maximum stack size per process." Am I right ???
> > -spc (Wishes we could use Postfix at The Office though ... )
> Sorry but, IMHO, the problem here isn't sendmail, but linux threads.
The problem *is* sendmail, or at least, the milter library, which is a
part of sendmail, using pthreads when (personally) I don't see the actual
need for it (for instance, the Postfix interface doesn't require threading).
-spc (And if the protocol used between sendmail and milter were
documented, I would scrap the use of milter entirely, but alas,
the protocol isn't documented, and *that* fact *is* documented)
More information about the Greylist-users