cyrus murder, mupdate sucking up CPU

Aleksandar Milivojevic alex at milivojevic.org
Fri Mar 3 14:53:39 EST 2006


I've asked about this problem earlier while trying out version 2.3.1.  
I've just compiled 2.3.3 (Simon's SRPM package) and still having the 
same problem.  This is the show stopper for me for upgrading from 2.2 
to 2.3.

The problem is mupdate process sucks all CPU cycles it can get.

Now for the weird stuff.

Running strace -p 3990 (3990 being PID of mupdate process) just shows 
it waiting in accept system call.

However, running strace -f -p 3990 showed this:

[pid  3995] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  3998] futex(0x8122134, FUTEX_WAKE, 1 <unfinished ...>
[pid  3995] <... clock_gettime resumed> {1141412737, 901972000}) = 0
[pid  3994] <... futex resumed> )       = 0
[pid  3998] <... futex resumed> )       = 1
[pid  3995] futex(0x8119fe0, FUTEX_WAKE, 1 <unfinished ...>
[pid  3994] futex(0x8122134, FUTEX_WAKE, 1 <unfinished ...>
[pid  3998] gettimeofday( <unfinished ...>
[pid  3995] <... futex resumed> )       = 0
[pid  3994] <... futex resumed> )       = 0
[pid  3998] <... gettimeofday resumed> {1141412737, 902155}, NULL) = 0
[pid  3995] futex(0x8119fe4, FUTEX_WAIT, -106641967, {59, 994760000} 
<unfinished ...>
[pid  3994] time( <unfinished ...>
[pid  3998] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  3995] <... futex resumed> )       = -1 EAGAIN (Resource 
temporarily unavailable)
[pid  3994] <... time resumed> NULL)    = 1141412737
[pid  3998] <... clock_gettime resumed> {1141412737, 902307000}) = 0
[pid  3995] futex(0x8119fe0, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid  3994] select(7, [6], NULL, NULL, {0, 0}finished ...>
[pid  3992] <... clock_gettime resumed> {1141412737, 903913000}) = 0

Now the strange thing, after I exit strace, mupdate starts to behave 
and goes to idling.  Attaching again to it with strace still shows the 
same output, but it is not consuming almost any CPU cycles.  However, 
it is still huge, around 170MB.

Even more strange is that if I restart it (stop Cyrus, start it again), 
the new mupdate process also seems to work OK!?  Reboot the system, and 
get the same problem again.

Could it be that I'm hitting a bug somewhere else in the system (like 
kernel)?  Is anybody else running Cyrus 2.3.x in murder configuration 
on CentOS4 or RHEL4 (update 2)?


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the Info-cyrus mailing list