Outils pour résoudre les problèmes de mémoire
Remarque
Les plans Essentiel, Standard et Entreprise seront déconseillés à compter de la mi-mars 2025, avec une période de mise hors service de 3 ans. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez l’annonce de mise hors service d’Azure Spring Apps.
Le plan de consommation standard et dédiée sera déconseillé à compter du 30 septembre 2024, avec un arrêt complet après six mois. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez Migrer le plan de consommation standard et dédiée Azure Spring Apps vers Azure Container Apps.
Cet article s’applique au : Niveau ✔️ De base/Standard ✔️ Entreprise
Cet article décrit différents outils utiles pour résoudre les problèmes de mémoire Java. Vous pouvez utiliser ces outils dans de nombreux scénarios non limités aux problèmes de mémoire, mais cet article se concentre uniquement sur la rubrique de la mémoire.
Alertes et diagnostics
Les sections suivantes décrivent les alertes et diagnostics d’intégrité des ressources disponibles via le Portail Azure.
Intégrité des ressources
Vous pouvez surveiller des événements de cycle de vie d’application et configurer des alertes avec le Journal des activités Azure et Azure Service Health. Pour plus d’informations, consultez Surveiller des événements de cycle de vie d’application à l’aide du Journal d’activités Azure et d’Azure Service Health.
Resource Health envoie des alertes sur les événements de redémarrage de l’application en raison de problèmes de mémoire insuffisante (OOM). Pour plus d’informations, consultez Problèmes de redémarrage d’application provoqués par des problèmes hors mémoire.
La capture d’écran suivante montre une alerte d’intégrité des ressources d’application indiquant un problème OOM.
Diagnostiquer et résoudre les problèmes
Le service de diagnostics Azure Spring Apps est une expérience interactive vous permettant de résoudre les problèmes de votre application sans besoin de configuration. Pour plus d’informations, consultez Auto-diagnostic et résolution des problèmes dans Azure Spring Apps.
Dans le Portail Azure, vous pouvez trouver l’Utilisation de la mémoire sous Diagnostiquer et résoudre les problèmes, comme illustré dans la capture d’écran suivante.
L’Utilisation de la mémoire fournit un diagnostic simple pour l’utilisation de la mémoire de l’application, comme illustré dans la capture d’écran suivante.
Métriques
Les sections suivantes décrivent les métriques qui couvrent les problèmes tels que l’utilisation élevée de la mémoire, la mémoire de segment trop volumineuse et le nettoyage de la mémoire anormal (trop ou pas assez fréquent). Pour plus d’informations, consultez Démarrage rapide : Monitoring d’Azure Spring Apps avec les journaux, les métriques et le suivi.
Utilisation de la mémoire de l’application
L’utilisation de la mémoire de l’application est un pourcentage égal à la mémoire de l’application utilisée par la limite de mémoire de l’application. Cette valeur affiche l’ensemble de la mémoire de l’application.
jvm.memory.used/committed/max
Pour la mémoire JVM, il existe trois métriques : jvm.memory.used, jvm.memory.committedet jvm.memory.max, qui sont décrites dans la liste suivante.
La « mémoire JVM » n’est pas un concept clairement défini. Ici, jvm.memory est la somme de la mémoire segmentée et de la partie de l’ancienne permGen de la mémoire non-segmentée. La mémoire JVM n’inclut pas la mémoire directe ou d’autres mémoires comme la pile de threads. Spring Boot Actuator collecte ces trois métriques et détermine l’étendue de jvm.memory.
jvm.memory.usedest la quantité de mémoire JVM utilisée, y compris la mémoire segmentée utilisée et l’ancien permGen dans la mémoire non segmentée.jvm.memory.usedest une réflexion majeure du changement de mémoire segmentée, car l’ancienne partie permGen est généralement stable.Si vous trouvez
jvm.memory.usedtrop grand, envisagez de définir une taille de mémoire segmentée maximale plus petite.jvm.memory.committedest la quantité de mémoire validée pour que la machine virtuelle JVM soit utilisée. La taille dejvm.memory.committedest essentiellement la limite de mémoire JVM utilisable.jvm.memory.maxest la quantité maximale de mémoire JVM, pas à confondre avec la quantité réelle disponible.La valeur de
jvm.memory.maxpeut parfois être déroutante, car elle peut être beaucoup plus élevée que la mémoire de l’application disponible. Pour clarifier,jvm.memory.maxest la somme de toutes les tailles maximales de la mémoire segmentée et de l’ancienne partie permGen de la mémoire non segmentée, quelle que soit la mémoire disponible réelle. Par exemple, si une application est définie avec 1 Go de mémoire dans le portail Azure Spring Apps, la taille de mémoire segmentée par défaut est de 0,5 Go. Pour plus d’informations, consultez la section Taille maximale de segment par défaut de la gestion de la mémoire Java.Si la taille de l’espace de classe compressée par défaut est de 1 Go, la valeur de
jvm.memory.maxest supérieure à 1,5 Go, quelle que soit la taille de mémoire de l’application de 1 Go. Pour plus d’informations, consultez Plateforme Java , Édition Standard HotSpot Machine virtuelle Nettoyage de la mémoire Guide de réglage : Autres considérations dans la documentation Oracle.
jvm.gc.memory.allocated/promoted
Ces deux métriques sont destinées à observer le nettoyage de la mémoire Java (GC). Pour plus d’informations, consultez la section relative au nettoyage de la mémoire Java de la gestion de la mémoire Java. La taille maximale du segment influence la fréquence du GC mineur et du GC complet. Le métaspace maximal et la taille maximale de mémoire directe influencent le GC complet. Si vous souhaitez ajuster la fréquence du nettoyage de la mémoire, envisagez de modifier les tailles de mémoire maximales suivantes.
jvm.gc.memory.allocatedest la quantité d’augmentation de la taille du pool de mémoire de nouvelle génération après un GC avant le suivant. Cette valeur reflète un GC mineur.jvm.gc.memory.promotedest la quantité d’augmentation de la taille du pool de mémoire ancienne génération après un GC. Cette valeur reflète le GC complet.
Vous trouverez cette fonctionnalité sur le Portail Azure, comme illustré dans la capture d’écran suivante. Vous pouvez choisir des métriques spécifiques et ajouter des filtres pour une application, un déploiement ou une instance spécifiques. Vous pouvez également appliquer le fractionnement.
Débogage supplémentaire
Pour un débogage supplémentaire, vous pouvez capturer manuellement des vidages de segments et des vidages de threads, et utiliser Java Flight Recorder (JFR). 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.
Les vidages de segments enregistrent l’état de la mémoire segmentée Java. Les vidages de threads enregistrent les piles de tous les threads actifs. Ces outils sont disponibles via Azure CLI et sur la page d’application du Portail Azure, comme illustré dans la capture d’écran suivante.
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. Vous pouvez également utiliser des outils tiers comme Memory Analyzer pour analyser les vidages de segments.
Modifier les configurations pour résoudre les problèmes
Certains problèmes que vous pouvez identifier incluent le conteneur OOM, la mémoire de segments trop volumineuse et le nettoyage de la mémoire anormal. Si vous identifiez l’un de ces problèmes, vous devrez peut-être configurer la taille de mémoire maximale dans les options JVM. Pour plus d’informations, consultez la section Options JVM importantes de la gestion de la mémoire Java.
Vous pouvez modifier les options JVM en utilisant le portail Azure ou Azure CLI.
Dans le portail Azure, accédez à votre application, puis sélectionnez Configuration dans la section Paramètres du menu de navigation. Sous l’onglet Paramètres généraux, mettez à jour le champ Options JVM, comme illustré dans la capture d’écran suivante :
