Memory usage too high cause

/usr/bin/perl /usr/libexec/webmin/virtual-server/

service started from cron around midnight everyday is eating almost all RAM …
1010.13 MB total / 148.70 MB free

Is there a way to fix this problem ?

That’s really surprising, as that program isn’t doing anything all that complicated. Anybody else seeing large usage from I’m having trouble imagining what would trigger it to eat a bunch of RAM.

Ooh, I know! I bet you’re delivering your spam to an mbox format file, right? Those get huge, with a lot of messages…and while I’m pretty sure the mailbox functions aren’t reading the whole file into RAM, Maildir format would be more efficient. So, switching to delivering your spam to a Maildir style box is probably the quickest solution to the problem.

I am not sure what is the difference between Mailbox format or Maildir format …
Should I look into Mail preferences ?

As I can see in configuration of mail preferences I have set "Destination for Spam email" to:
Write to standard spam Maildir ~/Maildir/.spam/

Hmmm…OK, so that’s not the issue. I’m kinda stumped.

Are you sure you’re not just seeing buffer/cache usage grow? Linux is very aggressive with disk access caching, and so will fill up RAM pretty much to the top when a lot of disk usage is happening–it’s still available for allocation, so it doesn’t slow things down or make things swap out, but it makes memory usage look really high. Since you’ve specifically mentioned, I’m kind of assuming you’re looking at a process list or top and seeing a huge process, which wouldn’t be buffer/cache usage. I dunno.

Could you post the results of this command when you’re seeing this behavior:

ps auxc | grep

I launched command but nothing showed up so I manually launched and then
ps auxc | grep
root 1544 26.8 54.7 804772 509604 pts/0 D+ 10:48 1:27

  1. I use "System Information" panel
  2. I look into processes running
  3. Anyway I have cleared most of spam manually in some mail account
    And I have set autodelete spam from maildir if spam older then 4 days
  4. Now cpu and memory usage went down from about 12 hours running processes (!) to about 2 hours (starting from midnight)
  5. Last thing is that apache, mysql and bind services went down several times in one of that period of heavy memory usage, so I had to start em manually