Re: Mailboxes with slow access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Ellie,

Thanks for answers, I'm gonna check how much memory the imap process is using like you suggest. Any other update about this issue I'll post here.

Regards


--

Miguel Moreira
Gerente
DPR/SRE/GSR - Gerência de Serviços de Rede
+55(31)3339-1401
PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais


Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição.

Em Domingo, Janeiro 20, 2019 23:33 -02, ellie timoney <ellie@xxxxxxxxxxxx> escreveu:
 
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

[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux