it-swarm-eu.dev

Jak vytěžit maximum z MySQL na stroji Quad Core s 16 GB RAM?

Na své pracovní stanici provozuji server MySQL 5.5 pro analýzu vědeckých dat a přemýšlím, jak nakonfigurovat MySQL, abych z toho co nejlépe využil výkon. Typy dotazů, které obvykle spouštím, zahrnují spojení 10-20 tabulek a mohou běžet docela dlouho, jedna až několik minut není vůbec výjimkou. Pouze velmi málo uživatelů přistupuje k databázi současně (5 je maximum). Přesunul jsem server z Lenovo Thinkpad T61 s duálním jádrem 2,2 GHz a 4 GB RAM) na následující zcela nový stroj s ručně vybranými komponenty:

  • Intel i7 3770, 4x 3,4 GHz (běží @ 4x3,7 GHz)
  • Čipová sada Z77
  • 16 GB paměti DDR3 1600 RAM
  • Windows 7 Prof 64bitový
  • Windows a MySQL server běží na jednotce SSD Intel 520.

První testy (spuštění stejného dotazu na obou strojích) ukázaly definitivní zlepšení rychlosti pro nový, ale dotazy stále zabírají spoustu času a očekával jsem další zvýšení. Dotčené dotazy jsou poměrně dobře optimalizovány, tj. Všechny tabulky mají správný klíč, který se také používá jako „vysvětlte rozšířené“.

Nyní k mému současnému nastavení MySQL: Nejprve bych měl zmínit, že jsem se dávno přestěhoval z MyISAM do Innodbu.

Některé moje vylepšení my.ini (tj. Odchylky od výchozího nastavení):

# Maximum size for internal (in-memory) temporary tables. If a table
# grows larger than this value, it is automatically converted to disk
# based table This limitation is for a single table. There can be many
# of them.
#tmp_table_size=35M
tmp_table_size=4000M
max_heap_table_size=4000M

# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and
# row data. The bigger you set this the less disk I/O is needed to
# access data in tables. On a dedicated database server you may set this
# parameter up to 80% of the machine physical memory size. Do not set it
# too large, though, because competition of the physical memory may
# cause paging in the operating system.  Note that on 32bit systems you
# might be limited to 2-3.5G of user level memory per process, so do not
# set it too high.
#innodb_buffer_pool_size=96M
innodb_buffer_pool_size=800M

general-log
expire_logs_days = 60
general_log_file = "F:/my_query_mysql.log"
log-output = TABLE
optimizer_search_depth = 0 #meant to cure the "statistics state" bug in some queries

Chtěl bych vědět, zda by někdo navrhl změny výše uvedených čísel nebo dokonce další nastavení, o kterých nevím.

Ocenil bych jakoukoli užitečnou poznámku.

Steve

ÚPRAVA: Mám dva dotazy týkající se spojení napříč 10-20 tabulkami a spustil jsem je v notebooku Lenovo a v novém počítači. Otázka č. 1 trvala 3m36s na novém počítači vs 9m11s na notebooku; Dotaz č. 2 trval 22,5 s na pracovní stanici oproti 48,5 s na notebooku. Rychlost provádění se tedy zvýšila zhruba o faktor 2-2,5. Na pracovní stanici nebylo použito ani 50% RAM). Průměrné zatížení CPU na čtyřech jádrech (jak uvádí Správce úloh systému Windows) bylo pouze asi 13%. -core základ (jak uvádí Core Temp) byl asi 25-40% pro ONE jádro, zatímco to bylo <= 10% pro ostatní, což naznačuje, že MySQL nevyužívá více jader pro jediný dotaz.

10
Steve06

Protože používáte MySQL 5.5, můžete zvážit konfiguraci InnoDB pro přístup k více jádrům

Zde jsou nastavení, která byste měli používat

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

Zde jsou mé minulé příspěvky na MySQL 5.5 a aktivace více jader pro InnoDB

5
RolandoMySQLDBA

Percona - přední konzultant MySQL nabízí MySQL průvodce konfigurací . To vám umožní nakonfigurovat my.cnf/my.ini v závislosti na konfiguraci systému.

Také Percona lidé vydali knihu s názvem " High Performance MySQL ". Třetí vydání bylo nedávno vydáno a zahrnuje ladění do detailů.

2
Mahesh Patil

Využití paměti: viz http://mysql.rjweb.org/doc.php/memory (Většina laditelných tunerů nezáleží na dostatečném rozdílu.)

max_heap_table_size = 4000M je nebezpečně vysoká! Pokud to potřebují 4 uživatelé, jste mimo RAM a vyměňujete se. Výměna poškozuje výkon mnohem více než prakticky cokoli).

Dotazy trvající déle než několik sekund: Měly by být studovány pro zlepšení; poskytněte ZOBRAZIT TABULKU VYTVOŘENÍ; ZOBRAZIT STOLNÍ STAV; VYBRAT VYBRAT

1
Rick James

Můžete také zvážit možnosti vydry. Například PostgreSQL na FreeBSD. Přechod z Windows na Linux však zvýší váš výkon.

0
ilhan