I created a new 'zimbra' profile by renaming the old one. A week has
passed since this has been done and the slowness has not returned. All
mail is processed instantly.
The signature directory has over 500MB in over 43,000 files and this is
causing no issues. Looking at the old profile I see the following:
-rw-rw---- 1 zimbra zimbra 423221120 Feb 12 19:53 zimbra.css
-rw-rw---- 1 zimbra zimbra 80736604 Feb 12 19:53 zimbra.log
Note the very large zimbra.css file. and rather large zimbra.log file.
The current profile shows much smaller files:
-rw-rw---- 1 zimbra zimbra 65603240 Feb 20 07:35 zimbra.css
-rw-rw---- 1 zimbra zimbra 7642508 Feb 20 07:35 zimbra.log
Can this have some effect on the delays we had?
Thanks, Eric
Felix Schwarz wrote:
imho 100 MB for dspam is too much - should be lower but I don't know
hash_drv.
The server has only 1 GB of RAM. As dspam is running it starts with
very little memory and gradually grows up to 25% at the most.
...
> top - 19:29:06 up 20:05, 3 users, load average: 3.92, 2.29, 1.34
...
> Mem: 1032304k total, 1017456k used, 14848k free, 5324k
buffers
> Swap: 4096564k total, 635820k used, 3460744k free, 278584k cached
...
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 27 root 10 -5 0 0 0 S 1 0.0 3:46.68 kblockd/3
> 28959 zimbra 18 0 405m 108m 107m D 1 10.7 0:01.26 dspam
A load of 3.92 is not what I consider healthy in a uniprocessor
machine. You do use 620 MB of your swap. If DSPAM really needs 108 MB
of memory, this may cause some swapping when DSPAM starts up.
Can you look in your syslog if you find kblockd messages?
Currently, I don't have the time to map your strace output to DSPAM's
source code to see what's going on there but I suspect that you are
running out of memory.
fs
