[rlug] Optimizare delivery local postfix
Salutare, Rulez un server postfix (2.2.10) pe un domeniu intern exclusiv pentru alarme. Scopul lui e să preia alarme de la diverse sisteme de management și să le scrie în maildir-uri locale (după ce face expand la alias-uri). Problema e că nu face față deloc ok la vârfuri de alarme (spike-uri de 3-6000 de mailuri) și aș vrea să îi îmbunătățesc performanța (sau măcar să înțeleg de ce e limitat). Momentan reușește să facă local delivery la ~1000 mailuri/oră: http://imgur.com/1GH3y Sistemul pe care rulează e un Intel(R) Xeon(TM) CPU 3.00GHz cu HT, are la dispoziție 2G de RAM + 2 swap (nefolosiți) și scrie pe un volum RAID 1 de 133G (format parcă din 2 discuri). Load average-ul pe sistem e de regulă sub 1, dar în momente de flood de alarme crește între 2 și 3. Performanța discului nu e cine știe ce, dar nu e nici foarte rea (cele 6000 de mailuri sunt de regulă sub 1k): [root@raptor ~]# hdparm -tT /dev/cciss/c0d0p1 /dev/cciss/c0d0p1: Timing cached reads: 3848 MB in 2.00 seconds = 1923.33 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Timing buffered disk reads: 272 MB in 3.01 seconds = 90.50 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Filesystem-ul e ext3, montat cu noatime. Configurația postfix este: [root@raptor ~]# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 default_destination_concurrency_limit = 40 default_process_limit = 150 helpful_warnings = yes home_mailbox = Maildir/ html_directory = no inet_interfaces = localhost, 1.1.1.4 initial_destination_concurrency = 20 local_destination_concurrency_limit = 100 mail_owner = postfix mail_spool_directory = /var/spool/mail mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man maximal_queue_lifetime = 5m message_size_limit = 41943040 mydestination = $myhostname,localhost.$mydomain,localhost mydomain = lan.net myhostname = raptor.lan.net mynetworks = 10.0.250.0/24, 127.0.0.0/8 myorigin = $myhostname newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.2.10/README_FILES sample_directory = /usr/share/doc/postfix-2.2.10/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_connect_timeout = 5 smtp_helo_timeout = 10 smtpd_banner = $myhostname ESMTP $mail_name smtpd_client_connection_count_limit = 100 smtpd_client_restrictions = permit_mynetworks smtpd_error_sleep_time = 0 unknown_local_recipient_reject_code = 550 Am citit din documentația postfix http://www.postfix.org/QSHAPE_README.htmlși o parte din http://www.postfix.org/TUNING_README.html O parte din parametrii au fost deja tunați conform recomandărilor, dar nu am avut o mare creștere de performanță. În concluzie - mă puteți îndruma spre ceva documentație/articole care să îmi zică cum să găsesc unde am bottleneck-ul la local delivery? Dacă găsesc bottleneck-ul, am ceva șanse să îmbunătățesc performanța, sau sunt deja limitat de hardware? Mi se pare totuși o performanță mică să facă delivery la 1 mail/secundă cum face acum (recunosc, alias-urile au cam 20-30 de mailbox-uri în spate...). Care e experiența voastră în domeniu? Thanks, Adrian ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
On 01/11/2012 12:36 PM, Adrian Popa wrote: Timing buffered disk reads: 272 MB in 3.01 seconds = 90.50 MB/sec Dat fiind ca sintem in 2012, cam patetic, orice desktop te cam intrece. Daca nu-i cantitate mare un ssd decent ar fi mult mai rapid, si astea pina in 96GB sint chiar ieftine, doar vezi sa aiba iops rezonabil la scriere. Vezi si ce si cit toarna in syslog (daca nu ai nevoie dezactiveaza mail.*) si daca toarna cu sau fara sync -- Dan Borlovan Datagroup-Int ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
În maillog scrie cam 100M la 1-2 zile. Cum verific dacă scrie sincronizat sau nu? Nu am găsit referințe legate de sync nici în syslog nici în postfx. O să încerc cu mai puțin logging pe moment. 2012/1/11 Dan Borlovan d...@level7.ro On 01/11/2012 12:36 PM, Adrian Popa wrote: Timing buffered disk reads: 272 MB in 3.01 seconds = 90.50 MB/sec Dat fiind ca sintem in 2012, cam patetic, orice desktop te cam intrece. Daca nu-i cantitate mare un ssd decent ar fi mult mai rapid, si astea pina in 96GB sint chiar ieftine, doar vezi sa aiba iops rezonabil la scriere. Vezi si ce si cit toarna in syslog (daca nu ai nevoie dezactiveaza mail.*) si daca toarna cu sau fara sync -- Dan Borlovan Datagroup-Int ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/11 Adrian Popa adrian.popa...@gmail.com: În maillog scrie cam 100M la 1-2 zile. Cum verific dacă scrie sincronizat sau nu? Nu am găsit referințe legate de sync nici în syslog nici în postfx. O să încerc cu mai puțin logging pe moment. Syslogd-urile in principiu au o optiune speciala sa faca fsync (in sysklogd era cu -, in altele nu mai stiu pe de rost). Cel mai sanatos imho e sa faci loggingul remote. Acu daca stau si ma uit atent la mailul tau initial, n-ai zis in ce anume faci livrarea locala (in main.cf-ul ala scrie cate in luna si in stele, da' despre local cam putin). De notat ca local_destination_concurrency_limit nu e foarte sanatos sa-l faci asa mare, e pus in mod normal la 1-2 ca sa se poata serializa corect in caz ca ai sieve sau procmail. Altfel, masina in ce sta, ai iowait mare la MDA (care o fi el), ai lookupuri in db care se agata, etc? -- Petre, compilat cu --without-mafalda ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/11 Adrian Popa adrian.popa...@gmail.com: Salutare, Rulez un server postfix (2.2.10) pe un domeniu intern exclusiv pentru alarme. Scopul lui e să preia alarme de la diverse sisteme de management și să le scrie în maildir-uri locale (după ce face expand la alias-uri). Problema e că nu face față deloc ok la vârfuri de alarme (spike-uri de 3-6000 de mailuri) și aș vrea să îi îmbunătățesc performanța (sau măcar să înțeleg de ce e limitat). Momentan reușește să facă local delivery la ~1000 mailuri/oră: http://imgur.com/1GH3y Sistemul pe care rulează e un Intel(R) Xeon(TM) CPU 3.00GHz cu HT, are la dispoziție 2G de RAM + 2 swap (nefolosiți) și scrie pe un volum RAID 1 de 133G (format parcă din 2 discuri). Load average-ul pe sistem e de regulă sub 1, dar în momente de flood de alarme crește între 2 și 3. Performanța discului nu e cine știe ce, dar nu e nici foarte rea (cele 6000 de mailuri sunt de regulă sub 1k): [root@raptor ~]# hdparm -tT /dev/cciss/c0d0p1 /dev/cciss/c0d0p1: Timing cached reads: 3848 MB in 2.00 seconds = 1923.33 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Timing buffered disk reads: 272 MB in 3.01 seconds = 90.50 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device cred ca de aici ti se trage, e foarte mic transferul pe disk. Filesystem-ul e ext3, montat cu noatime. Configurația postfix este: [root@raptor ~]# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 default_destination_concurrency_limit = 40 default_process_limit = 150 helpful_warnings = yes home_mailbox = Maildir/ html_directory = no inet_interfaces = localhost, 1.1.1.4 initial_destination_concurrency = 20 local_destination_concurrency_limit = 100 mail_owner = postfix mail_spool_directory = /var/spool/mail mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man maximal_queue_lifetime = 5m message_size_limit = 41943040 mydestination = $myhostname,localhost.$mydomain,localhost mydomain = lan.net myhostname = raptor.lan.net mynetworks = 10.0.250.0/24, 127.0.0.0/8 myorigin = $myhostname newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.2.10/README_FILES sample_directory = /usr/share/doc/postfix-2.2.10/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_connect_timeout = 5 smtp_helo_timeout = 10 smtpd_banner = $myhostname ESMTP $mail_name smtpd_client_connection_count_limit = 100 smtpd_client_restrictions = permit_mynetworks smtpd_error_sleep_time = 0 unknown_local_recipient_reject_code = 550 Am citit din documentația postfix http://www.postfix.org/QSHAPE_README.htmlși o parte din http://www.postfix.org/TUNING_README.html O parte din parametrii au fost deja tunați conform recomandărilor, dar nu am avut o mare creștere de performanță. În concluzie - mă puteți îndruma spre ceva documentație/articole care să îmi zică cum să găsesc unde am bottleneck-ul la local delivery? Dacă găsesc bottleneck-ul, am ceva șanse să îmbunătățesc performanța, sau sunt deja limitat de hardware? Mi se pare totuși o performanță mică să facă delivery la 1 mail/secundă cum face acum (recunosc, alias-urile au cam 20-30 de mailbox-uri în spate...). Care e experiența voastră în domeniu? vezi daca te ajuta sa pui logurile intr-un ramdisk sa vezi daca de la syslogd ti se trage. cum ziceau si alti oameni, vezi la disk, ca e ceva in neregula. daca faci delivery local, vezi daca te ajuta sa treci la Maildir/. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/11 Petru Ratiu rpe...@gmail.com 2012/1/11 Adrian Popa adrian.popa...@gmail.com: În maillog scrie cam 100M la 1-2 zile. Cum verific dacă scrie sincronizat sau nu? Nu am găsit referințe legate de sync nici în syslog nici în postfx. O să încerc cu mai puțin logging pe moment. Syslogd-urile in principiu au o optiune speciala sa faca fsync (in sysklogd era cu -, in altele nu mai stiu pe de rost). Cel mai sanatos imho e sa faci loggingul remote. Da, ai dreptate: You may prefix each entry with the minus ''-'' sign to omit syncing the file after every logging. Note that you might lose information if the system crashes right behind a write attempt. Nevertheless this might give you back some performance, especially if you run programs that use logging in a very verbose manner. Se pare că by default syslogd-ul le scria în mod sincron. Am dezactivat acum asta pentru majoritatea log-urilor. Vedem dacă crește performanța... Acu daca stau si ma uit atent la mailul tau initial, n-ai zis in ce anume faci livrarea locala (in main.cf-ul ala scrie cate in luna si in stele, da' despre local cam putin). De notat ca local_destination_concurrency_limit nu e foarte sanatos sa-l faci asa mare, e pus in mod normal la 1-2 ca sa se poata serializa corect in caz ca ai sieve sau procmail. Mailurile merg în /home/user/Maildir. De acolo le citesc mai departe cu un dovecot. local_destination_concurrency_limit l-am crescut într-o tentativă orbească de a crește performanța - crezând că acolo e bottleneck-ul. Sistemul e un smtp chior, fără antivirus/antispam sau alte prelucrări. Ar trebui doar să expandeze alias-urile și să scrie în maildir. M-am uitat un pic și pe dimensiunea directoarelor din maildir - să nu fie overhead mare la crearea fișierelor noi în directoare cu nr mare de entry-uri, dar nu sunt (încă) foarte mari: [root@raptor Maildir]# ls -ld cur new tmp drwx-- 2 user user 94208 Jan 11 13:40 cur drwx-- 2 user user 61440 Jan 11 13:42 new drwx-- 2 user user 4096 Jan 11 13:42 tmp Altfel, masina in ce sta, ai iowait mare la MDA (care o fi el), ai lookupuri in db care se agata, etc? O să verific iowait data viitoare când sunt lovit de un val de e-mailuri. L-aș vedea cu ps -aux | grep D , nu? Sau am o variantă mai eficientă? DUninterruptible sleep (usually IO) Nu am o bază de date în care să facă lookup. Userii sunt locali (old school). Thanks -- Petre, compilat cu --without-mafalda ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
On 11.01.2012 13:51, Adrian Popa wrote: O să verific iowait data viitoare când sunt lovit de un val de e-mailuri. baga si un munin ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
Quoting Vlad Georgescu v...@lsi.ro: On 11.01.2012 13:51, Adrian Popa wrote: O s? verific iowait data viitoare când sunt lovit de un val de e-mailuri. baga si un munin si monteaza partitia unde se varsa log-le, si unde ai Inbox-ul cu noatime ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug This message was sent using IMP, the Internet Messaging Program. pgpBjL2eoYx0u.pgp Description: PGP Digital Signature ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/11 Adrian Popa adrian.popa...@gmail.com 2012/1/11 Petru Ratiu rpe...@gmail.com 2012/1/11 Adrian Popa adrian.popa...@gmail.com: În maillog scrie cam 100M la 1-2 zile. Cum verific dacă scrie sincronizat sau nu? Nu am găsit referințe legate de sync nici în syslog nici în postfx. O să încerc cu mai puțin logging pe moment. Syslogd-urile in principiu au o optiune speciala sa faca fsync (in sysklogd era cu -, in altele nu mai stiu pe de rost). Cel mai sanatos imho e sa faci loggingul remote. Da, ai dreptate: You may prefix each entry with the minus ''-'' sign to omit syncing the file after every logging. Note that you might lose information if the system crashes right behind a write attempt. Nevertheless this might give you back some performance, especially if you run programs that use logging in a very verbose manner. Se pare că by default syslogd-ul le scria în mod sincron. Am dezactivat acum asta pentru majoritatea log-urilor. Vedem dacă crește performanța... Acu daca stau si ma uit atent la mailul tau initial, n-ai zis in ce anume faci livrarea locala (in main.cf-ul ala scrie cate in luna si in stele, da' despre local cam putin). De notat ca local_destination_concurrency_limit nu e foarte sanatos sa-l faci asa mare, e pus in mod normal la 1-2 ca sa se poata serializa corect in caz ca ai sieve sau procmail. Mailurile merg în /home/user/Maildir. De acolo le citesc mai departe cu un dovecot. local_destination_concurrency_limit l-am crescut într-o tentativă orbească de a crește performanța - crezând că acolo e bottleneck-ul. Sistemul e un smtp chior, fără antivirus/antispam sau alte prelucrări. Ar trebui doar să expandeze alias-urile și să scrie în maildir. M-am uitat un pic și pe dimensiunea directoarelor din maildir - să nu fie overhead mare la crearea fișierelor noi în directoare cu nr mare de entry-uri, dar nu sunt (încă) foarte mari: [root@raptor Maildir]# ls -ld cur new tmp drwx-- 2 user user 94208 Jan 11 13:40 cur drwx-- 2 user user 61440 Jan 11 13:42 new drwx-- 2 user user 4096 Jan 11 13:42 tmp Altfel, masina in ce sta, ai iowait mare la MDA (care o fi el), ai lookupuri in db care se agata, etc? O să verific iowait data viitoare când sunt lovit de un val de e-mailuri. L-aș vedea cu ps -aux | grep D , nu? Sau am o variantă mai eficientă? DUninterruptible sleep (usually IO) io verifici cu iostat, de ex.: $ iostat -x -d 1 Linux 2.6.18-274.7.1.el5 (zero.it-acces.ro) 01/11/2012 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.18 6.81 0.57 5.5625.9999.0620.37 0.15 23.92 2.58 1.58 sda1 0.12 6.81 0.57 5.5617.2899.0618.98 0.15 23.86 2.56 1.57 sda2 0.06 0.00 0.01 0.00 8.71 0.00 964.84 0.00 67.34 16.64 0.02 daca %util e in jur de 100% ai disk-urile saturate cu I/O. await/svctm iti arata in milisecunde average wait pentru IO servicing (man iostat). poti sa vezi cu dstat / vmstat incarcarea disk/cpu corelat. singura chestie care nu o poti dezactiva e ca postfix sa nu faca fsync dupa fiecare fisier trimis, chestie care papa destul de mult I/O. Nu am o bază de date în care să facă lookup. Userii sunt locali (old school). Thanks -- Petre, compilat cu --without-mafalda ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
On 01/11/2012 02:36 PM, Catalin Muresan wrote: singura chestie care nu o poti dezactiva e ca postfix sa nu faca fsync dupa fiecare fisier trimis, chestie care papa destul de mult I/O. Sa-i cintam ia-ti raid hardware cu baterie? -- Dan Borlovan Datagroup-Int ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/11 Dan Borlovan d...@level7.ro: On 01/11/2012 02:36 PM, Catalin Muresan wrote: singura chestie care nu o poti dezactiva e ca postfix sa nu faca fsync dupa fiecare fisier trimis, chestie care papa destul de mult I/O. Sa-i cintam ia-ti raid hardware cu baterie? Daca-i raid, sa fie zero!!11 Acu serios, sa nu te puna pacatul sa te dedulcesti la fsyncurile pe care le face la coada and stuff daca nu vrei sa dai explicatii despre mailuri pierdute -- Petre, care a reusit saptamana trecuta sa trimita in /dev/spoof! vreo 80k de mailuri din condei, tot din tunarit postfixuri ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/11 Petru Ratiu rpe...@gmail.com 2012/1/11 Dan Borlovan d...@level7.ro: On 01/11/2012 02:36 PM, Catalin Muresan wrote: singura chestie care nu o poti dezactiva e ca postfix sa nu faca fsync dupa fiecare fisier trimis, chestie care papa destul de mult I/O. Sa-i cintam ia-ti raid hardware cu baterie? Daca-i raid, sa fie zero!!11 Acu serios, sa nu te puna pacatul sa te dedulcesti la fsyncurile pe care le face la coada and stuff daca nu vrei sa dai explicatii despre mailuri pierdute De ce ar pierde mailuri dacă nu face sync? Cu excepția unui crash de aplicație sau de sistem de operare, datele s-ar ține într-un buffer, nu? Presupun că bufferul ăsta e suficient de inteligent implementat (ca un sistem cache pentru disc) astfel încât orice operații ulterioare pe fișier (open/read) să se facă ținând cont de datele non-flushed din buffer, deci ar fi transparent pentru utilizator. O să încerc să extrag mai multe date despre io data viitoare când se va întâmpla și o să revin cu alte detalii. Mulțumesc. -- Petre, care a reusit saptamana trecuta sa trimita in /dev/spoof! vreo 80k de mailuri din condei, tot din tunarit postfixuri ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
Acu serios, sa nu te puna pacatul sa te dedulcesti la fsyncurile pe care le face la coada and stuff daca nu vrei sa dai explicatii despre mailuri pierdute De ce ar pierde mailuri dacă nu face sync? Cu excepția unui crash de aplicație sau de sistem de operare, datele s-ar ține într-un buffer, nu? And these things never happen, right? -- Petre sunt doua tipuri de admini: cei care au pierdut date si cei care n-au pierdut date... inca ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
On 1/11/2012 1:30 PM, Petru Ratiu wrote: 2012/1/11 Adrian Popaadrian.popa...@gmail.com: În maillog scrie cam 100M la 1-2 zile. Cum verific dacă scrie sincronizat sau nu? Nu am găsit referințe legate de sync nici în syslog nici în postfx. O să încerc cu mai puțin logging pe moment. Syslogd-urile in principiu au o optiune speciala sa faca fsync (in sysklogd era cu -, in altele nu mai stiu pe de rost). Cel mai sanatos imho e sa faci loggingul remote. Pe langa trimis log-urile remote si tunning de postfix, muta si cozile postfix-ului intr-un ramdisk. sr ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/11 Serghei Gutanu s...@gutanu.ro: On 1/11/2012 1:30 PM, Petru Ratiu wrote: 2012/1/11 Adrian Popaadrian.popa...@gmail.com: În maillog scrie cam 100M la 1-2 zile. Cum verific dacă scrie sincronizat sau nu? Nu am găsit referințe legate de sync nici în syslog nici în postfx. O să încerc cu mai puțin logging pe moment. Syslogd-urile in principiu au o optiune speciala sa faca fsync (in sysklogd era cu -, in altele nu mai stiu pe de rost). Cel mai sanatos imho e sa faci loggingul remote. Pe langa trimis log-urile remote si tunning de postfix, muta si cozile postfix-ului intr-un ramdisk. Doua, in raid 0, sa mearga mai repede! Wtf, ati innebunit? Mai bine faci livrare direct in /dev/null, stii o treaba. -- Petre. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/12 Serghei Gutanu s...@gutanu.ro On 1/11/2012 1:30 PM, Petru Ratiu wrote: 2012/1/11 Adrian Popaadrian.popa...@gmail.com: În maillog scrie cam 100M la 1-2 zile. Cum verific dacă scrie sincronizat sau nu? Nu am găsit referințe legate de sync nici în syslog nici în postfx. O să încerc cu mai puțin logging pe moment. Syslogd-urile in principiu au o optiune speciala sa faca fsync (in sysklogd era cu -, in altele nu mai stiu pe de rost). Cel mai sanatos imho e sa faci loggingul remote. Pe langa trimis log-urile remote si tunning de postfix, muta si cozile postfix-ului intr-un ramdisk. Si maildir-urile tot in ramdisk. -- Adi Pircalabu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/11 Adi Pircalabu apircal...@gmail.com: 2012/1/12 Serghei Gutanu s...@gutanu.ro On 1/11/2012 1:30 PM, Petru Ratiu wrote: 2012/1/11 Adrian Popaadrian.popa...@gmail.com: În maillog scrie cam 100M la 1-2 zile. Cum verific dacă scrie sincronizat sau nu? Nu am găsit referințe legate de sync nici în syslog nici în postfx. O să încerc cu mai puțin logging pe moment. Syslogd-urile in principiu au o optiune speciala sa faca fsync (in sysklogd era cu -, in altele nu mai stiu pe de rost). Cel mai sanatos imho e sa faci loggingul remote. Pe langa trimis log-urile remote si tunning de postfix, muta si cozile postfix-ului intr-un ramdisk. Si maildir-urile tot in ramdisk. Si ramdisku'n cloud! Bingo! -- Petre Godwin 2.0 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
On 1/11/2012 4:12 PM, Petru Ratiu wrote: Pe langa trimis log-urile remote si tunning de postfix, muta si cozile postfix-ului intr-un ramdisk. Doua, in raid 0, sa mearga mai repede! Wtf, ati innebunit? Mai bine faci livrare direct in /dev/null, stii o treaba. Acum depinde cat de mare e toleranta pentru a pierde X mail-uri din coada la momentul t. Daca-i zero, atunci intr-adevar nu-i o solutie. sr ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
On 11.01.2012 15:19, Petru Ratiu wrote: Si ramdisku'n cloud! Bingo! pentru un adevarat sentiment de (falsa) securitate, sa poti dormi noaptea ii faci si backup la fiecare 10 minute :))) si atunci poti sa il ridici oficial la rangul de pseudo-persistent RAM disk...in GOD we trust, the power company gives us the headaches :- Why the flock isn't it Friday yet? http://www.google.com/patents/US5241508 misu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
Nu mi se pare chiar așa de rea ideea mutării cozilor în ramdisk, doar ca nu știu dacă mă ajută ca performanță că presupun că bottleneck-ul e la scrierea unui singur mail în ~30 de Maildir-uri, nu mutatul din incoming în active... Până la urmă e un mv, nu un cp, deci sunt acțiuni doar la nivel de metadate de filesystem, nu se accesează contentul... O să văd la următorul sughiț dacă îmi dau seama care procese sunt starv-ate de IO... ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/11 Adrian Popa adrian.popa...@gmail.com Nu mi se pare chiar așa de rea ideea mutării cozilor în ramdisk Tu chiar n-ai citit ce-a zis Petre mai sus, nu? :) -- Ave http://flying.prwave.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Optimizare delivery local postfix
2012/1/11 Andrei Pascal avpas...@gmail.com 2012/1/11 Adrian Popa adrian.popa...@gmail.com Nu mi se pare chiar așa de rea ideea mutării cozilor în ramdisk Tu chiar n-ai citit ce-a zis Petre mai sus, nu? :) Ba da, dar serverul are destulă redundanță cât să nu fie o problemă chiar așa de rea. Oricum, când se umple coada, politica e mai bine pierdem alarmele vechi decât pe cele noi, așa ca nu ar fi o tragedie daca am mai pierde din mailuri... Ce-i drept, nu ar fi chiar ok într-un mediu unde mailurile sunt critice, dar nu e cazul meu... -- Ave http://flying.prwave.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
