la commande prend WAY trop de temps pour s'exécuter

Je cours du -shdans une variété de répertoires pour trouver des porcs de disque. J'ai obtenu deux serveurs identiques (Dell PE2850s), tous deux avec RHEL5 et cela prendra beaucoup plus de temps pour fonctionner dusur un serveur sur l'autre.

Par exemple, faire du -sh /opt/foobarprendra 5 minutes sur le serveur A (qui contient environ 25 Go) et sur le serveur B, la même commande avec la même quantité de données me sera rapportée presque instantanément. Je ne vois rien d'évident de façon flagrante en courant dessus, etc.

Tout conseil est grandement appréciée.

— Jon Weinraub
source

La vitesse de du -sne dépend pas de la taille des données mais plutôt du nombre de fichiers. Les deux arborescences de répertoires ont-elles un nombre similaire de fichiers?

— Ladadadada

En outre, dufonctionnera beaucoup plus rapidement si toutes les métadonnées du répertoire (comme les tailles de fichier) sont actuellement mises en cache. Si tel est le cas pour une raison quelconque sur un serveur et non sur l'autre, cela entraînera de grandes différences.

— Sven

@Ladadada Je dirais que oui, il y a à peu près la même quantité de fichiers. Même lors de l'ajout de l'astérisque pour obtenir une liste des tailles de fichiers individuellement, le défilement prend beaucoup de temps. Mais je ne suis pas totalement sûr de savoir si les métadonnées sont mises en cache ou non.

— Jon Weinraub

Réponses:

Si vous avez un grand nombre de fichiers dans ce répertoire et que le contenu du répertoire change constamment, l'entrée de répertoire elle-même se fragmente au fil du temps. Ensuite, lorsque le système d'exploitation lit le contenu du répertoire, il y aura beaucoup, beaucoup de recherches de disque inutiles. Cela se produit en particulier avec les systèmes de fichiers ext * (ext4 pourrait être mieux cependant) et les anciens systèmes de fichiers ReiserFS v3.x (si ceux-ci ont atteint 85% ou plus).

La solution est assez simple:

cp -pr origdir newdir
mv origdir origdir.bak
mv newdir origdir

Bien sûr, si tout est mis en cache dans la RAM, cela n'a pas beaucoup d'importance; Linux met généralement en cache les fichiers et les répertoires fréquemment utilisés de manière assez agressive. Si vous voulez vraiment garder le contenu de ces répertoires en RAM, vous pouvez mettre quelque chose comme ls -lah /your/dir 2>&1 >/dev/nulldans votre cron.

EDIT: Oh, une chose m'est venue à l'esprit. Si votre serveur possède un contrôleur RAID sauvegardé par batterie avec un peu de cache, veuillez vérifier que la batterie est OK. J'ai vu des situations où la batterie est morte et le contrôleur désactive complètement le cache, ruinant ainsi les performances. Par exemple, les serveurs HP peuvent indiquer dans les journaux iLO quelque chose sur la batterie du contrôleur; dans le tableau de bord de santé du serveur, tout semble bien et vert, mais seule l'entrée de journal vous en informera.

— Janne Pikkarainen
source

Cela me prendra probablement un peu de temps, c'est sur un serveur de production donc je devrai le faire du jour au lendemain et le répertoire entier contient plusieurs centaines de gigaoctets de données donc je ne veux pas l'enliser ... Je vais rapporter demain matin. Merci pour l'idée.

— Jon Weinraub

J'exécute toujours cette commande et je ne dis pas combien de temps cela prendra. Je l'ai même revu et cp fonctionne toujours, environ 1h15 depuis le démarrage. Même l'exécution d'un du sur ce dossier dans un autre shell a pris beaucoup de temps, mais vous pensez que je devrais juste umountle lecteur et fscklui?

— Jon Weinraub

Laissez-le fonctionner à moins qu'il ne dérange votre production. Avec RHEL5 et son planificateur d'E / S CFQ par défaut, vous pouvez placer la commande cp dans la classe inactive afin qu'elle n'intimide pas les autres processus: ionice -c3 -p $(pidof cp)ou ainsi.

— Janne Pikkarainen

Veuillez également lire ma dernière édition.

— Janne Pikkarainen

Je sais que cela fait un moment, mais j'ai finalement réussi à exécuter la commande cp dont vous avez parlé. Il faut deux heures pour copier 25 Go. Après avoir fait son mouvement, exécuter un autre du -sh était tout aussi lent. En fait, même l'effacement du répertoire de sauvegarde est également lent!

— Jon Weinraub

Je suggère d'essayer la commande simple sans aucun commutateur. Vous verrez finalement quel répertoire ralentit le processus. Peut-être un disque défectueux, ou une autre raison, ...

— Király István
source