Kontakty
IBSurgeon
Tato stránka byla strojově přeložena. Přečtěte si anglický originál. English

Knihovna IBSurgeon

23 dalších způsobů, jak zrychlit Firebird

Alexey Kovyazin, IBSurgeon, [email protected], 08-Jan-2019

Překlady: Portugalsky

Proč “23 dalších”?

Někteří z vás si pamatují článek « 45 způsobů, jak zrychlit Firebird», který byl publikován v květnu 2016. Nyní je čas publikovat další sérii tipů a triků, založených převážně na zkušenostech s optimalizací a údržbou databází Firebird a serverů s vysokým počtem připojení (1000+).

1. Nastavte Možnosti napájení na Vysoký výkon v Windows Server 2016 a 2019

Ve výchozím nastavení má Windows Server plán napájení nastaven na “Vyvážený”, což není vhodné pro databázové servery. Nastavte jej na “Vysoký výkon” a získáte přibližně +20% výkonu pro operace náročné na CPU. Lze jej nastavit online, bez restartu nebo rebootu. Obrázek níže ukazuje graf CPU, který demonstruje výhodu plánu napájení “Vysoký výkon”:

Více podrobností o našich testech s plány napájení Windows naleznete zde.

2. Povolte «Interakci s plochou» pro Classic na Windows

Pokud používáte Firebird s architekturou Classic na Windows, zaškrtněte volbu «Povolit službě interakci s plochou». Bez tohoto nastavení je prostředek «desktop heap» omezen systémem Windows a Firebird nemůže otevřít více než 250-300 připojení (závisí na metadatech databáze a související spotřebě paměti) - dojde k chybě Out Of Memory.

3. Pozor: Domain Controller

Problém, že Windows s rolí Domain Controller zakáže zápisovou mezipaměť na disku s databází Active Directory.

To ovlivňuje Firebird různými způsoby (stejně jako samozřejmě i jiné aplikace) a projevuje se to výrazně horším výkonem než na serverech bez rolí Active Directory.

Upozorňujeme, že tento problém se týká takových populárních verzí Windows jako Windows Small Business Server 2011, stejně jako dalších verzí s DC.

4. Zvyšte limit «max open files» na Linuxu

Pokud používáte Linux jako databázový server, nezapomeňte upravit limity pro Firebird. Zkontrolujte limity pro váš proces Firebird (SuperServer nebo SuperClassic) následujícím příkazem:

Code 
cat /proc//limits

a věnujte pozornost řádku s maximálním počtem otevřených souborů.

Firebird může používat až 4 handly na jedno připojení, a pokud vidíte něco jako:

Code 
Max open files 4096 4096 files

znamená to, že celkový počet připojení obsluhovaných procesem Firebird bude omezen na přibližně 1000.

Upozorňujeme - pokud máte na serveru 4 databáze, připojení pro každou databázi se počítá zvlášť.

Nastavte více - doporučuji 65535.

Nezapomeňte znovu zkontrolovat po restartu procesu Firebird, zda bylo nastavení aplikováno nebo ne.

Pro architekturu Classic je nutné zkontrolovat a zvýšit limity pro uživatele «firebird».

5. Používejte moderní Linux

Ano, chápu, že tato rada je triviální, ale mnohokrát jsem viděl výrazné zlepšení výkonu po migraci z CentOS 6 na 7, Ubuntu 12 na 16 (na stejném hardwaru!), takže nyní je to povinné doporučení pro databázové servery s více než 250-300 připojeními. Moderní Linux je předpokladem pro další optimalizační kroky.

Doporučené verze Linuxu: CentOS 7.x a Ubuntu 16, 18.

6. Rezervujte 40% RAM pro souborovou mezipaměť na Windows

Správce paměti OS má důsledky týkající se alokace paměti a ve výchozím nastavení Windows vyžaduje 40% RAM pro souborovou mezipaměť.

Bohužel, nedokonalý nástroj Windows Task Manager zobrazuje paměť, která se používá pro souborovou mezipaměť, jako «volnou», a někteří administrátoři se snaží, aby Firebird spotřeboval veškerou tuto volnou paměť, takže nastaví parametr DefaultDBCachePage v firebird.conf na velmi vysoké hodnoty, což obvykle vede ke swapování.

Vždy používejte nástroj RAMMap pro zobrazení skutečného využití paměti na Windows.

Empirické pravidlo pro Windows Server (vyhrazený pro použití jako Firebird server) je následující: paměť Firebird (Working Set) by měla být menší než 40% celkové RAM. Pokud je celková velikost pracovních sad všech procesů větší než 50%, může Windows spustit swap.

Upozorňujeme: “rezervovat” zde znamená nejen “nenastavovat příliš mnoho page bufferů ve Firebirdu”, ale také, což je důležité, omezit využití paměti jiným softwarem. Například, pokud máte MS Exchange nebo MSSQL na stejném serveru jako Firebird, ujistěte se, že omezíte jejich paměťové apetity.

Pokud vás zajímají podrobnosti, nahrál jsem webinář věnovaný správě paměti ve Firebirdu:

7. Rezervujte 30% RAM pro souborovou mezipaměť na Linuxu

Linux pracuje se souborovou mezipamětí jiným způsobem než Windows a obecně může být množství RAM použité pro souborovou mezipaměť výrazně menší než na Windows, bez znatelné degradace výkonu Firebirdu. Nicméně, pro zaručení vysokého výkonu systému s vysokým počtem připojení, zejména na Classic a SuperClassic, je dobrý nápad rezervovat 30% RAM pro souborovou mezipaměť.

8. Používejte irqbalance na Linuxu

irqbalance často zlepšuje výkon Firebirdu a vyvážení zátěže CPU na serverech s vysokým počtem jader.

9. Pro virtuální stroje - pozor na Memory Overcommit

Virtuální stroj může být nakonfigurován tak, aby měl více paměti, než fyzicky existuje na hostitelském stroji - pomocí funkce známé jako Memory Overcommit (název se může lišit v různých virtualizačních systémech). To znamená, že v případě špičky spotřeby paměti (na VM s databázovým serverem nebo na sousedním VM) může začít swap, což povede k výrazným zpožděním. Pro vysoce výkonný VM určený pro databázový server by měla být veškerá paměť statická.

10. Pro virtuální stroje - zkontrolujte limity VM

Často jsou VM vytvářeny s výchozími limity CPU a IO, které mohou být velmi nízké, jako 50 IOPS a 10% CPU. Zkontrolujte nastavení vašeho serverového VM a odstraňte všechny limity - vysoce výkonný databázový server by měl mít veškerý možný CPU, šířku pásma a IO.

11. Vyčistěte dočasné soubory Firebirdu

Firebird vytváří mnoho dočasných souborů pro různé operace: třídění, zpracování BLOB, trasování. Tyto soubory jsou uloženy na následujících místech: na Windows C:\ProgramData\firebird, na Linuxu / tmp / firebird

Normálně by tyto soubory měly být čištěny automaticky, ale někdy se to nestane (například v případě restartu serveru).

Pravidelně kontrolujte tyto složky a čistěte staré soubory - může tam být mnoho GB zastaralých souborů fb_NNN a jejich vyčištění uvolní místo na systémovém disku.

12. Nezapomeňte povolit souborovou mezipaměť s velkou mezipamětí Firebirdu

Jak víte, mezipaměť Firebirdu (nazývaná také «page buffers») je specifikována parametrem DefaultDBCachePages v firebird.conf/databases.conf, nebo přímo v hlavičce databáze.

Ve Firebirdu 3 SuperServer může být velikost této mezipaměti nastavena velmi vysoko, ale je důležité pamatovat na další parametr: FileSystemCacheThreshold.

Pokud je FileSystemCacheThreshold menší než DefaultDBCachePages nebo page buffers, nebude použita souborová mezipaměť operačního systému, což může vést k problémům s výkonem.

V 99% případů je lepší mít souborovou mezipaměť povolenou.

Pro zajištění toho vždy nastavte parametry podle následujícího pravidla:

  • DefaultDBCachePages = X
  • FileSystemCacheThreshold = X+ N, N>1

Existují vzácné případy, kdy vypnutí souborové mezipaměti zlepší výkon - pokud máte takový příklad, kontaktujte mě prosím - [email protected]!

13. Zrychlete bezpečnostní databázi

Každé připojení k databázi Firebird navazuje připojení k bezpečnostní databázi (security3.fdb v případě Firebirdu 3) a provádí několik čtení a zápisů (transakční stránky, hlavičková stránka). Pokud máte častá připojení, může se výkon vaší bezpečnostní databáze stát problémem.

Minimálně můžete udělat následující:

  • Zvyšte page buffers pro securityN.fdb (empirické optimum je 256 bufferů)
  • Přesuňte security3.fdb na rychlý disk (ve Firebirdu 3 je to standardní funkce, ve 2.5 bude vyžadovat přeinstalaci)

Poté můžete nastavit Forced Writes OFF pro bezpečnostní databázi - malá šance poškození v tomto případě není problém.

Nejradikálnějším způsobem je nastavit bezpečnostní databázi jako pouze pro čtení - eliminuje to všechny zápisy do ní.

Pokud často neměníte uživatele v bezpečnostní databázi, je to nejlepší řešení.

14. Vyzkoušejte SuperClassic na Firebirdu 3

Ve Firebirdu 3 byla architektura SuperServer silně propagována jako ultimátní řešení výkonu, ale existují některé typy zátěže, které vykazují lepší výkon se SuperClassic (ale ne Classic - ten vždy pracuje pomaleji než SuperServer/SuperClassic).

Jak provést tento experiment bezpečným způsobem? Postupujte podle následujících kroků:

Pro vyzkoušení SuperClassic

  1. Nastavte v firebird.conf
  2. ServerMode=SuperClassic
  3. DefaultDbCachePages=1024
  4. gfix -buff 0
  5. Restartujte Firebird

Pro návrat k SuperServer

  1. Nastavte v firebird.conf
  2. ServerMode=SuperServer
  3. DefaultDbCachePages=N # N*velikost stránky*počet_databází < 25% RAM
  4. FileSystemCacheThreshold = N+1
  5. gfix -buff 0
  6. Restartujte Firebird

Napište mi prosím ([email protected]) o výsledcích experimentu, zajímá mě vidět výsledky.

15. Velká databáze? Zvyšte velikost stránky

Ve výchozím nastavení mají databáze Firebird následující velikosti stránek:

  • 2.5 - 4096 bajtů
  • 3.0 - 8192 bajtů

Maximální velikost stránky je však 16K (ve 4.0 - 32K).

Pro databáze větší než 100Gb je v 95% případů lepší mít nejvyšší dostupnou velikost stránky, aby se:

  • Snížila hloubka indexů. Doporučuje se mít indexy s hloubkou menší nebo rovnou 3. Indexy s hloubkou 4 a 5 budou mnohem pomalejší
  • Zvýšilo využití RAM. Mezipaměť Firebirdu je specifikována ve stránkách, 1000 stránek s velikostí 8K bude 8Mb skutečné paměti a s 16K - 16Mb.
  • Snížil počet systémových stránek. To zrychlí přístup k záznamům velkých tabulek (méně skoků ukazatel-ukazatel-datová stránka) a pomáhá při přípravě velkých SQL dotazů. Pro zvýšení velikosti stránky databáze je třeba zálohovat databázi nástrojem gbak a poté obnovit s parametrem -page ( gbak -c -page 16384).

Upozorňujeme: pokud máte databázi s mnoha malými bloby, zvýšení velikosti stránky může buď snížit fragmentaci, nebo zvýšit fragmentaci, a je obtížné předpovědět, zda to zvýší nebo sníží výkon.

16. Nepoužívejte příznak no_reserve

Příznak no_reserve způsobuje, že Firebird nerezervuje volné místo (30%) na datových stránkách pro možné verze záznamů, ke kterým dochází po UPDATE nebo DELETE. Tento příznak umožňuje ukládat data kompaktnějším způsobem (a velikost databáze je také menší), ale v případě UPDATE/DELETE všechny změny jdou na novou datovou stránku. Výsledkem je, že v databázi s příznakem no_reserve jsou operace UPDATE/DELETE pomalejší.

Pokud tedy vaše databáze není pouze pro čtení, doporučuji odstranit příznak no_reserve.

Jak zkontrolovat, zda je nastaven nebo ne - viz řádek Attributes ve výstupu

Code 
gstat -h database

Jak zakázat:

Code 
gfix -use reserve database

Po tomto příkazu budou nové datové stránky vytvářeny s rezervovaným místem.

Pro dosažení plného efektu je však nutné zálohovat databázi pomocí gbak a poté obnovit, v tomto případě budou všechny datové stránky s rezervovaným místem.

Upozorňujeme: velikost databáze se po odstranění no_reserve příznaku a zálohování/obnovení zvětší.

17. Nastavte vysokou počáteční velikost pro zámkovou tabulku Firebirdu

Zámková tabulka je mechanismus Firebirdu, který se používá k synchronizaci přístupu k interním objektům enginu.

Tabulka zámků Firebird může růst automaticky, ale její zvětšování je pomalá operace, která může vést k mikro-zamrznutím. Tabulka zámků může pouze růst, počínaje počáteční velikostí (nastavuje se v firebird.conf).

Aby se předešlo opakovanému zvětšování tabulky zámků, je dobrým nápadem sledovat velikost tabulky zámků na konci pracovního období (den, týden atd.) a poté ji nastavit jako počáteční velikost v firebird.conf.

LockMemSize=99999999

Pro vaši informaci: LockMemSize na systémech s vysokou zátěží s ~1000 uživateli je obvykle pod 200 Mb.

18. Použijte fb_lock_print pro zjištění počtu připojení k databázi

Zjištění počtu připojení k databázi je častým úkolem pro vývojáře databází: může být nutné například pro licenční účely.

Vývojáři často používají dotaz SELECT count(*) FROM MON$ATTACHMENTS pro získání této hodnoty, ale není to optimální způsob: časté dotazy na tabulky MON$ mohou být zátěží pro databázi, takže je lepší použít alternativu:

Spusťte

fb_lock_print -d název_databáze | alias

a zkontrolujte hodnotu Owners - ukáže aktuální počet připojení k databázi.

19. Vyhněte se zbytečným LEFT JOIN

Často vidím dotazy s konstrukcí jako je tato:

T1 LEFT JOIN T2 ON (…) WHERE T2.Field_condition

V podstatě podmínka na T2 vylučuje NULL hodnoty z výstupu LEFT JOIN T2, takže je možné změnit LEFT JOIN na INNER JOIN - neovlivní to výsledek dotazu.

INNER JOIN dává optimalizátoru Firebird více volnosti a v moderních verzích Firebird je optimalizován mnohem lépe než LEFT.

Zvláště to dává smysl v následujících případech:

  • Žádná podmínka pro T1 v klauzuli WHERE
  • T2 je malá tabulka

20. Vyhněte se zbytečnému počítání záznamů

Další častou chybou ve složitých databázových dotazech a uložených procedurách je použití select count() pouze pro kontrolu existence záznamu.

Následující dotaz přečte všechny záznamy podle podmínky1:

Code 
(select count(*)…. where condition11) >0

Lepší je použít tuto konstrukci:

Code 
Exists(select first 1 id where condition1)

Pokud podmínka1 vrací více než 1 záznam, navrhovaná varianta bude mnohem rychlejší, protože nepřečte všechny záznamy, ale zastaví se po prvním načteném záznamu.

21. Vyhněte se zbytečnému řazení v uložených procedurách

Řazení výsledků dotazu uvnitř uložené procedury by mělo být odůvodněno obchodní logikou.

Například v příkladu uložené procedury níže je klauzule ORDER BY zbytečná z hlediska obchodní logiky, ale přidává zbytečnou operaci řazení.

Code 
create or alter procedure NEW_PROCEDURE
returns (
    SUMX double precision)
as
declare variable _amount double precision;
begin
for select T1.amount from Table1 t1 where ....
    order by id
    into :_amount
    do
    begin
     sumx=sumx+_amount
    end;
  suspend;
end

Zkontrolujte svůj PSQL kód na podobné situace a odstraňte zbytečné ORDER BY (stejně jako distinct a UNION).

22. Nedržte dotazy v připraveném stavu bez nutnosti

Často vidíme 500-1000 připravených příkazů v každém připojení (lze to zkontrolovat pomocí dotazů MON$).

Naprostá většina z nich se spustí pouze jednou a pak jen sedí v RAM, čímž zvětšují pracovní sadu Firebird a zpomalují dotazy MON$.

Doporučení je držet SQL dotazy v připraveném stavu pouze tehdy, pokud mají být spouštěny mnohokrát, nebo pokud je jejich doba přípravy velká (může tomu tak být u velmi velkých dotazů s mnoha spojeními a přístupem k obrovským tabulkám).

23. Vždy zavírejte dotazy s velkým řazením

Dokud není SQL dotaz s řazením (ORDER BY, GROUP BY, UNION, distinct) uzavřen, Firebird uchovává seřazené záznamy v paměti. Velikost paměti přidělené pro řazení je nastavena parametrem TempCacheLimit v firebird.conf, ve výchozím nastavení je 64 Mb.

I se zvýšeným TempCacheLimit dlouho běžící dotazy s velkým počtem seřazených záznamů nakonec spotřebují celou přidělenou částku, a v důsledku toho řazení přejde do dočasných souborů (tj. na disk). To může vést k výraznému zpomalení.

Doporučení je zavírat všechny takové dotazy včas.

Otázky?

Neváhejte mě kontaktovat s jakýmikoli dotazy: [email protected]!