A BUGNOTE has been added to this bug.
======================================================================
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000139
======================================================================
Reported By:                aaron
Assigned To:                
======================================================================
Project:                    DBMail
Bug ID:                     139
Category:                   IMAP daemon
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
======================================================================
Date Submitted:             12-Dec-04 00:27 CET
Last Modified:              12-Dec-04 00:30 CET
======================================================================
Summary:                    dbmail-imapd doesn't scale nicely with large 
message ranges
Description: 
Thomas Mueller wrote:

Sometimes my server uses for some minutes much more memory than it should
- and I guess it's dbmail.

I hope I'll find some time soon to use a profiler, but meanwhile I guess
the following happens: someone marks a mailbox for offline use and
dbmail-imapd does the following:
- fetch all mails from database
- keep the result set in memory
- deliver them
The third step can take a while so the process eats lots of memory for
quite some time - no bug, its a design problem.
This only happens for some minutes, that's why I'm quite sure it's no
memory hole.

The way to go would be to use a server side cursor so only one mail has to
be kept in memory - but AFAIK there's a storage system with SQL interface
(sorry couldn't resist) that doesn't support cursors.
======================================================================

----------------------------------------------------------------------
 aaron - 12-Dec-04 00:30 CET 
----------------------------------------------------------------------
Paul, you might know this code best, is there someplace in _ic_foo() that
goes through a result list from the database and builds some huge thing in
memory, and then begins to send it back to the client?

It might be as simple as placing some ic_write()'s in the middle of that
loop, rather than building up the whole structure at all.

Bug History
Date Modified  Username       Field                    Change              
======================================================================
12-Dec-04 00:27aaron          New Bug                                      
12-Dec-04 00:30aaron          Bugnote Added: 0000439                       
======================================================================

Reply via email to