Un cheat sheet sulle prestazioni per MongoDB

Le prestazioni del database influiscono sulle prestazioni dell'organizzazione e tendiamo a cercare una soluzione rapida. Esistono molte strade diverse per migliorare le prestazioni in MongoDB. In questo blog, ti aiuteremo a comprendere meglio il carico di lavoro del database e le cose che potrebbero danneggiarlo. La conoscenza di come utilizzare risorse limitate è essenziale per chiunque gestisca un database di produzione.

Ti mostreremo come identificare i fattori che limitano le prestazioni del database. Per garantire che il database funzioni come previsto, inizieremo dallo strumento di monitoraggio MongoDB Cloud gratuito. Quindi verificheremo come gestire i file di registro e come esaminare le query. Per essere in grado di ottenere un utilizzo ottimale delle risorse hardware, daremo un'occhiata all'ottimizzazione del kernel e ad altre impostazioni cruciali del sistema operativo. Infine, esamineremo la replica di MongoDB e come esaminare le prestazioni.

Monitoraggio gratuito delle prestazioni

MongoDB ha introdotto uno strumento gratuito di monitoraggio delle prestazioni nel cloud per istanze standalone e set di repliche. Se abilitati, i dati monitorati vengono caricati periodicamente sul servizio cloud del fornitore. Ciò non richiede agenti aggiuntivi, la funzionalità è integrata nel nuovo MongoDB 4.0+. Il processo è abbastanza semplice da configurare e gestire. Dopo l'attivazione del comando singolo, otterrai un indirizzo Web univoco per accedere alle tue recenti statistiche sulle prestazioni. Puoi accedere solo ai dati monitorati che sono stati caricati nelle ultime 24 ore.

Ecco come attivare questa funzione. Puoi abilitare/disabilitare il monitoraggio gratuito durante il runtime utilizzando:

-- Enable Free Monitoring
db.enableFreeMonitoring()
-- Disable Free Monitoring
db.disableFreeMonitoring()

Puoi anche abilitare o disabilitare il monitoraggio gratuito durante l'avvio di mongod utilizzando l'impostazione del file di configurazione cloud.monitoring.free.state o l'opzione della riga di comando --enableFreeMonitoring

db.enableFreeMonitoring()

Dopo l'attivazione, vedrai un messaggio con lo stato attuale.

{
    "state" : "enabled",
    "message" : "To see your monitoring data, navigate to the unique URL below. Anyone you share the URL with will also be able to view this page. You can disable monitoring at any time by running db.disableFreeMonitoring().",
    "url" : "https://cloud.mongodb.com/freemonitoring/cluster/XEARVO6RB2OTXEAHKHLKJ5V6KV3FAM6B",
    "userReminder" : "",
    "ok" : 1
}

Copia/incolla semplicemente l'URL dall'output di stato nel browser e puoi iniziare a controllare le metriche delle prestazioni.

Il monitoraggio MongoDB Free fornisce informazioni sulle seguenti metriche:

• Tempi di esecuzione dell'operazione (LETTURA, SCRITTURA, COMANDI)
• Utilizzo del disco (% UTIL MASSIMA DI QUALSIASI UNITÀ, % UTIL MEDIA DI TUTTE LE UNITÀ)
• Memoria (RESIDENTE, VIRTUALE, MAPPATA)
• Rete - Ingresso/Uscita (BYTES IN, BYTES OUT)
• Rete - Numero richieste (NUM RICHIESTE)
• Opcounter (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Opcounters - Replica (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Targeting delle query (SCANSIONATI / RESTITUITI, OGGETTI SCANSIONATI / RESTITUITI)
• Code (LETTORI, SCRITTORI, TOTALE)
• Utilizzo della CPU di sistema (USER, NICE, KERNEL, IOWAIT, IRQ, SOFT IRQ, STEAL, GUEST)

Per visualizzare lo stato del tuo servizio di monitoraggio gratuito, utilizza il seguente metodo:

db.getFreeMonitoringStatus()

Il serverStatus e l'helper db.serverStatus() includono anche statistiche di monitoraggio gratuite nel campo Monitoraggio gratuito.

Durante l'esecuzione con il controllo dell'accesso, l'utente deve disporre dei seguenti privilegi per abilitare il monitoraggio gratuito e ottenere lo stato:

{ resource: { cluster : true }, actions: [ "setFreeMonitoring", "checkFreeMonitoringStatus" ] }

Questo strumento potrebbe essere un buon inizio per coloro che hanno difficoltà a leggere l'output dello stato del server MongoDB dalla riga di comando:

db.serverStatus()

Il monitoraggio gratuito è un buon inizio ma ha opzioni molto limitate, se hai bisogno di uno strumento più avanzato potresti voler controllare MongoDB Ops Manager o ClusterControl.

Registrazione delle operazioni del database

I driver MongoDB e le applicazioni client possono inviare informazioni al file di registro del server. Tali informazioni dipendono dal tipo di evento. Per verificare le impostazioni correnti, accedi come amministratore ed esegui:

db.getLogComponents()

I messaggi di registro includono molti componenti. Ciò serve a fornire una categorizzazione funzionale dei messaggi. Per ciascuno dei componenti è possibile impostare una diversa verbosità del log. L'elenco corrente dei componenti è:

ACCESS, COMMAND, CONTROL, FTD, GEO, INDEX, NETWORK, QUERY, REPL_HB, REPL, ROLLBACK, REPL, SHARDING, STORAGE, RECOVERY, JOURNAL, STORAGE, WRITE.

Per maggiori dettagli su ciascuno dei componenti, controlla la documentazione.

Acquisizione delle query - Database Profiler

MongoDB Database Profiler raccoglie informazioni sulle operazioni eseguite su un'istanza mongod. Per impostazione predefinita, il profiler non raccoglie alcun dato. Puoi scegliere di raccogliere tutte le operazioni (valore 2) o quelle che richiedono più tempo del valore di slowms . Quest'ultimo è un parametro di istanza che può essere controllato tramite il file di configurazione di mongodb. Per controllare il livello attuale:

db.getProfilingLevel()

Per acquisire tutte le query impostate:

db.setProfilingLevel(2)

Nel file di configurazione puoi impostare:

profile = <0/1/2>
slowms = <value>

Questa impostazione verrà applicata su una singola istanza e non si propagherà in un set di repliche o in un cluster condiviso, quindi è necessario ripetere questo comando su tutti i nodi se si desidera acquisire tutte le attività. La profilazione del database può influire sulle prestazioni del database. Abilita questa opzione solo dopo un'attenta considerazione.

Quindi per elencare i 10 più recenti:

db.system.profile.find().limit(10).sort(
{ ts : -1 }
).pretty()

Per elencare tutto:

db.system.profile.find( { op:
{ $ne : 'command' }
} ).pretty()

E per elencare una collezione specifica:

db.system.profile.find(
{ ns : 'mydb.test' }
).pretty()

Registrazione MongoDB

La posizione del registro di MongoDB è definita nell'impostazione del percorso di registro della configurazione e di solito è /var/log/mongodb/mongod.log. Puoi trovare il file di configurazione di MongoDB in /etc/mongod.conf.

Ecco i dati di esempio:

2018-07-01T23:09:27.101+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to node1:27017
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Failed to connect to node1:27017 - HostUnreachable: Connection refused
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Dropping all pooled connections to node1:27017 due to failed operation on a connection
2018-07-01T23:09:27.102+0000 I REPL_HB  [replexec-2] Error in heartbeat (requestId: 21589) to node1:27017, response status: HostUnreachable: Connection refused
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to node1:27017

È possibile modificare la verbosità del registro del componente impostando (esempio di query):

db.setLogLevel(2, "query")

Il file di registro può essere significativo, quindi potresti voler cancellarlo prima della profilazione. Dalla console della riga di comando di MongoDB, inserisci:

db.runCommand({ logRotate : 1 });

Verifica dei parametri del sistema operativo

Limiti di memoria

Per vedere i limiti associati al tuo login, usa il comando ulimit -a. Le seguenti soglie e impostazioni sono particolarmente importanti per le distribuzioni mongod e mongos:

-f (file size): unlimited
-t (cpu time): unlimited
-v (virtual memory): unlimited
-n (open files): 64000
-m (memory size): unlimited [1]
-u (processes/threads): 32000

La versione più recente dello script di avvio di mongod (/etc/init.d/mongod) ha le impostazioni predefinite integrate nell'opzione di avvio:

start()
{
  # Make sure the default pidfile directory exists
  if [ ! -d $PIDDIR ]; then
    install -d -m 0755 -o $MONGO_USER -g $MONGO_GROUP $PIDDIR
  fi

  # Make sure the pidfile does not exist
  if [ -f "$PIDFILEPATH" ]; then
      echo "Error starting mongod. $PIDFILEPATH exists."
      RETVAL=1
      return
  fi

  # Recommended ulimit values for mongod or mongos
  # See http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings
  #
  ulimit -f unlimited
  ulimit -t unlimited
  ulimit -v unlimited
  ulimit -n 64000
  ulimit -m unlimited
  ulimit -u 64000
  ulimit -l unlimited

  echo -n $"Starting mongod: "
  daemon --user "$MONGO_USER" --check $mongod "$NUMACTL $mongod $OPTIONS >/dev/null 2>&1"
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/mongod
}

Il ruolo del sottosistema di gestione della memoria, chiamato anche gestore della memoria virtuale, è gestire l'allocazione della memoria fisica (RAM) per l'intero kernel e i programmi utente. Questo è controllato dai parametri vm.*. Ce ne sono due che dovresti considerare in primo luogo per ottimizzare le prestazioni di MongoDB:vm.dirty_ratio e vm.dirty_background_ratio .

vm.dirty_ratio è la quantità massima assoluta di memoria di sistema che può essere riempita con pagine sporche prima che tutto venga eseguito il commit su disco. Quando il sistema arriva a questo punto, tutti i nuovi blocchi di I/O fino a quando le pagine sporche non sono state scritte su disco. Questa è spesso la fonte di lunghe pause di I/O. Il valore predefinito è 30, che di solito è troppo alto. vm.dirty_background_ratio è la percentuale di memoria di sistema che può essere riempita con pagine "sporche", pagine di memoria che devono ancora essere scritte su disco. Il buon inizio è andare da 10 e misurare le prestazioni. Per un ambiente con poca memoria, 20 è un buon inizio. Un'impostazione consigliata per rapporti sporchi su server di database con memoria grande è vm.dirty_ratio =15 e vm.dirty_background_ratio =5 o forse meno.

Per controllare il rapporto sporco eseguire:

sysctl -a | grep dirty

Puoi impostarlo aggiungendo le seguenti righe a "/etc/sysctl.conf":

Scambiabilità

Sui server in cui MongoDB è l'unico servizio in esecuzione, è buona norma impostare vm.swapiness =1. L'impostazione predefinita è 60, che non è appropriata per un sistema di database.

vi /etc/sysctl.conf
vm.swappiness = 1

Pagine enormi trasparenti

Se stai eseguendo MongoDB su RedHat, assicurati che Transparent Huge Pages sia disabilitato.
Questo può essere verificato con il comando:

cat /proc/sys/vm/nr_hugepages 
0

0 significa che le pagine enormi trasparenti sono disabilitate.

Opzioni del file system

ext4 rw,seclabel,noatime,data=ordered 0 0

NUMA (Accesso alla memoria non uniforme)

MongoDB non supporta NUMA, disabilitalo nel BIOS.

Stack di rete

net.core.somaxconn = 4096
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_max_syn_backlog = 4096

Demone NTP

Per installare NTP time server demon, usa uno dei seguenti comandi di sistema.

#Red Hat
sudo yum install ntp
#Debian
sudo apt-get install ntp

Puoi trovare maggiori dettagli sulle prestazioni del sistema operativo per MongoDB in un altro blog.

Spiega il piano

Simile ad altri sistemi di database popolari, MongoDB fornisce una funzione di spiegazione che rivela come è stata eseguita un'operazione di database. I risultati di spiegazione mostrano i piani di query come un albero di fasi. Ogni fase trasmette i suoi eventi (ad esempio documenti o chiavi di indice) al nodo padre. I nodi foglia accedono alla raccolta o agli indici. Puoi aggiungere spiegare('executionStats') a una query.

db.inventory.find( {
     status: "A",
     $or: [ { qty: { $lt: 30 } }, { item: /^p/ } ]
} ).explain('executionStats');
or append it to the collection:
db.inventory.explain('executionStats').find( {
     status: "A",
     $or: [ { qty: { $lt: 30 } }, { item: /^p/ } ]
} );

Le chiavi i cui valori dovresti prestare attenzione nell'output dell'esecuzione del comando precedente:

• totalKeysExamined:il numero totale di voci dell'indice scansionate per restituire la query.
• totalDocsExamined:il numero totale di documenti scansionati per trovare i risultati.
• executionTimeMillis:tempo totale in millisecondi necessario per la selezione del piano di query e l'esecuzione della query.

Misurazione delle prestazioni del ritardo di replica

Il ritardo di replica è un ritardo tra un'operazione sul primario e l'applicazione di tale operazione dall'oplog al secondario. In altre parole, definisce quanto dista il secondario dietro il nodo primario, che nella migliore delle ipotesi dovrebbe essere il più vicino possibile a 0.

Il processo di replica può essere influenzato per diversi motivi. Uno dei problemi principali potrebbe essere che i membri secondari stanno esaurendo la capacità del server. Grandi operazioni di scrittura sul membro principale che impediscono ai membri secondari di riprodurre gli oplog o la creazione di indici sul membro principale.

Per controllare il ritardo di replica corrente, esegui in una shell MongoDB:

db.getReplicationInfo()
db.getReplicationInfo() 
{
    "logSizeMB" : 2157.1845703125,
    "usedMB" : 0.05,
    "timeDiff" : 4787,
    "timeDiffHours" : 1.33,
    "tFirst" : "Sun Jul 01 2018 21:40:32 GMT+0000 (UTC)",
    "tLast" : "Sun Jul 01 2018 23:00:19 GMT+0000 (UTC)",
    "now" : "Sun Jul 01 2018 23:00:26 GMT+0000 (UTC)"

L'output dello stato della replica può essere utilizzato per valutare lo stato corrente della replica e determinare se è presente un ritardo di replica non intenzionale.

rs.printSlaveReplicationInfo()

Mostra il ritardo tra i membri secondari rispetto al primario.

rs.status()

Mostra i dettagli approfonditi per la replica. Possiamo raccogliere informazioni sufficienti sulla replica utilizzando questi comandi. Si spera che questi suggerimenti forniscano una rapida panoramica su come rivedere le prestazioni di MongoDB. Facci sapere se ci siamo persi qualcosa.