On Mon, 09 Nov 2015 10:54:48 +0100 Andrea Brancatelli <abrancate...@schema31.it> wrote:
> > > 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. I don't think that's a smart thing to do. See https://www.percona.com/blog/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/ We have about 2MB/min going into innodb logs and already have 2*256MB innodb log files, which should be plenty. What kind of append performance are you seeing on your setup? What is your crash recovery time with such large log files? Anyway IO is not the bottleneck, as our db server is capable more than 4GB/s (nvme is amazing). It must be something else... -- Jure Pečar https://jure.pecar.org http://f5j.eu _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
