Afin de générer une description complète du problème, répondez aux questions suivantes :
    - Dans quelles circonstances le processus se bloque-t-il. Ce comportement est-il cohérent ?
    - Est-ce que cela fonctionnait mieux avant.
    - Heures d’occurrence et tendance
du comportement observée : le problème se produit-il uniquement lors de périodes de charge importante sur l’environnement de sauvegarde ou les sauvegardes ou un type particulier de groupe de sauvegarde ?
    - Quand le problème s’est-il produit pour la première fois ? Qu’est-ce qui a changé alors ?
    - Quelle est l’étendue du problème (tous les clients/certains clients, toutes les cibles de sauvegarde ou autres)
- Qu’est-ce qui a été essayé de résoudre jusqu’à présent et quelles conclusions en ont été tirées.

     - Quel processus NetWorker ne répond pas et sur quelle machine (serveur, nœud de stockage ou client).
     - Version et plate-forme
du serveur NetWorker - Vue d’ensemble de la taille et de la nature de la zone
de données de sauvegarde - Média cible pour ces sauvegardes

      - À l’aide du Guide de compatibilité NetWorker en ligne, vérifiez que tous les composants (serveur NetWorker, version du système de fichiers, proxy, nœuds de stockage, clients, cible) sont pris en charge.
      - Vérifiez qu’il n’y a pas de défaut sous-jacent du système d’exploitation ou de matériel qui pourrait expliquer les pannes du processus (pannes de disque, disque plein, erreurs réseau, etc.).

      Le Guide de planification de l’optimisation des performances de NetWorker contient plusieurs suggestions de recommandations et de configurations logicielles et matérielles requises à mettre en œuvre afin de disposer d’un environnement NetWorker optimisé. Il convient de le vérifier pour s’assurer que les pratiques d’excellence sont suivies pour cette zone de données. Cela est pertinent si le processus ne répond pas se produit à des moments où la charge est la plus lourde.

       La façon dont nous procédons pour trouver la cause première du problème d’absence de réponse du processus dépend du comportement défini à l’étape 1. Si le déclencheur est inconnu, des tests peuvent être effectués pour tenter d’établir ce qui déclenche le crash :

    - Surveiller les performances du système en cas de forte charge
- Examinez les fichiers journaux du système d’exploitation au moment des pannes pour vérifier s’il y a des comportements
communs - Lisez le planning NetWorker pour déterminer s’il existe une corrélation entre les heures d’occurrence d’une activité planifiée NetWorker particulière.
    - Découvrez quelles opérations non NetWorker exécutées sur cette machine pourraient affecter son comportement et si leur planification est en corrélation avec les heures de pannes.
    - Si le plantage se produit régulièrement, modifiez certains paramètres pour essayer d’en déterminer la cause.  Par exemple, la sauvegarde sur un autre support cible ou la sauvegarde de différents types de données à partir du même client NetWorker

Un coredump est un fichier spécial qui représente un vidage de la mémoire de travail d’un processus à un moment précis, généralement lorsque le programme s’est arrêté anormalement.  Les fichiers de vidage mémoire peuvent être utilisés pour diagnostiquer la raison pour laquelle un processus ne répond pas, en analysant les fonctions du processus en cours d’exécution au moment de la panne et les données consultées.

La plupart des systèmes d’exploitation ne génèrent pas automatiquement des fichiers de vidage mémoire.  Les paramètres du système d’exploitation doivent être modifiés afin qu’un fichier de vidage mémoire soit généré au moment de l’arrêt d’un processus.  Cette modification doit être effectuée avant le crash.

1) Recherchez dans le répertoire /nsr/cores les vidages mémoire récents des processus NetWorker sous UNIX ou Linux ou vérifiez le répertoire de plantage tel que défini dans le registre Windows (voir étape 2).

2) S’il n’y en a pas, vérifiez que le système d’exploitation est configuré pour générer des fichiers de vidage mémoire en cas de blocage du processus.  Voir la documentation du système d’exploitation pour plus de détails, mais en bref, cela impliquera probablement de changer les valeurs ulimit -c et -f sous linux ou unix et d’effectuer une modification du registre dans Windows.

Pour Windows 2008R2 :  
- Mettez à jour le registre avec la nouvelle clé fournie à http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx.
- À l’aide des valeurs recommandées, le fichier de vidage est créé dans C :\Users\Administrator\AppData\Local\CrashDumps
- Enable full crash dumps.

3) Le fichier mémoire peut être examiné sur la machine hôte elle-même ou peut être empaqueté pour analyse sur une autre machine.  Des détails sur l’empaquetage de ces fichiers mémoire sont disponibles ici :

UNIX et Linux core file packaging :
489272 : Collecte des informations de vidage mémoire/sur incident et journaux

connexesPour Windows, suivez les instructions présentées ici :
198564 : Comment collecter le noyau et le vidage utilisateur pour le(s) processus(s) bloqué(s) sous Windows          

4) Analysez les données disponibles :

- Fichiers
log du système d’exploitation - Fichier log du processus NetWorker du serveur NetWorker et du nœud de stockage concerné.  
- Fichier mémoire ou fichier

de blocage : l’analyse détaillée d’un fichier mémoire nécessite une connaissance avancée des opérations internes de NetWorker et doit être effectuée par le support EMC NetWorker.  Cependant, une lecture initiale du fichier mémoire peut être effectuée pour comparer le contenu du fichier mémoire avec les problèmes connus.

Linux et HP-UX
gdb [chemin complet vers le processus] [fichier de base]
(gdb) où

AIX
dbx [chemin complet vers le processus] [fichier de base]
(dbx) où

Solaris
pstack [fichier de base ]
dbx [chemin complet vers le processus] [fichier de base]
(dbx) où

Windows
- Démarrez le programme
de débogage windows windbg- Cliquez sur Fichier et ouvrez le fichier de vidage dans windbg.
- Tapez analyze --v dans la fenêtre de commande inférieure pour récupérer des informations complètes.
    
5) Sur la base de l’analyse ci-dessus et des connaissances sur le comportement du système, vous pouvez comparer l’incident à la liste des problèmes connus détaillée dans les Notes de mise à jour de NetWorker pour la dernière version.

Si vous pensez qu’une panne du logiciel NetWorker est à l’origine de l’absence de réponse, vous devez empaqueter le fichier d’incident (voir étape 3) et le fournir avec une description complète du comportement observé au support NetWorker de Dell Technologies pour une analyse détaillée du problème.