Come ottenere il massimo da MySQL su una macchina QuadCore con 16 GB di RAM?


10

Sto eseguendo un server MySQL 5.5 sulla mia stazione di lavoro per l'analisi dei dati scientifici e mi chiedo come configurare MySQL per ottenere il massimo dalle prestazioni. I tipi di query che eseguo in genere riguardano join di 10-20 tabelle e possono essere eseguiti per un periodo piuttosto lungo, da uno a diversi minuti senza alcuna eccezione. Solo pochissimi utenti accedono al database contemporaneamente (5 è il massimo). Ho spostato il server da un Lenovo Thinkpad T61 con un Dual Core da 2,2 GHz e 4 GB di RAM alla seguente macchina nuova di zecca con componenti selezionati manualmente:

  • Intel i7 3770, 4x 3,4 GHz (in esecuzione @ 4x3,7 GHz)
  • Chipset Z77
  • 16 GB di RAM DDR3 1600
  • Windows 7 Prof 64-bit
  • I server Windows e MySQL funzionano su un'unità SSD Intel serie 520.

I primi test (eseguendo la stessa query su entrambe le macchine) hanno mostrato un miglioramento definitivo della velocità per quello nuovo, ma le query richiedono ancora molto tempo e mi aspettavo un aumento maggiore. Le query in questione sono abbastanza ben ottimizzate, vale a dire che tutte le tabelle hanno una chiave corretta che viene anche utilizzata come "spiegazione estesa".

Ora alle mie attuali impostazioni di MySQL: per prima cosa dovrei menzionare che sono passato da MyISAM a Innodb molto tempo fa.

Alcune delle mie modifiche a my.ini (es. Partenze dalle impostazioni predefinite):

# 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

Mi piacerebbe sapere se qualcuno suggerirebbe modifiche ai numeri precedenti o anche ulteriori impostazioni che non conosco.

Gradirei qualsiasi commento utile.

Steve

EDIT: Ho due query che coinvolgono join su 10-20 tavoli e le ho eseguite sul mio notebook Lenovo e sul nuovo PC. La query n. 1 ha richiesto 3m36s sulla nuova macchina contro 9m11s sul laptop; La query n. 2 ha richiesto 22,5 secondi sulla workstation rispetto a 48,5 secondi sul laptop. Quindi la velocità di esecuzione è stata migliorata di circa il fattore 2-2,5. Sulla workstation non è stato utilizzato nemmeno il 50% della RAM. Il carico medio della CPU tra i quattro core (come riportato da Task Manager di Windows) era solo del 13% circa. Il carico su base core (come riportato da Core Temp) era di circa il 25-40% per ONE core, mentre era <= 10% per gli altri, indicando che MySQL non utilizza più core per una singola query .


Mostra il carico del tuo server, quindi controlla la memoria, io, i carichi della cpu ecc.

Eseguirò alcuni test e

Questo dovrebbe essere sufficiente per una prima indicazione per vedere dove si trova il problema.

ho appena aggiunto alcune statistiche.

2
Inoltre, puoi anche provare la procedura guidata Percona per ottenere le impostazioni "consigliate" per il tuo server di database su tools.percona.com/wizard
Stephen Senkomago Musoke,

Risposte:


5

Dato che stai eseguendo MySQL 5.5, potresti prendere in considerazione la configurazione di InnoDB per accedere a più core

Ecco le impostazioni che dovresti usare

innodb_thread_concurrency imposta il limite superiore sul numero di thread simultanei che InnoDB può tenere aperti. Il miglior numero di round da impostare per questo è (2 X Numero di CPU) + Numero di dischi. AGGIORNAMENTO : Come ho appreso in prima persona dalla Conferenza di Percona a New York, dovresti impostarlo su 0 per avvisare InnoDB Storage Engine di trovare il miglior numero di thread per l'ambiente in cui è in esecuzione.

innodb_concurrency_tickets imposta il numero di thread che possono bypassare il controllo della concorrenza impunemente. Una volta raggiunto questo limite, il controllo della concorrenza dei thread diventa di nuovo la norma.

innodb_commit_concurrency imposta il numero di transazioni simultanee che possono essere impegnate. Poiché il valore predefinito è 0, la mancata impostazione consente a qualsiasi numero di transazioni di impegnarsi contemporaneamente.

innodb_thread_sleep_delay imposta il numero di millisecondi in cui un thread InnoDB può essere inattivo prima di rientrare nella coda InnoDB. L'impostazione predefinita è 10000 (10 sec).

innodb_read_io_threads e innodb_write_io_threads (entrambi da MySQL 5.1.38) allocare il numero specificato di thread per letture e scritture. L'impostazione predefinita è 4 e il massimo è 64.

innodb_replication_delay impone che il ritardo del thread su uno slave sia raggiunto innodb_thread_concurrency

Ecco i miei post precedenti su MySQL 5.5 e l'attivazione di più core per InnoDB


2

Percona - Il principale consulente MySQL offre una procedura guidata per la configurazione di MySQL . Ti consente di configurare in my.cnf/my.inibase alla configurazione del tuo sistema.

Anche le persone di Percona hanno pubblicato un libro intitolato " High Performance MySQL ". La terza edizione è stata recentemente pubblicata e tratta l'accordatura in modo molto dettagliato.


sono questi valori ciò che suggeriscono per una buona prestazione o semplicemente sputa ciò che ho inserito?
OpenCoderX l'

1

Utilizzo della memoria: vedi http://mysql.rjweb.org/doc.php/memory (La maggior parte dei parametri sintonizzabili non farà abbastanza differenza per la materia.)

max_heap_table_size = 4000M è pericolosamente alto! Se 4 utenti ne hanno bisogno, sei a corto di RAM e di scambio. Lo scambio danneggia le prestazioni molto più di qualsiasi altra cosa.

Domande che richiedono più di qualche secondo: dovrebbero essere studiate per il miglioramento; fornire SHOW CREATE TABLE; MOSTRA STATO TABELLA; SPIEGA SELEZIONA


0

Puoi prendere in considerazione anche altre opzioni. Come PostgreSQL su FreeBSD. Ma passare da Windows a Linux aumenterà le prestazioni.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.