Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Anyone have any solutions (Sendmail CRON)
New on LowEndTalk? Please Register and read our Community Rules.

Anyone have any solutions (Sendmail CRON)

Ben1002Ben1002 Member
edited January 2013 in Help

Just a quick, any one have any ideas how to resolve this issue. One of our VPS nodes is getting high load at 20 past, 20 to and on the hour. We have traced the issue down to all the VPS's running the sendmail cron at the same time. Anyone have an ideas on how to prevent the sendmail cron causing high load on the hardware node. We are not having the issue on any node except this one which leads me to believe one of the sendmail processes are causing high disk usage. The load is definitely caused by disk and not CPU. However, I can not seem to track down which sendmail cron is casuing the issue. Any ideas?


  • jhjh Member
    edited January 2013

    ionice might be helpful to reduce the IO priority of the sendmail cron

  • Is port 25 blocked on this particular node?

  • How many emails is it sending out?

  • jarjar Provider
    edited January 2013

    Sure it's multiple VPS and not just a single one? Sometimes it can be hard to tell. I'll usually sit with two terminal windows open, one with top and one ready to enter the value to submit to vzpid. Shut down or reboot the offending container and see if it continues. Maybe check it a couple times to verify you're hitting the right container.

  • Doesn't appear to be sending any emails, I'll block port 25 on the switch just to make sure. Appears to be something with the default template. Most likely due to a client using an invalid FQDN.

  • try to check your raid make sure its ok (just in case) & monitoring the problematic container connection sometimes I found useful

  • Maybe a problematic container with a huge mail queue?

  • for i in /vz/private/*/var/spool/mqueue ; do time du -s -h $i ; done

    then see if the du of one of these directories takes a long time, compared to the others. If so, one of your users has a huge mail queue (probably of failed / deferred emails) which is walked when the cron runs and is causing the slowdown.

  • Get SSDs into that one :D

  • @rds100 No luck on that one,
    @shigawire Not as simple as just getting SSD's, its obvious there is an issue here.

  • are they all using Debian 32 bit template?

  • @graca Yep most of them are debian 32 bit.

    @George_Fusioned The drives are fine it's set to send emails on smart errors, and the rai d controller is reporting Optimal as is smart.

    @rds100 WIll do! Thanks for that!

  • @rds all of them are:
    real 0m0.001s
    user 0m0.000s
    sys 0m0.000s

  • @*ND -> couple times I'm experiencing this problem, I suggest you to check the Deb 32 bit template & your SolusVM,

    in my case the problem was, on Deb 32 bit, when I update the hostname from solus panel, it did updated correctly on the web, but somehow it did not applied on the container.

    so manual fix the container /etc/hostnames & /etc/hosts fix the MTA problem (just flush sendmail afterwards) but this only temporary when I restart the container the old hostname back again.

  • BitProcessorBitProcessor Member
    edited January 2013

    Or you could write a little script, looking if the cron entry is there, then changing hour & minute in random values (within possible limits of course), in order to spread the load over a whole day ?

  • I'm pretty sure it's something to do with the fqdn stuff since I've seen this before on a managed system, send mail hates that kind of stuff. Likely the containers are just regenerating the alias file. Only happens on this specific system though.

Sign In or Register to comment.