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
Servery jsou docela robustní s načtením typu OLAP/DataWarehouse (DW):
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).
ALTER TABLE...DROP KEY...ADD INDEX
Dejte mi vědět, jestli mi chybělo něco důležitého
Na zdraví
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
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.
MySQL automaticky použije více jader, takže buď vaše zatížení 25% je náhoda1 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 .
1Ná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.
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.)
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ů.
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.