[imp] Crazy memory usage when viewing attachments

Kevin Konowalec webadmin at ualberta.ca
Sun Nov 26 21:31:21 PST 2006


Horde: 3.1.2
Imp: H3 (4.1.2)
Turba: H3 (2.1.1)

We were running into pretty consistent runaway httpd children when  
users would download large (> 30 MB) attachments.  Memory usage would  
balloon to at least 4 times the size of the attachment and the  
process would monopolize the CPU for literally several minutes.   
(This was after removing or sufficiently increasing various Horde,  
PHP, and system-level limits as the httpd childs would segfault  
previously.)

After tracing through way too much PHP, two lines looked suspicious:


--- horde/lib/Horde/MIME/Part.php.bak Wed Jul  5 10:30:47 2006
+++ horde/lib/Horde/MIME/Part.php     Tue Nov 21 03:26:12 2006
@@ -1152 +1152 @@
-            $message = preg_replace("/=\r?\n/", '', $this->_contents);
+//            $message = preg_replace("/=\r?\n/", '', $this- 
 >_contents);

--- horde/imp/lib/MIME/Contents.php.bak       Thu May  4 21:30:21 2006
+++ horde/imp/lib/MIME/Contents.php   Tue Nov 21 03:26:26 2006
@@ -173 +173 @@
-            $this->_bodypart[$id] = str_replace("\r\n", "\n", $this- 
 >_bodypart[$id]);
+//            $this->_bodypart[$id] = str_replace("\r\n", "\n",  
$this->_bodypart[$id]);



These calls were being made for any and all attachments regardless of  
encoding or MIME type.  Completely commenting out both lines  
immediately solved the runaway processes.  A 100 MB JPEG attachment  
took under 10 seconds of processing before download began compared to  
over 10 minutes before (but it still used just over 400 MB of memory).

Where N is the size of the attachment, I'm gonna take a stab in the  
dark and assume the 4N memory requirement is most likely attributed  
to each byte in the attachment being represented as a 32-bit value.   
As for the CR+LF regexps, I admit I haven't gone through the RFC, but  
I'm guessing this isn't explicitly necessary for the majority of non- 
text attachments especially when they're a base64 blob.  So far,  
plain text, JPEG, TIFF, and random binary blobs have downloaded  
without incident.

So can anyone suggest a reason why we shouldn't be doing this?  Or  
can we go ahead and comment these lines out in our production servers?



On Nov 23, 2006, at 1:09 PM, Michael M Slusarz wrote:

> Quoting patrick <gibblertron at gmail.com>:
>
>> I'm noticing that IMP requires an incredible amount of RAM to display
>> a message with a relatively large attachment. For example, on of our
>> customers was complaining that she couldn't open a message that was
>> was 1.4MB in size. Our memory limit was set to 50MB, and Apache was
>> running out of memory when viewing this message. Increasing it to  
>> 64MB
>> seemed to solve it, but I'm trying to comprehend what in IMP is
>> causing it to required more than 35 times the size of the message in
>> order to view it?
>
> Any code suggestions on reducing memory usage would be much  
> appreciated.  But remember the following:
> 1.) PHP is a high-level language, and was not designed for  
> programmers to easily manage memory usage.  mallocs, etc. are  
> handled by the interpreter and is transparent to a PHP script.  So  
> complaining about memory usage, without providing us pointers on  
> how we (as PHP coders) can reduce memory usage, is not tremendously  
> helpful.
> 2.) You don't think that, for example, a windows program uses a  
> similar amount of memory to view a message?  Try running  
> thunderbird and looking at memory usage when viewing a 1.5 mb message.
>
> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
> -- 
> IMP mailing list - Join the hunt: http://horde.org/bounties/#imp
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: imp-unsubscribe at lists.horde.org
>



More information about the imp mailing list