Jon Duggan wrote: > I have a few queries regarding the migration. I'll not paste them all at > once but rather one at a time. > > The main issue I have at the moment is IMAP is very very slow. In some > cases it's timing out. Our webmail server (using overlook (modified > squirrelmail)) is taking a good few minutes to render. We have two webmail > servers, one is running a local imapd and the other is currently pointing to > an imapd on another box, both have the same issue. Our mysql server doesn't > have an higher load than normal and i've tried (dare i say it) shutting of > postfix frontend so its stops processing mail and this isn't making any > difference. > > I've set TRACE_LEVEL to 5 but cant really see anything specific. These > machines are all on bonded gigabit Ethernet and i've tested network > throughput to rule out any connectivity/switching problems and this is fine. > > > These are the errors im currently getting; > > Jun 6 10:53:06 mail4-core-1 dbmail/imap4d[16923]: Error:[server] > pool.c,set_lock(+66): Error setting lock. Trying again.
These are relatively innocent. They just indicate the pool code couldn't get an immediate lock on the shared memory segment. Your logs indicate it succeeds after a couple of attempts every time. > I don't believe i saw these errors in 2.0.10, but perhaps they were there :) > Are these normal? Yes, they are normal and their trace priority should be downgraded. Only when a process can't get a lock after several attempts, an error should be logged. > > Can someone tell me what i should be doing to debug this? It is considerably > slower than 2.0.10 on the same hardware It shouldn't be. Of course, running on trace level 5 will make things /very/ slow, but I assume you only do that because you have a problem. First thing to do is find out where the bottleneck occurs. Is it cpu bound, memory bound, disk io, network io? What is the load on one of these slow imap servers. Try running vmstat on them. Since you've been doing level 5 tracing, try to provide a sample of the kind of IMAP commands you're using. I don't know how deep the modifications to the SM codebase have gone, but SM is definitely a well tested client for dbmail. If overlook uses different commands, that might be an issue.... > > (ive had a few complaints of imap being slow in outlook/$OTHER_CLIENTS also, > but i cant guarantee these are of the same issue, although it looks likely) I'm beginning to suspect you're missing something in the database. Are you doing slow_query logging? Study the dbmail logs to find queries that are taking long to complete. Perhaps you need some additional indexes. Also, you mention other problems regarding the migration. Perhaps they are related. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
