My blind shot is that it doesn't depend on dbmail itself, but to MySQL "filling up".
Things probably get slow when either: * your controler cache gets filled and the controller starts writing for real to disk * your InnoDB log buffer gets full and the DB has to start committing pending transactions to the real IDB files. There is not much you can to for the first thing, but for the second one you can tweak the innodb_log_file_size and innodb_log_files_in_group. The purpose of those files is being written sequentially thus avoiding the bottleneck of the disk having to seek the inodes and the free inodes as the table grows. I suggest you to "watch" those file while the DB is appending the messages and see how fast they get filled, a complete roundabout implies a flush to the real tables. Just to give you a vague idea, on our system we have 6 * 512MB files. --- Andrea Brancatelli Schema31 S.p.a. Responsabile IT ROMA - BO - FI - PA ITALY Tel: +39. 06.98.358.472 Cell: +39 331.2488468 Fax: +39. 055.71.880.466 Società del Gruppo SC31 ITALIA Il 2015-11-09 10:17 Jure Pečar ha scritto: > Hello, > > I'm doing some perfomance testing of our dbmail instance. I noticed that If I > copy large number of mails into single folder, append starts to get really > slow. For example, I have a spam collection of more than 50k sitting on a > cyrus imap comfortably in a single folder with append to it taking about > 0.03s. When I try to copy it to a folder on dbmail imapd, initial appends to > empty folder take less than a second, but this quickly grows to tens of > seconds and at around 7k mails copied each append takes around 100 seconds. > > Is this expected behaviour? There are no obvious slow queries in mysql slow > query log. > > Can anything be done to improve this?
_______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail