Re: [suse-security] OT: VM killing sec relevant daemons
Dear Maarten, thanks for your reply. I definitely will put in more memory if the customer pays ;)
Instead of memtest, just running 'top' or 'free' would have told you what's wrong...
if top or free had told me this I wouldn't have asked
Spamd and amavisd will quite easily kill your machine seen as it has only 256 MB. Just one mass-mailing (inbound of outbound) will take care of that. Been there, done that, got the T-shirt...
It can't be easy as that, because the machine is up for almost half a year and only recently started to behave like this. On top of that, for three weeks in a row the customer sent tons of mails from this server (some promo or other) and nothing happened. Usually this server takes about 1000 mails inbound and about 500 to 1500 mails outbound in stride without so much as a whimp. All the time this happened for the last few days the load never reached 4.00 which I would've expected. And all the time more than 30% memwere unused... That's why I asked. Regards Wolfgang
Just a thought, check "ps auxwww" to see if there are any zombie processies holding mem. -jeff Wolfgang Leithner wrote:
Dear Maarten, thanks for your reply. I definitely will put in more memory if the customer pays ;)
Instead of memtest, just running 'top' or 'free' would have told you what's wrong...
if top or free had told me this I wouldn't have asked
Spamd and amavisd will quite easily kill your machine seen as it has only 256 MB. Just one mass-mailing (inbound of outbound) will take care of that. Been there, done that, got the T-shirt...
It can't be easy as that, because the machine is up for almost half a year and only recently started to behave like this.
On top of that, for three weeks in a row the customer sent tons of mails from this server (some promo or other) and nothing happened.
Usually this server takes about 1000 mails inbound and about 500 to 1500 mails outbound in stride without so much as a whimp.
All the time this happened for the last few days the load never reached 4.00 which I would've expected. And all the time more than 30% memwere unused...
That's why I asked.
Regards
Wolfgang
On Friday 30 July 2004 19:42, Wolfgang Leithner wrote:
Dear Maarten, thanks for your reply. I definitely will put in more memory if the customer pays ;)
Instead of memtest, just running 'top' or 'free' would have told you what's wrong...
if top or free had told me this I wouldn't have asked
Well, evidently. But are you sure you didn't overlook something like full use of swap ?
Spamd and amavisd will quite easily kill your machine seen as it has only 256 MB. Just one mass-mailing (inbound of outbound) will take care of that. Been there, done that, got the T-shirt...
It can't be easy as that, because the machine is up for almost half a year and only recently started to behave like this.
We have seen that same effect. It depends on the mail, too: a mass mailing with 5k ascii text didn't present a problem, whereas a similar email with a 5k attachment did. At one point I saw 'ps ax' report over 600 amavis(*) processes. The machine just grinded to a halt then. (*) Granted, at that point we weren't running amavisD as you are.
On top of that, for three weeks in a row the customer sent tons of mails from this server (some promo or other) and nothing happened.
Usually this server takes about 1000 mails inbound and about 500 to 1500 mails outbound in stride without so much as a whimp.
Look in the mail logfile just before the time the messages log showed the VM: bits and see what was sent. Maybe amavis keeps a logfile where it reports what was done, too. Another possibility is that you were DoS'ed. Maybe someone found a new way to DoS amavis or spamassassin, or maybe they used the old way, zipping up a huge file consisting of zeros and attaching that. Upon extracting that, amavis will allocate all of the machines' memory. Stuff like that...
All the time this happened for the last few days the load never reached 4.00 which I would've expected. And all the time more than 30% memwere unused...
Well. Sorry if it is another reason altogether. But the "VM: killing ..." message was just too familiar for me. It happens when all memory is exhausted AFAIK, and that just leaves little margin for error. And if your customer gives you static about this extra memory: Just have him compare the cost of you debugging this problem for an hour versus the cost of a brand new 512 MB stick. Most customers _are_ good business people. :-) I've been in the same boat. Maarten -- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER
Dear All, thanks for all the input :) Now I go to sleep (after 21 hrs of debugging) and dream of flying memory sticks. On Monday the delivery will fullfill my dreams and the server will be happy (hopefully) Yours Wolfgang
participants (3)
-
Jeff Blasius -
maarten van den Berg -
Wolfgang Leithner