dovecot imap out of memory

[tikidollracer]

new alarm user here. i'm migrating a server from debian/ppc to alarm on a pi. i've mostly got things working on a single account, but i'm getting the error message below from dovecot in mail.log. i don't see this discussed in the forum. i googled around, and no-one suggested a real fix. i did play w/ vsz_limit from 64M to 2048M to no effect. the default is 256M. this tells me i'm probably seeing a software issue, as my pi doesn't have 2048M of memory. strangely, dovecot/imap does seem to be working, at least to some extent. i do have large mailboxes (~100k messages), but i can't find a pattern to accessing them and seeing the errors. i've tried turning off/on dovecot lmtp/sieve, etc. to no avail. any hints are appreciated,

Feb 2 14:32:25 localhost dovecot: imap(smurman): Fatal: pool_system_realloc(1811939328): Out of memory
Feb 2 14:32:25 localhost dovecot: imap(smurman): Fatal: master: service(imap): child 1580 returned error 83 (Out of memory (service imap { vsz_limit=256 MB }, you may need to increase it) - set CORE_OUTOFMEM=1 environment to get core dump)

thanks,

-SM-

[moonman]

are you running headless? did you play with /boot/config.txt? by default 128 mb of ram is assigned to cpu. It should by dynamic but i found it didn't work very well for me.

[tikidollracer]

headless - yes. boot/config - no. i'm also running out of memory w/ spam assassin sa-update, which is also haven't found a workaround for.

update - according to top i'm only using 1/4 of my available memory. it's possible that the dynamic memory split isn't working. or maybe i need to do something to enable it? mixed reports of forcing gpu memory to low values.

[pepedog]

dovecot, spamassassin, I run these, you need a spinning hard drive and swap.
Even then dovecot needs a restart now and then when you are targeted

[tikidollracer]

pepedog - lots of people run these tools as small servers on small hardware, including myself. spinning disks fail.

update - one of the issues i was having is that i restored the dovecot cache files from my previous box which had more ram. still don't seem to be able to use all the available ram on the pi, but maybe setting gpu_mem will work. just need to get some backups sorted to try it.

[moonman]

The way I do it usually, I do use XBMC on it so I have 128 dedicated. Headless should work with 32MB (I think... don't remember what was the minimum). I had the same problem - couldn't use all the ram no matter what and programs were running out of memory.

$this->bbcode_second_pass_code('', 'gpu_mem_512=128
gpu_mem_256=128
#cma_lwm=16
#cma_hwm=32
#cma_offline_start=16')

[tikidollracer]

thanks for the suggestions. i run xbmc on my other pi, but this is the 1st headless pi i've built other than for play. i think it's 16G gpu for the 256 pi (mine), and 32G for the 512 pi. the other issue i've noticed is the lack of a hardware clock. i installed fake-hwclock, but that doesn't fix everything (anything?).

i kinda got caught. i had some unexpected issues w/ the ppc box i was running, and decided it had reached end-of-life. i had an extra pi so i used it to get back up and running. if it's not going to work i can always look at buying an A10 chip or similar.

-SM-

[moonman]

fake-hwclock restores the time at boot to what it was last time you shutdown your pi. you need to enable fake-hwclock service for it to work. Rpi is definitely not a speed demon.

[tikidollracer]

the pi is fast enough for what i need, but i can't get the memory sorted. i tried a couple gpu_mem256/512 settings but can't get it to boot up. do the other arm SoC have these same types of gpu issues?

[tikidollracer]

update - i was able to get my model A pi to boot using gpu_mem256=48 and this has solved my issues for now. below is my typical coarse memory state from top. before i could not get it to go below 150k free. basically i started at gnu_mem=16 and went up by 16 until one booted. don't ask me why 48M worked. there are similar random reports around the interwebs, but for now i'll take it. hopefully it won't be too firmware sensitive.

KiB Mem: 214128 total, 135876 used, 78252 free, 13268 buffers

-SM-