Paul J Stevens wrote:
Michael Monnerie wrote:
I make an imapsync to my mailserver, which connects to the PostgreSQL
db, and I get these numbers:
mailsrv -> db 15.482.309
db -> mailsrv 648.119.851
client -> mailsrv 1.771.458
mailsrv -> client 15.956.176
So with ~18MB IMAP traffic I produce ~663MB database traffic? Can
somebody explain me this?
Interesting figures. Can you produce a base-line? Like say: traffic
numbers for syncing a single account, containing a single folder with a
single message of a known size, blah blah. Log the query patterns
triggered, and the traffic numbers involved. Out of curiosity. Perhaps
the explanation will jump out if the logs.
One hypothesis a priori: we don't cache as much as we could. In fact,
dbmail caches *very* little and will at times happily call the same
query a thousand times. And it doesn't even use prepared statements (yet).
I also had a hard time migrating 20GB of mbox email to dbmail, it actually
took about 12 days, 3 imapsync runs with wrappers alerting me when things get
ugly (granted I had the emails evenly distributed between accounts, so I could
arrange a staged migration).
The figures you are talking about can be easily derived using my torture
script which I wrote to track down the 2.2 memory leaks some months ago. You
guys even included it in the test-scripts section. On a quick glance it will
need the following modifications:
* in init_db() function, so that all resulting emails will be identical (now
the subject is an incrementing number)
* in torture() imapsync is supplied a skipheader that may no longer be relevant
* at the end of the script the torture runs twice with and without
G_SLICE=always-malloc which is irrelevant
* instead of t_memcheck() the dbmail-imapd daemon should be started by
t_normal()
Cheers!
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
