"Managed Service for Apache Spark" is the new name for the product formerly known as "Dataproc on Compute Engine" (cluster deployment) and "Google Cloud Serverless for Apache Spark" (serverless deployment).

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Risolvere i problemi di memoria insufficiente delle VM

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

Effetti dell'errore OOM

Quando le VM Managed Service for Apache Spark 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 di esaurimento della memoria della VM worker causano la perdita del nodo su YARN HDFS, il che ritarda l'esecuzione del job Managed Service for Apache Spark.

Controlli della memoria YARN

Apache YARN fornisce i seguenti tipi di controlli della memoria:

Basato su sondaggi (legacy)
Restrittiva
Elastic

Per impostazione predefinita, Managed Service for Apache Spark non imposta yarn.nodemanager.resource.memory.enabled per abilitare 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 del 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 Managed Service for Apache Spark

Quando la VM del cluster Managed Service for Apache Spark è sotto pressione della memoria, la protezione della memoria di Managed Service for Apache Spark termina i processi o i container finché la condizione OOM non viene rimossa.

Managed Service for Apache Spark fornisce la protezione della memoria per i seguenti nodi del cluster nelle seguenti versioni dell'immagine Managed Service for Apache Spark:

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 terminazioni della protezione della memoria

Puoi utilizzare le seguenti informazioni per identificare e confermare le interruzioni dei job dovute a problemi di memoria.

Terminazioni dei processi

I processi che la protezione della memoria di Managed Service for Apache Spark termina escono con il codice 137 o 143.
Quando Managed Service for Apache Spark termina un processo a causa della pressione della memoria, possono verificarsi le seguenti azioni o condizioni:
- Managed Service for Apache Spark incrementa la metrica cumulativa dataproc.googleapis.com/node/problem_count e imposta reason su ProcessKilledDueToMemoryPressure. Consulta la sezione Raccolta delle metriche delle risorse di Managed Service for Apache Spark.
- Managed Service for Apache Spark 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 nodo master o del pool di nodi driver

Quando un job del pool di nodi master o driver di Managed Service for Apache Spark termina a causa della pressione della memoria, il job non riesce con il codice Driver received SIGTERM/SIGKILL signal and exited with INT di errore. 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 la protezione della memoria di Managed Service for Apache Spark abbia terminato il job (vedi Terminazioni dei processi).
Soluzioni:
- Se il cluster ha un pool di driver, aumenta driver-required-memory-mb in base alla memoria utilizzata effettiva 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

Managed Service for Apache Spark 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 Managed Service for Apache Spark 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 in modo coerente, verifica 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 di Managed Service for Apache Spark utilizzano l'utilità earlyoom per evitare blocchi del sistema liberando memoria quando la memoria disponibile è a livelli critici. La configurazione predefinita è adatta a molti workload. Tuttavia, potresti dover modificare la configurazione se il nodo master ha una grande quantità di memoria e si verifica un rapido consumo di memoria.

In scenari con un'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 della memoria utilizzata 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 memoria utilizzata.

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

Connettiti al nodo master utilizzando SSH.
Apri il file di configurazione per modificarlo:
```
sudo nano /etc/default/earlyoom
```
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.

Considerazioni sulla regolazione: se imposti il valore di -M su un valore troppo elevato, earlyoom termina i processi in modo più aggressivo. Ciò può influire sulle applicazioni anche quando potrebbe essere ancora disponibile memoria sufficiente. Monitora il comportamento del sistema dopo aver apportato modifiche. Modifica il valore di -M in base alle dimensioni dell'istanza e al carico di lavoro. Una linea guida generale è impostare -M su un valore che rappresenti il 1-5% della memoria di sistema totale.

Per un nodo master con una memoria sostanziale, 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
Riavvia il servizio earlyoom per applicare le modifiche:
```
sudo systemctl restart earlyoom
```