Sounds like you could consider partitioning (if you aren’t already) - then you can scale-out the disk iops without needing fancy hardware/software: https://www.cyrusimap.org/docs/cyrus-imapd/2.4.7/overview.php#partitions <https://www.cyrusimap.org/docs/cyrus-imapd/2.4.7/overview.php#partitions>
Hope this is useful! M -- Merlin Hartley IT Systems Engineer MRC Mitochondrial Biology Unit Cambridge, CB2 0XY United Kingdom > On 17 Jan 2017, at 16:43, Eugene M. Zheganin via Info-cyrus > <info-cyrus@lists.andrew.cmu.edu> wrote: > > Hi. > > On 17.01.2017 19:09, Andy Dorman via Info-cyrus wrote: >> >> I am not an expert by any means and I hope someone corrects me if I make a >> bad suggestion...but I have two questions: >> >> 1. It sounds like you have a heavily used server, so why do you have Cyrus >> listening on both "localhost:lmtp" AND a unix socket "/var/imap/socket/lmtp"? >> >> From the log entry it looks like your MTA uses a unix socket. Unless you >> have something else (mail clients or other MTAs running on your Cyrus >> server?) that need to communicate via the localhost:lmtp port, you could >> comment out the unneeded lmtp service line and save those resources. > Well, on one hand you are right, seems like noone uses network lmtp > connections, but on the other hand how can the idle processes save resources > ? They only can save the memory, which doesn't seem to be the problem. > However, I will try you advice. >> >> 2. You say "increasing this value can make the situation even worse". Which >> value? There are 5 values on those two lines that you could increase. And >> by "even worse" do you mean even more refused connections? > The maxchild number. >> >> While I am not a Cyrus guru, I have seen my share of overloaded mail servers >> and if you are running into a disk IO limit, adding more processes fighting >> over a limited resource is very likely to make things worse. So you should >> also confirm a hardware limitation is not at play here. > Yup, this is exaclty what happens when increasing the maxchild number: more > messages start to bounce. And yes, the disks iops seems to be the limiting > factor. So, are there any other approaches besides scaling out the disks iops > ? > > Thanks. > Eugene. > > > ---- > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
