Perché il mio lavoro Spark o Hive su Amazon EMR fallisce con un HTTP 503 "Slow Down" AmazonS3Exception?

5 minuti di lettura
0

Il mio lavoro con Apache Spark o Apache Hive su Amazon EMR fallisce con un HTTP 503 "Slow Down" AmazonS3Exception simile al seguente: java.io.ioException: com.amazon.ws.emr.hadoop.fs.shaded.com.amazonaws.services.s3.model.amazonS3Exception: Slow Down (Service: Amazon S3; Status Code: 503; Error Code: 503 Slow Down; Request ID: 2E8B8866BFF00645; S3 Extended Request ID: oGSeRdT4xSKtyZAcUe53LgUf1+I18dNXpL2+qZhFWhuciNOYpxX81bpFiTw2gum43GcOHR+UlJE=), S3 Extended Request ID: oGSeRdT4xSKtyZAcUe53LgUf1+I18dNXpL2+qZhFWhuciNOYpxX81bpFiTw2gum43GcOHR+UlJE=

Breve descrizione

Questo errore si verifica quando la frequenza delle richieste di Amazon Simple Storage Service (Amazon S3) per l'applicazione supera le frequenze normalmente sostenute di oltre 5.000 richieste al secondo e Amazon S3 ottimizza internamente le prestazioni.

Per migliorare la percentuale di successo delle tue richieste quando accedi ai dati S3 utilizzando Amazon EMR, prova i seguenti approcci:

  • Modifica la strategia di ripetizione dei tentativi per le richieste S3.
  • Regola il numero di richieste S3 simultanee.

Risoluzione

Per aiutare a identificare il problema con troppe richieste, è consigliabile configurare le metriche delle richieste di Amazon CloudWatch per il bucket S3. Puoi determinare la soluzione più adatta al tuo caso d'uso in base a queste metriche di CloudWatch.

Configurazione delle metriche delle richieste di CloudWatch

Per monitorare le richieste di Amazon S3, attiva le metriche delle richieste di CloudWatch per il bucket. Quindi, definisci un filtro per il prefisso. Per un elenco di metriche utili da monitorare, consulta Monitoraggio delle metriche con Amazon CloudWatch.

Modifica la strategia di ripetizione dei tentativi per le richieste S3

Per impostazione predefinita, EMRFS utilizza una strategia di backoff esponenziale per riprovare le richieste ad Amazon S3. Il limite predefinito di tentativi EMRFS è 15. Tuttavia, è possibile aumentare il limite di tentativi su un nuovo cluster, su un cluster in esecuzione o in fase di runtime dell'applicazione.

Per aumentare il limite di tentativi, modifica il valore del parametro fs.s3.maxRetries. Se imposti un valore molto alto per questo parametro, potresti riscontrare una durata del lavoro più lunga. Prova a impostare questo parametro su un valore elevato (ad esempio 20), monitora il sovraccarico della durata dei lavori e quindi modifica questo parametro in base al tuo caso d'uso.

Per un nuovo cluster, puoi aggiungere un oggetto di configurazione simile al seguente quando avvii il cluster:

[
  {
    "Classification": "emrfs-site",
    "Properties": {
      "fs.s3.maxRetries": "20"
    }
  }
]

Dopo il lancio del cluster, le applicazioni Spark e Hive in esecuzione su Amazon EMR utilizzano il nuovo limite.

Per aumentare il limite di tentativi su un cluster in esecuzione, procedi come segue:

  1. Apri la console Amazon EMR.

  2. Nell'elenco dei cluster, scegli il cluster attivo che desideri riconfigurare in Nome.

  3. Apri la pagina dei dettagli del cluster per il cluster e scegli la scheda Configurazioni.

  4. Nell'elenco a discesa Filtro, seleziona il gruppo di istanze che desideri riconfigurare.

  5. Nell'elenco a discesa Riconfigura, scegli Modifica nella tabella.

  6. Nella tabella di classificazione della configurazione, scegli Aggiungi configurazione, quindi inserisci quanto segue:

Per Classificazione: emrfs-site

Per Proprietà: fs.s3.maxRetries

Per Valore: il nuovo valore per il limite di tentativi (ad esempio, 20)

  1. Seleziona Applica questa configurazione a tutti i gruppi di istanze attivi.

  2. Scegli Salva modifiche.

Dopo l'implementazione della configurazione, le applicazioni Spark e Hive utilizzano il nuovo limite.

Per aumentare il limite di tentativi in fase di runtime, usa una sessione ](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-shell.html)shell (interprete di comandi) Spark[ simile a quanto segue:

spark> sc.hadoopConfiguration.set("fs.s3.maxRetries", "20")
spark> val source_df = spark.read.csv("s3://awsexamplebucket/data/")
spark> source_df.write.save("s3://awsexamplebucket2/output/")

Ecco un esempio di come aumentare il limite di tentativi in fase di runtime per un'applicazione Hive:

hive> set fs.s3.maxRetries=20;
hive> select ....

Regola il numero di richieste S3 simultanee

  • Se hai più lavori (Spark, Apache Hive o s-dist-cp) di lettura e scrittura sullo stesso prefisso S3, puoi regolare la concorrenza. Inizia con i lavori più impegnativi di lettura/scrittura e riduci la concorrenza per evitare un parallelismo eccessivo. Se hai configurato l'accesso multi-account per Amazon S3, tieni presente che anche altri account potrebbero inoltrare lavori allo stesso prefisso.
  • Se visualizzi errori quando il lavoro tenta di scrivere nel bucket di destinazione, riduci l'eccessivo parallelismo di scrittura. Ad esempio, usa le operazioni Spark .coalesce() o .repartition() per ridurre il numero di partizioni di output Spark prima di scrivere su Amazon S3. È inoltre possibile ridurre il numero di core per esecutore o ridurre il numero di esecutori.
  • Se visualizzi errori quando il lavoro tenta di leggere dal bucket di origine, regola la dimensione degli oggetti. È possibile aggregare oggetti più piccoli a oggetti più grandi in modo da ridurre il numero di oggetti letti dal lavoro. In questo modo, i tuoi lavori leggeranno set di dati con meno richieste di lettura. Ad esempio, usa s3-dist-cp per unire un numero elevato di file di piccole dimensioni in un numero minore di file di grandi dimensioni.

Informazioni correlate

Modelli di progettazione basati sulle best practice: ottimizzazione delle prestazioni di Amazon S3

Perché la mia applicazione Amazon EMR fallisce con un HTTP 403 "Access Denied" AmazonS3Exception?

Perché la mia applicazione Amazon EMR fallisce con un HTTP 404 "Not Found" AmazonS3Exception?

AWS UFFICIALE
AWS UFFICIALEAggiornata 2 anni fa