Da quando MySQL è stato originariamente biforcato per formare MariaDB, è stato ampiamente supportato e adottato rapidamente da un vasto pubblico nella comunità di database open source. Originariamente un sostituto drop-in, MariaDB ha iniziato a distinguersi da MySQL, specialmente con il rilascio di MariaDB 10.2.
Nonostante ciò, tuttavia, non c'è ancora alcuna reale differenza significativa tra MariaDB e MySQL, poiché entrambi hanno motori compatibili e possono funzionare in modo nativo l'uno con l'altro. Quindi non sorprenderti se l'ottimizzazione della configurazione di MariaDB ha un approccio simile a un'ottimizzazione di MySQL.
Questo blog discuterà dell'ottimizzazione di MariaDB, in particolare di quei sistemi che funzionano in un ambiente Linux.
Ottimizzazione hardware e di sistema MariaDB
MariaDB consiglia di migliorare il tuo hardware nel seguente ordine di priorità...
Memoria
La memoria è il fattore più importante per i database in quanto consente di regolare le variabili di sistema del server. Più memoria significa cache di chiavi e tabelle più grandi, che vengono archiviate in memoria in modo che i dischi possano accedere, un ordine di grandezza più lento, viene successivamente ridotta.
Tieni presente, tuttavia, che la semplice aggiunta di più memoria potrebbe non comportare miglioramenti drastici se le variabili del server non sono impostate per utilizzare la memoria extra disponibile.
L'utilizzo di più slot RAM sulla scheda madre aumenta la frequenza del bus e ci sarà più latenza tra la RAM e la CPU. Ciò significa che è preferibile utilizzare la dimensione RAM massima per slot.
Dischi
L'accesso veloce al disco è fondamentale, poiché alla fine è dove risiedono i dati. La cifra chiave è il tempo di ricerca del disco (una misura della velocità con cui il disco fisico può spostarsi per accedere ai dati), quindi scegli i dischi con un tempo di ricerca il più basso possibile. Puoi anche aggiungere dischi dedicati per file temporanei e registri delle transazioni.
Ethernet veloce
Con i requisiti appropriati per la tua larghezza di banda Internet, ethernet veloce significa che può avere una risposta più rapida alle richieste dei clienti, tempi di risposta della replica per leggere i log binari attraverso gli slave, anche tempi di risposta più rapidi sono molto importanti soprattutto su Galera cluster basati su.
CPU
Sebbene i colli di bottiglia hardware spesso cadano altrove, i processori più veloci consentono di eseguire calcoli più rapidamente e di inviare i risultati al client più rapidamente. Oltre alla velocità del processore, anche la velocità del bus del processore e la dimensione della cache sono fattori importanti da considerare.
Impostazione del programmatore di I/O del disco
Gli schedulatori di I/O esistono come un modo per ottimizzare le richieste di accesso al disco. Unisce le richieste di I/O a posizioni simili sul disco. Ciò significa che l'unità disco non ha bisogno di cercare così spesso e migliora un enorme tempo di risposta complessivo e salva le operazioni del disco. I valori consigliati per le prestazioni I/O sono noop e scadenza.
noop è utile per verificare se le complesse decisioni di pianificazione I/O di altri schedulatori non causano regressioni delle prestazioni I/O. In alcuni casi può essere utile per dispositivi che effettuano autonomamente la pianificazione dell'I/O, come storage intelligente, o dispositivi che non dipendono da movimenti meccanici, come gli SSD. Di solito, lo scheduler I/O DEADLINE è una scelta migliore per questi dispositivi, ma a causa del minor sovraccarico NOOP può produrre prestazioni migliori su determinati carichi di lavoro.
Per la scadenza, è uno scheduler I/O orientato alla latenza. Ad ogni richiesta di I/O è assegnata una scadenza. Di solito, le richieste vengono archiviate in code (lettura e scrittura) ordinate per numeri di settore. L'algoritmo DEADLINE mantiene due code aggiuntive (lettura e scrittura) in cui le richieste vengono ordinate per scadenza. Finché nessuna richiesta è scaduta, viene utilizzata la coda "settore". Se si verificano timeout, le richieste dalla coda "scadenza" vengono servite fino a quando non ci sono più richieste scadute. In genere, l'algoritmo preferisce le letture alle scritture.
Per i dispositivi PCIe (unità SSD NVMe), hanno le proprie code interne di grandi dimensioni insieme a un servizio rapido e non richiedono né traggono vantaggio dall'impostazione di uno scheduler I/O. Si consiglia di non avere parametri di configurazione espliciti in modalità pianificazione.
Puoi controllare l'impostazione della pianificazione con:
cat /sys/block/${DEVICE}/queue/schedulerAd esempio, dovrebbe apparire come questo output:
cat /sys/block/sda/queue/scheduler
[noop] deadline cfqPer renderlo permanente, modifica il file di configurazione /etc/default/grub, cerca la variabile GRUB_CMDLINE_LINUX e aggiungi elevator proprio come di seguito:
GRUB_CMDLINE_LINUX="elevator=noop"Aumenta il limite di file aperti
Per garantire buone prestazioni del server, il numero totale di connessioni client, file di database e file di registro non deve superare il limite massimo del descrittore di file sul sistema operativo (ulimit -n). I sistemi Linux limitano il numero di descrittori di file che un processo può aprire a 1.024 per processo. Sui server di database attivi (soprattutto quelli di produzione) può facilmente raggiungere il limite di sistema predefinito.
Per aumentare questo, modifica /etc/security/limits.conf e specifica o aggiungi quanto segue:
mysql soft nofile 65535
mysql hard nofile 65535Ciò richiede un riavvio del sistema. Successivamente, puoi confermare eseguendo quanto segue:
$ ulimit -Sn
65535
$ ulimit -Hn
65535Opzionalmente, puoi impostarlo tramite mysqld_safe se stai avviando il processo mysqld tramite mysqld_safe,
[mysqld_safe]
open_files_limit=4294967295o se stai usando systemd,
sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF
[Service]
LimitNOFILE=infinity
EOF
sudo systemctl daemon-reloadImpostazione di Swappiness su Linux per MariaDB
Linux Swap gioca un ruolo importante nei sistemi di database. Si comporta come la tua ruota di scorta nel tuo veicolo, quando brutte perdite di memoria interferiscono con il tuo lavoro, la macchina rallenterà... ma nella maggior parte dei casi sarà comunque utilizzabile per completare il compito assegnato.
Per applicare le modifiche alla tua swappiness, esegui semplicemente
sysctl -w vm.swappiness=1Ciò avviene dinamicamente, senza bisogno di riavviare il server. Per renderlo persistente, modifica /etc/sysctl.conf e aggiungi la riga,
vm.swappiness=1È abbastanza comune impostare swappiness=0, ma dal rilascio di nuovi kernel (cioè kernel> 2.6.32-303), sono state apportate modifiche quindi è necessario impostare vm.swappiness=1.
Ottimizzazioni del file system per MariaDB
I file system più comuni utilizzati negli ambienti Linux che eseguono MariaDB sono ext4 e XFS. Sono inoltre disponibili alcune configurazioni per l'implementazione di un'architettura utilizzando ZFS e BRTFS (come indicato nella documentazione di MariaDB).
Oltre a questo, la maggior parte delle impostazioni del database non ha bisogno di registrare il tempo di accesso ai file. Potresti voler disabilitarlo quando monti il volume nel sistema. Per fare ciò, modifica il tuo file /etc/fstab. Ad esempio, su un volume chiamato /dev/md2, ecco come appare:
/dev/md2 / ext4 defaults,noatime 0 0Creazione di un'istanza MariaDB ottimale
Memorizza i dati su un volume separato
È sempre l'ideale separare i dati del database su un volume separato. Questo volume è specifico per quei tipi di volumi di archiviazione veloci come schede SSD, NVMe o PCIe. Ad esempio, se l'intero volume di sistema si guasta, il volume del database sarà al sicuro e ti assicuriamo che non verrà influenzato nel caso in cui l'hardware di archiviazione si guasta.
Ottimizza MariaDB per utilizzare la memoria in modo efficiente
innodb_buffer_pool_size
Il valore principale da regolare su un server di database con tabelle interamente/principalmente XtraDB/InnoDB può essere impostato fino all'80% della memoria totale in questi ambienti. Se impostato su 2 GB o più, probabilmente vorrai regolare anche innodb_buffer_pool_instances. Puoi impostarlo dinamicamente se stai usando MariaDB>=versione 10.2.2. In caso contrario, richiede il riavvio del server.
tmp_memory_table_size/max_heap_table_size
Per tmp_memory_table_size (tmp_table_size), se hai a che fare con tabelle temporanee di grandi dimensioni, impostarlo su un valore più alto fornisce miglioramenti delle prestazioni poiché verrà archiviato nella memoria. Questo è comune nelle query che utilizzano pesantemente GROUP BY, UNION o sottoquery. Sebbene se max_heap_table_size è inferiore, verrà applicato il limite inferiore. Se una tabella supera il limite, MariaDB la converte in una tabella MyISAM o Aria. Puoi vedere se è necessario aumentare confrontando le variabili di stato Created_tmp_disk_tables e Created_tmp_tables per vedere quante tabelle temporanee del totale creato devono essere convertite su disco. Spesso le query GROUP BY complesse sono responsabili del superamento del limite.
Mentre max_heap_table_size, questa è la dimensione massima per le tabelle MEMORY create dall'utente. Il valore impostato su questa variabile è applicabile solo alle tabelle appena create o ricreate e non a quelle esistenti. Il più piccolo di max_heap_table_size e tmp_table_size limita anche le tabelle in memoria interne. Quando viene raggiunta la dimensione massima, qualsiasi ulteriore tentativo di inserimento di dati riceverà un errore "tabella ... è piena". Le tabelle temporanee create con CREATE TEMPORARY non verranno convertite in Aria, come accade con le tabelle temporanee interne, ma riceveranno anche un errore di tabella piena.
innodb_log_file_size
Le memorie di grandi dimensioni con elaborazione ad alta velocità e disco I/O veloce non sono nuove e hanno un prezzo ragionevole come consigliato. Se preferisci maggiori guadagni in termini di prestazioni soprattutto durante e la gestione delle tue transazioni InnoDB, è ragionevole impostare la variabile innodb_log_file_size su un valore maggiore come 5Gib o anche 10GiB. Aumentare significa che le transazioni più grandi possono essere eseguite senza la necessità di eseguire l'I/O del disco prima del commit.
join_buffer_size
In alcuni casi, le tue query tendono a non utilizzare un'indicizzazione adeguata o semplicemente, ci sono istanze in cui è necessario eseguire questa query. A meno che non venga chiamata o invocata pesantemente dal punto di vista del client, l'impostazione di questa variabile è la cosa migliore a livello di sessione. Aumentalo per ottenere join completi più rapidi quando l'aggiunta di indici non è possibile, anche se tieni presente i problemi di memoria, poiché i join allocheranno sempre la dimensione minima.
Imposta il tuo max_allowed_packet
MariaDB ha la stessa natura di MySQL quando gestisce i pacchetti. Suddivide i dati in pacchetti e il client deve essere a conoscenza del valore della variabile max_allowed_packet. Il server avrà un buffer per memorizzare il corpo con una dimensione massima corrispondente a questo valore max_allowed_packet. Se il client invia più dati della dimensione max_allowed_packet, il socket verrà chiuso. La direttiva max_allowed_packet definisce la dimensione massima del pacchetto che può essere inviato.
L'impostazione di questo valore troppo basso può causare l'interruzione di una query e la chiusura della connessione client, il che è abbastanza comune per ricevere errori come ER_NET_PACKET_TOO_LARGE o connessione persa al server MySQL durante la query. Idealmente, soprattutto per la maggior parte delle richieste di applicazioni oggi, puoi iniziare a impostarlo su 512 MiB. Se si tratta di un tipo di applicazione a bassa richiesta, basta utilizzare il valore predefinito e impostare questa variabile solo tramite sessione quando necessario se i dati da inviare o ricevere sono troppo grandi del valore predefinito (16MiB da MariaDB 10.2.4). In alcuni carichi di lavoro che richiedono l'elaborazione di pacchetti di grandi dimensioni, è necessario regolarne l'aumento in base alle proprie esigenze, soprattutto durante la replica. Se max_allowed_packet è troppo piccolo sullo slave, anche lo slave interrompe il thread di I/O.
Utilizzo di Threadpool
In alcuni casi, questa regolazione potrebbe non essere necessaria o consigliata per te. I threadpool sono più efficienti in situazioni in cui le query sono relativamente brevi e il carico è vincolato alla CPU (carichi di lavoro OLTP). Se il carico di lavoro non è vincolato alla CPU, potresti comunque voler limitare il numero di thread per risparmiare memoria per i buffer di memoria del database.
L'uso del pool di thread è una soluzione ideale, specialmente se il tuo sistema sta subendo un cambio di contesto e stai cercando modi per ridurlo e mantenere un numero di thread inferiore al numero di client. Tuttavia, anche questo numero non dovrebbe essere troppo basso, poiché vogliamo anche sfruttare al massimo le CPU disponibili. Pertanto dovrebbe esserci, idealmente, un singolo thread attivo per ogni CPU sulla macchina.
Puoi impostare thread_pool_max_threads, thread_pool_min_threads per il numero massimo e minimo di thread. A differenza di MySQL, questo è presente solo in MariaDB.
Imposta la variabile thread_handling che determina come il server gestisce i thread per le connessioni client. Oltre ai thread per le connessioni client, questo vale anche per alcuni thread del server interni, come i thread slave Galera.
Ottimizza la cache della tua tabella + max_connections
Se si verificano casi occasionali nell'elenco dei processi relativi all'apertura di tabelle e agli stati di chiusura delle tabelle, può significare che è necessario aumentare la cache della tabella. Puoi monitorarlo anche tramite il prompt del client mysql eseguendo SHOW GLOBAL STATUS LIKE 'Open%table%'; e monitorare le variabili di stato.
Per max_connections, se l'applicazione richiede molte connessioni simultanee, puoi iniziare a impostarlo su 500.
Per table_open_cache, deve essere il numero totale delle tue tabelle ma è meglio aggiungerne altre a seconda del tipo di query che servi poiché anche le tabelle temporanee devono essere memorizzate nella cache. Ad esempio, se hai 500 tabelle, sarebbe ragionevole iniziare con 1500.
Mentre table_open_cache_instances, inizia a impostarlo su 8. Ciò può migliorare la scalabilità riducendo la contesa tra le sessioni, la cache delle tabelle aperte può essere partizionata in diverse istanze cache più piccole di dimensioni table_open_cache / table_open_cache_instances.
Per InnoDB, table_definition_cache funge da limite software per il numero di istanze di tabelle aperte nella cache del dizionario dati di InnoDB. Il valore da definire imposterà il numero di definizioni di tabella che possono essere archiviate nella cache delle definizioni. Se utilizzi un numero elevato di tabelle, puoi creare una cache di definizione delle tabelle di grandi dimensioni per accelerare l'apertura delle tabelle. La cache di definizione della tabella occupa meno spazio e non utilizza descrittori di file, a differenza della normale cache delle tabelle. Il valore minimo è 400. Il valore predefinito si basa sulla formula seguente, con un limite massimo di 2000:
MIN(400 + table_open_cache / 2, 2000)Se il numero di istanze di tabelle aperte supera l'impostazione table_definition_cache, il meccanismo LRU inizia a contrassegnare le istanze di tabella per l'eliminazione e alla fine le rimuove dalla cache del dizionario dati. Il limite aiuta a risolvere le situazioni in cui quantità significative di memoria verrebbero utilizzate per memorizzare nella cache istanze di tabelle utilizzate raramente fino al successivo riavvio del server. Il numero di istanze di tabella con metadati memorizzati nella cache potrebbe essere superiore al limite definito da table_definition_cache, perché le istanze di tabella padre e figlio con relazioni di chiave esterna non vengono inserite nell'elenco LRU e non sono soggette a rimozione dalla memoria.
A differenza di table_open_cache, table_definition_cache non utilizza descrittori di file ed è molto più piccola.
Gestione della cache delle query
Preferibilmente, consigliamo di disabilitare la cache delle query in tutta la configurazione di MariaDB. È necessario assicurarsi che query_cache_type=OFF e query_cache_size=0 per completare la disabilitazione della cache delle query. A differenza di MySQL, MariaDB supporta ancora completamente la cache delle query e non ha in programma di ritirare il supporto per utilizzare la cache delle query. Alcune persone affermano che la cache delle query offre ancora vantaggi in termini di prestazioni. Tuttavia, questo post di Percona La cache delle query MySQL:il peggior nemico o il migliore amico rivela che la cache delle query, se abilitata, risulta avere un sovraccarico e mostra di avere prestazioni del server scadenti.
Se intendi utilizzare la cache delle query, assicurati di monitorare la cache delle query eseguendo SHOW GLOBAL STATUS LIKE 'Qcache%';. Qcache_inserts contiene il numero di query aggiunte alla cache delle query, Qcache_hits contiene il numero di query che hanno utilizzato la cache delle query, mentre Qcache_lowmem_prunes contiene il numero di query che sono state eliminate dalla cache per mancanza di memoria. A tempo debito, l'utilizzo e l'abilitazione della cache delle query potrebbero frammentarsi. Un Qcache_free_blocks alto rispetto a Qcache_total_blocks può indicare una frammentazione. Per deframmentarlo, eseguire FLUSH QUERY CACHE. Ciò deframmenterà la cache delle query senza eliminare alcuna query.
Controlla sempre i tuoi server
È molto importante monitorare correttamente i nodi MariaDB. Sono disponibili strumenti di monitoraggio comuni (come Nagios, Zabbix o PMM) se tendi a preferire strumenti gratuiti e open source. Per gli strumenti aziendali e completi ti suggeriamo di provare ClusterControl, in quanto non solo fornisce monitoraggio, ma offre anche performance advisor, avvisi e allarmi che ti aiutano a migliorare le prestazioni del tuo sistema e rimanere aggiornato con le attuali tendenze mentre interagisci con il team di supporto. Il monitoraggio del database con ClusterControl è gratuito e fa parte della Community Edition.
Conclusione
L'ottimizzazione della configurazione di MariaDB è quasi lo stesso approccio di MySQL, ma con alcune disparità, poiché differisce in alcuni dei suoi approcci e versioni che supporta. MariaDB è ora un'entità diversa nel mondo dei database e ha rapidamente guadagnato la fiducia della comunità senza alcun FUD. Hanno le loro ragioni per cui deve essere implementato in questo modo, quindi è molto importante sapere come ottimizzarlo e ottimizzare i tuoi server MariaDB.
