abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
dnes 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 1
dnes 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 0
dnes 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 1
dnes 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 1
včera 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 9
včera 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
včera 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
16.10. 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 1
16.10. 22:44 | Komunita

Greg Kroah-Hartman informuje na svém blogu, že do zdrojových kódu linuxového jádra bylo přidáno (commit) prohlášení Linux Kernel Enforcement Statement. Zdrojové kódy Linuxu jsou k dispozici pod licencí GPL-2.0. Prohlášení přidává ustanovení z GPL-3.0. Cílem je chránit Linux před patentovými trolly, viz například problém s bývalým vedoucím týmu Netfilter Patrickem McHardym. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (18%)
 (0%)
 (0%)
 (3%)
 (71%)
 (8%)
Celkem 38 hlasů
 Komentářů: 1, poslední dnes 11:21
    Rozcestník

    Stavíme poštovní server – 17 (Další ladění konfigurace)

    19. 4. 2010 | Lukáš Jelínek | Sítě | 10433×

    Další ladění konfigurace

    link

    Na výkon má vliv řada konfiguračních parametrů. Velmi záleží na tom, kde je konkrétně problém s výkonem (ve které části serveru) a který systémový prostředek, resp. jeho nedostatek, problémy způsobuje.

    Další popis se bude týkat výhradně Postfixu. V praxi se však velmi často stává, že úzké hrdlo není Postfix, nýbrž jiná součást serverového řešení, typicky třeba Spamassassin nebo ClamAV. V takových případech je potřeba soustředit se právě na tyto další programy a upravit jejich konfiguraci, případně se poohlédnout po jejich méně náročných alternativách.

    Existuje více systémových prostředků, kterých se může při provozu serveru nedostávat. Je to především procesor, operační paměť, přenosové pásmo pro komunikaci s úložištěm (diskem) a přenosové pásmo pro síťovou komunikaci. V některých případech může být takový zdroj například i DNS server, vzdálená databáze nebo LDAP server.

    Procesor

    link

    Procesor bývá pro holý Postfix (bez dalších programů) málokdy nedostatkový zdroj. Většina operací s poštou je nenáročná. Větší zátěž se objevuje jen v případech, kdy se provádí složitější analýza těla zpráv nebo při šifrování komunikace (TLS). Na tyto věci je tedy potřeba se primárně zaměřit. Není-li potřeba TLS, lze ho vypnout (přinejmenším pro směr ven, aby to nemělo dopady na klienty nastavené natvrdo tak, že ho používají) a ušetřit tím nemalé množství procesorového času.

    Dále se mohou objevit problémy při velkém množství otevřených relací (jak u příchozí, tak u odchozí pošty), na kterých probíhá komunikace. Systém je tak nucen k velmi častému přepínání kontextu a roste vlastní režie systému. Velmi záleží na tom, jak se s tím vyrovná jádro systému – například u Linuxu verzí 2.4 (občas ho lze ještě na serverech potkat) to bylo dost nepříznivé, protože operační složitost plánování běhu úloh byla lineární (u jader 2.6 byl zaveden nový plánovač s konstantní složitostí; plánovač CFS, který je v Linuxu od jádra 2.6.23, má složitost přibližně logaritmickou). Dalším faktorem je počet procesorů či jejich jader.

    Pokud se tedy vyskytuje situace, že má Postfix trvale problémy s nedostatkem procesorového výkonu (projevují se vytížením všech procesorů/jader procesy Postfixu, dlouhou prodlevou při příjmu zpráv apod.), je v první řadě potřeba zjistit, čím je to způsobeno. Pokud se využívají složitá pravidla pro analýzu těla zpráv, je vhodné zvážit jejich smysl a případně přesunout celou analýzu do Spamassassinu nebo jiného podobného programu, pokud se používá. Totéž se týká i analýzy hlaviček.

    Je-li příčinou vysoký počet současně otevřených relací, lze jejich počet omezit. Je třeba to dělat primárně na odchozí straně (kde to způsobí jen případné zvětšení zpoždění zpráv; omezování příchozích relací má vždy za následek odmítání klientů).

    Ve výchozím nastavení vytvoří řídicí proces master maximálně 100 procesů pro určitou službu. Pokud je počet procesů služby smtp nízký (výrazně nižší než uvedený limit), nemá smysl ho dále omezovat. Pokud se ale k této hodnotě blíží nebo ji případně dosahuje, lze hodnotu snížit například na 50 a sledovat, jak se chování systému změní. Změna může vypadat takto (v souboru master.cf – ostatní řádky se nemění):

    smtp      unix  –       –       –       –       50       smtp
    

    Pokud je zásah úspěšný (uvedená hodnota samozřejmě není dogma – vhodnou lze nejlépe najít testováním), je potřeba kontrolovat, zda se ve frontách nehromadí zprávy. Může se totiž stát, že je potřeba doručovat na mnoho serverů současně a proto se limit procesů vyčerpá. Pro sledování stavu fronty, zejména počtu zpráv čekajících na doručení do určité domény a časové distribuce doby čekání, lze s výhodou použít nástroj qshape – podrobné informace o jeho použití najdete v manuálu (qshape(1)) a v dokumentaci k Postfixu.

    Jedno z možných řešení situací, kdy se zprávy hromadí ve frontách, je omezit počet současného doručování do téže domény. Server totiž normálně může vytvořit pro určitou doménu více relací současně (standardně až 20) a doručovat paralelně. To může zrychlit doručení, protože někdy poštu pro doménu přijímá více serverů, ale také to spotřebuje více procesů. Je-li zbytečná spotřeba procesů nežádoucí, lze souběžné doručování omezit (v main.cf):

    smtp_destination_concurrency_limit = 2
    

    Uvedený řádek zajistí, že se nebude doručovat ve více než dvou souběžných relacích pro tutéž doménu. Rychlejšímu vyprazdňování front to pomůže jen v případech, kdy se doručuje do relativně malého počtu domén, ale do každé směřuje hodně zpráv. Opět je potřeba důkladně otestovat chování a vyzkoušet více různých hodnot.

    Paměť

    link

    Podobně jako v případě procesoru, Postfix je velmi nenáročný i na paměť. Dá se říci, že nejvíce paměti se spotřebuje pro diskovou cache, nikoli pro vlastní data nebo programový kód. Pro případy nedostatku fyzické paměti (systém se dostává do stavu, kdy je paměti málo – musí proto odkládat paměťové stránky na disk a omezovat diskovou cache) platí prakticky totéž jako pro problémy s procesory. Omezení počtu relací směrem ven sníží paměťové nároky Postfixu.

    Disk

    link

    Pomalost disku nebo diskového pole je svízelná. Často brzdí celý zbytek serveru, který většinu času čeká na dokončení diskových operací. Řešení (bez instalace lepšího hardwaru) může situaci obvykle jen částečně zlepšit.

    Pokud je problém v tom, že je diskové úložiště nejen pomalé, ale že také často dochází k odkládání paměťových stránek kvůli nedostatku fyzické paměti, je první potřebný krok snížení paměťových nároků (viz výše). Toto ovšem pomůže i v případě, že nedochání k odkládání, resp. že odkládací prostor není vůbec použit. Důvod samozřejmě je, že čím větší je disková cache v operační paměti, tím menší množství dat je třeba přenést mezi pamětí a diskem.

    Síť

    link

    Problém s nedostatečně rychlou sítí (typicky s internetovým připojením, například s připojením firemní sítě, kde je server umístěn) není spjat přímo s konkrétním softwarem (tj. v tomto případě Postfixem), nýbrž je zcela obecný. Nicméně vhodnou konfigurací lze zátěž snížit, byť samozřejmě za cenu určitých kompromisů.

    V první řadě lze vypnout kontroly podle vzdálených blacklistů – ať se již používají přímo v Postfixu (například v parametru smtpd_client_restrictions) nebo prostřednictvím Spamassassinu. Sníží to poněkud účinnost antispamové ochrany, někdy je to ale relativně malá cena za lepší propustnost síťového připojení.

    Další možnost je eliminovat nadbytečné DNS dotazy. Lze si na stroji dostupném rychlým spojem (v lokální síti) spustit cachující DNS server a nastavit si DNS resolver (standardně v /etc/resolv.conf) tak, aby dotazy posílal na něj. Případně lze tento server spustit i přímo na stroji, kde běží Postfix, i když to není příliš čisté řešení.

    Nelze-li použít podobné řešení, je ještě možnost vypnout DNS dotazy pro klienty. Zajistí se to tímto nastavením:

    smtpd_peername_lookup = no
    

    Tato volba bude mít za následek, že se v logu serveru a v hlavičkách Received ve zprávách objeví u klientů pouze IP adresa, místo názvu bude „unknown“. Při určitém nastavení antispamové ochrany (například při použití pravidel whitelist_from_rcvd nebo def_whitelist_from_rcvd v programu Spamassassin) to však má mírný vliv na přesnost antispamové ochrany.

    Jinak pro síť platí opět totéž jako pro procesor a paměť. Snížením počtu souběžných odchozích relací se zátěž sítě sníží (projeví se to zejména na asymetrických komunikačních spojích, kde je odchozí směr výrazně pomalejší než příchozí).

    Ostatní

    link

    Do kategorie „ostatní“ patří všechno to, co nešlo přímo zařadit do předchozích kategorií. Jedná se zejména o externí zdroje dat, které mohou být brzdou například proto, že je zatěžují (kromě poštovního serveru) i další odběratelé informací.

    Nejčastěji je problém s databází uživatelů, schránek a aliasů. Cílem pak je, aby se se vzdáleným zdrojem (typicky databází nebo serverem LDAP) komunikovalo co nejúsporněji a nejefektivněji.

    Značná část zde spadá do působnosti programu Dovecot, který Postfixu slouží jako autentizační rozhraní. O tom bude ale řeč až příště, proto následující odstavce budou věnovány pouze tomu, co souvisí výhradně s Postfixem.

    Základem je zjišťovat ze vzdáleného zdroje co nejméně informací. Zejména není třeba zjišťovat nic, co může být přímo součást konfigurace, protože jde o údaje nedílně spjaté s instalací na konkrétním serveru. Příkladem jsou třeba identifikátory uživatele a skupiny (virtual_uid_maps, virtual_gid_maps) v klasickém případě, kdy jsou pevně dány. Podobně například cestu k domovskému adresáři lze často sestavit přímo z adresy příjemce a není nutné ji získávat databázovým dotazem.

    Dále je potřeba, aby byla databáze (nebo obecně jakýkoli datový zdroj) kvalitně navržena a aby byly vhodně konstruovány i dotazy. Někdy je to problém, protože dotazy směřují do již existující databáze, ale i tam lze často udělat mnoho pro zrychlení přístupu – například vytvořením indexů.

    Pokud si vzpomenete na sedmý díl seriálu, určitě vás napadne další zajímavá možnost, jak zrychlit přístup – využít službu proxymap. Tady je ale důležité to, jakým způsobem služba proxymap funguje. Zrychlí funkci jen v případě, že je problémem velký počet současných připojení (naráží se na limit nebo je problém se spotřebou paměti databázovým serverem). V opačném případě může být komunikace naopak pomalejší, protože proxymap veškeré přístupy serializuje – řadí je za sebe a tím brání lepšímu časovému využití komunikačního kanálu.

    Je-li zdrojem dat databáze, lze si udržovat lokální on-line replikovanou verzi, samozřejmě pokud to databáze umožňuje (což například MySQL standardně ano). Veškeré dotazy se provádějí jen na této lokální kopii, bez nutnosti odesílat a přijímat nějaká vzdálená data. Data se přenášejí jen při změnách v hlavní databázi (master) na tuto kopii.

    Optimalizace konfigurace programu Dovecot

    link

    To by bylo ohledně optimalizace (beze změny architektury) Postfixu téměř vše. Ne však úplně vše, protože příští díl bude věnován optimalizaci konfigurace programu Dovecot, kde se řada úprav nepřímo dotkne i programu Postfix.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    19.4.2010 10:54 ch-in-A
    Rozbalit Rozbalit vše vyborny, clanek!
    vyborny, clanek/serial! diky
    Josef Kufner avatar 19.4.2010 15:52 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: vyborny, clanek!
    +1

    Chtělo by to ještě pár dílů o nějakých pěkných specialitkách. Třeba jak na virtuální imap složky v dovecotu a podobné věci (trošu jsem je oťukával, ale moc to nefungovalo).
    Hello world ! Segmentation fault (core dumped)
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.