Résolution des problèmes de performance

Cette section contient une liste de symptômes que vous pouvez vérifier pour diagnostiquer et résoudre les problèmes de performances.

Si votre source de données est un flux Kinesis, les problèmes de performances se présentent généralement sous la forme d’une métrique millisbehindLatest élevée ou croissante. Pour les autres sources, vous pouvez vérifier une métrique similaire qui représente le retard de lecture depuis la source.

Le chemin des données

Lorsque vous étudiez un problème de performance lié à votre application, considérez le chemin complet emprunté par vos données. Les composants d’application suivants peuvent devenir des goulots d’étranglement en termes de performances et créer une contre-pression s’ils ne sont pas correctement conçus ou fournis :

• Sources de données et destinations : assurez-vous que les ressources externes avec lesquelles votre application interagit sont correctement provisionnées en fonction du débit dont bénéficiera votre application.

• Données d’état : assurez-vous que votre application n’interagit pas trop fréquemment avec le magasin d’état.

  Vous pouvez optimiser le sérialiseur utilisé par votre application. Le sérialiseur Kryo par défaut peut gérer n’importe quel type sérialisable, mais vous pouvez utiliser un sérialiseur plus performant si votre application ne stocke des données que dans des types POJO. Pour plus d'informations sur les sérialiseurs Apache Flink, consultez la section Types de données et sérialisation dans la documentation d'Apache Flink.

• Opérateurs : assurez-vous que la logique métier mise en œuvre par vos opérateurs n’est pas trop compliquée ou que vous ne créez ni n’utilisez pas de ressources pour chaque enregistrement traité. Assurez-vous également que votre application ne crée pas de fenêtres défilantes ou bascule trop fréquemment.

Solutions de résolution des problèmes de performances

Cette section contient des solutions potentielles aux problèmes de performances.

CloudWatch niveaux de surveillance

Vérifiez que les niveaux CloudWatch de surveillance ne sont pas définis sur un paramètre trop détaillé.

Le paramètre de niveau de surveillance des journaux Debug génère une grande quantité de trafic, ce qui peut créer une contre-pression. Vous ne devez l’utiliser que lorsque vous étudiez activement les problèmes liés à l’application.

Si votre application possède un paramètre Parallelism élevé, l’utilisation du niveau de surveillance des métriques Parallelism générera également un volume de trafic important pouvant entraîner une contre-pression. Utilisez ce niveau de métrique uniquement lorsque le Parallelism pour votre application est faible ou lorsque vous étudiez des problèmes liés à l’application.

Pour plus d’informations, consultez Niveaux de surveillance des applications.

Métrique du processeur de l'application

Vérifiez la métrique CPU de l’application. Si cette métrique est supérieure à 75 %, vous pouvez autoriser l’application à s’allouer davantage de ressources en activant l’autoscaling.

Si l’autoscaling est activé, l’application alloue davantage de ressources si l’utilisation du processeur est supérieure à 75 % pendant 15 minutes. Pour plus d’informations sur la mise à l’échelle, consultez la section Gérer correctement la mise à l’échelle suivante et Mise à l'échelle.

Note

Une application n’utilise l’autoscaling qu’en fonction de l’utilisation du processeur. L’application n’utilisera pas l’autoscaling en réponse à d’autres métriques du système, tels que l’heapMemoryUtilization. Si votre application utilise beaucoup d’autres métriques, augmentez manuellement le parallélisme de votre application.

Parallélisme des applications

Augmentez le parallélisme de l’application. Vous mettez à jour le parallélisme de l'application à l'aide du ParallelismConfigurationUpdate paramètre de l'UpdateApplicationaction.

Le nombre maximal de KPU pour une application est de 64 par défaut et peut être augmenté en demandant une augmentation de limite.

Il est également important d’attribuer le parallélisme à chaque opérateur en fonction de sa charge de travail, plutôt que de simplement augmenter le parallélisme de l’application. Consultez Parallélisme des opérateurs ci-dessous.

Journalisation d'applications

Vérifiez si l’application enregistre une entrée pour chaque enregistrement en cours de traitement. La rédaction d’une entrée de journal pour chaque enregistrement pendant les périodes où le débit de l’application est élevé entraîne de graves blocages dans le traitement des données. Pour vérifier cette condition, recherchez dans vos journaux les entrées de journal que votre application écrit avec chaque enregistrement qu’elle traite. Pour plus d’informations sur la lecture des journaux d’application, consultez Analyse des journaux avec CloudWatch Logs Insights.

Parallélisme des opérateurs

Vérifiez que la charge de travail de votre application est répartie uniformément entre les processus de travail.

Pour obtenir des informations sur le réglage de la charge de travail des opérateurs de votre application, consultez Mise à l’échelle des opérateurs.

Logique de l'application

Examinez la logique de votre application pour détecter les opérations inefficaces ou non performantes, telles que l’accès à une dépendance externe (telle qu’une base de données ou un service Web), l’accès à l’état de l’application, etc. Une dépendance externe peut également nuire aux performances si elle n’est pas performante ou si elle n’est pas accessible de manière fiable, ce qui peut pousser la dépendance externe à renvoyer des erreurs HTTP 500.

Si votre application utilise une dépendance externe pour enrichir ou traiter les données entrantes, envisagez plutôt d’utiliser des E/S asynchrones. Pour plus d’informations, consultez Async I/O dans la documentation Apache Flink.

Mémoire d'application

Vérifiez que votre application ne présente aucune fuite de ressources. Si votre application n’élimine pas correctement les threads ou la mémoire, il est possible que les métriques millisbehindLatest, CheckpointSize et CheckpointDuration connaissent des pics ou augmentent progressivement. Cette condition peut également entraîner des échecs du gestionnaire de tâches.