On Tue, Jan 19, 2016 at 10:12:12AM +1000, Piers Rowan wrote: > - dovecot > - apache (roundcube webmail) > - sendmail
unless you're a sendmail expert with a decade or two of experience working with it, you might want to think about switching to postfix. > - clamav-milter > - amavisd-milter > > RAM: 4.10 GB > CPU: QEMU Virtual CPU version (cpu64-rhel6), 5 cores CPU allocation of 5 cores is probably overkill for mail, unless you're processing a LOT of incoming mail with clamav and spamassassin. how many users do you have, and how much mail are you receiving and processing (msgs/day and megabytes/day)? btw, I used to run mail servers at ISPs for thousands of users on 1990s and 2000s hardware, which was nowhere near as fast (slower disks, slower CPU, *much* less RAM) as what you can get today for a fraction of the price. if your mail VM can't even handle a few dozen or few hundred users, there's something seriously wrong....probably disk I/O contention from other services running on the same machine and disk. > The server is a VM on a host server that also provides http / mysql > services. mail is VERY dependent on disk I/O - especially if you have multiple users reading their mail via POP/IMAP (or via webmail such as roundcube, which connects via imap). and it only gets worse if you have other processes fighting dovecot for disk access. If at all possible, you should consider having a dedicated mail server, or at least dedicated drive(s) for mail, that doesn't have to share disk I/O with anything else - and certainly not with other I/O heavy services like a web server or mysql. If your server is located in-house (i.e. not in a co-lo facility), you may also want to consider adding a fast SSD (or two in RAID-1 configuration for safety AND roughly double the read performance) just for the mail spool (and make sure dovecot etc are configured NOT to move mail to user home directories, but to leave them on the SSD). You can get Samsung 850 Pro 128GB for $116. $188 for 256GB. if your total mail size is < 128GB and unlikely to grow that large in the forseeable future, you're better off with a pair of 128GB drives in RAID-1 than a single 256GB drive. if it's a VM at a co-lo facility, talk to them about getting a host with at least one SSD so you can move your mail spool to that. the random-access nature of SSDs (i.e. they don't have to waste time moving the disk head around to access data) mitigates many of the speed problems caused by having multiple users read large mailboxes at the same time. spinning hard disks will get around 100 IOPS at best. a good SSD will get anywhere up to 100,000 IOPS depending on how it's being used (but you can expect a minimum of 10,000) > The host server runs cron jobs to poll the email server (importing > data from mail boxes into the CRM) so - to clutch at straws - so you're regularly importing mail into a database of some sort? that may be the source of your problem - dovecot will be contending with mysql for disk I/O unless the mysql db and the mail spool are on different disks (ideally, two separate SSDs. or two separate RAID-1 devices on SSD) how big is the database? if it's huge, can you archive older stuff to another server, or do you need instant access to the old data? btw it's worthwhile doing some research on database tuning. here's a useful Q&A on tuning mysql for SSDs http://dba.stackexchange.com/questions/59828/ssd-vs-hdd-for-databases > I am not sure if the host and guest are competing for the disk IO at > the same time with these calls. Contrary to that is that the host > server does not experience any slow downs. they almost certainly are, from what you've said about what the server is doing. as russell suggested, run iostat - and run it on the host, not on the VM. > Before the holidays we added another 30 users to the servers. 30 users is not a lot, and is unlikely to have made much difference unless they're extraordinarily heavy users of mail, several orders of magnitudemuch more so than all your previous users. i could see adding a few thousand or even a few hundred extra users making a significant performance impact, but not just a few dozen. craig -- craig sanders <[email protected]> _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
