Hi,
But I guess I know now what's going on. Lock contention (many little calls to
malloc() and free() together with the M:N threading model of libpthread.so,
the default scheduler mode of libpthread.so (LIBPTHREAD_SYSTEM_SCOPE), so all
threads have to share the scheduled CPU slice for one pro
Hi,
Have you applied the libpthread fix for HT in relation to
pthread_cond_timedwait()?
http://lists.freebsd.org/pipermail/freebsd-threads/2006-February/003398.html
Yes, it's already part of FreeBSD 6.2
But I guess I know now what's going on. Lock contention (many little calls to
malloc()
On Sun, 2007-03-11 at 11:43 +0100, Martin Blapp wrote:
> All you need are multipart mails, so the do_multipart codepath is executed.
> The
> server we use has two cores, and HTT is activated, so 4 kernel threads can be
> executed the same time.
>
Have you applied the libpthread fix for HT in
Hi,
Remove the static qualifier from all functions in message.c, recompile
with '-g -O0', then wait till clamd hangs again. Get a backtrace of
each thread, and see more exactly in which function they are in, and
which file:line. Then let it run again, and take a snapshot of thread
state again.
On 3/11/07, Martin Blapp <[EMAIL PROTECTED]> wrote:
99 busy threads, and one idle, and all those busy threads are somewhere in
do_multipart, but they don't do any work. They starve and get killed after the
timeout, but the real scan doesn't happen. When the maximum of clamd threads is
Try this
Yes, my debug results show that it's messageToFileblob(), which is itself a
complex function. Maybe a race with temporary files ? Locking the codepath to
messageToFileblob fixes the problem too ... I'm still working on it ...
Ok. After hours if debugging I found that this part of the export c
Hi,
Perhaps it is something else that is not thread safe, that do_mulipart() is
calling?
Yes, my debug results show that it's messageToFileblob(), which is itself a
complex function. Maybe a race with temporary files ? Locking the codepath to
messageToFileblob fixes the problem too ... I'm
Hi,
Perhaps it is something else that is not thread safe, that do_mulipart() is
calling?
I suspect so ... Maybe its also some bad lock contention somewhere ? Anyway,
I'll try to narrow this down even more ... I hope to find the problem soon.
Naturally CPU usage will go down if you change a
Martin Blapp wrote:
Hi,
It looks like the codepath in do_multipart() is not threadsafe, as it
deadlocks threads entering it at the same time. This needs more
investigation
but for now this quick fix (the third one) will be enough. Since I use this
patch, CPU utilisation has go down and even a
