Problèmes de redémarrage d’application provoqués par des problèmes de mémoire insuffisante
Remarque
Azure Spring Apps est le nouveau nom du service Azure Spring Cloud. Bien que le service ait un nouveau nom, vous verrez l’ancien nom à divers endroits pendant un certain temps, car nous travaillons à mettre à jour les ressources telles que les captures d’écran, les vidéos et les diagrammes.
Cet article s’applique au : Niveau ✔️ De base/Standard ✔️ Entreprise
Cet article décrit les problèmes de mémoire insuffisante (OOM) pour les applications Java dans Azure Spring Apps.
Types de problèmes de mémoire insuffisante
Il existe deux types de problèmes de mémoire insuffisante : conteneur OOM et JVM OOM.
Le conteneur OOM, également appelé système OOM, se produit lorsque la mémoire de l’application disponible est insuffisante. Le problème de conteneur OOM provoque des événements de redémarrage d’application, qui sont signalés dans la section Resource Health du Portail Azure. Normalement, le conteneur OOM est dû à des configurations de taille de mémoire incorrectes.
JVM OOM se produit lorsque la quantité de mémoire utilisée a atteint la taille maximale définie dans les options JVM. JVM OOM n’entraîne pas le redémarrage d’une application. Normalement, JVM OOM est le résultat d’un code incorrect, que vous pouvez trouver en recherchant des exceptions
java.lang.OutOfMemoryErrordans le journal des applications. JVM OOM a un effet négatif sur les outils d’application et de profilage Java, tels que l’enregistreur de version d’évaluation Java.
Cet article se concentre sur la façon de résoudre les problèmes de conteneur OOM. Pour résoudre les problèmes liés à JVM OOM, vérifiez les outils tels que le vidage de segments, le vidage de thread et l’enregistreur de version d’évaluation Java. Pour plus d'informations, consultez Capturer le vidage de segments et le vidage de thread manuellement et utiliser Java Flight Recorder dans Azure Spring Apps.
Résoudre les problèmes de redémarrage de l’application en raison d’OOM
Les sections suivantes décrivent les outils, les métriques et les options JVM que vous pouvez utiliser pour diagnostiquer et résoudre les problèmes liés à l’OOM de conteneur.
Afficher les alertes sur la page Intégrité des ressources
La page Intégrité des ressources du Portail Azure affiche les événements de redémarrage de l’application en raison d’un OOM de conteneur, comme illustré dans la capture d’écran suivante :
Configurer la taille de mémoire
Les métriques Utilisation de la mémoire de l’application, jvm.memory.used et jvm.memory.committed fournissent une vue de l’utilisation de la mémoire. Pour plus d’informations, consultez la section Métriques des Outils pour résoudre les problèmes de mémoire. Configurez les tailles de mémoire maximales dans les options JVM pour vous assurer que la mémoire est inférieure à la limite.
La somme des tailles de mémoire maximales de toutes les parties du modèle de mémoire Java doit être inférieure à la mémoire réelle disponible de l’application. Pour définir vos tailles de mémoire maximales, consultez la disposition de mémoire classique décrite dans la section Disposition de l’utilisation de la mémoire de la gestion de la mémoire Java.
Trouvez un équilibre lorsque vous définissez la taille de mémoire maximale. Lorsque vous définissez la taille de mémoire maximale trop élevée, il existe un risque d’OOM de conteneur. Lorsque vous définissez la taille de mémoire maximale trop faible, il y a un risque d’OOM JVM, et le nettoyage de la mémoire se déclenchera et ralentira l’application.
Contrôler la mémoire segmentée
Vous pouvez définir la taille maximale du segment à l’aide des options JVM -Xms, -Xmx, -XX:InitialRAMPercentage et -XX:MaxRAMPercentage.
Vous devrez peut-être ajuster les paramètres de taille maximale du segment lorsque la valeur de jvm.memory.used est trop élevée dans les métriques. Pour plus d’informations, consultez la section jvm.memory.used/committed/max des Outils pour résoudre les problèmes de mémoire.
Contrôler la mémoire directe
Il est important de définir l’option JVM -XX:MaxDirectMemorySize pour les raisons suivantes :
- Vous ne remarquerez peut-être pas quand des infrastructures telles que nio et gzip utilisent la mémoire directe.
- Le nettoyage de la mémoire directe est géré uniquement pendant le nettoyage de la mémoire complet et le nettoyage de la mémoire complet se produit uniquement lorsque le segment est presque plein.
Normalement, vous pouvez définir MaxDirectMemorySize pour une valeur inférieure à la taille de mémoire de l’application moins la mémoire segmentée moins la mémoire non segmentée.
Métaspace de contrôle
Vous pouvez définir la taille maximale de métaspace en définissant l’option JVM -XX:MaxMetaspaceSize. L’option -XX:MetaspaceSize définit la valeur de seuil pour déclencher le nettoyage de la mémoire complet.
La mémoire métaspace est généralement stable.