nagymennyiségű hírlevél kiküldés

Linux-haladó

Tudom, ha így kezdem az már gyanús:) de valóban nem spam-elésről van szó.
Eddig ~15.000-60.000 e-mail címes hírlevelek kiküldését kellett megoldani.
Megy is probléma nélkül. Azonban most úgy áll a dolog, hogy hamarosan 50-100szor nagyobb (~2-3 millió cím) hírlevél kiküldéssel is boldogulni kellene 1-2 nap alatt.Elérkezettnek találtam az időt, hogy a hírlevél kiküldés saját szervert kapjon. Gondoltam arra is, hogy több SMTP-t kellene beállítani, hogy párhuzamosítsam a küldést, de ahogy utána néztem, alapból a Postfix 100 kapcsolatot kezel, annak bőven elégnek kellene lennie. Kérdés, hogy jól gondolom-e, hogy valóban tud-e akár egyszerre 100 szálon küldeni levelet.

Ha jól gondolom, akkor egy nem túl erős gépnek is bírnia kellene:
pl: Intel Dual Core Xeon E3110 3.0GH, 2GB RAM, gigás LAN, 2x500GB SATA (SATA/SAS 6iR RAID vezérlő, bár az LSI MegaCLI-je nem túl felhasználóbarát számomra)

Van-e valakinek hasonló dologban tapasztalata, esetleg ötlet, vagy megerősítés, hogy jól gondolom-e?

  • 2358 megtekintés

( vladekkk | 2009. 06. 29., h – 23:21 )

[nemokoskodniakarok,nemkötözködni,off]

Bocsi hogy offolok, de magyarország negyede netezik rendszeresen, ez kb 2,3 - 2,5 millio ember, és + egy kevés csak ritkábban, ami ugy 3-4 millio emailcimet jelent, de fixme ha nem igy van. igazabol nem tudom honnan van neked ennyi feliratkozott embered, de ha pl tied a myvip, vagy az iwiw akkor teljesen megertelek, de igy nem tudom elkepzelni, vilagosits mar fel :)

[nemokoskodniakarok,nemkötözködni,off]

( YanChi | 2009. 06. 30., k – 00:09 )

Nekem, amikor pár százezres listákra toltuk a leveleket, a szűk keresztmetszet a fogadó oldalon jelentkezett: a feliratkozottaink jelentős része citro, vip és hasonló ingyenes levelezőkről került ki, akik óránként csak meghatározott mennyiségű levelet fogadtak egy IP-ről. A mailqueue szépen megette a RAM-ot (spammerek ugye ezzel nem foglalkoznak, ami nem megy elsőre, azt eldobják), mert tízezer levél várakozott benne a sorsára. Szép nagy loadokat lehetett produkálni.

igen, freemail, vip és társai miatt véletlenszerűen következnek egymás után a különböző domain-es címek, hogy ne legyenek megsokkolva a fogadó szerverek

nálunk nem sok false cím van, hamar kiderülne (és nem csak a visszapattanásokból), azonban a hírlevelek perszonalizáltak, így minden levél egyesével megy ki, nem lehet összefogni őket, viszont ha a csatolmányokat (például kép a html levélhez) nem a levél tartalmazza, csak egy http-s link van benne, akkor a levelek mérete csökken, 2m levél esetén is kb. 19-20GB az össz, ergo, ha levonjuk a nagy százalék sikeresen kiküldött levelet, akkor simán elférhet az egész queue a memóriában (bár érdemes figyelni, hogy több kiküldés is futhat), ehhez érdemes hozzávenni, hogy szoros határidővel mennek a kiküldések, így nincs értelme 1-2 napnál nagyobbra hagyni a queue time-ot

ezek szerint sok memóriával és tárhellyel megoldató a dolog elméletileg, kérdés, a gyakorlat igazolja-e, hamarosan kiderül

ejh, pedig reméltem, hogy itt már valaki foglalkozott ilyennel:)

"igen, freemail, vip és társai miatt véletlenszerűen következnek egymás után a különböző domain-es címek, hogy ne legyenek megsokkolva a fogadó szerverek"

:D Szerintem a véletlenszerűennél jobb sorrendet is ki lehet találni.

:: by BRI.
:: config :: Acer TravelMate // Ubuntu Jaunty
:: tothab [a] gmail [pötty] kom
:: black rose immortal's weblog

3 eve ahol dolgoztam anno szinten 50-100 ezer emailt kellett kikuldeni, es ott is iszonyat load-ot okozott a szerveren, amit ugy tudtunk csokkenteni, es a teljesitmenyt tobb 10szeresere novelni, hogy csinaltunk egy 512MB-os RAMDisk-et es rapakoltuk a postfix belso queue-it, egy script figyelte a szabad teruletet, es ha kezdett elfogni, akkor kiszedte es elmentette a visszapattno emaileket. Mivel rovid kicsi de sok email volt, elfert a ramdisk-en, viszont az IO muveletek nem fogtak meg a szervert. Egyszeru megoldas volt, de a celnak megfelelt.

En erre inkabb olyan raidcontrollert vennek, amiben van memoria, mondjuk akar 512M. Es persze battery is.
Amire figyelni kell: a kartya biosaban be kell allitani, hogy az irasi muveletekhez is hasznalja a memoriajat (write back cache).
Valoban rettenetes teljesitmeny-novekedest tud okozni, a ramdiszk hatranyai nelkul. Persze nem ingyen :)

--
Gabriel Akos

( andrej_ v | 2009. 06. 30., k – 23:12 )

Vegyetek VPS-t .US-ben és .UK vagy .NL-ben is ehhez. Adott végű domaineket pedig valami statisztika szerint routold a VPS-ek felé, mint lokális mail relayek. A diszkekből kevés lehet az 500GB és ha már ilyen raid cucc van dobj be még egy 500-as vinyót egy RAID5-höz. Memóriát se sajnáld, minimum 4GB a fő szerveren, mert a párhuzamos szálak megeszik hamar. A VPS-ekbe elég lehet 384-512MB. (Emlékeim szerint a postfix transport tud round-robin módon is osztani, szóval az adott számú mail per IP per óra van, akkor csökkenthető a hatás.

A több IP ugyanarról a gépről nehéz lesz, mert honnan fogja tudni a postfix hogy épp melyikről menjen ki? Bár fel lehet húzni több chrootba több postfixet, amiknek egy "vezérlő" MTA szórja a maileket roundrobin. Nekem az a tippem, hogy sok helyen nem csak az egyedi IP-t szűrik, hanem a hálózatot, tehát ha kapsz egy /27-et (16 IP-t) akkor ha az ISP megcsinalja hozza a megfelelo whois-t is akkor kivághatnak az alapján.

A tapasztalatokat azért majd írd meg, hogy mi működött. :)

( janoszen v | 2009. 07. 01., sze – 02:50 )

Gyorsan markoljatok több IP-t és a szoftvert lehetőleg úgy írjátok meg, hogy az azonos szolgáltatóra menő levelek különböző HELOval más IPről essenek be. Gmailnél gondolom a tétel elég nagy lesz, szóval a per IP korlátozások valószínűleg ott is életbe lépnek. A VPS is játszik, csak azt talán egy hajszálnyival több energia megcsinálni.

én erre gondoltam ezek alapján:

dns név: smtp01.domain.tld..smtp10.domain.tld
ip: xxx.yyy.zzz.1..xxx.yyy.zzz.10

felhúzni mind a 10 IP-t a lan interface-re, majd a postfix-ből csinálni 10 példányt (/etc/postfix01../etc/postfix10, /var/spool/postfix01../var/spool/postfix10), végül elindítani mindegyiket, csak figyelni kell arra, hogy mindegyik példány a hozzá rendelt IP-re bind-eljen csak és kész

Hirtelen vegiggodolva, biztos, hogy kell neked postfix erre? Most nem a zwei kollega 'rent a botnet' otletere gondoltam, hanem arra, hogy irsz egy smtp klienst, ami pl. adatbazisbol szedi az email cimeket, meg valahonnan a leveleket. Azert nem kell neked smtp szerver, mert nem levelezni akarsz, csak kuldeni leveleket. A hibakoddal - pl. '450 easy, body, easy' - elutasitott - pl. greylisting miatt - cimzetteket pedig csak meg kellene jelolni egy idobelyeggel. Igy nem lenne queue-d, ami egy halom eroforrast megfogna.

Szoval kicsit konkretabban, van egy sql tablad egy halom email cimmel, es a testreszabashoz szukseges adatokkal. Fogsz egy halom smtp kuldo programot, akar tobb gepen futva (ahogy fentebb irtatok). Ezek mindegyike (valamilyen algoritmussal) valaszt maganak egy halom cimet (+adatot), majd elkezdi kikuldeni a cimzetteknek. Az eredmenyt pedig visszairja az adatbazisba. Amikor egy processz vegzett a maga szeletevel, akkor visszater a korabbi sikertelen cimzettekhez, es ujra probalkozik.

Nyilvan szamon kell tartani a probalkozasok szamat, az aktualis hibakodot, elment/nem ment el, stb.

SPAMtelenul - POP3 spamszuro szolgaltatas

Hmmm... az ido nagyja imho a halozati kommunikacioval (pl. mx rekordok lekerese + a level effektiv elkuldese) megy el, de a valaszt neked kell tudni. Ez csak egy otlet volt. Ha nekem kellene csinalnom, akkor C-ben irnam, amivel aligha veszitesz sebesseget.

Azert a vegen mondd el, hogy mivel es hogyan oldottad meg, erdekel.

SPAMtelenul - POP3 spamszuro szolgaltatas

más dolgok miatt csak mostanában sikerült nekiállnom

jelenleg ott tartok, hogy kész a script amivel 1-250 postfix példányt tudok vezérelni (template alapján létrehozni, meg a szokásos: start, reload, restart, flush, stop, queue-ban várakozó e-mail-ek darabszáma, stb.), mindegyik külön fájlba teszi a log-ot, stb.

a /etc/syslog-ng/syslog-ng.conf-ot módosítottam, hogy elég kapcsolatot kezeljen:
unix-stream("/dev/log" max_connections(1000));
bár a stream helyett szerencsésebb lenne ilyen esetben már a socket használata

50 példány működéséig még nincs nagyon gond, de 100 közeli értéknél már az alábbi hibaüzenet jön:
Error accepting new connection; error='Too many open files (24)'

amit csináltam próbaképp':
1. /etc/security/limits.conf-ban felemeltem a limitet
* hard nofile 1024000

2. a /etc/sysctl.conf-ban megemeltem az alábbiak értékeit
fs.epoll.max_user_watches
fs.inotify.max_user_watches
fs.epoll.max_user_instances
fs.inotify.max_user_instances
fs.file-max

de nem segített egyik megoldás sem, mire nem gondoltam?

update:
kimaradt, hogy grsec-es kernel

update2:
a /etc/security/limits.conf-ban beraktam a hard mellé egy soft szabályt is:
* soft nofile 1024000

most úgy néz, minden jól működik, csak kell még memória a gépbe :)