Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 2 subscribers
  • Views 1558 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

7.202 ASG with 100% CPU caused by mailsec-reporter

tkaufi
Hi,

i´m running a 220 ASG in Clustermode with SMTP Proxy, Encryption and other services. FW ist 7.202

Since a few days we have the issue that mailsec-reporter.pl script causes 100% CPU for a couple of hours. And that nearly every day.

I´ve found a thread in this forum, where the issue has been discussed and it was due to a big reporting file (dbl) But my .dbl files (i.e. mailsec.dbl) is below 25 Meg.
-------------------------- output of ll ---------------------------
rw-r--r-- 1 root root 1680384 Aug 27 08:34 accounting.dbl
-rw-r--r-- 1 root root 1466368 Aug 27 02:30 accounting_archive.dbl
-rw-r--r-- 1 root root  442368 Aug 27 08:21 auth.dbl
-rw-r--r-- 1 root root    4096 Aug 26 16:05 imp2p.dbl
-rw-r--r-- 1 root root    2048 Apr  2 13:04 ips.dbl
-rw-r--r-- 1 root root    2048 Apr  2 13:04 ipscount.dbl
-rw-r--r-- 1 root root    1024 Aug  9 08:25 mailsec.dbl
-rw-r--r-- 1 root root    1024 Aug 27 07:40 mailsec.dbl-journal
-rw-r--r-- 1 root root   55296 Aug 26 20:20 pfilter.dbl
drwxr-xr-x 2 root root    4096 Aug 27 08:28 sqlitetmp
-rw-r--r-- 1 root root 1163264 Aug 27 08:25 websec.dbl
------------------------------------------------------------------
What else can be the reason for this issue?
Is it adviseable to kill the job?

Cu
Thomas


This thread was automatically locked due to age.
Parents
  • 0
    There shouldn't be any harm if you just kill it; the selfmonitor will catch it and automatically restart it. If this problem persists you might want to consider 7.300; there have been lots of changes in the reporting backend.

    Cheers,
     andreas
Reply
  • 0
    There shouldn't be any harm if you just kill it; the selfmonitor will catch it and automatically restart it. If this problem persists you might want to consider 7.300; there have been lots of changes in the reporting backend.

    Cheers,
     andreas
Children
  • 0 in reply to andreas
    hi,

    killing the mailsec-reporter script job reduces the load to "normal".
    After the automatic restart of the job by selfmonitor, everything seems to be ok.
    But after a couple of hours, the processor load rises up again to 100% within seconds and lasts again some hours.

    Don´t want to update to 7.300 at this time. It´s in stable state only for a few days and watching the board, i´v recognized the coming up of several issues.
    Since the 2 boxes are in clustermode and in productional state with smtp proxy, encryption and firewalling for the whole company, i´ll be carefull with new firmware, especially if it touches so much.

    Cu
  • 0 in reply to tkaufi
    How many emails are processed by the firewall per hour? Can you take a look into your smtp/exim log file for anything that looks unusual?

    Generally, the only thing that the reporter does is to count processed email events, pre-aggregate them and write them to the database in 5 minute intervals. If the reporter needs more than 5 minutes to write the data to the database (for whatever reason: high load, high I/O, swapping, extremely larger number of mails during that interval, ...) it will look like it is constantly taking 100% cpu.

    Cheers,
     andreas
  • 0 in reply to andreas
    hi

    well, we have, depending on the time of day, up to 150 mph (mails per hour, no miles [:D]) an 3 Gig smtp traffic per week.

    the logs are looking pretty good, no unusual entry, as far i can see.

    ok, if mailsec-reporter needs more than the 5 minutes it may help to change the crontab?
    Otherwise the other load entrys (io, swap etc) are quite normal plus after a kill of the job and the automated restart it runs normal, too.
    And i´ve found, if the mailsec-reporter runs into the night, at midnight the load falls down to usual load. Does something stop it at this time?

    CU
  • 0 in reply to tkaufi
    I had the same problem, the support crew took a look and ended up deleting the file it was trying to process and letting it recreate it.  That seemed to fix it.
  • 0 in reply to number2jcb
    Changing the crontab will not work. You can of course try to delete the mailsec.dbl (and the journal), but considering the small file sizes this probably won't help you much. The mail usage isn't too big either, 150 mails per hour is a mere 2.5 mails per minute, so less than 15 mails per 5 minute reporting interval. I'd suggest you create the /var/log/debug/ directory and run "/etc/init.d/syslogng reload" so that the reporters are restarted. Take a look at what happens in the log.mailsec-reporter file, especially around the 5 minute intervals; it will also log how long the database transaction takes. 
    Remember to remove the debug directory again when you're finished (and reload the syslog service),  data will pile up fast if you don't.

    Cheers,
     andreas
  • 0 in reply to andreas
    @andreas

    I´ve done so. What i can see, that log.mailsec-reporter file is growing with every mail. In the file, some information about the mail(s) will be written down. And everytime the 5 min intervall comes up, there is an additional entry that  the reporter starts. 
    Some of the mail entrys in the log file are separeted by tabstops, while others are in a "column". I think this is only a display problem.
    So it doesn´t look strange. Nothing what points to a db problem.

    But this is during "normal" system load.
    I don´t know what happens, if mailsec-reporter lasts 100% CPU.
    Unfortunately, after restarting logging the cpu load falls down to normal load.
    And i can´t reproduce the situation with full cpu load caused by the reporter.

    Should i wait until it happens again, with the debugging on? And cleaning the directory manuelly to prevent data flood?

    CU
    Thomas
  • 0 in reply to tkaufi
    Hi,
    of course it would be more interesting to know what happens when the 100% cpu situation occurs. Now that you know how it looks in regular usage you should be able to spot abnormal conditions easier [:)]
    The disk won't run full because of a couple of hours of debugging output, I just wanted to make sure you don't leave it turned on forever.

    Cheers,
      andreas
Cookie Information Banner