Re: Sieve script not working
On 1/20/19 12:13 AM, Nic Bernstein wrote: Andrea, It would help to know which version of Cyrus you're having difficulty with, and what setting you're using for 'unixhierarchysep'? Sorry, I obviously should have said it from the start: I'm using version 2.5.12 on FreeBSD 11.2/amd64. I'm not using 'unixhierarchysep', so the "default" separator shoud be a dot. I'm also not using "altnamespace". bye & Thanks av. 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
Re: Mailboxes with slow access
Hi Miguel, On Sat, Jan 19, 2019, at 8:20 AM, Miguel Mucio Santos Moreira wrote: > Hi folks! > > I've had a problem with some huge mailboxes, with a lot of folders and > subfolders. Problably thousand of folders.> The access on these mailboxes is > too slow, if you change from INBOX to > another folder called CYRUS, even if CYRUS folder has just 4 messages > for example the access is slow. This sounds like you don't have enough RAM to hold the metadata for these mailboxes in memory, and so the system is swapping while accessing them. You could find the imapd process that is servicing this connection and look at its virtual memory size, and compare that to the amount of physical RAM in your system, to see whether this is the case. Or, if you post up the size of these mailboxes' cyrus.header, cyrus.index, cyrus.annotations, cyrus.cache (...) files and the size of their [user].conversations file (if you have conversations enabled), then maybe someone will be able to suggest a RAM size that would support this. You mention being in a murder environment -- I'm not sure if you will need to increase the RAM on just the backend for these mailboxes, or the frontends as well. Maybe someone running a large murder can chime in with how they provision their servers? Sorry I don't have specific numbers for you, but hopefully this points you in the right direction! > I was trying to find out anything on internet about this issue and I > read that a parameter maxword on imapd.conf could be the solution.> Nowadays > in our cyrus-imap murder all backend servers and > frontend servers have the maxword parameter set to default value > which is 128kb.> Based on that information, I'd like to know if I increase > this > parameter to a high value like 1Mb for instance it could fix the issue > about slow access and which considerations about memory, disk and cpu > resources I must take care if I set up this value in my environment.> Another > question is, this value must be setting in all backends and > frontends servers? imapd.conf(5) says: > maxword: 131072 > Maximum size of a single word for the parser. Default > 128k This setting won't have any effect on performance at all. It's just an upper limit for the IMAP parser -- if some IMAP client tries to send a single word that is longer than this, the imapd process serving their connection will exit immediately with a "word too long" error rather than trying to keep parsing. Normal traffic won't hit this limit, it's just protecting itself from (possibly malicious) garbage. The default should be never need changing really. Hope this helps, ellie 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
Re: prblems rebuilding conversations db
Hi Michael, On Wed, Jan 16, 2019, at 10:12 PM, Michael Menge wrote: > Hi, > > because conversations db seems to be required for search indexes, I > enabled this option > on our production servers today and tried to rebuild the conversations > db for all users with > > ctl_conversationsdb -v -b UID > > For most users this did take less than a second. But for some users > this process would > not finish. I did kill one process after about 30 Minutes (most others > after 3 Minutes). > The UserID.conversations has grown over 2 GB (the mailbox itself has > only ~700 MB of mails, > and the conversations files from finnished rebuilds are less then 20 MB) So, a 2GB-and-growing conversations db for a 700MB mailbox is a ratio of ~3:1, which seems obscene... For comparison, the Conversations.append_reply_200 cassandane test (two messages with 100 replies each) produces an 87Kb conversations db for a 1016Kb mailbox (ratio ~1:12, n.b inverted!), which makes your ~3:1 and growing ratio seem even more obscene... Obviously you can't share the bad conversations db because conversations db's are full of personally-identifying information. But I wonder if looking through it with `cyr_dbtool ... show` turns up any unusual patterns, especially in comparison to one of the good users? I wonder if it's somehow repeating itself? Bron, does this sound like anything you've seen before, that maybe got fixed on master but not backported to 3.0? > Cyrus Logs show many "ctl_conversationsdb[933]: mailbox: longlock > user.UserID for 1.5 seconds" > every few seconds. This message is logged when the lock is released, if that lock had been held for >1s. It's reporting that it held the lock for longer than it would like to have, but at least you know the lock has been released. I think this is telling you that user-visible performance on the mailbox would have been impacted while this was occurring (because imapd/lmtpd wouldn't be able to access their mailbox while ctl_conversationsdb was holding those locks), but also tells you that ctl_conversationsdb was doing the right thing, and not just holding a single lock for the entire job. Though, that raises the question: was the user accessing the mailbox while the rebuild was in progress? I wonder if their client is doing something funny and tripping things up? Cheers, ellie > I did try reconstruct -r -G user/UserID, followed by > ctl_conversationsdb -v -z UID > and tried to rebuild the db again. Reconstruct reported no errors, and > the new rebuild > hat the same problem. > > Has anybody seen a similar problem? > > Any ideas how to fix this? > > > We are running cyrus-imapd 3.0.8 > > > Kind regards > > Michael Menge > > > M.MengeTel.: (49) 7071/29-70316 > Universität Tübingen Fax.: (49) 7071/29-5912 > Zentrum für Datenverarbeitung mail: > michael.me...@zdv.uni-tuebingen.de > Wächterstraße 76 > 72074 Tübingen 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
