Po po téměř roce vývoje od vydání verze 5.38 byla vydána nová stabilní verze 5.40 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 75 vývojářů. Změněno bylo přibližně 160 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Po dvou měsících vývoje byla vydána nová verze 0.13.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 73 vývojářů. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
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 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.
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.
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.
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í).
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.
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.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
19.4.2010 15:52