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

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

• Další ladění konfigurace
  • Procesor
  • Paměť
  • Disk
  • Síť
  • Ostatní
• Optimalizace konfigurace programu Dovecot

Další ladění konfigurace

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

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ěť

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

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íť

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í

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

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.

       

Komentáře

[ch-in-A]

vyborny, clanek/serial! diky

[Josef Kufner]

+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).