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
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
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
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
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,
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
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
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
[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
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
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
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
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
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
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
15 matches
Mail list logo