Vous consultez actuellement l'aide de la version:

Une fois les instances CQ déployées, certaines tâches sont nécessaires pour surveiller et conserver leur fonctionnalité, performance et intégrité.

Un facteur clé est qu’en vue d’identifier des problèmes potentiels, vous devez savoir comment vos systèmes fonctionnent dans des conditions normales. Le meilleur moyen pour cela est de surveiller le système et de collecter des informations sur une période donnée.

Vérification Considérations Commentaire/Actions
Plan de sauvegarde.   Découvrez comment sauvegarder votre instance CQ.
Plan de reprise sur sinistre. Consignes de reprise sur sinistre de votre entreprise.  
Un système de suivi des erreurs est disponible pour signaler les problèmes. Par exemple, bugzilla, jira, ou plusieurs autres.  
Les systèmes de fichier sont surveillés. Le référentiel CRX se "bloque" s’il n’y a pas suffisamment d’espace disque disponible. Il reprendra une fois qu’il y aura suffisament d’espace disponible. "*ERROR* LowDiskSpaceBlocker" De tels messages s’affichent dans le fichier journal lorsque l’espace disque est faible.
Les fichiers journaux sont surveillés.    
La surveillance du système est (constamment) exécutée en arrière-plan. Cela comprend l’usage du processeur, de la mémoire, du disque et du réseau. Utilisation, par exemple, de iostat / vmstat / perfmon. Les données enregistrées sont visualisées et peuvent être utilisées pour suivre les problèmes de performance. Les données brutes sont également accessibles.
Les performances CQ sont surveillées. Cela comprend le décompte des demandes pour surveiller le niveau de trafic. Si une perte de performance significative ou sur le long terme est constatée, une investigation approfondie doit être entreprise.
Vous surveillez vos agents de réplication.    
Purge régulière des instances de workflow. Taille du référentiel et performance des workflows. Voir Purge régulière des instances de workflow.

Sauvegardes

Il est recommandé de sauvegarder :

  • L’installation de votre logiciel, avant ou après des modifications importantes dans la configuration
  • Le contenu conservé dans le référentiel - régulièrement

Votre entreprise a probablement établi un protocole de sauvegarde que vous devez suivre, des considérations supplémentaires sur ce qui doit être sauvegardé et quand inclure :

  • L’importance du système et des données.
  • À quelle fréquence les modifications sont-elles apportées au logiciel ou aux données ?
  • Le volume de données ; la capacité peut parfois poser problème, de même que la durée nécessaire pour effectuer la sauvegarde.
  • Si votre sauvegarde peut être effectuée au moment où les utilisateurs sont en ligne ; et si possible, quel est l’impact sur la performance.
  • La position géographique des utilisateurs ; quel est le meilleur moment pour effectuer la sauvegarde (pour minimiser l’impact) ?
  • Votre stratégie de reprise après sinistre; y a-t-il des directives sur l’emplacement du stockage de données de sauvegarde (par exemple, hors site et médias spécifiques etc.).

Une sauvegarde complète est souvent effectuée à intervalles réguliers (par exemple de manière quotidienne, hebdomadaire ou mensuelle), avec des sauvegardes incrémentielles (par exemple par heure, jour ou semaine).

Attention :

Lors de l’exécution des sauvegardes de vos instances de production, des tests doivent être effectués pour vous assurer que la sauvegarde peut être restaurée.

Sans cela, la sauvegarde est potentiellement inutile (au pire des cas).

Remarque :

Pour plus d’informations sur les performances de sauvegarde, consultez la section Performance de sauvegarde.

Prise en charge de votre installation logicielle

Après l’installation de votre configuration ou des modifications importantes au sein de celle-ci, effectuez une sauvegarde de votre installation logicielle.

Pour ce faire, vous devez sauvegarder entièrement votre référentiel, puis :

  1. Désactiver CQ.

  2. Sauvegardez l’intégralité du fichier <cq-installation-dir> depuis votre système de fichiers.

Attention :

Si vous gérez un serveur d’application tiers, des fichiers supplémentaires peuvent se trouver sur un emplacement différent et doivent galement être pris en charge. Découvrez comment installer AEM avec un serveur d’application pour plus d’informations sur la configuration des serveurs d’applications.

Attention :

La sauvegarde incrémentielle de l’entrepôt de données de fichier est prise en charge ; lorsque vous utilisez la sauvegarde incrémentielle pour d’autres composants (tels que l’index Lucene), assurez-vous que les fichiers supprimés sont également marqués comme supprimé dans la sauvegarde.

Remarque :

La duplication du disque peut également être utilisée comme mécanisme de sauvegarde.

Sauvegarde de votre référentiel

La section Sauvegarde et restauration de la documentation CRX permet de couvrir tous les problèmes liés aux sauvegardes du référentiel CRX.

Pour des détails sur l’exécution d’une sauvegarde « à chaud » en ligne, voir Création d’une sauvegarde en ligne.

Purge de version

L’outil Purge de versions est prévu pour la purge des versions d’un nœud ou d’une hiérarchie de nœuds dans votre référentiel. Son principal objectif est de vous aider à réduire la taille du référentiel en supprimant les anciennes versions de vos nœuds.

Cette section traite des opérations de maintenance liées à la fonctionnalité de création de versions de CQ. L’outil Purge de versions est prévu pour la purge des versions d’un nœud ou d’une hiérarchie de nœuds dans votre référentiel. Son principal objectif est de vous aider à réduire la taille du référentiel en supprimant les anciennes versions de vos nœuds.

Aperçu

L’outil Purge de versions est disponible dans la console Outils sous Versions ou directement à l’adresse :

http://<server>:<port>/etc/versioning/purge.html

screen_shot_2012-03-15at14418pm

Chemin de début

Un chemin absolu sur lequel la purge doit être effectuée. Vous pouvez sélectionner le chemin de début en cliquant sur le navigateur d’arborescence du référentiel.

Récursif

Lors de la purge des données, vous pouvez choisir d’effectuer une opération sur un nœud ou sur une hiérarchie complète en choisissant Récursif. Dans ce cas, le chemin donné définit le nœud racine de la hiérarchie.

Nombre maximum de versions à conserver

Le nombre maximum de versions à conserver pour un nœud. Lorsque ce nombre dépasse la valeur, les versions les plus anciennes sont purgées.

Âge maximal de la version

L’âge maximal de la version d’un nœud. Lorsque l’âge d’une version dépasse cette valeur, elle est purgée.

Exécution d’essai

Étant donné que la suppression des versions de contenu est définitive et ne peut pas être rétablie sans la restauration d’une sauvegarde, l’outil Purge de versions fournit un mode Exécution d’essai qui permet d’afficher un aperçu des versions purgées. Pour lancer le mode Exécution d’essai du processus de purge, cliquez sur Exécution d’essai.

Purge

Lancez la purge des versions sur le nœud défini par le chemin de début.

Purge des versions d’un site web

Pour purger les versions d’un site web, procédez comme suit :

  1. Accédez à la console Outils, sélectionnez Versions et double-cliquez sur Purger les versions.

  2. Définir le chemin de début du contenu à purger (par exemple /content/geometrixx-outdoors).

    • Si vous souhaitez purger uniquement le nœud défini par le chemin, désélectionner Récursif.
    • Si vous souhaitez purger le nœud défini par le chemin et ses descendants, sélectionnez Récursif.
  3. Définissez le nombre maximal de versions (pour chaque nœud) que vous souhaitez conserver. Laissez le paramètre vide si vous ne souhaitez pas l’utiliser.

  4. Définissez l’âge maximal de la version en jours (pour chaque nœud) que vous souhaitez conserver. Laissez le paramètre vide si vous ne souhaitez pas l’utiliser.

  5. Cliquez sur Exécution d’essai pour prévisualiser le processus de purge.

  6. Cliquez sur Purge pour lancer le processus.

Attention :

Les nœuds purgés ne peuvent pas être rétablis sans restaurer le référentiel. Vous devez veiller à votre configuration. Nous vous recommandons de toujours lancer une exécution d’essai avant la purge.

Analyse de la console

Les processus Exécution d’essai et Purge répertorient tous les noeuds qui ont été traités. Au cours du processus, un nœud peut avoir l’un des états suivants :

  • ignorer (pas de version) : le nœud ne prend pas en charge les versions et est ignoré lors du processus.
  • ignorer (aucune version) : le nœud n’a pas de version et est ignoré lors du processus.
  • conservé : le nœud n’est pas purgé.
  • purgé : le nœud est purgé.

Par ailleurs, la console affiche des informations utiles sur les versions :

  • V 1.0 : le numéro de version.
  • V 1.0.1 * : l’étoile indique que la version est active.
  • Thu Mar 15 2012 08:37:32 GMT+0100 : la date de la version.

Dans l’exemple suivant :

  • Les versions Shirts sont purgées parce que leur âge de version est supérieur à 2 jours.
  • Les versions Tonga Fashions! sont purgées, car le nombre de versions est supérieur à 5.
global_version_screenshot

Utilisation des enregistrements et des fichiers journaux d’audit

Les enregistrements et les fichiers journaux d’audit associés à Adobe Experience Manager (AEM) sont disponibles dans différents emplacements. Ce qui suit vise à vous donner un aperçu de ce que vous pouvez trouver, à quels emplacements.

Utilisation des journaux

La gestion du contenu web d’AEM permet d’enregistrer de manière détaillée les journaux. Après avec décompressé et démarré Quickstart, vous pouvez trouver les journaux à l’adresse suivante :

  • <cq-installation-dir>/crx-quickstart/logs/
  • <cq-installation-dir>/crx-quickstart/repository/

Rotation de fichier journal

La rotation de fichier journal fait référence au processus qui limite la croissance du fichier par la création régulière d’un nouveau fichier. Dans AEM, un fichier journal appelé error.log est activé une fois par jour, selon les règles en place :

  • Le fichier error.log est renommé selon le modèle {original_filename}.yyyy-MM-dd. Par exemple, le 11 juillet 2010, le fichier journal actuel est renommé error.log-2010-07-10, puis un nouveau fichier error.og est créé.
  • Les fichiers journaux précédents ne sont pas supprimés. Il est de votre responsabilité de nettoyer les anciens fichiers journaux régulièrement pour limiter l’utilisation du disque.

Remarque :

Si vous mettez à niveau votre installation d’AEM, notez que tout fichier journal existant qui n’est plus utilisé par AEM restera sur le disque. Vous pouvez les supprimer en toute sécurité. Toutes les nouvelles entrées de journal seront écrites dans les nouveaux fichiers journaux.

Recherche de fichiers journaux

Divers fichiers journaux sont conservés sur le serveur de fichiers sur lequel vous avez installé AEM :

  • <cq-installation-dir>/crx-quickstart/logs
    • access.log
      Toutes les demandes d’accès à la gestion du contenu web d’AEM et au référentiel sont enregistrées ici.
    • audit.log
      Les actions de modération sont enregistrées ici.
    • error.log
      Les messages d’erreur (de différents niveaux de gravité) sont enregistrés ici.
    • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
      Ce journal est uniquement utilisé si Dynamic Media est activé. Il propose des statistiques et des informations d’analyse utilisées pour analyser le comportement du processus interne d’ImageServer.
    • request.log
      Chaque demande d’accès est enregistrée ici en même temps que la réponse.
    • s7access-<yyyy>-<mm>-<dd>.log
      Ce journal est uniquement utilisé si Dynamic Media est activé. Le journal s7access enregistre chaque demande faite à Dynamic Media via /is/image et /is/content.
    • stderr.log
      Contient les messages d’erreur, de différents niveaux de gravité, générés lors du démarrage. Par défaut, le niveau de journalisation est défini sur Avertissement (WARN)
    • stdout.log
      Contient des messages de journaux indiquant les événements pendant le démarrage.
    • upgrade.log
      Fournit un journal de toutes les opérations de mise à niveau s’exécutant depuis les modules com.day.compat.codeupgrade et com.adobe.cq.upgradesexecutor.
  • <cq-installation-dir>/crx-quickstart/repository
    • revision.log
      Informations sur la journalisation des révisions.

Remarque :

Les journaux ImageServer et s7access ne sont pas inclus dans le module complet de téléchargement généré à partir de system/console/status-Bundlelist. Pour la prise en charge, si vous avez des problèmes avec Dynamic Media, ajoutez également les journaux ImageServer et s7access lorsque vous contactez le service clientèle. 

Activation du niveau de journalisation DEBUG

Le niveau de journalisation par défaut (configuration des journaux Apache Sling) consiste en des informations, les messages de débogage n’y sont donc pas consignés.

Pour activer le niveau de journalisation de débogage pour un journal, définissez la propriété org.apache.sling.commons.log.level pour le débogage dans le référentiel. Par exemple, sur /libs/sling/config/org.apache.sling.commons.log.LogManager pour configurer la journalisation globale Apache Sling.

Attention :

Ne laissez pas le journal au niveau de débogage plus longtemps que nécéssaire, car cela génère un grand nombre d’entrées, causant ainsi du gaspillage de ressources.

Une ligne dans le fichier de débogage commence généralement par DEBUG, puis fournit le niveau de journalisation, l’action d’installation et le message du journal. Par exemple :

DEBUG 3 WebApp Panel: WebApp successfully deployed

Les niveaux de journalisation sont les suivants :

0 Erreur fatale L’action a échoué et l’installateur ne peut pas continuer.
1 Erreur L’action a échoué. L’installation se poursuit, mais une partie de la gestion du contenu web d’AEM n’a pas été installée correctement et ne fonctionnera pas.
2 Avertissement L’action a réussi, mais des problèmes sont survenus. La gestion du contenu web d’AEM risque de ne pas fonctionner correctement.
3 Information L’action a réussi.

Création d’un fichier journal personnalisé

Remarque :

Lorsque vous utilisez Adobe Experience Manager, vous disposez de plusieurs méthodes pour gérer les paramètres de configuration pour ces services. Consultez Configuration OSGi pour obtenir plus de détails et les pratiques recommandées.

Dans certains cas, vous pouvez créer un fichier journal personnalisé avec un niveau de journalisation différent. Vous pouvez le faire depuis le référentiel en procédant comme suit :

  1. S’il n’existe pas déjà, créez un dossier de configuration (sling:Folder) pour votre projet /apps/<project-name >/config.

  2. Sous /apps/<project-name>/config, créez un nœud pour la nouvelle configuration de l’enregistreur de journaux Apache Sling :

    • Nom : org.apache.sling.commons.log.LogManager.factory.config-<identifiant> (comme c’est un enregistreur)
      <identifiant> est remplacé par un texte libre que vous devez saisir pour identifer l’instance (vous ne pouvez pas ignorer cette information). Par exemple, org.apache.sling.commons.log.LogManager.factory.config-MINE
    • Type : sling:OsgiConfig

    Remarque :

    Bien que cela ne constitue pas une exigence technique, il est recommandé de rendre <identifiant> unique.

  3. Fixez les propriétés suivantes sur ce nœud :

    • Nom : org.apache.sling.commons.log.file
      Type: Chaîne
      Valeur: spécifiez le fichier journal ; par exemple, logs/myLogFile.log

    • Nom : org.apache.sling.commons.log.names
      Type : Chaîne[] (Chaîne + Multi)
      Valeur : spécifiez les services OSGi pour lequel l’enregistreur consigne les messages ; par exemple, tous les services suivants :
      • org.apache.sling
      • org.apache.felix
      • com.day
    • Nom : org.apache.sling.commons.log.level
      Type : Chaîne
      Valeur : spécifiez le niveau de journalisation requis (debug, info, warn ou error) ; par exemple debug
    • Configurez les autres paramètres en fonction de vos besoins :
      • Nom : org.apache.sling.commons.log.pattern
        Type : Chaîne
        Valeur : spécifiez le modèle de message de journal requis ; par exemple,
        {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

    Remarque :

    org.apache.sling.commons.log.pattern prend en charge jusqu’à six arguments.

    {0} L’horodatage de type java.util.Date
    {1} l’indicateur de journal
    {2} le nom du thread actuel
    {3} le nom de l’enregistreur
    {4} le niveau de journalisation
    {5} le message de journal

    Si l’appel de journal comprend un Throwable, la trace de pile est ajoutée au message.

    Attention :

    org.apache.sling.commons.log.names doit avoir une valeur.

    Remarque :

    Les chemins de l’auteur de journal est relatif à l’emplacement de quickstart.

    Par conséquent, un fichier journal spécifié en tant que :

        logs/thelog.log

    écrit à :

        <cq-installation-dir>/crx-quickstart/logs/thelog.log.

    Et un fichier journal spécifié en tant que :

        ../logs/thelog.log

    écrit à un répertoire :

        <cq-installation-dir>/logs/
        (c’est-à-dire à côté de  <cq-installation-dir>/crx-quickstart/)

  4. Cette étape est nécessaire uniquement lorsqu’un nouvel auteur est nécessaire (c’est-à-dire avec une configuration différente de l’auteur par défaut).

    Attention :

    Une nouvelle configuration d’auteur de journalisation est uniquement nécessaire lorsque celle par défaut n’est pas appropriée.

    Si aucun auteur explicite n’est configuré, le système génère automatiquement un auteur implicite par défaut.

    Sous /apps/<nom-du-projet>/config, créez un nœud pour la nouvelle configuration d’auteur de journalisation Apache Sling :

    • Nom : org.apache.sling.commons.log.LogManager.factory.writer-<identifiant> (comme il s’agit d’un auteur)
      Pour l’enregistreur, <identifiant> est remplacé par un texte libre que vous devez saisir pour identifier l’instance (vous ne pouvez pas ignorer cette information). Par exemple, org.apache.sling.commons.log.LogManager.factory.writer-MINE
    • Type : sling:OsgiConfig

    Remarque :

    Bien que cela ne constitue pas une exigence technique, il est recommandé de rendre <identifiant> unique.

    Définissez les propriétés suivantes sur ce nœud :

    • Nom : org.apache.sling.commons.log.file
      Type : Chaîne
      Valeur : spécifiez le fichier journal pour qu’il corresponde au fichier spécifié dans l’enregistreur ;
                dans cet exemple, ../logs/myLogFile.log.
    • Configurez les autres paramètres en fonction de vos besoins :
      • Nom : org.apache.sling.commons.log.file.number
        Type : Long
        Valeur : spécifiez le nombre de fichiers journaux que vous souhaitez conserver ; par exemple, 5
      • Nom : org.apache.sling.commons.log.file.size
        Type : Chaîne
        Valeur : spécifiez-la comme nécessaire pour contrôler la rotation du fichier par taille/date ; par exemple, ’.’dd-MM-yyyy

    Remarque :

    org.apache.sling.commons.log.file.size contrôle la rotation du fichier journal en fonction du paramètre suivant :

    • une taille maximale de fichier
    • une planification heure/date

    pour indiquer quand un nouveau fichier sera créé (et le fichier existant renommé selon le modèle de nom).

    • Une taille maximale peut être spécifiée par un nombre. Si aucun indicateur de taille n’est donné, il s’agit du nombre d’octets, ou vous pouvez ajouter l’un des indicateurs de taille : Ko, Mo, Go (la casse est ignorée).
    • Une planification heure/date peut être spécifiée sous la forme d’un modèle java.util.SimpleDateFormat. Cela définit le délai au bout duquel le fichier subit une rotation ; de même que le suffixe ajouté au fichier pivoté (pour identification).
      La valeur par défaut est ’.’yyyy-MM-dd (pour la rotation quotidienne du journal).
      Par exemple, à minuit le 20 janvier 2010 (ou pour être précis, lorsque le premier message de journal après cette heure est envoyé), ../logs/error.log sera renommé ../logs/error.log.2010-01-20. La journalisation du 21 janvier sera générée vers ../logs/error.log (nouveau et vide) jusqu’à ce qu’elle soit remplacée lors de la prochaine modification quotidienne.
      ’.’aaaa-MM Rotation au début de chaque mois
      ’.’aaaa-ss Rotation le premier jour de la semaine (dépend du paramètre régional).
      ’.’aaaa-MM-jj Rotation à minuit chaque jour.
      ’.’aaaa-MM-jj-a Rotation à minuit et midi chaque jour.
      ’.’aaaa-MM-jj-HH Rotation au début de chaque heure.
      ’.’aaaa-MM-jj-HH-mm Rotation au début de chaque minute.
      Remarque : En spécifiant une heure/date :
          1. Vous devez « ajouter un échappement » au texte litéral dans une paire de guillemets simples (’ ’) ;
              cela permet d’éviter que certains caractères soient perçus comme des lettres.
          2. Utilisez uniquement les caractères autorisés pour un nom de fichier valide n’importe où dans l’option.

  5. Lisez votre nouveau fichier journal avec l’outil sélectionné.

    Le fichier journal créé dans cet exemple sera ../crx-quickstart/logs/mylogfile.log.

La console Felix fournit également des informations sur la prise en charge du journal Sling à l’adresse ../system/console/slinglog ; par exemple, http://localhost:4502/system/console/slinglog.

Recherche des enregistrements d’audit

Les enregistrements d’audit sont effectués pour fournir un registre de qui a fait quoi et quand. Les enregistrements d’audit sont générés pour les événements de gestion du contenu web d’AEM et OSGi.

Enregistrements d’audit de la gestion du contenu web d’AEM affiché lors de la création de page

  1. Ouvrez une page.

  2. Depuis le sidekick, vous pouvez sélectionner l’onglet avec l’icône de verrouillage, puis double-cliquer sur Journal d’audit…

  3. Une nouvelle fenêtre s’affiche et présente la liste des enregistrements d’audit pour la page en cours.

    screen_shot_2012-02-02at43601pm
  4. Cliquez sur OK pour fermer la fenêtre.

Enregistrements d’audit de la gestion du contenu web d’AEM dans le référentiel

Dans le fichier /var/audit, les enregistrements d’audit sont conservés selon la ressource. Vous pouvez faire défiler la page vers le bas jusqu’à ce que vous puissiez voir les différents enregistrements et les informations qu’ils contiennent.

Ces entrées contiennent les mêmes informations que lors de la modification d’une page.

Enregistrements d’audit OSGi dans la console web

Les événements OSGi produisent également des enregistrements d’audit pouvant être affichés dans l’onglet État de la configuration -> Fichiers journaux dans la console web Adobe CQ :

screen_shot_2012-02-13at50346pm

Surveillance de vos agents de réplication

Vous pouvez surveiller vos files d’attente de réplication pour détecter le moment où une file d’attente est arrêtée ou a bloquée, ce qui peut indiquer un problème avec une instance de publication ou le système externe :

  • toutes les files d’attente requises sont-elles activées ?
  • les files d’attente désactivées sont-elles à nouveau requises ?
  • toutes les files d’attente activées doivent avoir l’état inactif ou actif, qui indiquent le fonctionnement normal ; aucune file d’attente ne doit être bloquée, ce qui signale souvent des problèmes du côtés des destinataires.
  • Si la taille de la file d’attente augmente au fil du temps, cela peut indiquer qu’elle est bloquée.

Pour surveiller un agent de réplication :

  1. Accédez à l’onglet Outils dans AEM.

  2. Cliquez sur Réplication.

  3. Double-cliquez sur le lien vers les agents pour l’environnement approprié (le volet à gauche ou le volet de droite) ; par exemple Agents sur l’auteur.

    La fenêtre affiche une présentation de tous vos agents de réplication pour l’environnement de création, y compris leur cible et leur état.

  4. Cliquez sur le nom de l’agent appropriée (qui est un lien) pour afficher des informations détaillées sur cet agent :

    chlimage_1

    Vous pouvez effectuer les opérations suivantes :

    • Vérifier si l’agent est activé.
    • Afficher les cibles des réplications.
    • Vérifier si la file d’attente de réplication est activée.
    • Vérifier s’il existe des éléments dans la file d’attente.
    • Actualiser ou effacer pour mettre à jour l’affichage des entrées de file d’attente ; cela vous permet de voir les éléments entrer et sortir de la file d’attente.
    • Consulter le journal pour accéder au journal de toutes actions de l’agent de réplication.
    • Tester la connexion à l’instance cible.
    • Forcer un nouvel essai sur tous les éléments de la file d’attente si nécessaire.

    Attention :

    N’utilisez pas le lien « Tester la connexion » pour la boîte d’envoi de la réplication inverse sur l’instance de publication.

    Si un test de réplication est effectué pour une file d’attente de la boîte d’envoi, les éléments qui sont plus anciens que la réplication de test sont retraités avec chaque réplication inverse.

    Si de tels éléments existent déjà dans la file d’attente, ils peuvent être recherchés avec la requête XPath JCR suivante et doivent être supprimés.

    /jcr:root/var/replication/outbox//*[@cq:repActionType=’TEST’] 

Vous pouvez toujours développer une solution pour détecter tous les agents de réplication (situés sous /etc/replication/author ou /etc/replication/publish), puis vérifier l’état de l’agent (activé, désactivé) et de la file d’attente sous-jacente (active, inactive, bloquée).

Surveillance de la performance

L’optimisation de la performance est un processus interactif bénéficiant d’une attention particulière pendant le développement. Après le déploiement, ce point est généralement révisé à intervalle régulier ou après des événements spécifiques.

Les méthodes utilisées lors de la collecte des informations pour le ciblage peuvent également être utilisées pour une surveillance continue.

Remarque :

Les configurations spécifiques disponibles pour améliorer la performance peuvent également être vérifiées.

Vous trouverez ci-après une liste des problèmes de performance qui surviennent de temps à autre, ainsi que des solutions potentielles sur la façon de les repérer et de les résoudre.

Area Symptome(s) Pour augmenter la capacité... Pour réduire le volume...
Client Usage processeur intensif du client. Installez un processeur client avec de meilleures performances. Simplifiez la mise en page (HTML).
  Faible usage du processeur de serveur. Mettez à jour vers un navigateur plus rapide. Améliorez le cache côté client.
  Certains clients rapides, d’autres lents.    
Serveur      
Réseau Faible usage du processeur sur les serveurs et les clients. Supprimez tous les goulets d’étranglement du réseau. Améliores/optimisez la configuration du cache client.
  La navigation locale sur le serveur est (comparativement) rapide. Augmentez la bande passante du réseau. Réduisez le "poids" de vos pages web (par exemple moins d’images, HTML optimisé).
Serveur web Usage élevé du processeur sur le serveur web. Mettez vos serveurs web en cluster. Réduisez le nombre d’accès par page (visite).
    Utilisez un équilibreur de charge matériel.  
Application Usage élevé du processeur du serveur. Mettez en cluster vous instances CQ5. Recherchez, et éliminez les monopoles de processeur et de mémoire (utiliser la révision du code, la sortie d’expiration, etc).
  Consommation de mémoire élevée.   Améliorez la mise en cache à tous les niveaux.
  Faibles délais de réponse.   Optimisez les modèles et les composants (par exemple la structure, la logique).
Référentiel      
Cache      

Des problèmes de performances peuvent être causés par des éléments qui n’ont rien à voir avec votre site web, y compris des ralentissements temporaires de la vitesse de connexion, le chargement du processeur, et bien plus encore.

Cela peut également impacter tous vos visiteurs, ou uniquement un partie d’entre eux.

Toutes ces informations doivent être obtenues, classées et analysées avant que vous ne puissiez optimiser la performance générale ou résoudre des problèmes spécifiques.

  • Avant d’être confronté à des problèmes de performance :
    • Collectez autant d’informations que possible afin d’avoir une bonne maîtrise du système dans des circonstances normales.
  • Lorsque vous êtes confronté à un problème de performance :
    • Essayez de le répliquer avec un navigateur web standard (de préférence plusieurs), sur un autre client qui dispose d’une bonne performance générale et/ou sur le serveur lui-même (si possible)
    • Vérifiez si un élément (associé au système) a récemment changé, et si ces modifications n’ont pas affecté la performance
    • Posez-vous des questions telles que :
      • Ce problème arrive-t-il à des moments spécifiques ?
      • Se reproduit-t-il uniquement sur des pages spécifiques ?
      • D’autres demandes sont-elles impactées ?
    • Collectez autant d’informations que possible à comparer à votre connaissance du système dans des circonstances normales :

Outils pour surveiller et analyser les performances

Les sections suivantes vous offrent un bref aperçu des outils disponibles pour surveiller et analyser les performances.

Certains d’entre eux varient en fonction de votre système d’exploitation.

Outil Utilisé pour analyser... Utilisation/Plus d’informations...
request.log Les temps de réponse et la simultanéité. Interprétation de request.log.
truss/strace Chargements de page

Commandes Unix/Linux pour tracer les appels et les signaux du système. Augmentez le niveau de journalisation sur INFO.

Analysez le nombre de chargements de pages par demande, quelles pages, etc.

Images mémoire de threads Observer les threads JVM. Identifiez les contentions, les verrouillages et les exécutions longues.

En fonction du système d’exploitation :
- Unix/Linux : kill -QUIT <pid>
- Windows (mode console) : Ctrl-Break

Des outils d’analyse sont disponibles, tels que TDA.

Images mémoire de threads Problèmes d’insuffisance de mémoire affectant la vitesse de performance.

Ajoutez l’option :
    -XX:+HeapDumpOnOutOfMemoryError
à l’appel Java vers CQ.

Voir le Guide de dépannage pour Java SE 6 avec HotSpot VM.

Appels système Identifier les problèmes de durée.

Appels à System.currentTimeMillis() ou com.day.util.Les durées sont utilisées pour générer les horodatages à partir de votre code ou via les commentaires HTML.

Remarque : Ils doivent être mis en œuvre afin de pouvoir être activés/désactivés si nécessaire. Lorsqu’un système fonctionne parfaitement, il n’est pas nécessaire de perdre du temps à collecter des statistiques.

Apache Bench Identifier les fuites de mémoire, analyser les temps de réponse de manière sélective.

L’utilisation de base est :

ab -k -n <requests> -c <concurrency> <url>

Voir Apache Bench et la page ab man pour plus de détails.

Analyse de la recherche   Exécuter les recherches hors ligne, identifier le délai de réponse de la demande, tester et confirmer les résultats.
JMeter Tests de chargement et tests fonctionnels. http://jakarta.apache.org/jmeter/
JProfiler Profilage complet du processeur et de la mémoire. http://www.ej-technologies.com/
JConsole Observer les métriques et les threads JVM.

Utilisation : jconsole

Voir jconsole et Surveiller la performance en utilisant JConsole.

Remarque : Avec JDK 1.6, JConsole est extensible avec des modules complémentaires ; par exemple, Top ou TDA (Thread Dump Analyzer).

Java VisualVM Observer les métriques, les threads, la mémoire et le profilage JVM.

Utilisation : jvisualvm ou visualvm

Voir jvisualvm, visualvm et Surveillance de la performance à l’aide de (J)VisualVM.

Remarque : Avec JDK 1.6, VisualVM est extensible avec des modules complémentaires.

truss/strace, lsof Appel du noyau en profondeur et analyse des processus (Unix). Commandes Unix/Linux.
Statistiques de durée Voir les statistiques de durée pour le rendu de page.

Pour voir les statistiques de durée pour le rendu de page, vous pouvez utiliser Ctrl-Shift-U avec ?debugClientLibs=true défini dans l’URL.

Outil de profilage du processeur et de la mémoire
Utilisé pour l’analyse des demandes lentes pendant le développement. Par exemple, YourKit.
Collecte des informations L’état actuel de votre installation. Apprendre le plus possible sur votre installation peut également vous aider à détecter ce qui a pu causé un changement au niveau de la performance et si ces changements sont justifiés. Ces informations doivent être collectées de façon régulière, afin que vous puissiez facilement identifier des modifications importantes.

Interprétation de request.log

Ce fichier permet d’enregistrer des données de base sur chaque demande envoyée à CQ. Vous pouvez en tirer des conclusions précieuses.

request.log fournit une méthode intégrée pour identifier la durée des demandes. Pour le développement, il est utile d’utiliser tail sur request.log et d’observer les temps de réponse lents.Pour analyser un fichier request.log de plus grande envergure, nous vous recommandons l’utilisation de rlog.jar, qui permet de trier et de filtrer les délais de réponse.

Nous vous recommandons d’isoler les pages « lentes » de request.log, puis de les régler individuellement pour une meilleure performance. Cette opération est généralement effectuée en incorporant des mesures de performance par composant, ou en utilisant un outil de profilage des performances tel que yourkit.

Surveillance du trafic sur votre site web

Le journal des demandes permet d’enregistrer chaque demande effectuée, ainsi que la réponse donnée :

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

En totalisant toutes les entrées GET d’une période spécifique (par exemple plus de 24 heures), vous pouvez informer sur le temps moyen passé sur votre site web.

Surveillance des délais de réponse avec CQ request.log

Le journal des demande est un point de départ intéressant pour l’analyse de performances :

    <cq-installation-dir>/crx-quickstart/logs/request.log

Le journal se présente comme suit (les lignes sont raccourcis pour plus de simplificité) :

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1 
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms 
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1 
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Ce journal dispose d’une ligne par requête ou réponse :

  • La date à laquelle chaque requête ou réponse a été effectuée.
  • Le nombre de requêtes, entre crochets. Ce numéro correspond à la requête et à la réponse.
  • Une flèche indiquant s’il s’agit d’une requête (flèche vers la droite) ou d’une réponse (flèche vers la gauche).
  • Pour les demandes, la ligne contient :
    • la méthode (généralement, GET, HEAD ou POST)
    • la page demandée
    • le protocole
  • Pour les réponses, la ligne contient :
    • le code d’état (200 signifie « réussite », 404 signifie « page non trouvée »
    • le type MIME
    • le temps de réponse

L’utilisation de petits scripts vous permet d’extraire les informations requises du fichier journal et de compiler les statistiques de votre choix. Par ailleurs, vous pouvez voir quelles pages ou quels types de pages sont lents et si la performance générale est satisfaisante.

Surveillance des temps de réponse de la recherche avec request.log CQ5

Les requêtes de recherche sont également enregistrées dans le fichier journal :

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Par conséquent, comme indiqué ci-dessus, vous pouvez utiliser des scripts pour extraire les informations nécessaires et établir des statistiques.

Toutefois, une fois que vous avez déterminé le délai de réponse, vous pourriez avoir besoin d’analyser pourquoi la requête prend autant temps et de déterminer les mesures à prendre pour améliorer la réponse. 

Surveillance du nombre et de l’impact des utilisateurs simultanés

request.log peut encore être utilisé pour surveiller les accès simultanés et la réaction du système.

Des tests doivent être effectués pour déterminer le nombre d’utilisations simultanées pouvant être traitées par le système avant qu’il n y ait un impact négatif. Des scripts peuvent encore être utilisés pour extraire les résultats du fichier journal :

  • Surveillez le nombre de demandes effectuées dans un certain laps de temps, par exemple une minute
  • Testez l’impact d’un certain nombre d’utilisateurs effectuant tous les mêmes demandes (aussi proches que possible) au même moment, par exemple 30 utilisateurs cliquant sur Enregistrer en même temps.
31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Utilisation de rlog.jar pour trouver des demandes avec de longues durées

CQ comprend divers outils d’assistance situés dans :
    <cq-installation-dir>/crx-quickstart/opt/helpers

L’un de ces outils, rlog.jar, peut être utilisé pour trier rapidement request.log de sorte que les demandes soient affichées selon la durée, c’est-à-dire de la plus longue à la plus courte.

La commande suivante affiche les arguments possibles :

$java -jar rlog.jar 
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG 
Usage: 
  java -jar rlog.jar [options] <filename> 
Options: 
  -h               Prints this usage. 
  -n <maxResults>  Limits output to <maxResults> lines. 
  -m <maxRequests> Limits input to <maxRequest> requests. 
  -xdev            Exclude POST request to CRXDE.

Par exemple, vous pouvez l’exécuter en spécifiant le fichier request.log en tant que paramètre et afficher les 10 premières demandes ayant la plus longue durée :

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log 
*Info * Parsed 464 requests. 
*Info * Time for parsing: 22ms 
*Info * Time for sorting: 2ms 
*Info * Total Memory: 1mb 
*Info * Free Memory: 1mb 
*Info * Used Memory: 0mb 
------------------------------------------------------ 
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html 
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript 
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html 
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html 
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript 
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript 
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8 
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json 
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8 

Vous pouvez avoir à concaténer les différents fichiers request.log si vous devez effectuer cette opération sur un grand échantillon de données.

Apache Bench

Pour minimiser l’impact des cas particuliers (tels que le nettoyage, etc.), il est recommandé d’utiliser un outil tel que apachebench (voir par exemple ab pour obtenir plus d’informations) pour vous aider à identifier les fuites de mémoire et à analyser de manière sélective le délai de réponse.

Apache Bench peut être utilisé de la manière suivante :

$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

Les chiffres ci-dessus sont extraits d’un ordinateur portable standard MacBook Pro 2010 (mid) avec accès à la page d’entreprise geometrixx, comme inclus dans une installation de CQ 5.6.1 par défaut. La page est très simple, mais non optimisée pour la performance.

apachebench affiche également la durée par demande comme la moyenne de toutes les requêtes simultanées ; voir Durée par requête : 54,595 [Ms] (moyenne de toutes les requêtes simultanées). Vous pouvez modifier la valeur du paramètre d’accès simultané -c (nombre de demandes multiples à exécuter à un moment donné) pour afficher tous les effets.

Compteurs de demandes

Les informations sur le trafic de demandes (nombre de demandes au cours d’une période déterminée) vous donnent une indication du chargement de votre instance. Ces informations peuvent être extraites de request.log à l’aide des compteurs, automatisant ainsi la collecte de données pour vous permettre de constater :

  • les différences considérables d’activité (c’est-à-dire la différence entre « nombreuses demandes » et « faible activité »
  • lorsqu’une instance n’est pas en cours d’utilisation
  • chaque redémarrage (les compteurs sont réinitialisés à 0)

Pour automatiser la collecte des informations, vous pouvez également installer un RequestFilter (filtre de demandes) pour compter chaque demande de manière incrémentale. Plusieurs compteurs peuvent être utilisés pour des périodes différentes. 

Les informations collectées peuvent être utilisées pour indiquer :

  • les changements importants de l’activité
  • une instance redondante
  • chaque redémarrage (le compteur est réinitialisé à 0)

Commentaires HTML

Nous vous recommandons d’inclure des commentaires HTML sur la performance du serveur pour chaque projet. Vous pouvez trouver de nombreux exemples pertinents dans la sphère publique ; sélectionnez une page, ouvrez la source de la page pour l’afficher, faites-la ensuite défiler vers le bas, et le code suivant peut ensuite être consulté :

</body>
  </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Surveillance de la performance à l’aide JConsole

La commande d’outil jconsole est disponible avec JDK.

  1. Démarrez votre instance CQ5.

  2. Exécutez jconsole.

  3. Sélectionnez votre instance CQ et connectez-vous.

  4. Depuis l’application locale, double-cliquez sur com.day.crx.quickstart.Main ; l’aperçu par défaut s’affiche :

    chlimage_1

    Après cela, vous pouvez sélectionner d’autres options.

Surveillance de la performance à l’aide de (J)VisualVM

Depuis JDK 1.6, la commande d’outil jvisualvm est disponible. Une fois que vous avez installé JDK 1.6, vous pouvez :

  1. Démarrez votre instance CQ5.

    Remarque :

    Si vous utilisez Java 5, vous pouvez ajouter l’argument Dcom.sun.management.jmxremote à la ligne de commande Java qui permet de lancer votre JVM. JMX est activé par défaut avec Java 6.

  2. Exécutez l’une des deux options suivantes :

    • jvisualvm : dans le dossier bin JDK 1.6 (version testée)
    • visualvm : peut être téléchargé à partir de VisualVM (la version la plus à la pointe)
  3. Depuis l’application locale, double-cliquez sur com.day.crx.quickstart.Main ; l’aperçu par défaut s’affiche :

    chlimage_1

    Après cela, vous pouvez sélectionner d’autres options, y compris le moniteur :

    chlimage_1

Vous pouvez utiliser cet outil pour générer des images mémoire de threads et des images mémoire d’en-tête. Ces informations sont souvent demandées par l’équipe technique.

Collecte des informations

Combien d’auteurs travaillent avec le système ?

Pour afficher le nombre d’auteurs qui ont utilisé le système depuis l’installation, utilisez la ligne de commande :

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Pour afficher le nombre d’auteurs à une date spécifique :

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Quel est le nombre moyen d’activations de page par jour ?

Pour voir nombre total d’activation de page depuis l’installation du serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

  • Type XPath
  • Path /
  • Query //element(*, cq:AuditEvent)[@cq:type=’Activate’]

Calculez ensuite le nombre de jours écoulés depuis l’installation pour calculer la moyenne.

Combien de pages maintenez-vous actuellement sur ce système ?

Pour voir nombre de pages actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE- outils- requête :

  • Type XPath
  • Chemin d’accès /
  • Requête //element(*, cq:Page)

Si vous utilisez MSM, quel est le nombre moyen de rollouts par mois ?

Pour déterminer le nombre total de déploiements depuis l’installation, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

  • Type XPath
  • Chemin d’accès /
  • Requête //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']

Calculez le nombre de mois écoulés depuis l’installation pour calculer la moyenne.

Quel est le nombre moyen de Live Copies par mois ?

Pour déterminer le nombre total des Live Copies effectuées depuis l’installation utilisent une requête de référentiel ; via CRXDE- outils- requête :

  • Type XPath
  • Path /
  • Query //element(*, cq:LiveSyncConfig)

Utilisez toujours le nombre de mois écoulés depuis l’installation pour calculer la moyenne.

Si vous utilisez la gestion des actifs numériques CQ, combien de ressources y maintenez-vous actuellement ?

Pour voir le nombre de ressource de gestion des actifs numériques que vous conservez actuellement, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

  • Type XPath
  • Path /
  • Query /jcr:root/content/dam//element(*, dam:Asset)

Quelle est la taille moyenne des ressources ?

Pour déterminer la taille totale du dossier /var/dam
 :

  1. Utilisez WebDAV pour mapper le référentiel CQ dans le système de fichiers local.

  2. Utilisez la ligne de commande :

    cd /Volumes/localhost/var
    du -sh dam/

    Pour obtenir la taille moyenne, divisez la taille globale par le nombre total de ressources dans /var/dam (obtenu ci-dessus).

Combien de modèles sont actuellement utilisés ?

Pour identifier le nombre de modèles actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

  • Type XPath
  • Path /
  • Query //element(*, cq:Template)

Combien de composants sont actuellement utilisés ?

Pour voir nombre de composants actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

  • Type XPath
  • Path /
  • Query //element(*, cq:Component)

Combien de demandes par heure recevez-vous sur le système de création lorsque le niveau d’activité est élevé ?

Pour déterminer le nombre de demandes par heure que vous recevez sur le système de création lorsque le niveau d’activité est élevé :

  1. Pour déterminer le nombre total de demandes depuis l’installation, utilisez la ligne de commande :

    cd <cq-installation-dir>/crx-quickstart/logs
    grep -R "\->" request.log | wc -l
  2. Pour déterminer les dates de début et de fin :

    vim request.log
    G / 1G: for the last/first lines

    Utilisez ces valeurs pour calculer le nombre d’heures qui se sont écoulées depuis l’installation, puis le nombre moyen de demandes par heure.

Combien de demandes par heure recevez-vous sur le système de publication lorsque le niveau d’activité est élevé ?

Répétez la procédure ci-dessus sur votre instance de publication.

Analyse de scénarios spécifiques

Voici une liste de suggestions des éléments à vérifier si vous commencez à rencontrer certains problèmes de performances CQ. La liste n’est (malheureusement) pas tout à fait complète.

Processeur à 100 %

Si le processeur de votre système fonctionne en permanence à 100 %, voir :

Mémoire insuffisante

Bien que ces erreurs doivent être détectées au cours du développement et des tests, certains scénarios peuvent vous échapper.

Si votre système ne dispose pas de suffisamment de mémoire, cela peut vous être signalé de différentes façons, notamment une détérioration des performances et des messages d’erreur comprenant le sous-texte :

    java.lang.OutOfMemoryError

Dans ce cas, vérifiez :

I/O des disques

Si votre système ne dispose pas de suffisamment d’espace de disque ou que le disque est en train de se détériorer, commencez par voir :

Détérioriation régulière des performances

Si vous voyez la performance de votre instance se détériorer après chaque réinitialisation (parfois après une semaine ou plus), ce qui suit peut être vérifié :

Réglage de JVM

La capacité de réglage de Java Virtual Machine (JVM) a été considérablement améliorée (surtout depuis Java 7). Pour cette raison, la spécification d’une taille fixe raisonnable de JVM et l’utilisation des paramètres par défaut sera souvent convenable.

Si les paramètres par défaut ne sont pas adéquats, il est important de créer une méthode pour surveiller et évaluer la performance de GC avant de tenter d’effectuer un réglage de JVM ; cela peut impliquer de surveiller des facteurs comme la taille du tas, l’algorithme et d’autres aspects.

Autres options courantes :

  • VerboseGC :
    -verbose:gc \
    -Xloggc:$LOGS/verbosegc.log \
    -XX:+PrintGCDetails \
    -XX:+PrintGCDateStamps

Le rapport résultant peut être assimilé par un visualiseur GC comme :

http://www.ibm.com/developerworks/library/j-ibmtools2/

Ou JConsole :

Cela vous aidera à déterminer la quantité de mémoire utilisée, les algorithmes GC utilisés, leur durée d’exécution et l’impact sur la performance de l’application.Sans cela, le réglage consiste simplement à manipuler des boutons de façon aléatoire.

Remarque :

Pour la machine virtuelle d’Oracle, il existe également des informations à l’adresse suivante :

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne