Fehlerbehebung bei der Leistung

Dieser Abschnitt enthält eine Liste von Symptomen, anhand derer Sie Leistungsprobleme diagnostizieren und beheben können.

Wenn es sich bei Ihrer Datenquelle um einen Kinesis-Stream handelt, zeigen sich Leistungsprobleme in der Regel als hohe oder ansteigende millisbehindLatest-Metrik. Bei anderen Quellen können Sie eine ähnliche Metrik überprüfen, die die Verzögerung beim Lesen aus der Quelle darstellt.

Der Datenpfad

Wenn Sie ein Leistungsproblem mit Ihrer Anwendung untersuchen, sollten Sie den gesamten Pfad berücksichtigen, den Ihre Daten zurücklegen. Die folgenden Anwendungskomponenten können zu Leistungsengpässen und Gegendruck führen, wenn sie nicht richtig konzipiert oder bereitgestellt werden:

• Datenquellen und -ziele: Stellen Sie sicher, dass die externen Ressourcen, mit denen Ihre Anwendung interagiert, entsprechend dem Durchsatz bereitgestellt werden, den Ihre Anwendung erfährt.

• Zustandsdaten: Stellen Sie sicher, dass Ihre Anwendung nicht zu häufig mit dem Zustandsspeicher interagiert.

  Sie können den Serializer optimieren, den Ihre Anwendung verwendet. Der standardmäßige Kryo-Serializer kann jeden serialisierbaren Typ verarbeiten, aber Sie können einen leistungsfähigeren Serializer verwenden, wenn Ihre Anwendung nur Daten in POJO-Typen speichert. Informationen zu Apache Flink-Serialisierern finden Sie unter Datentypen und Serialisierung in der Apache Flink-Dokumentation.

• Operatoren: Stellen Sie sicher, dass die von Ihren Operatoren implementierte Geschäftslogik nicht zu kompliziert ist oder dass Sie nicht für jeden verarbeiteten Datensatz Ressourcen erstellen oder verwenden. Stellen Sie außerdem sicher, dass Ihre Anwendung nicht zu häufig gleitende oder rollierende Fenster erzeugt.

Lösungen zur Fehlerbehebung bei der Leistung

Dieser Abschnitt enthält mögliche Lösungen für Leistungsprobleme.

CloudWatch Überwachungsebenen

Stellen Sie sicher, dass die CloudWatch Überwachungsebenen nicht zu ausführlich eingestellt sind.

Die Einstellung Debug der Überwachungsprotokollebene generiert eine große Menge an Datenverkehr, was zu Gegendruck führen kann. Sie sollten sie nur verwenden, wenn Sie aktiv Probleme mit der Anwendung untersuchen.

Wenn Ihre Anwendung eine hohe Parallelism-Einstellung hat, erzeugt die Verwendung der Ebene Parallelism der Überwachungsmetriken ebenfalls eine große Menge an Datenverkehr, was zu Gegendruck führen kann. Verwenden Sie diese Metrikebene nur, wenn Parallelism für Ihre Anwendung niedrig ist oder wenn Sie Probleme mit der Anwendung untersuchen.

Weitere Informationen finden Sie unter Ebenen der Anwendungsüberwachung.

CPU-Metrik für die Anwendung

Überprüfen Sie die CPU-Metrik der Anwendung. Wenn diese Metrik über 75 Prozent liegt, können Sie der Anwendung erlauben, mehr Ressourcen für sich selbst zuzuweisen, indem Sie Auto Scaling aktivieren.

Wenn Auto Scaling aktiviert ist, weist die Anwendung mehr Ressourcen zu, wenn die CPU-Auslastung 15 Minuten lang über 75 Prozent liegt. Weitere Informationen zur Skalierung finden Sie im folgenden Abschnitt Richtiges Verwalten der Skalierung und unter Skalierung.

Anmerkung

Eine Anwendung wird nur als Reaktion auf die CPU-Auslastung automatisch skaliert. Die Anwendung skaliert nicht automatisch als Reaktion auf andere Systemmetriken, wie z. B. heapMemoryUtilization. Wenn Ihre Anwendung häufig andere Metriken verwendet, erhöhen Sie die Parallelität Ihrer Anwendung manuell.

Parallelität von Anwendungen

Erhöhen Sie die Parallelität der Anwendung. Sie aktualisieren die Parallelität der Anwendung mithilfe des ParallelismConfigurationUpdate Aktionsparameters. UpdateApplication

Die maximale Anzahl von KPUs für eine Anwendung beträgt standardmäßig 64 und kann erhöht werden, indem eine Erhöhung des Grenzwerts angefordert wird.

Es ist wichtig, jedem Operator auch auf der Grundlage seines Workloads Parallelität zuzuweisen, anstatt nur die Anwendungsparallelität allein zu erhöhen. Weitere Informationen finden Sie im Nachfolgenden unter Parallelität des Operators.

Anwendungsprotokollierung

Prüfen Sie, ob die Anwendung für jeden Datensatz, der verarbeitet wird, einen Eintrag protokolliert. Das Schreiben eines Protokolleintrags für jeden Datensatz in Zeiten, in denen die Anwendung einen hohen Durchsatz hat, kann zu schwerwiegenden Engpässen bei der Datenverarbeitung führen. Um diesen Zustand zu überprüfen, fragen Sie Ihre Protokolle auf Protokolleinträge ab, die Ihre Anwendung bei jedem verarbeiteten Datensatz schreibt. Weitere Informationen zum Auslesen von Anwendungsprotokollen finden Sie unter Analysieren von Protokollen mit CloudWatch Logs Insights.

Parallelität des Operators

Stellen Sie sicher, dass der Workload Ihrer Anwendung gleichmäßig auf die Worker-Prozesse verteilt ist.

Informationen zur Optimierung des Workloads der Operatoren Ihrer Anwendung finden Sie unter Operatorenskalierung.

Anwendungslogik

Untersuchen Sie Ihre Anwendungslogik auf ineffiziente oder leistungsschwache Operationen, wie z. B. den Zugriff auf eine externe Abhängigkeit (z. B. eine Datenbank oder einen Webservice), den Zugriff auf den Anwendungszustand usw. Eine externe Abhängigkeit kann auch die Leistung beeinträchtigen, wenn sie nicht performant ist oder nicht zuverlässig zugänglich ist, was dazu führen kann, dass die externe Abhängigkeit HTTP 500-Fehler zurückgibt.

Wenn Ihre Anwendung eine externe Abhängigkeit verwendet, um eingehende Daten anzureichern oder anderweitig zu verarbeiten, sollten Sie stattdessen asynchrone E/A verwenden. Weitere Informationen finden Sie unter Async E/A in der Apache-Flink-Dokumentation.

Speicher der Anwendung

Überprüfen Sie Ihre Anwendung auf Ressourcenlecks. Wenn Ihre Anwendung Threads oder Speicher nicht ordnungsgemäß entsorgt, kann es sein, dass die Metriken millisbehindLatest, CheckpointSize und CheckpointDuration steil ansteigen oder allmählich zunehmen. Dieser Zustand kann auch zu Fehlern im Aufgaben- oder Auftragsmanager führen.