| 
      
      
      From: Dave S. <dst...@ma...> - 2007-01-21 20:40:56
      
     | 
| Actually it does help - thanks!
=20
It gives me a sense that we're not using SQLGrey in a strange way, or have =
it configured wrong. We have made several mods to the code, but we have =
had these "450 Server Config Problems" long before the mods.
=20
Question: Do you run the cleanup in Async or Sync mode? We have been =
running Async, and I have always feared this was a problem, even though we =
have tested Sync mode and gotten the same errors.
=20
I also noted that you run MySQL instead of Postgres. It would be possible =
for us to switch, but certainly difficult to try just for testing.
=20
Also, we almost always get these errors at the top of the hour. The only =
cronjob that runs at the top of the hour is a process that rolls our log =
files, and gzips them for us. During the gzip process the load spikes a =
little, but not much, even through the gzip process may take 90% of the =
CPU for 30-60 seconds.
=20
Thanks,
=20
-- Dave
>>> Dan Faerch <da...@ha...> 12:37 PM Sunday, January 21, 2007 >>>
Dave Strickler wrote:
> Currently we're using SQLGrey v1.6.7, and we are getting a lot of =
"warning: connect to 127.0.0.1:2501: Connection timed out". They seem to =
come in clumps, as if the SQLGrey code was very busy, and couldn't answer =
the requests. This gives a "450 Server configuration problem" to the =
Sender, and makes the sender think we have done something very bad.
>  =20
We have never had the problem with sqlgrey you describe.
I can't solve your problem, but i can tell you what we have made our =
setup:
In our cluster of mailservers, each server is scaled to handle about=20
600.000 mail-requests daily. (some a little more or a little less based=20
on hardware). The same cluster nodes run 2 other policy-deamons, our =
own=20
"malware-sandbox", spamassasin and virusscanning using 3 scanners. On=20
each node, that is.
In peak-hour they sometimes have a load of 4.0-8.0, but they still run=20
great.
In master.cf we have raised the limit of simultaneous smtpd to 500,=20
based on real-life measurements (debian default is 50 i think).  So=20
thats maximum 500 simultaneous request for sqlgrey as well.
We use sqlgrey's db_clustering. All writes go to a central MySQL, read=20
request go to a MySQL on 127.0.0.1.
The MySQL clutster also handles postfix'es Access, Virtual & transport=20
tables and Spam/Virus quarantine. So SQL is pretty busy as well.
Sqlgrey is configured in Postfix main.cf as such:
---------------------
smtpd_restriction_classes =3D sqlgrey
sqlgrey  =3D  check_policy_service inet:127.0.0.1:2501
smtpd_sender_restrictions =3D
                         sqlgrey
                         <other restrictions go here>
---------------------
Most hardware  is:
- Dual Xeon 3.00GHz
- 2 x 60gig scsi discs, running as a raid MIRROR (not for speed=20
obviously, but for safety)
- 1 gig ram.
Dont know if this helps you in any way :)
- Dan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV=20
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...=20
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
This message has been certified virus-free by MailWise Filter - The real-ti=
me, intelligent, e-mail firewall used to scan inbound and outbound messages =
for SPAM, Viruses and Content. =0A=0A  For more information, please visit: http:=
//www.mailwise.com=0A
 |