Je možné, aby MySQL používal více než jedno jádro?

Question

Byl jsem představen s některými dedikovanými servery MySQL, které nikdy nepoužívají více než jedno jádro. Jsem více vývojář než DBA pro MySQL, takže potřebujete nějakou pomoc

Založit

Servery jsou docela robustní s načtením typu OLAP/DataWarehouse (DW):

Primární: 96 GB RAM, 8 jader a jedno pole RAID 10
Test: 32 GB RAM se 4 jádry)
Největší DB je 540 GB, celková hodnota je kolem 1,1 TB a většinou tabulek InnoDB
Solaris 10 Intel-64
MySQL 5.5.x

Poznámka: Největší DB je replikovaná z OLTP DR server a DW je načten z toho. Není to plný DW: pouze posledních 6 měsíců až 6 týdnů, takže je menší než OLTP DB).

Pozorování na testovacím serveru

3 samostatné připojení
každý má souběžnou (a jinou) ALTER TABLE...DROP KEY...ADD INDEX
3 tabulky mají 2,5, 3,8 a 4,5 milionu řádků
Využití procesoru se zvyšuje až o 25% (jedno jádro je maximalizováno) a není vyšší
3 ALTERY zabírají 12-25 minut (jeden z nejmenších trvá 4,5)

Otázky

Jaké nastavení nebo oprava je vyžadována, aby bylo možné použít více než jedno jádro?
To je důvod, proč MySQL nepoužívá všechna dostupná jádra? (stejně jako ostatní RDBMS)
Je to důsledek replikace?

Další poznámky

Rozumím rozdílu mezi „vláknem“ RDBMS a „vláknem OS“
Neptám se na žádnou formu paralelismu
Některé systémové proměnné pro InnoDB a vlákna jsou suboptimální
(hledáte rychlou výhru)
Krátkodobě nemůžu změnit rozložení disku
OS lze v případě potřeby vylepšit
Jeden ALTER TABLE na nejmenším stole trvá 4,5 minut (šokující IMO)

Upravit 1

innodb_thread_concurrency je nastavena na 8 na obou. Ano, je to špatně, ale MySQL nebude používat více jader
innodb_buffer_pool_size je 80 GB na primární, 10 GB na test (jiná instance je vypnuta). To je v pořádku.
innodb_file_per_table = ON

Upravit 2

innodb_flush_log_at_trx_commit = 2
innodb_use_sys_malloc = ON
innodb_flush_method by měl být O_DIRECT (ale SHOW VARIABLES to neukazuje)
innodb_doublewrite = OFF
Systém souborů = ZFS (A můj sysadmin to našel: http://blogs.Oracle.com/realneel/entry/mysql_innodb_zfs_best_practices )

Testovat

innodb_flush_method se nezobrazuje jako O_DIRECT, kdy má být
bude sledovat nastavení RolandoMySQLDBA

Dejte mi vědět, jestli mi chybělo něco důležitého

Na zdraví

Aktualizace

Změněno innodb_flush_method + 3 x nastavení podprocesu v odpovědi RolandoMySQLDBA
Výsledek:> 1 jádro použité pro testy = pozitivní výsledek

RolandoMySQLDBA · Accepted Answer

Vlastně jsem diskutoval o innodb_thread_concurrency s MySQL Expert na konferenci Percona Live NYC v květnu 2011 .

Naučil jsem se něco překvapivého: Přes dokumentaci je nejlepší odejít innodb_thread_concurrency na 0 (nekonečná souběžnost). InnoDB tak rozhodne o nejlepším počtu innodb_concurrency_tickets se otevře pro dané nastavení instance MySQL.

Jakmile nastavíte innodb_thread_concurrency až 0, můžete nastavit innodb_read_io_threads a innodb_write_io_threads (oba od MySQL 5.1.38) na maximální hodnotu 64. To by mělo zapojit více jader.

Derek Downey · Answer

MySQL automaticky použije více jader, takže buď vaše zatížení 25% je náhoda¹ nebo potenciální nesprávná konfigurace na systému Solaris. Nebudu předstírat, že budu vědět, jak naladit solaris, ale tady je článek, který jde přes některé informace o ladění specifické pro Solaris .

Ladicí stránky InnoDB byly přepracovány v MySQL 5.5, takže tam jsou i nějaké dobré informace. Z InnoDB disk IO tipy :

Pokud špičkový nástroj Unix nebo Správce úloh systému Windows ukáže, že procento využití PROCESORU s pracovním zatížením je menší než 70%, je vaše pracovní zatížení pravděpodobně vázáno na disk. Možná provádíte příliš mnoho transakčních transakcí nebo je fond vyrovnávacích pamětí příliš malý. Pomáhat bude fond vyrovnávacích pamětí , ale nenastavujte ho na více než 80% fyzické paměti.

Některé další věci ke kontrole:

Přepnutí innodb_flush_method na O_DIRECT stojí za testování. Pokud to pomůže, možná budete muset připojit souborový systém s volbou forcedirectio
Změňte innodb_flush_log_at_trx_commit z 1 na 0 (pokud vám nevadí ztráta poslední sekundy při selhání mysql) nebo 2 (pokud vám nevadí ztráta poslední sekundy při selhání operačního systému).
Zkontrolujte hodnotu innodb_use_sys_malloc . Tento článek obsahuje více informací o proměnné.

V té době nebyly pro vícejádrové procesory naladěny žádné knihovny alokátorů paměti. InnoDB proto implementoval svůj vlastní alokátor paměti v subsystému mem. Tento alokátor je chráněn jediným mutexem, který se může stát úzkým hrdlem.

Na konci této části jsou však některé námitky o tom, co to znamená zapnout proměnnou (ve výchozím nastavení je v 5.5).

Pokud je přidělovač paměti InnoDB deaktivován, InnoDB bude ignorovat hodnotu parametru innodb_additional_mem_pool_size.
Je možné, že replikace způsobuje některý problém. Uvědomuji si, že vás nezajímá paralelismus, ale z popisu tento pracovní dokument :

V současné době není replikace na vícejádrových počítačích dobře nastavena. Jeden podproces podproces provádí události replikace jeden po druhém a nemusí zvládnout zátěž způsobenou souběžným vícenásobným připojením klientů obsluhovaným CPU samostatného hlavního serveru.

Nakonec nemusí být InnoDB nejlepším motorem pro datawarehousing, protože se vyskytují operace na disku. Můžete zvážit změnu tabulek datawarehouse na Compressed MyISAM .

¹_{Náhodou mám na mysli, že existuje úzký profil, který zabraňuje zvýšení vaší zátěže nad 25%, ale nemusí to být nutně problém s jedním jádrem.}

Rick James · Answer

Poznámka: Tato odpověď se týká jediného připojení pomocí více jader. Otázka OP byla nejednoznačná; nesprávně předpokládal, že MySQL jako celek nemůže použít více než jedno jádro. Ostatní odpovědi správně poukazují na to, že 3-Alter testovací případ je skutečně vázán na V/V, a proto se neprokazuje otázka názvu.

Jediné připojení bude používat pouze jedno jádro. (OK, InnoDB používá jiná vlákna, tedy jádra, pro některé I/O zpracování, ale to není významné.)

Měli jste 3 ALTERY, takže jste nepoužívali mnohem více než 3 jádra.

Bohužel ani PARTITION nepoužívá více jader.

Až donedávna se vícenásobné spojení maximalizovalo po 4-8 jádrech. Percona Xtradb (součástí MariaDB) lépe využívá více jader, ale stále jen jedno na vlákno. Maximálně dosahují asi 32 jader.

(Aktualizace v roce 2015 :) Více připojení s maximem 5,6 mimo asi 48 jader. 5.7 slibuje, že bude ještě lepší. (Tedy říká Oracle benchmarky.) Stále však nelze použít více jader pro jediné připojení.

Aktualizace (po přechodu na OpenWorld Oracle): nová verze 8.x nebude mít žádný paralelismus.

Další aktualizace - 8.0.17 obsahuje případy, kdy bude na několika vybraných dotazech používat více jader. (To znamená, nebuďte nadšeni.)

jfg956 · Answer

IMHO a v popsaném případu použití nikdy nebudete používat více než jedno jádro. Důvod je ten, že vaše pracovní vytížení je IO vázáno, nikoli vázáno na CPU. Protože vaše 3 připojení vytvářejí nový index, každý z nich potřebuje přečíst celou tabulku z disku: to je to, co bere čas, bez výpočtu indexů.

OkezieE · Answer

Zvažte, že váš úzký profil může být výkonem vašeho souborového systému IO).

Kromě nastavení navržená @RolandoMySQLDBA , jsem také nastavil noatime nastavení připojení v /etc/fstab pro oddíl, který obsahuje můj datový adresář mysql (/data01/mysql v mém případě s /dev/sdb1 připojeno k /data01).

Ve výchozím nastavení linux zaznamenává přístupový čas pro KAŽDÉ čtení nebo zápis na disk, což negativně ovlivňuje IO výkon, zejména pro vysoké IO aplikace jako databáze). To znamená, že i čtení data ze souboru spustí zápis na disk ... WAT!

Chcete-li to zakázat, přidejte možnost noatime mount v /etc/fstab pro požadovaný bod připojení následovně (příklad v mém případě):

/dev/sdb1 /data01 ext4 defaults,noatime 0 2

Poté znovu připojte oddíl:

mount -o,remount /data01

To by mělo zvýšit výkon čtení a zápisu aplikací používajících tento oddíl. Ale ... nic nepřekoná, že drží všechna vaše data v paměti.