Le programme «du» peut-il être rendu moins agressif?

Nous avons un travail régulier qui fait des durésumés d'un certain nombre de sous-répertoires, sélectionne les pires contrevenants et utilise les résultats pour trouver s'il y a des choses qui augmentent rapidement pour repérer les problèmes potentiels. Nous utilisons diffcontre des instantanés pour les comparer.

Il existe un répertoire de niveau supérieur, avec un certain nombre (quelques centaines) de sous-répertoires, chacun pouvant contenir des dizaines de milliers de fichiers chacun (ou plus).

Un " du -s" dans ce contexte peut être très agressif pour les E / S, ce qui oblige notre serveur à libérer son cache, puis à des pics d'ES massifs qui sont un effet secondaire très indésirable.

Quelle stratégie peut-on utiliser pour obtenir les mêmes données, sans les effets secondaires indésirables?

disk-usage io limit

— Danny Staple
source

En Allemagne, vous pouvez le remplacer par "Sie".

— Federico Poloni

Réponses:

Jetez un oeil à ionice. De man ionice:

Ce programme définit ou obtient la classe de planification io et la priorité d'un programme. Si aucun argument ou juste -p n'est donné, ionice interrogera la classe d'ordonnancement io actuelle et la priorité pour ce processus.

Pour exécuter duavec la classe d'E / S "inactive", qui est la priorité la plus basse disponible, vous pouvez faire quelque chose comme ceci:

ionice -c 3 du -s

Cela devrait empêcher dud'interférer avec les E / S d'autres processus. Vous pouvez également envisager de modifier le programme pour réduire sa priorité de processeur, comme suit:

renice -n 19 "$duPid"

Vous pouvez également faire les deux au moment de l'initialisation:

nice -n 19 ionice -c 3 du

— Chris Down
source

Pour renice un programme existant, vous devez appeler reniceau lieu de nice. Pour commencer duavec les deux ionice et agréable, vous pouvez enchaîner les deux programmes: nice -n19 ionice -c3 du.

— jofel

nicelui-même affecte également la priorité du planificateur d'E / S, pas seulement le processeur.

— jordanm

@jordanm Pour autant que je sache (au moins sous Linux), nicen'affecte que la finesse du processeur (ce qui peut affecter indirectement les E / S, mais ne devrait pas affecter la priorité du planificateur d'E / S). Où voyez-vous ce comportement? Est-ce documenté quelque part?

— Chris Down

@ChrisDown - Je me souviens l'avoir lu dans Understanding the Linux Kernel

— jordanm

@jordanm Hm, j'ai ce livre. Je l'ai parcouru rapidement et n'ai trouvé que la page 263 donnant des détails explicites nice, et il ne parle que des quantums de temps de base du processeur. Avez-vous une idée de l'endroit où se trouvait le livre? Je serais intéressé de lire une source faisant autorité que les Etats, il est pas mentionné dans man nice, man 2 nice, man 2 setpriority, info niceou info 'nice invocation'pour autant que je peux dire, ce qui est étrange parce que certains d' entre eux vont dans un peu de détails sur la façon dont les nicetravaux d'appel et ce qu'il fait.

— Chris Down

Si vous avez des tonnes de fichiers dans un seul répertoire, cela peut être responsable des pics d'E / S, car de nombreux systèmes de fichiers ne gèrent pas bien les grandes arborescences de fichiers dans un seul répertoire. Le diviser en plusieurs sous-répertoires peut vous y aider. Si vous avez plus de 10 000 fichiers dans un seul répertoire et que cela cause des problèmes, vous devriez probablement le diviser.

En ce qui concerne le suivi de l'utilisation du disque, vous pouvez d'abord regarder df, si la valeur d'utilisation n'y a pas augmenté rapidement, les sous-répertoires non plus et vous pouvez ignorer ducomplètement.

Une autre alternative peut être un système de quota de disque qui assure un suivi continu de l'utilisation, si votre système de fichiers le prend en charge.

— frostschutz
source

Le système est une ferme de build, donc le nombre de fichiers dans un répertoire est vraiment dû aux développeurs des composants que nous construisons. dfne fonctionnerait pas tout à fait - le problème est que nous avons des scripts de nettoyage, donc nous pouvons ne voir aucun changement, mais nous avons manqué un avertissement précoce pour un travail automatique qui accapare agressivement l'espace disque. Nous utilisons zabbix pour surveiller l'utilisation globale du disque, mais connaître les répertoires individuels où les choses vont un peu fou est assez essentiel.

— Danny Staple

De plus, ionicevous pouvez essayer de rendre les accès au disque plus efficaces. Cela peut être tenté en exécutant

find /du/root -printf ""
find /du/root -perm 777 -printf ""

d'abord (peut-être ioniceaussi). Cela ne fonctionnera pas s'il y a trop de fichiers. Combien est trop dépend de la quantité de RAM disponible.

— Hauke Laging
source