After some more digging, I think the problem might be reproduced by following these steps:
1. Create a new database and table structure for dbmail. 2. create a test user - [email protected] 3. Alter table "dbmail_messages" to start message_idnr from a high number. ALTER TABLE dbmail_messages auto_increment = 99999999; 4. send 30 to 40 test messages to the [email protected] mailbox and then test imap. Now dbmail-imapd will cause 100% (or high) CPU and show a delay while running SEARCH and SORT commands. I hope this helps in further narrowing down the problem. I have a lots of users and emails in the production database and the message_idnr is very high, could this be causing a bottleneck in dbmail-imapd? ----- Original Message ---- From: N Sj <[email protected]> To: DBMail mailinglist <[email protected]> Sent: Tue, July 6, 2010 9:17:24 AM Subject: Re: [Dbmail] dbmail very slow performance on imap SEARCH and SORT commands I'm also seeing a somewhat similar problem, in addition to the delay I'm also seeing dbmail-imapd taking 100% CPU during that session. I'm attaching the log file for dbmail with TRACE_SYSLOG = 10 This logfile is only for "SEARCH ALL UNDELETED" IMAP command. My database is big, ~300GB, I've also tested this with creating a brand new db in mysql and I wasn't able to reproduce the problem, even though the mysql SELECT statement returns right away, (I'm not sure though) but it seems to be somehow related to database. Thank you for any help that anybody can provide. ----- Original Message ---- From: Erwin Lubbers <[email protected]> To: DBMail mailinglist <[email protected]> Sent: Thu, July 1, 2010 1:47:18 AM Subject: Re: [Dbmail] dbmail very slow performance on imap SEARCH and SORT commands Hi Paul, A bit delay in my answer. But I did make a trace with the level set to 5. I did copy-and-paste the following commands directly after the strace command, so there is no delay seen while imapd was waiting for my commands to enter: .... LOGIN "***user***" "***password***" .... SELECT "INBOX" .... SEARCH ALL UNDELETED .... SORT (DATE) US-ASCII ALL UNDELETED .... LOGOUT The trace is attached. Regards, Erwin Op 8 jun 2010, om 22:55 heeft Paul J Stevens het volgende geschreven: > >> There is a gap of around 3 seconds directly after I entered the . >> SEARCH ALL UNDELETED command. > > which would be explained by you taking 3 seconds to enter that command. > >> And there is a very large (almost 14 >> seconds) gap after reading the results from MySQL of the SELECT that >> is done for the SEARCH command. > > that one is tricky. Could you try again with trace_syslog=5, that would > give better indication where in the dbmail code the bottleneck is > occuring, or if it's in libmysqlclient. > > -- > ________________________________________________________________ > Paul Stevens paul at nfg.nl > NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 > The Netherlands________________________________http://www.nfg.nl > _______________________________________________ > DBmail mailing list > [email protected] > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
