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.01.2019

Překlady: portugalština

Proč „23 dalších“?

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

1. Nastavte Power Options na High Performance v Windows Server 2016 a 2019

Ve výchozím nastavení má Windows Server plán napájení nastavený na „Balanced“, který není vhodný pro databázové servery. Nastavte jej na „High Performance“ 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í „High-performance“:

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

2. Povolte «Interact with desktop» u Classic na Windows

Pokud používáte Firebird s architekturou Classic na Windows, povolte zaškrtávací políčko «Allow service to interact with desktop». Bez tohoto nastavení je prostředek „desktop heap“ omezen 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 spočívá v tom, že Windows s rolí Domain Controller vypíná write cache na disku s databází Active Directory.

Ovlivňuje Firebird různými způsoby (stejně jako samozřejmě jiné aplikace) a vykazuje výrazně horší výkon než na serverech bez rolí Active Directory.

Vezměte prosím na vědomí, že tento problém ovlivňuje tak populární verzi Windows, jako je Windows Small Business Server 2011, stejně jako další verze s DC.

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

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

Code 
cat /proc//limits

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

Firebird může použít až 4 handles na připojení, a pokud máte něco takového:

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.

Vezměte prosím na vědomí - pokud máte na serveru 4 databáze, počítá se připojení pro každou databázi.

Nastavte více - doporučuji 65535.

Nezapomeňte to znovu zkontrolovat po restartu procesu Firebird: bylo to 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 dobré zlepšení výkonu po migraci z CentOS 6 na 7, Ubuntu 12 na 16 (na stejném hardwaru!), takže nyní je to nutné doporučení pro databázové servery s více než 250-300 připojeními. Moderní Linux je předpokladem před dalšími kroky optimalizace.

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

6. Rezervujte 40 % RAM pro file cache na Windows

OS Memory Manager má důsledky týkající se alokace paměti a ve výchozím nastavení Windows vyžaduje 40 % RAM pro file cache.

Bohužel, nástroj Windows Task Manager zobrazuje paměť, která je použita pro file cache, jako «free», a někteří administrátoři se snaží přimět Firebird, aby spotřeboval všechnu tuto volnou paměť, takže nastaví parametr DefaultDBCachePage v firebird.conf na velmi vysoké hodnoty, což obvykle vede k 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 server Firebird) je následující: paměť Firebirdu (Working Set) by měla být menší než 40 % celkové RAM. Pokud je celková velikost working setů všech procesů větší než 50 %, může Windows spustit swap.

Vezměte prosím na vědomí: „rezervovat“ zde znamená nejen „nenastavovat příliš mnoho page buffers ve Firebirdu“, ale také, což je důležité, omezit využití paměti jiným softwarem. Například pokud máte na stejném serveru s Firebird MS Exchange nebo MSSQL, ujistěte se, že omezíte jejich nároky na paměť.

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

7. Rezervujte 30 % RAM pro file cache na Linuxu

Linux pracuje s file cache jiným způsobem než Windows a obecně může být množství RAM použité pro file cache výrazně menší než na Windows, bez znatelného zhoršení výkonu Firebirdu. Pro zaručení vysokého výkonu systému s vysokým počtem připojení, zejména u Classic a SuperClassic, však bude dobrým nápadem rezervovat 30 % RAM pro file cache.

8. Používejte irqbalance na Linuxu

irqblalnce často zlepšuje výkon Firebirdu a vyvažování 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 - s funkcí známou jako Memory Overcommit (název se může lišit na 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í VM) může začít swap, což povede k výrazným zpožděním. Pro vysoce výkonnou VM určenou 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ší serverové 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. Čistěte dočasné soubory Firebirdu

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

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

Kontrolujte tyto složky pravidelně 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 file cache při velké cache Firebirdu

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

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

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

V 99 % případů je lepší mít file cache povolenou.

Abyste to zajistili, vždy nastavte parametry podle následujícího pravidla:

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

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

13. Zrychlete security databázi

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

Jako minimum 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 (je to standardní funkce ve Firebird 3, ve 2.5 bude vyžadovat přeinstalaci)

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

Nejradikálnějším způsobem je učinit security databázi read-only - eliminuje to všechny zápisy do ní.

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

14. Vyzkoušejte SuperClassic na Firebird 3

Ve Firebird 3 byla architektura SuperServer silně propagována jako konečné řešení výkonu, ale existují některé typy zátěže, které vykazují lepší výkon se SuperClassic (ale ne s Classic - ta 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*page size*databases_count < 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ž 100 Gb 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. Cache Firebirdu je určena ve stránkách, 1000 stránek s velikostí stránky 8K bude 8 Mb skutečné paměti a s 16K - 16 Mb.
  • Snížil počet systémových stránek. Zrychlí to přístup k záznamům velkých tabulek (méně skoků pointer-pointer-data page) a pomůže s přípravou velkých SQL dotazů. Pro zvýšení velikosti stránky databáze by měla být databáze zálohována nástrojem gbak a poté obnovena s parametrem -page ( gbak -c -page 16384).

Vezměte prosím na vědomí: 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 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ů, které vznikají 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 jdou všechny změny na novou datovou stránku. V důsledku toho jsou v databázi s příznakem no_reserve operace UPDATE/DELETE pomalejší.

Takže pokud vaše databáze není read-only, 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 vytvořeny s rezervovaným místem.

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

Vezměte prosím na vědomí: velikost databáze po odstranění příznaku no_reserve a zálohování/obnovení vzroste.

17. Nastavte vysokou počáteční velikost pro lock table Firebirdu

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

Tabulka zámků Firebird může automaticky růst, 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, a to od počáteční velikosti (nastavené v firebird.conf).

Aby se zabránilo opakovaným kolům zvětšování tabulky zámků, dobrým nápadem je 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 vysokým zatížením 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 databázových vývojářů: může být nutné například pro licenční účely.

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

Spusťte

fb_lock_print -d database_name | alias

a zkontrolujte hodnotu Owners – zobrazí 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á Firebird optimalizátoru více volnosti a v moderních verzích Firebird je optimalizován mnohem lépe než LEFT.

Zejména to má 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() jen pro ověření existence záznamu.

Následující dotaz přečte všechny záznamy odpovídající condition1:

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

Místo toho použijte tuto konstrukci

Code 
Exists(select first 1 id where condition1)

Pokud condition1 vrací více než 1 záznam, navrhovaná varianta bude mnohem rychlejší, protože nečte všechny záznamy, 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 z pohledu obchodní logiky zbytečná, 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. Neponechávejte dotazy ve stavu připraveném bez nutnosti

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

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

Doporučení je ponechat SQL dotazy ve stavu připraveném pouze tehdy, pokud jsou určeny ke spuštění mnohokrát, nebo pokud je jejich doba přípravy dlouhá (může nastat u velmi velkých dotazů s mnoha joiny 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 alokované pro řazení je nastavena parametrem TempCacheLimit v firebird.conf, ve výchozím nastavení je to 64 Mb.

I se zvýšeným TempCacheLimit budou dlouho běžící dotazy s velkým počtem řazených záznamů nakonec spotřebovávat celé alokované množství, 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.

Máte otázky?

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