Re: [Dovecot] imap memory footprint rather large

2008-05-12 Thread Timo Sirainen
On Mon, 2008-05-12 at 18:19 +0100, martin f krafft wrote: > also sprach Timo Sirainen <[EMAIL PROTECTED]> [2008.05.12.1813 +0100]: > > v1.1 drops fields that aren't accessed after 30 days. > > And that interval is hardcoded or configurable? Hardcoded in src/lib-index/mail-cache-private.h: /* Dro

Re: [Dovecot] imap memory footprint rather large

2008-05-12 Thread martin f krafft
also sprach Timo Sirainen <[EMAIL PROTECTED]> [2008.05.12.1813 +0100]: > v1.1 drops fields that aren't accessed after 30 days. And that interval is hardcoded or configurable? Also, do you have an ETA on the 1.1 release? As you may know, we're freezing Debian stable in August or September and it w

Re: [Dovecot] imap memory footprint rather large

2008-05-12 Thread Timo Sirainen
On Mon, 2008-05-12 at 18:00 +0100, martin f krafft wrote: > also sprach Timo Sirainen <[EMAIL PROTECTED]> [2007.08.13.2324 +0100]: > > > Is there a way to vacuum/reduce/optimise the cache? > > > > You can always delete it, but if your client wants the same > > information all over again it gets gr

Re: [Dovecot] imap memory footprint rather large

2008-05-12 Thread martin f krafft
also sprach Timo Sirainen <[EMAIL PROTECTED]> [2007.08.13.2324 +0100]: > > Is there a way to vacuum/reduce/optimise the cache? > > You can always delete it, but if your client wants the same > information all over again it gets grown to the same size. > Probably it doesn't after the initial mailbo

Re: [Dovecot] imap memory footprint rather large

2007-08-20 Thread Curtis Maloney
Leroy van Logchem wrote: I found the file to be ever growing, so when it had grown back to 160Mb in a single day, I decided to employ cron on the mail server: 11 4 * * * find $HOME/.maildir -type f -name dovecot.index.cache -exec rm {} \; Since my mail is fetched in the background anyway,

Re: [Dovecot] imap memory footprint rather large

2007-08-17 Thread Leroy van Logchem
I found the file to be ever growing, so when it had grown back to 160Mb in a single day, I decided to employ cron on the mail server: 11 4 * * * find $HOME/.maildir -type f -name dovecot.index.cache -exec rm {} \; Since my mail is fetched in the background anyway, I am happy to take the per

Re: [Dovecot] imap memory footprint rather large

2007-08-15 Thread martin f krafft
also sprach martin f krafft <[EMAIL PROTECTED]> [2007.08.14.1552 +0200]: > > So I guess most of the data in your dovecot.index.cache file > > came from some initial FETCH ENVELOPE/BODYSTRUCTURE/etc. for all > > messages. If you delete it, it won't probably get as large > > anymore. > > This is tru

Re: [Dovecot] imap memory footprint rather large

2007-08-14 Thread martin f krafft
also sprach Timo Sirainen <[EMAIL PROTECTED]> [2007.08.14.1358 +0200]: > So I guess most of the data in your dovecot.index.cache file came from > some initial FETCH ENVELOPE/BODYSTRUCTURE/etc. for all messages. If you > delete it, it won't probably get as large anymore. This is true, I deleted it

Re: [Dovecot] imap memory footprint rather large

2007-08-14 Thread Timo Sirainen
[back to list] On Tue, 2007-08-14 at 14:50 +0300, Timo Sirainen wrote: > On Tue, 2007-08-14 at 13:47 +0200, martin f krafft wrote: > > also sprach Timo Sirainen <[EMAIL PROTECTED]> [2007.08.14.1250 +0200]: > > > mmap()ing a 200MB file doesn't mean that it immediately uses 200MB > > > of memory. It

Re: [Dovecot] imap memory footprint rather large

2007-08-14 Thread Timo Sirainen
On Tue, 2007-08-14 at 08:13 +0200, martin f krafft wrote: > also sprach Timo Sirainen <[EMAIL PROTECTED]> [2007.08.14.0028 +0200]: > > What exactly do you mean by FETCHing metadata? Something like ENVELOPE > > or BODYSTRUCTURE? And this is fetched for all messages instead of just > > new ones? That

Re: [Dovecot] imap memory footprint rather large

2007-08-13 Thread martin f krafft
also sprach Timo Sirainen <[EMAIL PROTECTED]> [2007.08.14.0028 +0200]: > What exactly do you mean by FETCHing metadata? Something like ENVELOPE > or BODYSTRUCTURE? And this is fetched for all messages instead of just > new ones? That could easily explain why cache is so large. The code is: resp

Re: [Dovecot] imap memory footprint rather large

2007-08-13 Thread Timo Sirainen
On Mon, 2007-08-13 at 22:59 +0200, martin f krafft wrote: > The way offlineimap reads may is by FETCHing metadata, then > APPENDing new local mail, SEARCHing for the UIDs of each uploaded > mail, and finally FETCHing new remote mail. What exactly do you mean by FETCHing metadata? Something like E

Re: [Dovecot] imap memory footprint rather large

2007-08-13 Thread Timo Sirainen
On Mon, 2007-08-13 at 23:24 +0200, martin f krafft wrote: > also sprach martin f krafft <[EMAIL PROTECTED]> [2007.08.13.2259 +0200]: > > Memory use seems to be O(n) in the size of the folder. On the folder > > with 70k messages, dovecot seems to allocate 280m of memory, which > > I just saw in the

Re: [Dovecot] imap memory footprint rather large

2007-08-13 Thread martin f krafft
also sprach martin f krafft <[EMAIL PROTECTED]> [2007.08.13.2259 +0200]: > Memory use seems to be O(n) in the size of the folder. On the folder > with 70k messages, dovecot seems to allocate 280m of memory, which I just saw in the logs: mmap() failed with index cache file /home/madduck/.maild

[Dovecot] imap memory footprint rather large

2007-08-13 Thread martin f krafft
Dear list, I am experimenting with a new mail handling setup and it involves a single IMAP folder with just under 70'000 messages. When OfflineIMAP connects to the server, the imap process starts to eat up a lot of memory: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1