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
