"Managed Service for Apache Spark" è il nuovo nome del prodotto precedentemente noto come "Dataproc on Compute Engine" (deployment del cluster) e "Google Cloud Serverless for Apache Spark" (deployment serverless).

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Risolvere i problemi di memoria insufficiente delle VM

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

Effetti dell'errore OOM

Quando le VM di Managed Service for Apache Spark riscontrano errori di memoria insufficiente (OOM), si verificano 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".
Gli errori OOM delle VM worker causano la perdita del nodo su YARN HDFS, il che ritarda l'esecuzione dei job di Managed Service for Apache Spark.

Controlli della memoria YARN

Apache YARN fornisce i seguenti tipi di controlli della memoria:

Basato sul polling (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 della memoria restrittiva può causare la terminazione dei container quando è disponibile 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 impedire gli errori OOM quando i processi consumano aggressivamente la memoria.

Protezione della memoria di Managed Service for Apache Spark

Quando una 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 di 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 terminazioni dei job dovute alla pressione della memoria.

Terminazioni dei processi

I processi terminati dalla protezione della memoria di Managed Service for Apache Spark 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 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, abilita Logging, quindi utilizza il seguente filtro di 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 nodo master o del pool di nodi driver di Managed Service for Apache Spark termina a causa della pressione della memoria, il job non riesce con il codice di errore Driver received SIGTERM/SIGKILL signal and exited with INT. Per visualizzare questi messaggi, abilita Logging, quindi utilizza il seguente filtro di 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 google.dataproc.oom-killer log o il 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 all'utilizzo effettivo della memoria utilizzata 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 gestore delle risorse YARN: container id exited with code EXIT_CODE. Per visualizzare questi messaggi, abilita Logging, quindi utilizza il seguente filtro di 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 google.dataproc.oom-killer log o il 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 container siano configurate correttamente.
- Valuta la possibilità di ridurre 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 aumento dell'utilizzo di container specifici. In caso affermativo, ripartiziona il 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 impedire il blocco del sistema liberando memoria quando la memoria disponibile è estremamente bassa. La configurazione predefinita è adatta a molti workload. Tuttavia, potrebbe essere necessario modificare la configurazione se il nodo master ha una grande quantità di memoria e riscontra un consumo rapido di memoria.

Negli 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 smette di rispondere. Questo 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

Questa è 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 predefinita di earlyoom utilizza una quantità fissa di memoria libera come trigger. Nelle macchine virtuali con una grande quantità di RAM, ad esempio 32GB o più, questa quantità fissa potrebbe rappresentare una piccola frazione della memoria totale. Ciò rende il sistema suscettibile a picchi improvvisi nella memoria utilizzata.

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

Connettiti al nodo master tramite SSH.
Apri il file di configurazione per la modifica:
```
sudo nano /etc/default/earlyoom
```
Regola la soglia minima di memoria. Individua la riga EARLYOOM_ARGS. L' -M <kbytes> opzione imposta la quantità minima di memoria libera in KiB che earlyoom tenta di mantenere. Il valore predefinito è -M 65536, ovvero 64 MiB.

Considerazioni sull'ottimizzazione: l'impostazione di un valore -M troppo elevato può causare la terminazione più aggressiva dei processi da parte di earlyoom. Ciò può influire sulle applicazioni anche quando potrebbe essere ancora disponibile memoria sufficiente. Monitora il comportamento del sistema dopo aver apportato le modifiche. Regola il valore -M in base alle dimensioni dell'istanza e al carico di lavoro. Una linea guida generale è impostare -M su un valore che rappresenti l'1-5% della memoria totale del sistema.

Per un nodo master con una quantità di memoria sostanziale, aumenta questo valore. Ad esempio, per impostare la soglia su 1 GiB (1048576 KiB), modifica la riga come segue:
```
EARLYOOM_ARGS="-r 15 -M 1048576 -s 1"
```
Note:
- -r: intervallo di report sulla memoria in secondi
- -s: soglia dello spazio di swap per attivare earlyoom
Riavvia il servizio earlyoom per applicare le modifiche:
```
sudo systemctl restart earlyoom
```