Cyrus tweaks (slow on roundcube)

signaldeveloper at signaldeveloper at
Sun Sep 6 21:15:38 EDT 2015

Haha hey bron. Sorry, I'm a 24/7 workaholic. :)

I don't think it's IO. It's a VM on a HA cluster. The node its on is 64GB of RAM, I have 1 user and assigned everything to it for now. Everything else runs beautifully on it the identical nodes. I have similar setups (non kolab) that run off of dovecot and runs fantastic. Other file intensive apps also work well. 

Some of the cyrus.conf

configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus-admin
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
sasl_pwcheck_method: auxprop saslauthd
sasl_mech_list: PLAIN LOGIN
allowplaintext: no
tls_server_cert: /etc/pki/cyrus-imapd/cyrus-imapd.pem
tls_server_key: /etc/pki/cyrus-imapd/cyrus-imapd.pem
# uncomment this if you're operating in a DSCP environment (RFC-4594)
# qosmarking: af13
auth_mech: pts
pts_module: ldap
ldap_servers: ldap://localhost:389
ldap_sasl: 0

Hosts file is fine I checked that, thanks. Kolab uses 389 to authenticate for everything, so Cyrus is using LDAP as you can see above. I think the problem lies in the constant TLS logins into Cyrus for every click:

imap[2281]: login: localhost [::1] johndoe at PLAIN+TLS User logged in SESSIONID=<>
Sep  5 20:54:51 es1 imap[2281]: USAGE johndoe at user: 0.009998 sys: 0.006999

Again its only one user, on roundcube... I am afraid to put any more users on it. There doesn't seem to be much of performance tweaks with Cyrus around the web either...

> On Sep 6, 2015, at 7:57 PM, Bron Gondwana <brong at> wrote:
> On a Sunday night?  Not really.
> So Cyrus itself isn't this slow unless you have a horrible IO system under it or so little RAM that you can't fit the entire index into memory and it goes swapping.
> A possible issue would be failed DNS resolution on every connect, so you could check your hosts file to make sure localhost is mentioned (or change the default_host to to avoid the name lookup at all).
> I don't know WTF Kolab are doing with chattrsync.  Cyrus uses fdatasync correctly to avoid losing data already - if it doesn't that's a really serious bug, but I'm pretty sure I've audited everything.
> So basically - check your IO speeds, and check your DNS.  Anything more than that, I'd need to see the system or know more about how Kolab itself is set up.
> Bron.
>> On Mon, Sep 7, 2015, at 02:26, Paul Bronson wrote:
>> Anyone have any ideas on this?
>> On Sat, Sep 5, 2015 at 10:22 PM, Paul Bronson <signaldeveloper at> wrote:
>> Okay guys, I have put a lot of research into this so bear with me. 
>> Here's what I am up against. I have been working with RC (roundcube) for a long time and I know some awesome mySQL tweaks that work wonders, etc. My tweaks haven't done a single thing for the kolab install. This the first time I've worked with memcache. So here's my config before I proceed:
>>     // IMAP Server Settings
>>     $config['default_host'] = 'localhost';
>>     $config['default_port'] = 143;
>>     $config['imap_delimiter'] = '/';
>>     $config['imap_force_lsub'] = true;
>>     // Caching and storage settings
>>     $config['imap_cache'] = 'memcache';
>>     $config['imap_cache_ttl'] = '10d';
>>     $config['messages_cache'] = 'db';
>>     $config['message_cache_ttl'] = '10d';
>>     $config['session_storage'] = 'db';
>>     // SMTP Server Settings
>>     $config['smtp_server'] = 'tls://localhost';
>>     $config['smtp_port'] = 587;
>>     $config['smtp_user'] = '%u';
>>     $config['smtp_pass'] = '%p';
>>     $config['smtp_helo_host'] = $_SERVER["HTTP_HOST"];
>> I did notice that when I turn off tls on:
>> $config['smtp_server'] = 'tls://localhost';
>> that I can't log into RC, it seems to want to force me to use TLS, which I read somewhere else. Not sure if this is the culprit here.
>> CHATTRSYNC is off on cyrus already (by default I guess?)
>> I've installed imapproxy which seems to be working as far as the logs are concerned, but I STILL get about 3-4-5 second delay when opening through email. I have since uninstalled the imapproxy... Memcache is working properly according to the simply ps aux command or memcache-tool command but it still seems slow on RC, doesn't seem to have made a difference. I get these constant logs:
>> Sep  5 20:54:51 es1 imap[2281]: login: localhost [::1] johndoe at PLAIN+TLS User logged in SESSIONID=<>
>> Sep  5 20:54:51 es1 imap[2281]: USAGE johndoe at user: 0.009998 sys: 0.006999
>> It logs everytime the user makes a click or opens an email. Again, imapproxy didn't work much.. I tried disabling TLS, tried changing the cache methods.. Have been doing research pretty much all day trying to tweak this. Some have said comment out the kolab files plugin, that didn't make any difference at all. Cyrus just seems to take forever for some reason.. I am talking 4-5 seconds waiting before the email even shows on the screen.
>> memcache conf:
>> PORT="11211"
>> USER="memcached"
>> MAXCONN="1024"
>> CACHESIZE="1024"
>> OPTIONS="-l"
>> OPTIONS="-vv >> /var/log/memcached 2>&1"
>> I tried increasing cache size, didn't help (not that I thought it would either)... I am getting a little desperate here.
>> I changed php.ini to memory_limit = 4096M... Already kicked up my innodb performance settings tuned like my fast non-kolab servers.. I don't think its a mysql problem either.. The problem is with the 
>> Any ideas as to why this is so slow compared to my non-kolab RC install I have going right now (dovecot based)? 
>> By the way, this server has two active email accounts on it.. No load what so ever.
>> Kolab 3.4, centos 6
>> I am not sure what else to try to make cyrus faster!!! Can someone suggest something?
>> ----
>> Cyrus Home Page:
>> List Archives/Info:
>> To Unsubscribe:
> --
>   Bron Gondwana
>   brong at
> ----
> Cyrus Home Page:
> List Archives/Info:
> To Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Info-cyrus mailing list