Risolvere i problemi di memoria insufficiente delle VM

Questa pagina fornisce informazioni sugli errori di esaurimento della memoria (OOM) della VM Compute Engine di Dataproc e spiega i passaggi che puoi eseguire per risolvere i problemi e risolvere gli errori OOM.

Effetti dell'errore OOM

Quando le VM Compute Engine di Dataproc riscontrano errori di esaurimento della memoria (OOM), gli effetti includono le seguenti condizioni:

  • Le VM master e worker si bloccano per un periodo di tempo.

  • Gli errori OOM delle VM master causano l'esito negativo dei job con errori "task not acquired" (attività non acquisita).

  • Gli errori OOM della VM worker causano la perdita del nodo su YARN HDFS, il che ritarda l'esecuzione del job Dataproc.

Controlli della memoria YARN

Apache YARN fornisce i seguenti tipi di controlli della memoria:

  • Basato sul polling (legacy)
  • Restrittiva
  • Elastic

Per impostazione predefinita, Dataproc non imposta yarn.nodemanager.resource.memory.enabled per attivare i controlli della memoria YARN, per i seguenti motivi:

  • Il controllo rigoroso della memoria può causare la terminazione dei container quando la memoria è sufficiente se le dimensioni dei container non sono configurate correttamente.
  • I requisiti di controllo della memoria elastica possono influire negativamente sull'esecuzione dei job.
  • I controlli della memoria YARN potrebbero non riuscire a impedire errori di memoria insufficiente quando i processi consumano memoria in modo aggressivo.

Protezione della memoria di Dataproc

Quando una VM del cluster Dataproc è sotto pressione della memoria, la protezione della memoria di Dataproc termina i processi o i container finché la condizione OOM non viene rimossa.

Dataproc fornisce la protezione della memoria per i seguenti nodi del cluster nelle seguenti versioni immagine di Dataproc su Compute Engine:

Ruolo 1,5 2.0 2.1 2.2
VM master 1.5.74+ 2.0.48+ tutti tutti
VM worker Non disponibile 2.0.76+ 2.1.24+ tutti
VM del pool di driver Non disponibile 2.0.76+ 2.1.24+ tutti

Identificare e confermare le interruzioni della protezione della memoria

Puoi utilizzare le seguenti informazioni per identificare e confermare le interruzioni dei job dovute alla pressione della memoria.

Elabora cessazioni

  • I processi terminati dalla protezione della memoria di Dataproc escono con il codice 137 o 143.

  • Quando Dataproc termina un processo a causa della pressione della memoria, possono verificarsi le seguenti azioni o condizioni:

    • Dataproc incrementa la metrica cumulativa dataproc.googleapis.com/node/problem_count e imposta reason su ProcessKilledDueToMemoryPressure. Consulta la sezione Raccolta delle metriche delle risorse di Dataproc.
    • Dataproc scrive un log google.dataproc.oom-killer con il messaggio: "A process is killed due to memory pressure: process name. Per visualizzare questi messaggi, attiva la registrazione, quindi utilizza il seguente filtro dei log: 
      resource.type="cloud_dataproc_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.cluster_uuid="CLUSTER_UUID"
jsonPayload.message:"A process is killed due to memory pressure:"

Terminazioni dei job del pool di nodi master o del driver

  • Quando un job del pool di nodi master o driver di Dataproc termina a causa di un'eccessiva pressione sulla memoria, il job non riesce e viene visualizzato il codice di errore Driver received SIGTERM/SIGKILL signal and exited with INT. Per visualizzare questi messaggi, attiva la registrazione, quindi utilizza il seguente filtro dei log: 

    resource.type="cloud_dataproc_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.cluster_uuid="CLUSTER_UUID"
jsonPayload.message:"Driver received SIGTERM/SIGKILL signal and exited with"

    • Controlla il log google.dataproc.oom-killer o dataproc.googleapis.com/node/problem_count per verificare che Dataproc Memory Protection abbia terminato il job (vedi Terminazioni dei processi).

    Soluzioni:

    • Se il cluster ha un pool di driver, aumenta driver-required-memory-mb all'utilizzo effettivo della memoria del job.
    • Se il cluster non ha un pool di driver, ricrealo riducendo il numero massimo di job simultanei in esecuzione sul cluster.
    • Utilizza un tipo di macchina del nodo master con maggiore memoria.

Terminazioni dei container YARN dei nodi worker

  • Dataproc scrive il seguente messaggio nel resource manager YARN: container id exited with code EXIT_CODE. Per visualizzare questi messaggi, attiva la registrazione, poi utilizza il seguente filtro dei log:

    resource.type="cloud_dataproc_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.cluster_uuid="CLUSTER_UUID"
jsonPayload.message:"container" AND "exited with code" AND "which potentially signifies memory pressure on NODE

  • Se un container è uscito con code INT, controlla il log google.dataproc.oom-killer o dataproc.googleapis.com/node/problem_count per verificare che la protezione della memoria di Dataproc abbia terminato il job (vedi Terminazioni dei processi).

    Soluzioni:

    • Verifica che le dimensioni dei contenitori siano configurate correttamente.
    • Valuta la possibilità di abbassare yarn.nodemanager.resource.memory-mb. Questa proprietà controlla la quantità di memoria utilizzata per la pianificazione dei container YARN.
    • Se i container dei job non riescono costantemente, controlla se la distorsione dei dati sta causando un maggiore utilizzo di container specifici. In questo caso, esegui nuovamente il partizionamento del job o aumenta le dimensioni del worker per soddisfare i requisiti di memoria aggiuntivi.

Ottimizzare la protezione della memoria Linux sul nodo master (avanzato)

I nodi master Dataproc utilizzano l'utilità earlyoom per evitare blocchi del sistema liberando memoria quando la memoria disponibile è molto bassa. La configurazione predefinita è adatta a molti workload. Tuttavia, potresti dover modificare la configurazione se il nodo master ha una grande quantità di memoria e registra un rapido consumo di memoria.

In scenari con elevata pressione della memoria, il sistema può entrare in uno stato di "thrashing", in cui trascorre la maggior parte del tempo nella gestione della memoria e diventa non reattivo. Ciò può accadere così rapidamente che earlyoom non riesce ad agire in base alle impostazioni predefinite o non riesce ad agire prima che venga richiamata la risposta OOM del kernel.

Prima di iniziare

  • Si tratta di un'opzione di ottimizzazione avanzata. Prima di modificare le impostazioni di earlyoom, dai la priorità ad altre soluzioni, ad esempio l'utilizzo di una VM master con più memoria, la riduzione della concorrenza dei job o l'ottimizzazione dell'utilizzo della memoria dei job.

Personalizzare le impostazioni di earlyoom

La configurazione earlyoom predefinita utilizza una quantità fissa di memoria libera come trigger. Sulle macchine virtuali con una grande quantità di RAM, ad esempio 32GB o più, questo importo fisso potrebbe rappresentare una piccola frazione della memoria totale. Ciò rende il sistema sensibile a picchi improvvisi di utilizzo della memoria.

Per personalizzare le impostazioni di earlyoom, connettiti al nodo master e modifica il file di configurazione.

  1. Connettiti al nodo master utilizzando SSH.

  2. Apri il file di configurazione per modificarlo:

    sudo nano /etc/default/earlyoom

  3. Regola la soglia minima di memoria. Individua la riga EARLYOOM_ARGS. L'opzione -M <kbytes> imposta la quantità minima di memoria libera in KiB che earlyoom tenta di mantenere. Il valore predefinito è -M 65536, ovvero 64 MiB.

    Per un nodo master con una memoria considerevole, aumenta questo valore. Ad esempio, per impostare la soglia su 1 GiB (1048576 KiB), modifica la riga nel seguente modo:

    EARLYOOM_ARGS="-r 15 -M 1048576 -s 1"

    Note:

    • -r: intervallo del report sulla memoria in secondi
    • -s: La soglia di spazio di swap per attivare earlyoom

  4. Riavvia il servizio earlyoom per applicare le modifiche:

    sudo systemctl restart earlyoom