Od té doby, co byla MySQL původně vytvořena pro vytvoření MariaDB, byla široce podporována a rychle přijata velkým publikem v komunitě open source databází. Původně náhradní náhrada MariaDB začala vytvářet rozdíly proti MySQL, zejména s vydáním MariaDB 10.2.
Navzdory tomu však stále není žádný skutečný rozdíl mezi MariaDB a MySQL, protože oba mají enginy, které jsou kompatibilní a mohou spolu nativně běžet. Nebuďte tedy překvapeni, pokud ladění vašeho nastavení MariaDB bude mít podobný přístup jako jedno ladění MySQL.
Tento blog se bude zabývat laděním MariaDB, konkrétně systémů běžících v prostředí Linuxu.
Optimalizace hardwaru a systému MariaDB
MariaDB doporučuje zlepšit hardware v následujícím pořadí priorit...
Paměť
Paměť je pro databáze nejdůležitějším faktorem, protože umožňuje upravit systémové proměnné serveru. Více paměti znamená větší mezipaměť klíčů a tabulek, které jsou uloženy v paměti, takže disky mohou přistupovat, řádově pomaleji, a následně se sníží.
Mějte však na paměti, že pouhé přidání další paměti nemusí vést k drastickým vylepšením, pokud proměnné serveru nejsou nastaveny tak, aby využívaly další dostupnou paměť.
Použití více slotů RAM na základní desce zvyšuje frekvenci sběrnice a mezi RAM a CPU bude větší latence. To znamená, že je vhodnější použít nejvyšší velikost RAM na slot.
Disky
Rychlý přístup k disku je kritický, protože v něm jsou uložena data. Klíčovým ukazatelem je doba vyhledávání disku (měření rychlosti pohybu fyzického disku pro přístup k datům), takže vybírejte disky s co nejnižší dobou vyhledávání. Můžete také přidat vyhrazené disky pro dočasné soubory a protokoly transakcí.
Rychlý Ethernet
S odpovídajícími požadavky na šířku pásma vašeho internetu, rychlý ethernet znamená, že může mít rychlejší odezvu na požadavky klientů, doba odezvy replikace pro čtení binárních protokolů napříč podřízenými zařízeními, rychlejší doba odezvy je také velmi důležitá, zvláště u Galery - založené klastry.
CPU
Přestože hardwarová úzká hrdla často padají jinde, rychlejší procesory umožňují rychlejší provádění výpočtů a rychlejší odesílání výsledků zpět klientovi. Kromě rychlosti procesoru jsou důležitými faktory, které je třeba zvážit, také rychlost sběrnice procesoru a velikost mezipaměti.
Nastavení plánovače I/O disku
Plánovače I/O existují jako způsob optimalizace požadavků na přístup k disku. Sloučí I/O požadavky na podobná místa na disku. To znamená, že disková jednotka nemusí vyhledávat tak často a zlepšuje celkovou dobu odezvy a šetří operace s diskem. Doporučené hodnoty pro výkon I/O jsou noop a deadline.
noop je užitečné pro kontrolu, zda složitá rozhodnutí o plánování I/O jiných plánovačů nezpůsobují regrese I/O výkonu. V některých případech to může být užitečné pro zařízení, která sama plánují I/O, jako inteligentní úložiště nebo zařízení, která nejsou závislá na mechanickém pohybu, jako jsou SSD. Obvykle je pro tato zařízení lepší volbou plánovač I/O DEADLINE, ale kvůli menší režii může NOOP při určitých pracovních zátěžích poskytovat lepší výkon.
Pro uzávěrku je to plánovač I/O orientovaný na latenci. Každý požadavek I/O má přidělenou lhůtu. Požadavky jsou obvykle uloženy ve frontách (čtení a zápis) seřazených podle čísel sektorů. Algoritmus DEADLINE udržuje dvě další fronty (čtení a zápis), kde jsou požadavky seřazeny podle termínu. Dokud nevypršel časový limit žádného požadavku, používá se „sektorová“ fronta. Pokud dojde k vypršení časového limitu, požadavky z fronty „uzávěrky“ jsou obsluhovány, dokud již nebudou existovat žádné požadavky, jejichž platnost vypršela. Algoritmus obecně preferuje čtení před zápisem.
Zařízení PCIe (jednotky NVMe SSD) mají své vlastní velké interní fronty spolu s rychlým servisem a nevyžadují ani nemají prospěch z nastavení plánovače I/O. Doporučuje se nemít žádný explicitní konfigurační parametr režimu plánovače.
Nastavení plánovače můžete zkontrolovat pomocí:
cat /sys/block/${DEVICE}/queue/schedulerMělo by to například vypadat takto:
cat /sys/block/sda/queue/scheduler
[noop] deadline cfqAby to bylo trvalé, upravte konfigurační soubor /etc/default/grub, vyhledejte proměnnou GRUB_CMDLINE_LINUX a přidejte výtah stejně jako níže:
GRUB_CMDLINE_LINUX="elevator=noop"Zvýšení limitu otevřených souborů
Aby byl zajištěn dobrý výkon serveru, celkový počet klientských připojení, databázových souborů a souborů protokolu nesmí překročit maximální limit deskriptoru souboru v operačním systému (ulimit -n). Systémy Linux omezují počet deskriptorů souborů, které může každý proces otevřít, na 1 024 na proces. Na aktivních databázových serverech (zejména produkčních) může snadno dosáhnout výchozího systémového limitu.
Chcete-li toto zvýšit, upravte soubor /etc/security/limits.conf a zadejte nebo přidejte následující:
mysql soft nofile 65535
mysql hard nofile 65535To vyžaduje restart systému. Poté můžete potvrdit spuštěním následujícího:
$ ulimit -Sn
65535
$ ulimit -Hn
65535Volitelně to můžete nastavit pomocí mysqld_safe, pokud spouštíte proces mysqld prostřednictvím mysqld_safe,
[mysqld_safe]
open_files_limit=4294967295nebo pokud používáte systemd,
sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF
[Service]
LimitNOFILE=infinity
EOF
sudo systemctl daemon-reloadNastavení Swappiness v Linuxu pro MariaDB
Linux Swap hraje v databázových systémech velkou roli. Chová se jako vaše rezervní pneumatika ve vašem vozidle, když vám při práci překážejí nepříjemné úniky paměti, stroj se zpomalí... ale ve většině případů bude stále použitelný k dokončení přiděleného úkolu.
Chcete-li použít změny na swappiness, jednoduše spusťte,
sysctl -w vm.swappiness=1To se děje dynamicky, bez nutnosti restartovat server. Aby byl trvalý, upravte /etc/sysctl.conf a přidejte řádek
vm.swappiness=1Je docela běžné nastavit swappiness=0, ale od vydání nových jader (tj. jader> 2.6.32-303) byly provedeny změny, takže musíte nastavit vm.swappiness=1.
Optimalizace souborového systému pro MariaDB
Nejběžnější souborové systémy používané v prostředích Linuxu se systémem MariaDB jsou ext4 a XFS. K dispozici jsou také určitá nastavení pro implementaci architektury pomocí ZFS a BRTFS (jak je uvedeno v dokumentaci MariaDB).
Většina nastavení databáze navíc nepotřebuje zaznamenávat dobu přístupu k souboru. Možná budete chtít toto zakázat při připojování svazku do systému. Chcete-li to provést, upravte svůj soubor /etc/fstab. Například na svazku s názvem /dev/md2 to vypadá takto:
/dev/md2 / ext4 defaults,noatime 0 0Vytvoření optimální instance MariaDB
Ukládání dat na samostatný svazek
Vždy je ideální oddělit data databáze na samostatném svazku. Tento svazek je speciálně určen pro tyto typy rychlých svazků úložiště, jako jsou karty SSD, NVMe nebo PCIe. Pokud například selže celý váš systémový svazek, budete mít svazek databáze v bezpečí a můžete si být jisti, že se to nedotkne v případě selhání hardwaru úložiště.
Vylaďte MariaDB pro efektivní využití paměti
innodb_buffer_pool_size
Primární hodnotu, kterou je třeba upravit na databázovém serveru s úplně/primárně tabulkami XtraDB/InnoDB, lze v těchto prostředích nastavit až na 80 % celkové paměti. Pokud je nastaveno na 2 GB nebo více, pravděpodobně budete chtít upravit také innodb_buffer_pool_instances. Můžete to nastavit dynamicky, pokud používáte MariaDB>=10.2.2 verze. V opačném případě vyžaduje restart serveru.
tmp_memory_table_size/max_heap_table_size
Pro tmp_memory_table_size (tmp_table_size), pokud máte co do činění s velkými dočasnými tabulkami, nastavení této vyšší zajistí zvýšení výkonu, protože budou uloženy v paměti. To je běžné u dotazů, které intenzivně využívají GROUP BY, UNION nebo dílčí dotazy. Ačkoli je-li max_heap_table_size menší, bude platit spodní limit. Pokud tabulka překročí limit, MariaDB ji převede na tabulku MyISAM nebo Aria. Zda je nutné zvýšit, zjistíte porovnáním stavových proměnných Created_tmp_disk_tables a Created_tmp_tables, abyste viděli, kolik dočasných tabulek z celkového počtu vytvořených tabulek je potřeba převést na disk. Za překročení limitu jsou často odpovědné složité dotazy GROUP BY.
Zatímco max_heap_table_size, toto je maximální velikost pro uživatelem vytvořené tabulky MEMORY. Hodnota nastavená pro tuto proměnnou je použitelná pouze pro nově vytvořené nebo znovu vytvořené tabulky, nikoli pro stávající. Menší z max_heap_table_size a tmp_table_size také omezuje interní tabulky v paměti. Po dosažení maximální velikosti se při každém dalším pokusu o vložení dat zobrazí chyba „tabulka... je plná“. Dočasné tabulky vytvořené pomocí CREATE TEMPORARY nebudou převedeny na Aria, jak je tomu u interních dočasných tabulek, ale také obdrží chybu plné tabulky.
innodb_log_file_size
Velké paměti s vysokorychlostním zpracováním a rychlým I/O diskem nejsou novinkou a mají rozumnou cenu, jak doporučuje. Pokud dáváte přednost většímu nárůstu výkonu, zejména během a zpracování vašich transakcí InnoDB, je rozumné nastavit proměnnou innodb_log_file_size na větší hodnotu, jako je 5Gib nebo dokonce 10GiB. Zvýšení znamená, že větší transakce mohou běžet, aniž by bylo nutné provést vstup/výstup na disku před potvrzením.
join_buffer_size
V některých případech mají vaše dotazy tendenci postrádat správné indexování nebo jednoduše existují případy, kdy potřebujete tento dotaz spustit. Nastavení této proměnné je nejlepší na úrovni relace. Zvětšete ji, abyste získali rychlejší úplná spojení, když přidávání indexů není možné, i když mějte na paměti problémy s pamětí, protože spojení vždy přidělují minimální velikost.
Nastavte svůj max_allowed_packet
MariaDB má při manipulaci s pakety stejnou povahu jako MySQL. Rozděluje data do paketů a klient si musí být vědom hodnoty proměnné max_allowed_packet. Server bude mít vyrovnávací paměť pro uložení těla s maximální velikostí odpovídající této hodnotě max_allowed_packet. Pokud klient odešle více dat, než je max_allowed_packet size, bude soket uzavřen. Direktiva max_allowed_packet definuje maximální velikost paketu, který lze odeslat.
Nastavení této hodnoty příliš nízko může způsobit, že se dotaz zastaví a uzavře klientské připojení, což je docela běžné, že se během dotazu objeví chyby jako ER_NET_PACKET_TOO_LARGE nebo Ztráta připojení k serveru MySQL. V ideálním případě, zvláště u většiny dnešních požadavků na aplikace, můžete začít s nastavením na 512 MiB. Pokud se jedná o typ aplikace s nízkou poptávkou, stačí použít výchozí hodnotu a nastavit tuto proměnnou pouze prostřednictvím relace v případě potřeby, pokud jsou data, která mají být odeslána nebo přijata, příliš velká než výchozí hodnota (16 MiB od MariaDB 10.2.4). V určitých pracovních zátěžích, které vyžadují zpracování velkých paketů, pak musíte upravit jeho vyšší podle vašich potřeb, zejména při replikaci. Pokud je max_allowed_packet na slave zařízení příliš malý, způsobí to také slave zastavení I/O vlákna.
Použití fondu vláken
V některých případech nemusí být toto ladění nutné nebo doporučené. Fondy vláken jsou nejúčinnější v situacích, kdy jsou dotazy relativně krátké a zátěž je vázána na CPU (pracovní zátěže OLTP). Pokud zátěž není vázána na CPU, možná budete chtít omezit počet vláken, aby se ušetřila paměť pro vyrovnávací paměti databáze.
Použití fondu vláken je ideálním řešením, zejména pokud váš systém prochází přepínáním kontextu a vy hledáte způsoby, jak toto snížit a udržovat nižší počet vláken, než je počet klientů. Toto číslo by však také nemělo být příliš nízké, protože chceme také maximálně využít dostupné CPU. Proto by v ideálním případě mělo existovat jedno aktivní vlákno pro každý CPU na počítači.
Můžete nastavit thread_pool_max_threads, thread_pool_min_threads pro maximální a minimální počet vláken. Na rozdíl od MySQL je to přítomno pouze v MariaDB.
Nastavte proměnnou thread_handling, která určuje, jak server zpracovává vlákna pro klientská připojení. Kromě vláken pro připojení klientů to platí také pro určitá vnitřní vlákna serveru, jako jsou podřízená vlákna Galera.
Vylaďte mezipaměť stolu + max_connections
Pokud se v seznamu procesů setkáváte s občasnými výskyty stavů Otevírání tabulek a Zavírání tabulek, může to znamenat, že potřebujete zvýšit mezipaměť tabulek. Můžete to sledovat také prostřednictvím výzvy klienta mysql spuštěním SHOW GLOBAL STATUS LIKE 'Open%table%'; a sledovat stavové proměnné.
Pro max_connections, pokud vaše aplikace vyžaduje mnoho souběžných připojení, můžete začít nastavovat na 500.
Pro table_open_cache to bude celkový počet vašich tabulek, ale nejlepší je přidat další v závislosti na typu dotazů, které obsluhujete, protože dočasné tabulky by se měly také ukládat do mezipaměti. Pokud máte například 500 stolů, bylo by rozumné začít s 1500.
Zatímco máte table_open_cache_instances, začněte jej nastavovat na 8. To může zlepšit škálovatelnost snížením sporů mezi relacemi, mezipaměť otevřených tabulek lze rozdělit na několik menších instancí mezipaměti o velikosti table_open_cache / table_open_cache_instances.
Pro InnoDB funguje table_definition_cache jako měkký limit pro počet instancí otevřených tabulek v mezipaměti datového slovníku InnoDB. Hodnota, která má být definována, nastaví počet definic tabulek, které lze uložit do mezipaměti definic. Pokud používáte velký počet tabulek, můžete vytvořit velkou mezipaměť definic tabulek, abyste urychlili otevírání tabulek. Mezipaměť definic tabulek zabírá méně místa a na rozdíl od běžné mezipaměti tabulek nepoužívá deskriptory souborů. Minimální hodnota je 400. Výchozí hodnota je založena na následujícím vzorci s limitem 2000:
MIN(400 + table_open_cache / 2, 2000)Pokud počet instancí otevřených tabulek překročí nastavení table_definition_cache, mechanismus LRU začne označovat instance tabulky pro vyřazení a nakonec je odstraní z mezipaměti datového slovníku. Tento limit pomáhá řešit situace, ve kterých by bylo použito značné množství paměti k ukládání zřídka používaných instancí tabulek do mezipaměti do příštího restartu serveru. Počet instancí tabulky s metadaty uloženými v mezipaměti může být vyšší než limit definovaný parametrem table_definition_cache, protože instance nadřazené a podřízené tabulky se vztahy cizího klíče nejsou umístěny na seznamu LRU a nepodléhají vyřazení z paměti.
Na rozdíl od table_open_cache, tabulka_definition_cache nepoužívá deskriptory souborů a je mnohem menší.
Zacházení s mezipamětí dotazů
Pokud možno, doporučujeme deaktivovat mezipaměť dotazů ve všech nastaveních MariaDB. Chcete-li dokončit deaktivaci mezipaměti dotazů, musíte zajistit, aby query_cache_type=OFF a query_cache_size=0. Na rozdíl od MySQL MariaDB stále plně podporuje mezipaměť dotazů a nemá žádné plány na zrušení podpory používání mezipaměti dotazů. Někteří lidé tvrdí, že mezipaměť dotazů pro ně stále poskytuje výhody výkonu. Nicméně tento příspěvek od Percona The MySQL query cache:Worst nepřítel or best friend odhaluje, že cache dotazů, pokud je povolena, má za následek režii a ukazuje, že má špatný výkon serveru.
Pokud máte v úmyslu používat mezipaměť dotazů, ujistěte se, že sledujete mezipaměť dotazů spuštěním SHOW GLOBAL STATUS LIKE 'Qcache%';. Qcache_inserts obsahuje počet dotazů přidaných do mezipaměti dotazů, Qcache_hits obsahuje počet dotazů, které využily mezipaměť dotazů, zatímco Qcache_lowmem_prunes obsahuje počet dotazů, které byly vyřazeny z mezipaměti kvůli nedostatku paměti. V pravý čas se používání a povolení mezipaměti dotazů může roztříštit. Vysoké Qcache_free_blocks vzhledem k Qcache_total_blocks může znamenat fragmentaci. Chcete-li jej defragmentovat, spusťte FLUSH QUERY CACHE. Tím dojde k defragmentaci mezipaměti dotazů, aniž by došlo k vypuštění jakýchkoli dotazů.
Vždy sledujte své servery
Je velmi důležité, abyste správně monitorovali své uzly MariaDB. Běžné monitorovací nástroje (jako Nagios, Zabbix nebo PMM) jsou k dispozici, pokud dáváte přednost bezplatným a open source nástrojům. Pro podnikové a plně nabité nástroje vám doporučujeme vyzkoušet ClusterControl, protože neposkytuje pouze monitorování, ale nabízí také výkonnostní poradce, výstrahy a alarmy, které vám pomohou zlepšit výkon vašeho systému a zůstat v obraze s aktuálním trendy, když spolupracujete s týmem podpory. Monitorování databáze pomocí ClusterControl je zdarma a je součástí Community Edition.
Závěr
Vyladění nastavení MariaDB je téměř stejný přístup jako MySQL, ale s určitými rozdíly, protože se liší v některých přístupech a verzích, které podporuje. MariaDB je nyní jinou entitou ve světě databází a rychle si získala důvěru komunity bez jakéhokoli FUD. Mají své vlastní důvody, proč to musí být implementováno tímto způsobem, takže je velmi důležité, abychom věděli, jak to vyladit a optimalizovat váš server(y) MariaDB.