Pour résoudre le bogue de l'arrêt automatique de Tomcat_Tomcat

2020-02-14

Avant-propos

Le dernier projet Web javaee qui fonctionne depuis 4 ans reçoit souvent des commentaires des clients que le système ne peut pas être ouvert. Connectez-vous au serveur pour afficher le service et constater que tomcat est automatiquement fermé. Cela se produit une fois tous les 3 à 4 jours.

Le personnel d'exploitation et de maintenance a commencé à penser que d'autres services avaient tué le service tomcat, mais ils ne l'ont pas pris à cœur.

Enfin, le panier a été fermé, le personnel d'exploitation et de maintenance s'est plaint du client et leur performance a été déduite pendant un mois.

Je suis venu pour résoudre ce bug. Depuis la réception de la tâche, puis travaillez dessus, aucun bogue ne peut être résolu.

L'environnement d'exploitation du système est le suivant:

      
  • tomcat6.0
  •   
  • jdk7.0 32 bits
  •   
  • window server2003 32 bits, 32G mémoire.
  • Afficher les journaux. Si tomcat plante, il générera des fichiers journaux commençant par "hs_err" dans le répertoire bin tomcat. Ouvrez le dernier fichier journal, la première chose que vous voyez est le paragraphe suivant:


     # La mémoire est insuffisante pour que l'environnement d'exécution Java continue.
     # L'allocation de mémoire native (malloc) n'a pas pu allouer 32756 octets pour ChunkPool :: allocate
     # Raisons possibles:
     # Le système manque de RAM physique ou d'espace de swap
     # En mode 32 bits, la limite de taille du processus a été atteinte
     # Solutions possibles:
     # Réduisez la charge mémoire sur le système
     # Augmentez la mémoire physique ou permutez l'espace
     # Vérifiez si le magasin de sauvegarde de swap est plein
     # Utiliser Java 64 bits sur un système d'exploitation 64 bits
     # Diminuer la taille du tas Java (-Xmx / -Xms)
     # Diminue le nombre de threads Java
     # Diminuer les tailles de pile de threads Java (-Xss)
     # Définissez un cache de code plus grand avec -XX: ReservedCodeCacheSize =
     # Ce fichier de sortie peut être tronqué ou incomplet.
     #
     # Erreur de mémoire insuffisante (allocation.cpp: 211), pid = 7864, tid = 6556
     #
     # Version JRE: environnement d'exécution Java (TM) SE (7.0_79-b15) (build 1.7.0_79-b15)
     # Java VM: Java HotSpot (TM) Server VM (24.79-b02 mixed mode windows-x86)
     # Impossible d’écrire le vidage de mémoire. 
     

    Signifie probablement qu'il n'y a pas assez de mémoire pour allouer 32756 octets d'espace. Plusieurs solutions sont proposées en même temps:

    1. Réduisez la charge de la mémoire système;

    2. Augmentez la mémoire physique ou l'espace d'échange;

    3. Utilisez jdk 64 bits sur le système d'exploitation 64 bits;

    4. Réduisez la taille du tas java;

    5. Réduisez le nombre de threads java;

    6. Réduisez la taille de la pile de threads java.

    On peut conclure de ce qui précède que le jvm ne peut pas allouer 32756 octets d'espace mémoire.

    Depuis la réception de la tâche, j'ai toujours pensé que la configuration jvm était incorrecte, ce qui causait une mémoire insuffisante.

    Continuez à parcourir le fichier journal et recherchez la ligne "GC Heap History (10 events):", qui enregistre les modifications apportées au segment de mémoire au cours des 10 dernières récupérations de la jvm.


     GC Heap History (10 événements):
     Événement: 572312.299 tas GC avant
     {Tas avant invocations GC = 5046 (357 complet):
     PSYoungGen total 201472K, utilisé 200685K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 100% utilisé (0x573c0000,0x63540000,0x63540000)
     depuis l'espace 3328 Ko, 76% utilisé (0x63540000,0x637bb528,0x63880000)
     à l'espace 3328K, 0% utilisé (0x63880000,0x63880000,0x63bc0000)
     ParOldGen total 843776K, utilisé 422602K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d872b18,0x573c0000)
     PSPermGen total 262144K, utilisé 51848K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e62138,0x13bc0000)
     Événement: 572312,305 tas GC après
     Tas après invocations GC = 5046 (plein 357):
     PSYoungGen total 201472K, utilisé 1103K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 0% utilisé (0x573c0000,0x573c0000,0x63540000)
     depuis l'espace 3328K, 33% utilisé (0x63880000,0x63993c90,0x63bc0000)
     à l'espace 3328K, 0% utilisé (0x63540000,0x63540000,0x63880000)
     ParOldGen total 843776K, utilisé 423618K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% usd (0x23bc0000,0x3d970b18,0x573c0000)
     PSPermGen total 262144K, utilisé 51848K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e62138,0x13bc0000)
     }
     Événement: 572351.132 tas GC avant
     {Tas avant invocations GC = 5047 (plein 357):
     PSYoungGen total 201472K, utilisé 199247K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 100% utilisé (0x573c0000,0x63540000,0x63540000)
     depuis l'espace 3328K, 33% utilisé (0x63880000,0x63993c90,0x63bc0000)
     à l'espace 3328K, 0% utilisé (0x63540000,0x63540000,0x63880000)
     ParOldGen total 843776K, utilisé 423618K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d970b18,0x573c0000)
     PSPermGen total 262144K, utilisé 51848K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e62138,0x13bc0000)
     Événement: 572351.137 tas GC après
     Tas après invocations GC = 5047 (plein 357):
     PSYoungGen total 201472K, utilisé 1615K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 0% utilisé (0x573c0000,0x573c0000,0x63540000)
     depuis l'espace 3328K, 48% utilisé (0x63540000,0x636d3ec8,0x63880000)
     à l'espace 3328K, 0% utilisé (0x63880000,0x63880000,0x63bc0000)
     ParOldGen total 843776K, utilisé 423674K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d97eb18,0x573c0000)
     PSPermGen total 262144K, utilisé 51848K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e62138,0x13bc0000)
     }
     Événement: 572398.649 tas GC avant
     (Tas avant invocations GC = 5048 (plein 357):
     PSYoungGen total 201472K, utilisé 199759K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 100% utilisé (0x573c0000,0x63540000,0x63540000)
     depuis l'espace 3328K, 48% utilisé (0x63540000,0x636d3ec8,0x63880000)
     à l'espace 3328K, 0% utilisé (0x63880000,0x63880000,0x63bc0000)
     ParOldGen total 843776K, utilisé 423674K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d97eb18,0x573c0000)
     PSPermGen total 262144K, utilisé 51848K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e62138,0x13bc0000)
     Événement: 572398,655 tas GC après
     Tas après invocations GC = 5048 (plein 357):
     PSYoungGen total 201472K, utilisé 1998K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 0% utilisé (0x573c0000,0x573c0000,0x63540000)
     depuis l'espace 3328K, 60% utilisé (0x63880000,0x63a73830,0x63bc0000)
     à l'espace 3328K, 0% utilisé (0x63540000,0x63540000,0x63880000)
     ParOldGen total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51848K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e62138,0x13bc0000)
     }
     Événement: 576881.689 tas GC avant
     {Tas avant invocations GC = 5049 (357 complet):
     PSYoungGen total 201472K, utilisé 200142K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 100% utilisé (0x573c0000,0x63540000,0x63540000)
     depuis l'espace 3328K, 60% utilisé (0x63880000,0x63a73830,0x63bc0000)
     à l'espace 3328K, 0% utilisé (0x63540000,0x63540000,0x63880000)
     ParOldGen total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51850K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e62850,0x13bc0000)
     Événement: 576881,696 tas GC après
     Tas après invocations GC = 5049 (plein 357):
     PSYoungGen total 201472K, utilisé 3155K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 0% utilisé (0x573c0000,0x573c0000,0x63540000)
     depuis l'espace 3328K, 94% utilisé (0x63540000,0x63854cb0,0x63880000)
     à l'espace 3328K, 0% utilisé (0x63880000,0x63880000,0x63bc0000)
     ParOldGen total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51850K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e62850,0x13bc0000)
     }
     Événement: 580535.452 tas GC avant
     {Tas avant invocations GC = 5050 (plein 357):
     PSYoungGen total 201472K, utilisé 201299K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 100% utilisé (0x573c0000,0x63540000,0x63540000)
     depuis l'espace 3328K, 94% utilisé (0x63540000,0x63854cb0,0x63880000)
     à l'espace 3328K, 0% utilisé (0x63880000,0x63880000,0x63bc0000)
     ParOldGen total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51856K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e64228,0x13bc0000)
     Événement: 580535.459 tas GC après
     Tas après invocations GC = 5050 (plein 357):
     PSYoungGen total 200960K, utilisé 1858K (0x573c0000, 0x63bc0000, 0x63bc0000)
     eden space 197632K, 0% utilisé (0x573c0000,0x573c0000,0x634c0000)
     depuis l'espace 3328K, 55% utilisé (0x63880000,0x63a50be0,0x63bc0000)
     à l'espace 3584K, 0% utilisé (0x634c0000,0x634c0000,0x63840000)
     ParOldGen total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51856K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e64228,0x13bc0000)
     } 
     

    Après avoir lu le contenu ci-dessus, je n'ai pas trouvé que l'effondrement du flash tomcat était dû à un espace insuffisant dans l'ancienne génération, la génération persistante et la nouvelle génération. Il y a plusieurs fois où 100% de l'espace dans la zone eden est utilisé pour le gc complet, mais l'espace dans la zone eden est revenu à des niveaux normaux après le garbage collection.

    Le journal enregistre également l'utilisation du segment de mémoire lors de l'effondrement flash tomcat:


     Tas
     PSYoungGen total 200960K, utilisé 95671K (0x573c0000, 0x63bc0000, 0x63bc0000)
     eden space 197632K, 47% utilisé (0x573c0000,0x5cf5d230,0x634c0000)
     depuis l'espace 3328K, 55% utilisé (0x63880000,0x63a50be0,0x63bc0000)
     à l'espace 3584K, 0% utilisé (0x634c0000,0x634c0000,0x63840000)
     ParOldGen total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51856K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e64228,0x13bc0000) 
     

    Tout est tellement normal et bizarre.

    En regardant le journal qui s'est produit auparavant, le contenu est similaire.

    Revisité le journal plusieurs fois, cette fois en se concentrant sur les solutions suggérées dans le journal:


     # Réduire memau total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51850K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e62850,0x13bc0000)
     Événement: 576881,696 tas GC après
     Tas après invocations GC = 5049 (plein 357):
     PSYoungGen total 201472K, utilisé 3155K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 0% utilisé (0x573c0000,0x573c0000,0x63540000)
     depuis l'espace 3328K, 94% utilisé (0x63540000,0x63854cb0,0x63880000)
     à l'espace 3328K, 0% utilisé (0x63880000,0x63880000,0x63bc0000)
     ParOldGen total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51850K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e62850,0x13bc0000)
     }
     Événement: 580535.452 tas GC avant
     {Tas avant invocations GC = 5050 (plein 357):
     PSYoungGen total 201472K, utilisé 201299K (0x573c0000, 0x63bc0000, 0x63bc0000)
     espace Eden 198144K, 100% utilisé (0x573c0000,0x63540000,0x63540000)
     depuis l'espace 3328K, 94% utilisé (0x63540000,0x63854cb0,0x63880000)
     à l'espace 3328K, 0% utilisé (0x63880000,0x63880000,0x63bc0000)
     ParOldGen total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51856K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e64228,0x13bc0000)
     Événement: 580535.459 tas GC après
     Tas après invocations GC = 5050 (plein 357):
     PSYoungGen total 200960K, utilisé 1858K (0x573c0000, 0x63bc0000, 0x63bc0000)
     eden space 197632K, 0% utilisé (0x573c0000,0x573c0000,0x634c0000)
     depuis l'espace 3328K, 55% utilisé (0x63880000,0x63a50be0,0x63bc0000)
     à l'espace 3584K, 0% utilisé (0x634c0000,0x634c0000,0x63840000)
     ParOldGen total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51856K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e64228,0x13bc0000)
     } 
     

    Après avoir lu le contenu ci-dessus, je n'ai pas trouvé que l'effondrement du flash tomcat était dû à un espace insuffisant dans l'ancienne génération, la génération persistante et la nouvelle génération. Il y a plusieurs fois où 100% de l'espace dans la zone eden est utilisé pour le gc complet, mais l'espace dans la zone eden est revenu à des niveaux normaux après le garbage collection.

    Le journal enregistre également l'utilisation du segment de mémoire lors de l'effondrement flash tomcat:


     Tas
     PSYoungGen total 200960K, utilisé 95671K (0x573c0000, 0x63bc0000, 0x63bc0000)
     eden space 197632K, 47% utilisé (0x573c0000,0x5cf5d230,0x634c0000)
     depuis l'espace 3328K, 55% utilisé (0x63880000,0x63a50be0,0x63bc0000)
     à l'espace 3584K, 0% utilisé (0x634c0000,0x634c0000,0x63840000)
     ParOldGen total 843776K, utilisé 423703K (0x23bc0000, 0x573c0000, 0x573c0000)
     espace objet 843776K, 50% utilisé (0x23bc0000,0x3d985cc0,0x573c0000)
     PSPermGen total 262144K, utilisé 51856K (0x03bc0000, 0x13bc0000, 0x23bc0000)
     espace objet 262144K, 19% utilisé (0x03bc0000,0x06e64228,0x13bc0000) 
     

    Tout est tellement normal et bizarre.

    En regardant le journal qui s'est produit auparavant, le contenu est similaire.

    Revisité le journal plusieurs fois, cette fois en se concentrant sur les solutions suggérées dans le journal:


     # Réduisez la charge mémoire sur le système
     # Augmentez la mémoire physique ou permutez l'espace
     # Vérifiez si le magasin de sauvegarde de swap est plein
     # Utiliser Java 64 bits sur un système d'exploitation 64 bits
     # Diminuer la taille du tas Java (-Xmx / -Xms)
     # Diminue le nombre de threads Java
     # Diminuer les tailles de pile de threads Java (-Xss) 
     

    Les solutions suivantes ne sont pas adoptées:

        
    • Réduisez la charge mémoire sur le système. La mémoire système est suffisante. Avec 32 Go de mémoire, 20 Go restent inutilisés. Pas besoin de réduire la mémoire.
    •   
    • Augmentez la mémoire physique ou permutez l'espace. La mémoire système est suffisante. Avec 32 Go de mémoire, 20 Go restent inutilisés, pas besoin d'augmenter la mémoire physique.
    •   
    • Utilisez Java 64 bits sur un système d'exploitation 64 bits. Un système d'exploitation 32 bits ne peut pas utiliser un jdk 64 bits.
    • Il ne reste que trois solutions:

          
      • Diminue la taille du tas Java (-Xmx / -Xms). Si le tas est défini trop grand, la mémoire restante sera affectée.
      •   
      • Diminue le nombre de threads Java
      •   
      • Diminuer la taille des piles de threads Java (-Xss)
      • Pour réduire le nombre de threads Java, vous devez modifier le code, ce qui n'est pas pratique.

        Dernière gauche

            
        • Diminue la taille du tas Java (-Xmx / -Xms)
        •   
        • Diminuer la taille des piles de threads Java (-Xss)
        • Avec ces deux solutions, commencez ici et l'aube est en avance.

          Examinez d'abord la solution Diminuer les tailles de pile de threads Java (-Xss)

          Les threads Java ont également besoin d'espace mémoire pour s'exécuter. Le paramètre -Xss spécifie la taille de chaque pile de threads et la quantité de mémoire allouée pour chaque thread démarré par le jvm. Dans la version jdk1.4, il s'agit de 256K, JDK1.5 et supérieur est de 1M.

          Les réglages des paramètres de tomcat jvm sont les suivants:


           JAVA_OPTS =% JAVA_OPTS% -server -Xms1024m -Xmx1024m -Xmn200M -XX: PermSize = 256M -XX: MaxPermSize = 512m -XX: SurvivorRatio = 1 -Xss256k 
           

          La taille de chaque pile de threads Java a été définie à 256 Ko via -Xss.

          Dans le langage Java, lorsque vous créez un thread, la machine virtuelle crée un objet Thread dans la mémoire JVM et crée un thread du système d'exploitation. La mémoire de ce thread système n'est pas JVMMemory, mais le reste du système. Mémoire (MaxProcessMemory-JVMMemory-ReservedOsMemory).

          Lorsqu'un thread doit être créé et que la mémoire restante du système d'exploitation n'est pas suffisante pour être allouée à un thread java, une erreur d'erreur de mémoire insuffisante est signalée.

          Étant donné que la taille de la pile de threads java est définie entre 256 Ko et -Xss, il est également décidé de ne pas utiliser cette solution.

          La seule solution qui reste est de diminuer la taille du tas Java (-Xmx / -Xms). En réduisant la taille du tas, en laissant suffisamment d'espace mémoire pour la pile de threads Java.

          Le système d'exploitation de fenêtre 32 bits alloue 2 Go d'espace mémoire à chaque processus, moins la capacité maximale du tas et la capacité maximale de PermSize, et la capacité restante est réservée à la pile de threads Java.

          Après avoir analysé le code et le journal des erreurs précédent, il est constaté qu'une erreur de mémoire insuffisante se produit généralement dans 350 threads.
          Lorsque des erreurs se produisent, moins de 40% de l'espace de tas est utilisé. Par conséquent, il a été décidé de réduire le tas Java de 1G à 768M.

          Les paramètres jvm modifiés sont les suivants:


           JAVA_OPTS =% JAVA_OPTS% -server -Xms768m -Xmx768m -Xmn200M -XX: PermSize = 256M -XX: MaxPermSize = 512m -XX: SurvivorRatio = 1 -Xss256k 
           

          Jusqu'à présent, le système fonctionne régulièrement depuis 1 mois et chaque index de paramètre se situe dans la plage normale. L'utilisation de tas la plus élevée n'est que de 70%.

          Résumé:

          1. Après avoir résolu ce bogue, j'ai approfondi ma compréhension de la machine virtuelle Java, en particulier les concepts de pile de threads, de tas de mémoire, de génération persistante et de nouvelle génération.

          2. Assurez-vous de lire attentivement les fichiers journaux pour exclure étape par étape les solutions potentielles. Synthétisez l'environnement d'exploitation du système et trouvez une solution raisonnable.

          D'accord, ce qui précède est l'intégralité du contenu de cet article. J'espère que le contenu de cet article aura une certaine référence et valeur d'apprentissage pour l'étude ou le travail de chacun. Merci de votre soutien.

          ory charge sur le système # Augmentez la mémoire physique ou permutez l'espace # Vérifiez si le magasin de sauvegarde de swap est plein # Utiliser Java 64 bits sur un système d'exploitation 64 bits # Diminuer la taille du tas Java (-Xmx / -Xms) # Diminue le nombre de threads Java # Diminuer les tailles de pile de threads Java (-Xss)

          Les solutions suivantes ne sont pas adoptées:

              
          • Réduisez la charge mémoire sur le système. La mémoire système est suffisante. Avec 32 Go de mémoire, 20 Go restent inutilisés. Pas besoin de réduire la mémoire.
          •   
          • Augmentez la mémoire physique ou permutez l'espace. La mémoire système est suffisante. Avec 32 Go de mémoire, 20 Go restent inutilisés, pas besoin d'augmenter la mémoire physique.
          •   
          • Utilisez Java 64 bits sur un système d'exploitation 64 bits. Un système d'exploitation 32 bits ne peut pas utiliser un jdk 64 bits.
          • Il ne reste que trois solutions:

                
            • Diminue la taille du tas Java (-Xmx / -Xms). Si le tas est défini trop grand, la mémoire restante sera affectée.
            •   
            • Diminue le nombre de threads Java
            •   
            • Diminuer la taille des piles de threads Java (-Xss)
            • Pour réduire le nombre de threads Java, vous devez modifier le code, ce qui n'est pas pratique.

              Dernière gauche

                  
              • Diminue la taille du tas Java (-Xmx / -Xms)
              •   
              • Diminuer la taille des piles de threads Java (-Xss)
              • Avec ces deux solutions, commencez ici et l'aube est en avance.

                Examinez d'abord la solution Diminuer les tailles de pile de threads Java (-Xss)

                Les threads Java ont également besoin d'espace mémoire pour s'exécuter. Le paramètre -Xss spécifie la taille de chaque pile de threads et la quantité de mémoire allouée pour chaque thread démarré par le jvm. Dans la version jdk1.4, il s'agit de 256K, JDK1.5 et supérieur est de 1M.

                Les réglages des paramètres de tomcat jvm sont les suivants:


                 JAVA_OPTS =% JAVA_OPTS% -server -Xms1024m -Xmx1024m -Xmn200M -XX: PermSize = 256M -XX: MaxPermSize = 512m -XX: SurvivorRatio = 1 -Xss256k 
                 

                La taille de chaque pile de threads Java a été définie à 256 Ko via -Xss.

                Dans le langage Java, lorsque vous créez un thread, la machine virtuelle crée un objet Thread dans la mémoire JVM et crée un thread du système d'exploitation. La mémoire de ce thread système n'est pas JVMMemory, mais le reste du système. Mémoire (MaxProcessMemory-JVMMemory-ReservedOsMemory).

                Lorsqu'un thread doit être créé et que la mémoire restante du système d'exploitation n'est pas suffisante pour être allouée à un thread java, une erreur d'erreur de mémoire insuffisante est signalée.

                Étant donné que la taille de la pile de threads java est définie entre 256 Ko et -Xss, il est également décidé de ne pas utiliser cette solution.

                La seule solution qui reste est de diminuer la taille du tas Java (-Xmx / -Xms). En réduisant la taille du tas, en laissant suffisamment d'espace mémoire pour la pile de threads Java.

                Le système d'exploitation de fenêtre 32 bits alloue 2 Go d'espace mémoire à chaque processus, moins la capacité maximale du tas et la capacité maximale de PermSize, et la capacité restante est réservée à la pile de threads Java.

                Après avoir analysé le code et le journal des erreurs précédent, il est constaté qu'une erreur de mémoire insuffisante se produit généralement dans 350 threads.
                Lorsque des erreurs se produisent, moins de 40% de l'espace de tas est utilisé. Par conséquent, il a été décidé de réduire le tas Java de 1G à 768M.

                Les paramètres jvm modifiés sont les suivants:


                 JAVA_OPTS =% JAVA_OPTS% -server -Xms768m -Xmx768m -Xmn200M -XX: PermSize = 256M -XX: MaxPermSize = 512m -XX: SurvivorRatio = 1 -Xss256k 
                 

                Jusqu'à présent, le système fonctionne régulièrement depuis 1 mois et chaque index de paramètre se situe dans la plage normale. L'utilisation de tas la plus élevée n'est que de 70%.

                Résumé:

                1. Après avoir résolu ce bogue, j'ai approfondi ma compréhension de la machine virtuelle Java, en particulier les concepts de pile de threads, de tas de mémoire, de génération persistante et de nouvelle génération.

                2. Assurez-vous de lire attentivement les fichiers journaux pour exclure étape par étape les solutions potentielles. Synthétisez l'environnement d'exploitation du système et trouvez une solution raisonnable.

                D'accord, ce qui précède est l'intégralité du contenu de cet article. J'espère que le contenu de cet article aura une certaine référence et valeur d'apprentissage pour l'étude ou le travail de chacun. Merci de votre soutien.

                La quantité de mémoire allouée par le thread. Dans la version jdk1.4, il s'agit de 256K, JDK1.5 et supérieur est de 1M.

                Les réglages des paramètres de tomcat jvm sont les suivants:


                 JAVA_OPTS =% JAVA_OPTS% -server -Xms1024m -Xmx1024m -Xmn200M -XX: PermSize = 256M -XX: MaxPermSize = 512m -XX: SurvivorRatio = 1 -Xss256k 
                 

                La taille de chaque pile de threads Java a été définie à 256 Ko via -Xss.

                Dans le langage Java, lorsque vous créez un thread, la machine virtuelle crée un objet Thread dans la mémoire JVM et crée un thread du système d'exploitation. La mémoire de ce thread système n'est pas JVMMemory, mais le reste du système. Mémoire (MaxProcessMemory-JVMMemory-ReservedOsMemory).

                Lorsqu'un thread doit être créé et que la mémoire restante du système d'exploitation n'est pas suffisante pour être allouée à un thread java, une erreur d'erreur de mémoire insuffisante est signalée.

                Étant donné que la taille de la pile de threads java est définie entre 256 Ko et -Xss, il est également décidé de ne pas utiliser cette solution.

                La seule solution qui reste est de diminuer la taille du tas Java (-Xmx / -Xms). En réduisant la taille du tas, en laissant suffisamment d'espace mémoire pour la pile de threads Java.

                Le système d'exploitation de fenêtre 32 bits alloue 2 Go d'espace mémoire à chaque processus, moins la capacité maximale du tas et la capacité maximale de PermSize, et la capacité restante est réservée à la pile de threads Java.

                Après avoir analysé le code et le journal des erreurs précédent, il est constaté qu'une erreur de mémoire insuffisante se produit généralement dans 350 threads.
                Lorsque des erreurs se produisent, moins de 40% de l'espace de tas est utilisé. Par conséquent, il a été décidé de réduire le tas Java de 1G à 768M.

                Les paramètres jvm modifiés sont les suivants:


                 JAVA_OPTS =% JAVA_OPTS% -server -Xms768m -Xmx768m -Xmn200M -XX: PermSize = 256M -XX: MaxPermSize = 512m -XX: SurvivorRatio = 1 -Xss256k 
                 

                Jusqu'à présent, le système fonctionne régulièrement depuis 1 mois et chaque index de paramètre se situe dans la plage normale. L'utilisation de tas la plus élevée n'est que de 70%.

                Résumé:

                1. Après avoir résolu ce bogue, j'ai approfondi ma compréhension de la machine virtuelle Java, en particulier les concepts de pile de threads, de tas de mémoire, de génération persistante et de nouvelle génération.

                2. Assurez-vous de lire attentivement les fichiers journaux pour exclure étape par étape les solutions potentielles. Synthétisez l'environnement d'exploitation du système et trouvez une solution raisonnable.

                D'accord, ce qui précède est l'intégralité du contenu de cet article. J'espère que le contenu de cet article aura une certaine référence et valeur d'apprentissage pour l'étude ou le travail de chacun. Merci de votre soutien.

www.xd1998.com@2001-2030Partage De Technologie