[linux] Postfix + Greylist

[Lubomir Host]

On Wed, Dec 15, 2004 at 09:08:02PM +0100, Lubos Vitek wrote:
> neviem ci toto prave pomoze, aj ked za pokus to mozno stoji. problem je
> v tom, ze do tych tabuliek sa zapisuju, citaju a mazu udaje nasledovne:
> 
> -- zo stranky postgrey: --
> When a request for delivery of a mail is received by Postfix via SMTP,
> the triplet CLIENT_IP / SENDER / RECIPIENT is built. If it is the first
> time that this triplet is seen, or if the triplet was first seen less
> than 5 minutes, then the mail gets rejected with a temporary error.
> Hopefully spammers or viruses will not try again later, as it is however
> required per RFC.
> ----
> 
> 
> kazdy mail klient, ktory sa konektne na server sa teda overuje trojicou 
> CLIENT_IP / SENDER / RECIPIENT. Samozrejme tabulka je zindexovana podla
> ip, sender a recipient. V pripade prveho vyskytu sa insertuje novy
> zaznam. V pripade opakovaneho vyskytu sa prislusny zaznam updatne (pole
> last_seen).
> 
> paralelne k tomu bezi cronjob, ktory kontroluje a maze vsetky zaznamy,
> ktore maju cas poslednej zmeny > X dni a pass_count = 0 (SPAM servre,
> ktore sa vyskytli len raz a pod.). V praxi to je na nasom servri a pri
> nasej trafike ca. 5000-15000 zaznamov pri kazdom mazani. aj napriek tomu
> mazaniu rastie tabulka spominanou rychlostou 10-100tis zaznamov za
> tyzden.
> 
> problem je v tom, ze cas pre selecty aj updaty samozrejme stale rastie a
> mysql z pohladu mailservra timeoutuje.

Ked uz pises, ze mas upraveny postgrey pre MySQL, tak by som ho vylepsil.
Je jasne, ze pri takomto algoritme a vypoctovom vykone, aky mas
k dispozicii, to nemoze zvladat taketo objemy dat.

Hlavny problem je pravdepodobne v query cache. Tu ale asi potrebujes, aby ti
selecty zbehli rychlo. Cize musis zabezpecit, aby sa pri updatoch
zbytocne nezneplatnovala. (To zistis jednoducho: sprav nejaky update
a zapis si cas vykonavania. Zbehni nejake selecty, nech sa dobre
nacachuju. A znovu pusti ten isty update. Cas vykonavania by sa mal
zvysit asi tak zo zlomkov sekund az na desiatky sekund).

Navrhoval by som skusit taketo:

- zrusit niektory z indexov (napr. RECIPIENT). MySQL bude menej casu
  travit updatovanim tohto indexu, kedze na serveri mozno nemas az tak
  vela userov.

- alebo obmedzit dlzku indexov

- zmenit politiku prace so zaznamami v tabulkach. Vytvorit jednu merge
  tabulku, odkial selectujes. Insertovat/updatovat do jednej tabulky. Zvysne
  2 miliony zaznamov nechat v tabulkach, ktore nebudes modifikovat tak
  casto. Cronom z tej insertovacej tabulky popreklapat starsie zaznamy
  alebo uz vyskytujuce sa zaznamy do tych ostatnych tabuliek, pripadne
  poupravovat pass_count v tych tabulkach na zaklade insertovacej
  tabulky a duplicitne zaznamy z insertovacej tabulky zmazat.

Tolko zopar mojich tipov. Viac ma momentalne nenapada.

rajo

-- 
Lubomir Host 'rajo' <rajo AT platon.sk>        ICQ #:  257322664
Platon Software Development Group              http://platon.sk/
http://www.gnu.org/philosophy/no-word-attachments.html