hi, so yesterday I move the whole mail system to a better machine. the only thing which is running on this system is dovect and:
10:44am up 6 days, 25 min, 3 users, load average: 28.03, 17.96, 9.05 233 processes: 231 sleeping, 2 running, 0 zombie, 0 stopped CPU0 states: 3.1% user, 29.4% system, 0.0% nice, 66.4% idle CPU1 states: 7.1% user, 63.2% system, 0.0% nice, 29.1% idle CPU2 states: 1.3% user, 3.1% system, 0.0% nice, 94.4% idle CPU3 states: 1.1% user, 7.4% system, 0.0% nice, 90.3% idle Mem: 1030496K av, 1021836K used, 8660K free, 0K shrd, 104064K buff Swap: 2040244K av, 55544K used, 1984700K free 776180K cached
so the problem here is again with the load 28 (!!!).....
in the imap.log:
imap(arvays): May 28 10:39:32 Error: Timeout while waiting for release of fcntl() lock for index file /home/arvays/Maildir/.INBOX/.imap.index
imap(lfarkas): May 28 10:42:05 Panic: unreached dovecot: May 28 10:42:07 Error: child 19933 (imap) killed with signal 6
imap(ahegedus): May 28 11:05:57 Panic: file maildir-sync.c: line 472 (maildir_sync_uidlist): assertion failed: (ACTION(hash_rec) == MAILDIR_FILE_ACTION_NEW) dovecot: May 28 11:05:58 Error: child 29103 (imap) killed with signal 6
-- Levente "Si vis pacem para bellum!"
On Wed, 2003-05-28 at 12:15, Farkas Levente wrote:
so the problem here is again with the load 28 (!!!).....
Did you try with default_mail_env = maildir:~/Maildir:INDEX=MEMORY? Does that effect the load at all?
imap(arvays): May 28 10:39:32 Error: Timeout while waiting for release of fcntl() lock for index file /home/arvays/Maildir/.INBOX/.imap.index
CVS was somewhat broken in 2003-05-23 14:40 .. 2003-05-26 13:07. If you're running such version that would explain this error.
imap(lfarkas): May 28 10:42:05 Panic: unreached
Hmm. Related to below I think.
imap(ahegedus): May 28 11:05:57 Panic: file maildir-sync.c: line 472 (maildir_sync_uidlist): assertion failed: (ACTION(hash_rec) == MAILDIR_FILE_ACTION_NEW)
Still hmm. But it could be related to the bug I found which was mostly just crashing or causing some other errors with me. Try if cvs update fixes.
Timo Sirainen wrote:
On Wed, 2003-05-28 at 12:15, Farkas Levente wrote:
so the problem here is again with the load 28 (!!!).....
Did you try with default_mail_env = maildir:~/Maildir:INDEX=MEMORY? Does that effect the load at all?
yes I try. first it drop the load but today I can't do anything, since the load was above 20 in both case.
imap(arvays): May 28 10:39:32 Error: Timeout while waiting for release of fcntl() lock for index file /home/arvays/Maildir/.INBOX/.imap.index
CVS was somewhat broken in 2003-05-23 14:40 .. 2003-05-26 13:07. If you're running such version that would explain this error.
the current is ok?
imap(lfarkas): May 28 10:42:05 Panic: unreached
Hmm. Related to below I think.
imap(ahegedus): May 28 11:05:57 Panic: file maildir-sync.c: line 472 (maildir_sync_uidlist): assertion failed: (ACTION(hash_rec) == MAILDIR_FILE_ACTION_NEW)
Still hmm. But it could be related to the bug I found which was mostly just crashing or causing some other errors with me. Try if cvs update fixes.
the current is ok?
-- Levente "Si vis pacem para bellum!"
On Wed, 2003-05-28 at 14:32, Farkas Levente wrote:
Did you try with default_mail_env = maildir:~/Maildir:INDEX=MEMORY? Does that effect the load at all?
yes I try. first it drop the load but today I can't do anything, since the load was above 20 in both case.
Did it drop the load much? Because it shouldn't, except because of these bugs that required rebuilding indexes. I'd like to know what causes these loads, but I can't really even guess without at least knowing what area is doing that (index building, clients downloading too many mails, ..?). Maybe I should write some kind of statistics gathering code which could be used to find that out..
CVS was somewhat broken in 2003-05-23 14:40 .. 2003-05-26 13:07. If you're running such version that would explain this error.
the current is ok?
Yes.
Timo Sirainen wrote:
On Wed, 2003-05-28 at 14:32, Farkas Levente wrote:
Did you try with default_mail_env = maildir:~/Maildir:INDEX=MEMORY? Does that effect the load at all?
yes I try. first it drop the load but today I can't do anything, since the load was above 20 in both case.
Did it drop the load much? Because it shouldn't, except because of these bugs that required rebuilding indexes. I'd like to know what causes these loads, but I can't really even guess without at least knowing what area is doing that (index building, clients downloading too many mails, ..?). Maybe I should write some kind of statistics gathering code which could be used to find that out..
do anything you like, but I can't told you more than there is almost nothing on this server just dovecot. if you give me any kind of tool I'll try it. actualy there is a named, dhcp, etc... but the load before dovecot was about 0.05 maximum 0.2!
-- Levente "Si vis pacem para bellum!"
Farkas Levente wrote:
Timo Sirainen wrote:
On Wed, 2003-05-28 at 14:32, Farkas Levente wrote:
Did you try with default_mail_env = maildir:~/Maildir:INDEX=MEMORY? Does that effect the load at all?
yes I try. first it drop the load but today I can't do anything, since the load was above 20 in both case.
Did it drop the load much? Because it shouldn't, except because of these bugs that required rebuilding indexes. I'd like to know what causes these loads, but I can't really even guess without at least knowing what area is doing that (index building, clients downloading too many mails, ..?). Maybe I should write some kind of statistics gathering code which could be used to find that out..
do anything you like, but I can't told you more than there is almost nothing on this server just dovecot. if you give me any kind of tool I'll try it. actualy there is a named, dhcp, etc... but the load before dovecot was about 0.05 maximum 0.2!
I switch my own mailbox from dovecot to courier (on the same server both are running now) and it a LOT faster! the simplist test to delete a mail and mozilla just jump to the next one. it took about 5-10 sec with dovecot!!! while it almost nothing (less than 1 sec) with courier.....
-- Levente "Si vis pacem para bellum!"
On Wed, May 28, 2003 at 01:57:46PM +0200, Farkas Levente wrote:
I switch my own mailbox from dovecot to courier (on the same server both are running now) and it a LOT faster! the simplist test to delete a mail and mozilla just jump to the next one. it took about 5-10 sec with dovecot!!! while it almost nothing (less than 1 sec) with courier.....
So Courier works fine even while the load is high? strace's output could show what Dovecot is doing wrong then. ie. just before expunge:
strace -p your_dovecot_imap_pid > /tmp/dove.log 2>&1
And stop it after expunge has completed.
I'm anyway guessing that it has something to do with the new syncing code.. What filesystem do you use?
Timo Sirainen wrote:
On Wed, May 28, 2003 at 01:57:46PM +0200, Farkas Levente wrote:
I switch my own mailbox from dovecot to courier (on the same server both are running now) and it a LOT faster! the simplist test to delete a mail and mozilla just jump to the next one. it took about 5-10 sec with dovecot!!! while it almost nothing (less than 1 sec) with courier.....
So Courier works fine even while the load is high? strace's output could
no we used to stop dovecot and killall imap what for the low load and restart dovecot manually. after we do it for an hour the load goes back to "just" 2-3 and in this case yes courier is much faster that dovecot.
show what Dovecot is doing wrong then. ie. just before expunge:
strace -p your_dovecot_imap_pid > /tmp/dove.log 2>&1
which imap process? since even if I set the maximum imap connection in mozilla to 1 logout and login again the mozilla (or dovecot) change it back to at least 2:-( anyway I try all of them, both as root and as the user itself, the only result is: trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
And stop it after expunge has completed.
any other logging mode?
I'm anyway guessing that it has something to do with the new syncing code.. What filesystem do you use?
ext3
-- Levente "Si vis pacem para bellum!"
participants (2)
-
Farkas Levente
-
Timo Sirainen