Caratteristiche del server

• RAM di sistema totale: 8 GB (su cui è in esecuzione MySQL + altro che MySQL, ovvero non dedicato a MySQL)
• Numero di core della CPU: 6
• Ho dei dati nel db pari a circa 2 GB
• La dimensione del pool di buffer InnoDB è impostata su 4 GB

Che è migliore:

• Istanze pool buffer buffer Innodb impostate su 1?
• Istanze pool buffer Innodb impostate su 2 (2 GB in ciascuna)?
• Istanze pool buffer Innodb impostate su 4 (1 GB in ciascuna)?
• Istanze pool buffer Innodb impostate su 8 (impostazione predefinita)

Non sono quindi sicuro di come ragionare quando si tratta delle istanze del pool di buffer e anche dell'intera "utilizzo delle istanze o dello scambio del sistema operativo quando si hanno dimensioni del pool di buffer InnoDB così grandi".

Quando torno a MySQL 5.5, penso a questa stessa cosa.

Quello che ho imparato in quegli anni è stato il seguente: se il pool di buffer era maggiore della metà della RAM installata e innodb_buffer_pool_instances era 1 (impostazione predefinita per 5.5), la minaccia di scambio era sempre imminente.

Ne ho discusso prima: esiste una regola empirica per quanto riguarda le dimensioni e il numero di istanze di un pool di buffer? . In quel post, ho citato un esempio di un client che aveva 192 GB di RAM sul server con pool di buffer da 162 GB. Quando innodb_buffer_pool_instances era 1, lo scambio è avvenuto. Quando ho impostato innodb_buffer_pool_instances su 2, le cose sono migliorate.

Nel tuo caso, poiché il pool di buffer è esattamente la metà, un valore di 1 potrebbe essere OK. Non me ne sarei mai accorto. Vorrei impostarlo su 2.

Poiché MySQL 5.6 ha un valore predefinito di 8, non dovresti più pensarci.

Dirò questo: la risposta di Akuzminsky ha il principio più alto . La mia risposta è solo sparare dall'anca sulla base di esperienze passate (buone e cattive).

Il numero di istanze del pool buffer deve essere aumentato per evitare la contesa del mutex del pool buffer.

Con dimensioni del pool buffer di 8 GB, dubito che vedrai mai la contesa del mutex del pool buffer.

AGGIORNAMENTO 0 :

Cito il buffer pool da 8 GB nella risposta mentre nella domanda originale la memoria totale era di 8 GB. Certo, il pool di buffer deve essere inferiore a 8 GB. 4 GB sembra un buon inizio, ma assicurati che non si verifichino scambi.

AGGIORNAMENTO 1 :

// dalle diapositive di Yasufumi (nelle versioni recenti di MySQL l'output potrebbe essere leggermente diverso)

Per determinare se è presente una contesa sul pool di buffer, il mutex raccoglie una dozzina di SHOW ENGINE INNODB STATUScampioni durante l'ora di punta.

Quindi aggregalo usando lo snippet di shell:

#!/bin/sh
cat $1.innodb | grep "Mutex at " | cut -d"," -f1 | sort | uniq -c > /tmp/tmp1.txt 
cat $1.innodb | grep "lock on " | cut -d"-"
-f2- | sort | uniq -c > /tmp/tmp2.txt
cat /tmp/tmp1.txt /tmp/tmp2.txt | sort -n > $1.contention rm /tmp/tmp1.txt /tmp/tmp2.txt

che fornisce un output come questo:

.....
4 lock on RW-latch at 0x7fb86b2c9138 created in file dict/dict0dict.c line 1356
6 lock on RW-latch at 0x7fb86b2c4138 created in file dict/dict0dict.c line 1356
12 lock on RW-latch at 0x7fb86b2d9538 created in file dict/dict0dict.c line 1356
20 lock on RW-latch at 0x7fb86b2db138 created in file dict/dict0dict.c line 1356
22 Mutex at 0x7fb86b28f0e0 created file btr/btr0sea.c line 139
30 lock on RW-latch at 0x7fb86b2ba938 created in file dict/dict0dict.c line 1356
36 lock on RW-latch at 0x7fb86b2bad38 created in file dict/dict0dict.c line 1356
71 Mutex at 0x7fb86b28ecb8 created file buf/buf0buf.c line 597
164 lock on RW-latch at 0x7fb86b28f0b8 created in file btr/btr0sea.c line 139

Se vedi un conteggio elevato delle attese di mutex del pool buffer, è tempo di prendere in considerazione più istanze del pool buffer. È improbabile che la contesa si verifichi su un pool di buffer più piccolo di ~ 48G.

Imposta "swappiness" su 1 se il tuo sistema operativo lo possiede. Il problema potrebbe essere una OOM eccessivamente aggressiva.

Vorrei suggerire di impostare questo in modo che corrisponda al numero massimo di thread MySQL che si desidera eseguire contemporaneamente. Uso il numero di core.

Ho anche impostato innodb_read_io_threadse innodb_write_io_threadsper abbinare questo numero.

Se innodb_buffer_pool_instancesè troppo basso, è probabile che i thread rimangano bloccati nelle attese dei semafori. Ciò fa apparire inattivi sia la CPU che l'I / O, anche se il sistema dovrebbe essere occupato e la latenza dell'applicazione passerà attraverso il tetto.