Re: scantime=249.2; scantime=175.0; scantime=190.9; scantime=68.9
In several places, Justin Mason has said the sysread debug line doesn't necessarily indicate an error (he actually says they're normal in debug mode), though these are fairly old posts. http://www.mail-archive.com/users@spamassassin.apache.org/msg31175.html http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200506.mbox/%3c4407.42b33d88.2f05af5b@spamassassin.apache.org%3e So the sysread may be a red herring. On Sat, 4 Sep 2010, Chris wrote: On Sat, 2010-09-04 at 08:42 -0500, Chris wrote: I'm trying to figure out why I'm having ridiculous scan times such as the above examples. Lower scan times such as in the 20 second range are the exception rather than the rule. I'm running bind as a local caching nameserver and it seems to be working correctly. I've just seen a ham that has a scantime=172.2. Could there be something else on the system that is affecting this? Any advice as to troubleshooting would be appreciated. I've started SA now with -D OPTIONS=-d -D -c -H -m 4 --max-conn-per-child=3 --min-children=1 While looking at my syslog I noticed the following: Sep 4 16:21:46 localhost spamd[15797]: prefork: periodic ping from spamd parent Sep 4 16:21:46 localhost spamd[15800]: prefork: periodic ping from spamd parent Sep 4 16:21:46 localhost spamd[15800]: prefork: sysread(9) not ready, wait max 300 secs Sep 4 16:21:46 localhost spamd[15797]: prefork: sysread(8) not ready, wait max 300 secs I've got the debug output on a ham, just waiting for a spam to come through then I'll post both to pastebin but the above doesn't look good. When this is happening my drive light seems to stay on forever and the system seems close to being unresponsive. Checking cpu usage when this is happening it stays around 4% for user and 3-4% for system. Link for a ham - http://pastebin.com/k55D79TL spam - http://pastebin.com/28qW2nga Though I hate to do it I've temporally shut down SA, hopefully some of you have a solution. Thanks Chris -- Public key #7BBC68D9 at| Shane Williams http://pgp.mit.edu/| System Admin - UT iSchool =--+--- All syllogisms contain three lines | sha...@shanew.net Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: scantime=249.2; scantime=175.0; scantime=190.9; scantime=68.9
On Sun, 2010-09-05 at 07:35 -0500, Shane Williams wrote: In several places, Justin Mason has said the sysread debug line doesn't necessarily indicate an error (he actually says they're normal in debug mode), though these are fairly old posts. http://www.mail-archive.com/users@spamassassin.apache.org/msg31175.html http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200506.mbox/%3c4407.42b33d88.2f05af5b@spamassassin.apache.org%3e So the sysread may be a red herring. On Sat, 4 Sep 2010, Chris wrote: On Sat, 2010-09-04 at 08:42 -0500, Chris wrote: I'm trying to figure out why I'm having ridiculous scan times such as the above examples. Lower scan times such as in the 20 second range are the exception rather than the rule. I'm running bind as a local caching nameserver and it seems to be working correctly. I've just seen a ham that has a scantime=172.2. Could there be something else on the system that is affecting this? Thanks, after reading Justin's input on the bug-report I see what's happening as far as the 'pings' go. I'll see how things go as the day progress regarding scan times. Chris -- Chris KeyID 0xE372A7DA98E6705C signature.asc Description: This is a digitally signed message part
Re: scantime=249.2; scantime=175.0; scantime=190.9; scantime=68.9
On Sat, 4 Sep 2010, Chris wrote: Running an X session, and I noticed that this is back: How much memory in that box? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- If Microsoft made hammers, everyone would whine about how poorly screws were designed and about how they are hard to hammer in, and wonder why it takes so long to paint a wall using the hammer. --- 12 days until the 223rd anniversary of the signing of the U.S. Constitution
Limit message size scans
I know there are a number of ways to limit the size of a messages that are scanned with spamassasin, but I am having problems with configurations. Spamc seems to have this capability already build in by default. Is there a config file that I can change to call spamc when the call is made from the .mailfilter that is in the users mail folder and contains code to call spamassassin. (xfilter /usr/bin/spamassassin -p) -- View this message in context: http://old.nabble.com/Limit-message-size-scans-tp29627866p29627866.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: scantime=249.2; scantime=175.0; scantime=190.9; scantime=68.9
On Sun, 2010-09-05 at 09:18 -0700, John Hardin wrote: On Sat, 4 Sep 2010, Chris wrote: Running an X session, and I noticed that this is back: How much memory in that box? 754Mb and 1Gb swap, top shows top - 12:16:19 up 51 days, 16:18, 2 users, load average: 0.31, 0.37, 0.65 Tasks: 179 total, 1 running, 178 sleeping, 0 stopped, 0 zombie Cpu(s): 10.3%us, 4.7%sy, 0.0%ni, 85.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem:772880k total, 685316k used,87564k free,31344k buffers Swap: 1076312k total, 249032k used, 827280k free, 156328k cached Spamd shows PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 22587 root 20 0 86500 77m 3192 S 0.0 10.3 0:11.96 spamd -- Chris KeyID 0xE372A7DA98E6705C signature.asc Description: This is a digitally signed message part
Re: scantime=249.2; scantime=175.0; scantime=190.9; scantime=68.9
Mem:772880k total, 685316k used,87564k free,31344k buffers Swap: 1076312k total, 249032k used, 827280k free, 156328k cached 250MB swapped, for less than 1 GB RAM, used is disastrous for an MTA. Increase RAM to 2GB, or until swap is always 0k used Len
Re: scantime=249.2; scantime=175.0; scantime=190.9; scantime=68.9
On Sat, 2010-09-04 at 08:42 -0500, Chris wrote:
I'm trying to figure out why I'm having ridiculous scan times such as
the above examples. Lower scan times such as in the 20 second range are
the exception rather than the rule. I'm running bind as a local caching
Do you use the URICountry plugin? It has been reported to cause
exceptionally long processing time in some cases. It certainly was the
cause on one machine for me.
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Limit message size scans
On Sun, 5 Sep 2010, COGZ wrote: I know there are a number of ways to limit the size of a messages that are scanned with spamassasin, but I am having problems with configurations. Spamc seems to have this capability already build in by default. Is there a config file that I can change to call spamc when the call is made from the .mailfilter that is in the users mail folder and contains code to call spamassassin. (xfilter /usr/bin/spamassassin -p) If the user is explicitly calling spamassassin that way there's little you can do on the SA side to override it. Can you educate your users to call spamc instead of spamassassin? If you have administrative access you could change the users' .mailfilter files... Perhaps replace /usr/bin/spamassassin with a shell script wrapper that calls spamc? That would be fairly fragile and would impact people outside the scope of .mailfilter files. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Sheep have only two speeds: graze and stampede. -- LTC Grossman --- 12 days until the 223rd anniversary of the signing of the U.S. Constitution
Re: scantime=249.2; scantime=175.0; scantime=190.9; scantime=68.9
On Sun, 5 Sep 2010, Chris wrote: On Sun, 2010-09-05 at 12:33 -0500, Len Conrad wrote: Mem:772880k total, 685316k used,87564k free,31344k buffers Swap: 1076312k total, 249032k used, 827280k free, 156328k cached 250MB swapped, for less than 1 GB RAM, used is disastrous for an MTA. Increase RAM to 2GB, or until swap is always 0k used It's just a single user home system. True, I probably do need to increase ram but I 'don't' think this has a bearing on this issue though I may be wrong. Your system is swapping. That kills performance, pretty much across the board. Either buy more memory or accept the impact of an underprovisioned machine on the performance of mail delivery. Do you really need your mail to be delivered _that_ promptly? If interactive performance is acceptable then what does it matter if an email (delivered in the background) takes 30 seconds or 300 seconds to be stuffed into your inbox? How many email users is this supporting? You might want to consider some glue-level performance hacks - for example, if your box is supporting email for your family members, and all delivery for that is local, then you could configure your MTA to not pass locally-originated-and-destined messages through clamav or SA at all. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Sheep have only two speeds: graze and stampede. -- LTC Grossman --- 12 days until the 223rd anniversary of the signing of the U.S. Constitution
Re: scantime=249.2; scantime=175.0; scantime=190.9; scantime=68.9
On Sun, 2010-09-05 at 20:02 +0200, Karsten Bräckelmann wrote: On Sat, 2010-09-04 at 08:42 -0500, Chris wrote: I'm trying to figure out why I'm having ridiculous scan times such as the above examples. Lower scan times such as in the 20 second range are the exception rather than the rule. I'm running bind as a local caching Do you use the URICountry plugin? It has been reported to cause exceptionally long processing time in some cases. It certainly was the cause on one machine for me. Thanks Karsten, just checked and it's not among those that I'm using. Chris -- Chris KeyID 0xE372A7DA98E6705C signature.asc Description: This is a digitally signed message part
Re: scantime=249.2; scantime=175.0; scantime=190.9; scantime=68.9
On Sun, 2010-09-05 at 12:54 -0700, John Hardin wrote: On Sun, 5 Sep 2010, Chris wrote: On Sun, 2010-09-05 at 12:33 -0500, Len Conrad wrote: Mem:772880k total, 685316k used,87564k free,31344k buffers Swap: 1076312k total, 249032k used, 827280k free, 156328k cached 250MB swapped, for less than 1 GB RAM, used is disastrous for an MTA. Increase RAM to 2GB, or until swap is always 0k used It's just a single user home system. True, I probably do need to increase ram but I 'don't' think this has a bearing on this issue though I may be wrong. Your system is swapping. That kills performance, pretty much across the board. Either buy more memory or accept the impact of an underprovisioned machine on the performance of mail delivery. Do you really need your mail to be delivered _that_ promptly? If interactive performance is acceptable then what does it matter if an email (delivered in the background) takes 30 seconds or 300 seconds to be stuffed into your inbox? Thanks for the input John, I can accept 30 or 45 seconds of drive access however when it comes to 300 I can't accept that. And you're absolutely correct, the problem is my lack of memory I realize that now. How many email users is this supporting? You might want to consider some glue-level performance hacks - for example, if your box is supporting email for your family members, and all delivery for that is local, then you could configure your MTA to not pass locally-originated-and-destined messages through clamav or SA at all. Just one user, me, though I already have procmail setup to not pass mail destined for mailing list through SA or ClamAv. I had SA set to check message size less than 250k in my procmailrc I've dropped it to 50k and will see what happens. I could probably drop some of the extra rulesets I run also which would probably cut down on access until I can upgrade my memory. I'm going to consider this thread closed then as being solved with upgrade to more memory. Many thanks to all who replied and offered suggestions. And to the SA Team, keep up the great work! Chris -- Chris KeyID 0xE372A7DA98E6705C signature.asc Description: This is a digitally signed message part
spam caught, now how to catch spammer
In the last several weeks I have been receiving a lot of spam with email addresses of the form: learningmadeeasy.???...@??.yourseemlost.net learningmadeeasy.???...@??.hisoftenusing.net learningmadeeasy.???...@??.wheatdrinkcontrol.net learningmadeeasy....@??.actbookfelt.net learningmadeeasy....@??.stillstationwhether.net learningmadeeasy....@??.legbottleloss.net and accountingeducation.gpx...@oiteew.badpeoplepaper.net accountingeducation.ihd...@aapufx.stillstationwhether accountingeducation.ionm...@wxnuab.legbottleloss.net accountingeducation.iqle...@mlmuwx.stillstationwhethe and affordablelifeinsurance.aj...@wiogif.constum.net affordablelifeinsurance.ki...@pzodkk.injecou.net How do we stop this guy?
Re: Limit message size scans
The problem with editing the users .mailfilter file is that they could overwrite it with their control panel. Seems like a shell script wrapper would be best. Any suggestions on how to configure? John Hardin wrote: On Sun, 5 Sep 2010, COGZ wrote: I know there are a number of ways to limit the size of a messages that are scanned with spamassasin, but I am having problems with configurations. Spamc seems to have this capability already build in by default. Is there a config file that I can change to call spamc when the call is made from the .mailfilter that is in the users mail folder and contains code to call spamassassin. (xfilter /usr/bin/spamassassin -p) If the user is explicitly calling spamassassin that way there's little you can do on the SA side to override it. Can you educate your users to call spamc instead of spamassassin? If you have administrative access you could change the users' .mailfilter files... Perhaps replace /usr/bin/spamassassin with a shell script wrapper that calls spamc? That would be fairly fragile and would impact people outside the scope of .mailfilter files. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Sheep have only two speeds: graze and stampede. -- LTC Grossman --- 12 days until the 223rd anniversary of the signing of the U.S. Constitution -- View this message in context: http://old.nabble.com/Limit-message-size-scans-tp29627866p29630276.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Limit message size scans
On Sun, 5 Sep 2010, COGZ wrote: The problem with editing the users .mailfilter file is that they could overwrite it with their control panel. Seems like a shell script wrapper would be best. Any suggestions on how to configure? Is there any way you can hook control panel to throw a warning if they use spamassassin and recommend spamc instead? User education is the _best_ option... John Hardin wrote: On Sun, 5 Sep 2010, COGZ wrote: I know there are a number of ways to limit the size of a messages that are scanned with spamassasin, but I am having problems with configurations. Spamc seems to have this capability already build in by default. Is there a config file that I can change to call spamc when the call is made from the .mailfilter that is in the users mail folder and contains code to call spamassassin. (xfilter /usr/bin/spamassassin -p) If the user is explicitly calling spamassassin that way there's little you can do on the SA side to override it. Can you educate your users to call spamc instead of spamassassin? If you have administrative access you could change the users' .mailfilter files... Perhaps replace /usr/bin/spamassassin with a shell script wrapper that calls spamc? That would be fairly fragile and would impact people outside the scope of .mailfilter files. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Where We Want You To Go Today 07/05/07: Microsoft patents in-OS adware architecture incorporating spyware, profiling, competitor suppression and delivery confirmation (U.S. Patent #20070157227) --- 12 days until the 223rd anniversary of the signing of the U.S. Constitution
