I have been experimenting for a while when I was bumping into my 16M
memory_limit when just sending a 2M attachment.
First I bumped up my memory_limit to 64M to avoid any Errors.
I logged the current memory usage using memory_get_usage at several
checkpoints. Here is a snippet from my logs that shows the
escalating memory usage during the sending process.
Oct 21 14:38:46 /home/f/fungus/public_html/mail/index.php[74]:
E_USER_NOTICE: Memory used: 1729640
Oct 21 14:38:46 /home/f/fungus/public_html/mail/program/steps/mail/
sendmail.inc[2]: E_USER_NOTICE: Memory used: 2593576
Oct 21 14:38:47 /home/f/fungus/public_html/mail/program/steps/mail/
sendmail.inc[231]: E_USER_NOTICE: Memory used: 7514208
Oct 21 14:38:47 /home/f/fungus/public_html/mail/program/include/
rcube_imap.inc[622]: E_USER_NOTICE: Memory used: 10155336
Oct 21 14:38:47 /home/f/fungus/public_html/mail/program/lib/imap.inc
[1886]: E_USER_NOTICE: Memory used: 12796272
Oct 21 14:38:47 /home/f/fungus/public_html/mail/program/lib/imap.inc
[1898]: E_USER_NOTICE: Memory used: 18078104
Oct 21 14:38:48 /home/f/fungus/public_html/mail/program/lib/imap.inc
[1907]: E_USER_NOTICE: Memory used: 18078136
After some searching through the code, and analyzing this same
process with different sized attachments, I have come to a conclusion
that memory usage must be improved.
Currently the memory_limit must be set at 3M plus six times the
maximum message size. 3M for the base application and enough room to
hold the message 6 times. Eek!
Example: for a 2M maximum message size the memory_limit must be 15M. 15M = 3M + 6*2M
Almost 2 whole copies of this message remain in memory in the
"program/steps/mail/sendmail.inc" file. Another copy is stored in
memory for the argument as sent to $IMAP->save_message() in "program/
include/rcube_imap.inc". Another copy for the argument passed to
iil_C_Append() in "program/lib/imap.inc". And 2 more copies are
generated inside that same function.
Solutions:
- destroy the MAIL_MIME object properly in the "program/steps/mail/
sendmail.inc" after it is done with.
2. rework the API to reduce function calls that require the message
body.
3. store the message only once globally, and have all functions read
it instead of passing the message around.
3. consider fixing the Iloha library to manage memory more
efficiently, or using another library.
--lonnie