<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#333333">
Ryan Sweat wrote:
<blockquote
cite="mid:37728b30712241342l6293ae6cm9cdf05fea028f1e7@mail.gmail.com"
type="cite">I'm having a problem with the SQL logging functionality in
MailScanner and hopefully someone can help me figure it out. After
MailScanner starts, it works perfectly for a period of time, usually 30
minutes to an hour, then it stops logging incoming email to the MySQL
database. The log shows "Logging message to SQL" but it never finishes
with the usual "Logged message to SQL. When this happens, the queue
builds incredibly fast and there are huge delays in delivering email --
often many hours of delay. Currently the MySQL database is local, but
I had the same problem logging to a remote database where an older
version of MailScanner is currently running (and logging) without
problems. I put some custom debugging in the
CustomFunctions/MailWatch.pm and I can tell that the connection to the
database is failing here and never seems to recover.
<br>
<br>
# Failed to connect - kick off new child, wait, and try again<br>
InitMailWatchLogging();<br>
<br>
I ran strace on the MailWatch SQL process until the problem occurred
and it doesn't really show any good info, other than it eventually gets
stuck waiting for data.
<br>
<br>
24731 write(3, "<22>Dec 24 15:15:20 MailScanner[24731]:
lBOGSJ16013580: Logged to MailWatch SQL\n\0", 81) = 81<br>
24731 accept(7, {sa_family=AF_INET, sin_port=htons(57527),
sin_addr=inet_addr("
<a moz-do-not-send="true" href="http://127.0.0.1">127.0.0.1</a>")},
[13249590112313933840]) = 10<br>
24731 close(9) = 0<br>
24731 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffaedc7350) = -1
EINVAL (Invalid argument)
<br>
24731 lseek(10, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)<br>
24731 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffaedc7350) = -1
EINVAL (Invalid argument)<br>
24731 lseek(10, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
<br>
24731 fcntl(10, F_SETFD, FD_CLOEXEC) = 0<br>
24731 alarm(9600) = 9600<br>
24731 read(10,<br>
<br>
# ps auwx | grep Mail<br>
root 22372 0.0 0.0 152796 31408 ? Ss 14:58 0:00
MailScanner: master waiting for children, sleeping
<br>
root 22373 8.7 0.3 237232 104848 ? S 14:58 3:24
MailScanner: finishing batch<br>
root 22387 7.8 0.3 242212 107484 ? S 14:58 3:02
MailScanner: finishing batch<br>
root 22396 8.4 0.3 237400 104764 ? S 14:58 3:17
MailScanner: finishing batch<br>
root 22409 3.9 0.3 234432 103984 ? S 14:58 1:33
MailScanner: finishing batch<br>
<br>
Strace on these MailScanner processes all show the same thing...
<br>
<br>
connect(8, {sa_family=AF_INET, sin_port=htons(11553),
sin_addr=inet_addr("<a moz-do-not-send="true" href="http://127.0.0.1">127.0.0.1</a>")},
16<br>
<br>
I check the port 11553 and it is indeed listening. Restarting
MailScanner fixes the problem (for about 30 minutes). I installed
MailScanner using the rpm packages/installation scripts on the download
page "
<a moz-do-not-send="true"
href="http://www.mailscanner.info/files/4/rpm/MailScanner-4.65.3-1.rpm.tar.gz">Version
4.65.3-1 for RedHat, Fedora and Mandrake Linux</a>". The OS is Linux
RHEL 5 64-bit, 16 processors and 32 GB ram. Has anyone experienced
this before or have any advice?
<br>
<br>
Thanks,<br>
<br>
Ryan<br>
</blockquote>
<font face="Helvetica, Arial, sans-serif">How big is your maillog table
? <br>
</font><font face="Helvetica, Arial, sans-serif">How often did you
prune your maillog table ? <br>
Did you optimize the table after you prune it ? <br>
<br>
I found out that if the table get locked ... mailwatch stopped writing
to it until you restart mailscanner !!!<br>
I couldn't find any explanation on this but I definitely can recreate
the problem.<br>
</font><font face="Helvetica, Arial, sans-serif"><br>
MySQL seems to executes a select and then starts inserting.<br>
The bigger the database, Insert,select, update, and delete
operation will take more time and increase the chances of table get
locked.<br>
<br>
</font><font face="Helvetica, Arial, sans-serif">To get around this you
can </font><font face="Helvetica, Arial, sans-serif">have a look at my
roll over table patch which available at :
<a class="moz-txt-link-freetext" href="http://mailwatch.sourceforge.net/doku.php?id=mailwatch:tipandtricks:rollover_table">http://mailwatch.sourceforge.net/doku.php?id=mailwatch:tipandtricks:rollover_table</a><br>
The idea is to partition maillog table into smaller chunks, therefore
one table will have less data. <br>
<br>
Since you have been blessed with good amount of memory, try increase
key_buffer_size. <br>
A better work around is to make MailWatch to write to temporary table
using memory (heap) engine and periodically flush it to the real table.
</font><font face="Helvetica, Arial, sans-serif"><br>
<br>
<br>
<br>
Regards,<br>
Rianto Wahyudi<br>
<br>
<br>
-- adela tirta belek<br>
<br>
<br>
<br>
<br>
</font>
</body>
</html>