it-swarm-eu.dev

O výkonu s jedním vláknem versus vícevláknové databáze

H2 je jednovláknová databáze s dobrou pověstí co se týče výkonu. Ostatní databáze jsou vícevláknové.

Moje otázka zní: kdy se databáze s více vlákny stane zajímavější než databáze s jedním vláknem? Kolik uživatelů? Kolik procesů? Co je spouštěč? Každý, kdo má zkušenosti sdílet?

Shrnutí

  • Obvyklým problémem je přístup na disk
  • SSD jsou rychlé, ale křehké (postup při selhání je nutností)
  • Jeden dlouhý dotaz v systému s jedním vláknem zablokuje všechny ostatní
  • Konfigurace vícevláknového systému může být složitá
  • Vícevláknové databáze jsou prospěšné i na jednojádrových systémech
59

Zde je můj názor:

Problémem (nebo nejpomalejší částí) systému DB je obvykle disk. CPU spikuje pouze během aritmetických operací, zpracování nebo jakéhokoli jiného úkolu, který CPU dělá. Při správné architektuře může multithreading pomoci vyrovnat zatížení dotazu na CPU namísto provádění pomalého čtení a zápisu na disku. Existují případy, kdy je rychlejší vypočítat hodnotu pomocí cyklů CPU, než vytvořit výpočetní sloupec (který byl dříve uložen na disk) a přečíst tento sloupec z disku.

V některých RDBMS existuje dočasná DB (tempdb), která je používána všemi DB v této instanci pro třídění, hašování, dočasné proměnné atd. Vícevláknové a dělení těchto tempdb souborů lze použít ke zlepšení propustnosti tempdb , čímž se zlepší celkový výkon serveru.

Pomocí multithreadingu (paralelismus) lze výslednou sadu dotazu rozdělit a zpracovat na různých jádrech serveru, namísto použití pouze jednoho jádra. Tato funkce ne vždy zlepšuje výkon, ale existují případy, kdy ano, a proto je tato funkce k dispozici.

Vlákna dostupná do DB se používají pro mnoho účelů: čtení/zápis na disk, uživatelská připojení, úlohy na pozadí, zamykání/blokování, síťové IO atd. ... V závislosti na architektuře OS jsou vlákna předávaná do CPU a jsou zvládnuto pomocí čekání a front. Pokud CPU dokáže tato vlákna velmi rychle rozbít, čekací doba bude nízká. Vícevláknová DB bude rychlejší než jednozávitová DB, protože v jednozávitové DB bude mít režie recyklace pouze jednoho vlákna spíše než mít snadno dostupné další běhouny.

Škálovatelnost se také stává problémem, protože ke správě a provádění škálovaného systému DB bude zapotřebí více vláken.

31
StanleyJohns

Pokud o MySQL mohu říci něco jiného, ​​je to, že InnoDB, jeho transakční (kompatibilní s ACID) úložný stroj, je skutečně vícevláknový. Nicméně, je stejně multithreaded jako VY konfigurovat to !!! I v pravém "out of the box" InnoDB funguje skvěle v jednom prostředí CPU vzhledem k jeho výchozímu nastavení. Abyste mohli využívat možnosti multithreadingu InnoDB, musíte si zapamatovat aktivaci mnoha možností.

innodb_thread_concurrency nastavuje horní hranici počtu souběžných vláken, které může InnoDB udržovat otevřený. Nejlepší číslo kola pro toto nastavení je (2 x počet procesorů) + počet disků. [~ # ~] update [~ # ~] : Jak jsem se dozvěděl z první konference na konferenci v Percona NYC, měli byste nastavit tuto hodnotu na 0, abyste byli upozorněni InnoDB Storage Engine k nalezení nejlepšího počtu vláken pro prostředí, ve kterém běží.

innodb_concurrency_tickets nastavuje počet vláken, které mohou beztrestně obejít kontrolu souběžnosti. Po dosažení tohoto limitu se opět stane normou kontrola souběžnosti vláken.

innodb_commit_concurrency nastavuje počet souběžných transakcí, které mohou být potvrzeny. Vzhledem k tomu, že výchozí hodnota je 0, nenastavení umožňuje libovolnému počtu transakcí provádět současně.

innodb_thread_sleep_delay nastavuje počet milisekund, ve kterých může být vlákno InnoDB v klidu před opětovným zadáním fronty InnoDB. Výchozí hodnota je 10 000 (10 sekund).

innodb_read_io_threads a innodb_write_io_threads (oba od MySQL 5.1.38) přidělují určený počet vláken pro čtení a zápisy. Výchozí hodnota je 4 a maximální 64.

innodb_replication_delay zavádí zpoždění podprocesu na slave je dosaženo innodb_thread_concurrency.

innodb_read_ahead_threshold umožňuje lineární čtení nastaveného počtu rozsahů (64 stránek [page = 16K]) před přepnutím na asynchronní čtení.

Čas by mi unikl, kdybych jmenoval více možností. Můžete si o nich přečíst v MySQL's Documentation .

Většina lidí si tyto funkce neuvědomuje a je s InnoDB velmi spokojená, když provádí transakce kompatibilní s ACID. Pokud Tweak některou z těchto možností, děláte tak na vlastní nebezpečí.

Hrál jsem s více instancemi fondu vyrovnávacích pamětí MySQL 5.5 (162 GB v 9 instancích vyrovnávacích fondů) a pokusil jsem se tímto způsobem data automaticky rozdělit do paměti. Někteří odborníci tvrdí, že by vám to mělo přinést 50% zlepšení výkonu. Dostal jsem spoustu zamykání nití, které ve skutečnosti InnoDB procházelo. Přepnul jsem na 1 buffer (162 GB) a vše bylo opět na světě v pořádku. Myslím, že potřebujete odborníky z Percony, abyste je mohli nastavit. Zítra budu na konferenci MySQL v Perconě v New Yorku a zeptám se na to, jestli se to otevře.

Závěrem lze říci, že InnoDB se nyní na serveru s více CPU chová dobře vzhledem k jeho výchozímu nastavení pro operace s více podprocesy. Vylepšení jim věnuje velkou péči, velkou trpělivost, skvělou dokumentaci a skvělou kávu (nebo Red Bull, Jolt atd.).

Dobré ráno, dobrý večer a dobrou noc !!!

AKTUALIZACE 2011-05-27 20:11

Přišel zpět z Percona MySQL Conference v New York ve čtvrtek. Jaká konference. Hodně jsem se naučil, ale dostal jsem odpověď, kterou se budu zabývat ohledně InnoDB. Byl jsem informován Ronald Bradford , že nastavení innodb_thread_concurrency na 0 umožní InnoDB rozhodnout interně nejlepší postup se souběžností podprocesů. Budu s tím experimentovat dále v MySQL 5.5.

AKTUALIZACE 2011-06-01 11:20

Pokud jde o jeden dlouhý dotaz, InnoDB je kompatibilní s ACID a funguje velmi dobře pomocí MultiVersion Concurrency Control . Transakce by měly být schopny přenášet úrovně izolace (ve výchozím nastavení opakovatelné čtení), které zabraňují ostatním v přístupu k datům.

Pokud jde o vícejádrové systémy, InnoDB prošel dlouhou cestu. V minulosti nemohl InnoDB fungovat ve vícebarevném prostředí. Pamatuji si, že musím na jednom serveru spouštět více instancí mysql, abych získal více jader, abych distribuoval více procesů mysqld napříč CPU. To už není nutné, díky Perconě a později MySQL (eh, Oracle, říká, že mě stále dělá gag), protože vyvinuli InnoDB do vyspělejšího úložného motoru, který může přistupovat k jádrům s jednoduchostí bez velkého vyladění. Současná instance InnoDB dnes může dobře fungovat na jednom jádrovém serveru.

49
RolandoMySQLDBA

Jakmile máte více souběžných uživatelů nebo procesů, nebo dokonce jediný proces s vícevláknovým přístupem k databázi, bude mít potenciálně zajímavá databáze s podporou podprocesů.

H2 je vlákno bezpečný, ale serializuje všechny požadavky do databáze, což se může stát potenciálním problémem s výkonem ve scénáři velkého zatížení. Zda to tak skutečně je pro konkrétní projekt, závisí na kombinaci vašich požadavků na výkon, počtu vláken/uživatelů/procesů přistupujících k databázi, frekvence dotazů prováděných těmito vlákny a průměrného a nejhoršího výkonu vašeho projektu. dotazy.

Například pokud vaše požadavky na výkon mají odpověď během jedné sekundy, nemáte více než 10 souběžných uživatelů, kteří provádějí jediný dotaz, který trvá 0,05 sekundy, než by bylo možné provést, databáze s jedním vláknem by vám stále umožnila tyto cíle dosáhnout (i když je to vícevláknové) by pravděpodobně již poskytlo znatelné zvýšení výkonu). Vzhledem ke stejnému scénáři s jediným potenciálním dotazem s nejhorším výkonem půl sekundy však serializace přístupu k databázi již neumožňuje splnit vaše výkonnostní cíle.

Pokud v současné době používáte H2 na svém projektu, doporučuji vám spustit profiler proti vaší kódové základně v zátěžovém scénáři (stačí vykopnout x počet vláken, které souběžně zasáhnou váš kód, pomocí několika obvyklých použití). To vám poskytne skutečné metriky týkající se výkonu a úzkých míst ve vaší kódové základně, namísto pouhé teoretizace. Pokud se ukáže, že vaše požadavky tráví velké procento času čekáním na přístup k databázi, je čas přejít na databázi s vlákny.

11
Luke Hutteman

Z toho, co mohu říci, je „jednovláknové“ trochu chybné označení pro H2. Jde o to, že serializuje všechny transakce (tj. Provádí je jednotlivě).

Zásadní otázka týkající se toho, zda je pro vaši aplikaci „ok“ nebo ne, není „Kolik uživatelů?“ nebo dokonce „Kolik procesů?“, ale „Jak dlouho budou mé transakce trvat?“

Pokud jsou všechny vaše transakce vteřiny, což může být v pořádku, může trvat několik hodin, nemusí to být v pořádku, protože všechny ostatní čekající transakce budou čekat na dokončení. Rozhodnutí o tom, zda je to „v pořádku“ nebo ne, bude záviset na vašich vlastních požadavcích na výkon - tj. Jak dlouho je přijatelné čekání, než moji uživatelé zasáhnou databázi transakcemi.

--UPRAVIT

Zdá se, že H2 ve skutečnosti serializuje transakce - pouze DML. Jinými slovy, spousta krátkých aktualizací v rámci jedné dlouhé transakce neblokuje jiné aktualizace . Pokud však nepoužíváte experimentální funkce MVCC , uzamčení tabulky znamená, že to má v praxi podobný účinek. K dispozici je také experimentální funkce "multi_threaded" , ale nelze použít současně s MVCC

Citování bitů a kousků ze serveru PostgreSQL ... Mějte prosím na paměti, že nemám vůbec ponětí o výhodnosti těchto argumentů - prostě se nehodí do komentáře.

Od vývojáře FAQ („Proč se vlákna nepoužívají ...“):

http://wiki.postgresql.org/wiki/Developer_FAQ#Why_don.27t_you_use_threads.2C_raw_devices.2C_async-I.2FO.2C_.3Cinsert_your_favorite_wizz-bang_feature_here.3E.3F

Vlákna se momentálně nepoužívají namísto více procesů pro backends, protože: (...)

  • Chyba v jednom backendu může poškodit další backendy, pokud jsou to vlákna v rámci jednoho procesu
  • Vylepšení rychlosti pomocí vláken jsou ve srovnání se zbývající dobou spuštění backendu malá.
  • Sdílení sdílených spustitelných mapování a použití shared_buffers znamená, že procesy, jako vlákna, jsou velmi efektivní z paměti
  • Pravidelné vytváření a ničení procesů pomáhá chránit před fragmentací paměti, která může být obtížně spravovatelná v dlouhodobých procesech

Ze seznamu Todo („Funkce, které nechceme“):

http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want

Všechny backendy běží jako vlákna v jediném procesu (nechtěné)

To eliminuje procesní ochranu, kterou získáme z aktuálního nastavení. Vytváření vláken je obvykle stejná režie jako vytváření procesů v moderních systémech, takže se zdá nerozumné používat model s čistými vlákny a MySQL a DB2 prokázaly, že vlákna představují tolik problémů, kolik řeší. (...)

Takže znovu ... absolutně netuším o výhodách výše uvedeného. Bylo to příliš dlouhé na to, aby se vešly do komentáře.

5