Détermination du fichier spécifique responsable des entrées / sorties élevées

C'est un problème simple, mais la première fois que j'ai à le résoudre: trouver quels fichiers / inodes spécifiques sont les cibles du plus grand nombre d'E / S. J'aimerais pouvoir avoir un aperçu général du système, mais si je dois donner un PID ou un TID, je vais bien avec ça.

Je voudrais y aller sans avoir à faire un straceprogramme sur qui apparaît dans iotop. De préférence, utilisez un outil dans la même veine que iotopcelui qui détaille par fichier. Je peux utiliser lsofpour voir quels fichiers mailman est ouvert mais cela n’indique pas quel fichier reçoit des E / S ni combien.

J'ai vu ailleurs où il était suggéré d'utiliser auditdmais je préférerais ne pas le faire car cela placerait les informations dans nos fichiers d'audit, que nous utilisons à d'autres fins et cela semble être une question sur laquelle je devrais pouvoir faire des recherches. de cette façon.

Le problème spécifique que j'ai actuellement est lié au remplissage trop rapide des instantanés LVM. Depuis, j'ai résolu le problème, mais j'aurais aimé pouvoir le résoudre de cette façon plutôt que de simplement afficher lstous les descripteurs de fichiers ouverts /proc/<pid>/fdpour voir lequel de ces descripteurs avait la croissance la plus rapide.

Cette question comporte plusieurs aspects qui ont été partiellement traités à l'aide d'autres outils, mais il ne semble pas qu'il existe un seul outil fournissant toutes les fonctionnalités que vous recherchez.

iotop

Cet outil indique quels processus consomment le plus d’E / S. Mais il manque des options pour afficher des noms de fichiers spécifiques.

$ sudo iotop
Total DISK READ:       0.00 B/s | Total DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                        
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    5 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/u:0]
    6 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    7 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/0]

Par défaut, il fait ce qui est habituel toppour les processus qui se disputent le temps de la CPU, à l'exception des E / S de disque. Vous pouvez le persuader de vous donner une vue de 30 000 pieds en utilisant le -acommutateur afin qu’il affiche une accumulation par processus, au fil du temps.

$ sudo iotop -a
Total DISK READ:       0.00 B/s | Total DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                        
  258 be/3 root          0.00 B    896.00 K  0.00 %  0.46 % [jbd2/dm-0-8]
22698 be/4 emma          0.00 B     72.00 K  0.00 %  0.00 % chrome
22712 be/4 emma          0.00 B    172.00 K  0.00 %  0.00 % chrome
 1177 be/4 root          0.00 B     36.00 K  0.00 %  0.00 % cupsd -F
22711 be/4 emma          0.00 B    120.00 K  0.00 %  0.00 % chrome
22703 be/4 emma          0.00 B     32.00 K  0.00 %  0.00 % chrome
22722 be/4 emma          0.00 B     12.00 K  0.00 %  0.00 % chrome

i * outils (inotify, iwatch, etc.)

Ces outils permettent d'accéder aux événements d'accès aux fichiers, mais ils doivent être spécifiquement ciblés sur des répertoires ou des fichiers spécifiques. Ils ne sont donc pas très utiles pour tenter de retracer l'accès à un fichier non fiable par un processus inconnu, lors du débogage de problèmes de performances.

En outre, le inotifycadre ne fournit aucun détail sur les fichiers en cours d'accès. Grâce à ces outils, seul le type d'accès, donc aucune information sur la quantité de données échangée n'est disponible.

iostat

Affiche les performances globales (lectures et écritures) en fonction de l'accès à un périphérique donné (disque dur) ou à une partition. Mais ne fournit aucune indication sur les fichiers générant ces accès.

$ iostat -htx 1 1
Linux 3.5.0-19-generic (manny)  08/18/2013  _x86_64_    (3 CPU)

08/18/2013 10:15:38 PM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.41    0.00    1.98    0.11    0.00   79.49

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda
                  0.01     0.67    0.09    0.87     1.45    16.27    37.06     0.01   10.92   11.86   10.82   5.02   0.48
dm-0
                  0.00     0.00    0.09    1.42     1.42    16.21    23.41     0.01    9.95   12.22    9.81   3.19   0.48
dm-1
                  0.00     0.00    0.00    0.02     0.01     0.06     8.00     0.00  175.77   24.68  204.11   1.43   0.00

blktrace

Cette option est trop faible. Il manque de visibilité sur les fichiers et / ou les inodes utilisés, uniquement les numéros de blocs bruts.

$ sudo blktrace -d /dev/sda -o - | blkparse -i -
  8,5    0        1     0.000000000   258  A WBS 0 + 0 <- (252,0) 0
  8,0    0        2     0.000001644   258  Q WBS [(null)]
  8,0    0        3     0.000007636   258  G WBS [(null)]
  8,0    0        4     0.000011344   258  I WBS [(null)]
  8,5    2        1 1266874889.709032673   258  A  WS 852117920 + 8 <- (252,0) 852115872
  8,0    2        2 1266874889.709033751   258  A  WS 852619680 + 8 <- (8,5) 852117920
  8,0    2        3 1266874889.709034966   258  Q  WS 852619680 + 8 [jbd2/dm-0-8]
  8,0    2        4 1266874889.709043188   258  G  WS 852619680 + 8 [jbd2/dm-0-8]
  8,0    2        5 1266874889.709045444   258  P   N [jbd2/dm-0-8]
  8,0    2        6 1266874889.709051409   258  I  WS 852619680 + 8 [jbd2/dm-0-8]
  8,0    2        7 1266874889.709053080   258  U   N [jbd2/dm-0-8] 1
  8,0    2        8 1266874889.709056385   258  D  WS 852619680 + 8 [jbd2/dm-0-8]
  8,5    2        9 1266874889.709111456   258  A  WS 482763752 + 8 <- (252,0) 482761704
...
^C
...
Total (8,0):
 Reads Queued:           0,        0KiB  Writes Queued:           7,       24KiB
 Read Dispatches:        0,        0KiB  Write Dispatches:        3,       24KiB
 Reads Requeued:         0       Writes Requeued:         0
 Reads Completed:        0,        0KiB  Writes Completed:        5,       24KiB
 Read Merges:            0,        0KiB  Write Merges:            3,       12KiB
 IO unplugs:             2           Timer unplugs:           0

Throughput (R/W): 0KiB/s / 510KiB/s
Events (8,0): 43 entries
Skips: 0 forward (0 -   0.0%)

fatrace

Ceci est une nouvelle addition au noyau Linux et une bienvenue, ce n'est donc que dans les nouvelles distributions telles que Ubuntu 12.10. Il manquait à mon système Fedora 14 8-).

Il fournit le même accès que vous pouvez obtenir inotifysans avoir à cibler un répertoire particulier et / ou des fichiers.

$ sudo fatrace
pickup(4910): O /var/spool/postfix/maildrop
pickup(4910): C /var/spool/postfix/maildrop
sshd(4927): CO /etc/group
sshd(4927): CO /etc/passwd
sshd(4927): RCO /var/log/lastlog
sshd(4927): CWO /var/log/wtmp
sshd(4927): CWO /var/log/lastlog
sshd(6808): RO /bin/dash
sshd(6808): RO /lib/x86_64-linux-gnu/ld-2.15.so
sh(6808): R /lib/x86_64-linux-gnu/ld-2.15.so
sh(6808): O /etc/ld.so.cache
sh(6808): O /lib/x86_64-linux-gnu/libc-2.15.so

Ce qui précède vous montre l'ID de processus auquel le fichier accède et le fichier auquel il accède, mais il ne vous donne aucune utilisation de la bande passante globale. Par conséquent, chaque accès est indiscernable de tout autre accès.

Alors que faire?

L' fatraceoption la plus prometteuse pour FINALEMENT consiste à fournir un outil qui peut vous montrer l'utilisation globale des E / S du disque en fonction des fichiers en cours d'accès, plutôt que des processus effectuant l'accès.

Les références

• fatrace: rapporte les événements d'accès au fichier à l'échelle du système
• fatrace - rapporte les événements d'accès au fichier à l'échelle du système
• Une autre nouvelle ABI pour fanotify
• blktrace Guide de l'utilisateur

Je n'ai pas encore reçu de réponse mais j'ai écrit ce script (à la fin) et il semble faire ce que je veux. Je ne l'ai pas testé sur d'autres systèmes et il est spécifique à Linux.

Fondamentalement, il ne dure straceque 30 secondes, filtre les appels système liés aux fichiers et s'efforce de supprimer le nom de fichier. Il compte le nombre d'occurrences de ce fichier dans straceet présente un résumé paginé à l'utilisateur. Ce n'est pas parfait, mais le nombre d'appels système à un fichier donné peut avoir une faible corrélation avec la quantité d'E / S qu'il exécute.

Je ne l'ai pas complètement testé, mais si ça ne marche pas, ça devrait donner aux gens un endroit où commencer. Si cela se concrétise davantage, il peut être souhaitable de réécrire ceci dans un langage de niveau supérieur tel que python .

Si je n'obtiens pas de réponse dans un délai d'une semaine sur une méthode moins homogène (même s'il s'agit d'un autre outil qui compte uniquement les E / S d'un processus particulier), je l'accepterai comme ma réponse pour la postérité.

Scénario:

#!/bin/bash

####
# Creates files underneath /tmp
# Requires commands: timeout  strace  stty
####
#
# All commands are GNU unless otherwise stated
#
##########################################################


####
## Initialization
####

outputFile=/tmp/out.$RANDOM.$$
uniqueLinesFile=/tmp/unique.$RANDOM.$$
finalResults=/tmp/finalOutput.txt.$$

if [ $# -ne 1 ]; then
    echo "USAGE: traceIO [PID]" >&2
    exit 2
fi

if ! [[ "$1" =~ ^[0-9]+$ ]]; then
    echo "USAGE: traceIO [PID]" >&2
    echo -e "\nGiven Process ID is not a number." >&2
    exit 2
fi

if [ ! -e /proc/$1 ]; then
    echo "USAGE: traceIO [PID]" >&2
    echo -e "\nThere is no process with $1 as the PID." >&2
    exit 2
fi

if [[ "x$PAGER" == "x" ]]; then

   for currentNeedle in less more cat; do

      which $currentNeedle >/dev/null 2>&1

      if [ $? -eq 0 ]; then
         PAGER=$currentNeedle
         break;
      fi

   done

  if [[ "x$PAGER" == "x" ]]; then

     echo "Please set \$PAGER appropriately and re-run" >&2
     exit 1

  fi

fi

####
## Tracing
####

echo "Tracing command for 30 seconds..."

timeout 30 strace -e trace=file -fvv -p $1 2>&1 | egrep -v -e "detached$" -e "interrupt to quit$" | cut -f2 -d \" > $outputFile

if [ $? -ne 0 ]; then
   echo -e "\nError performing Trace. Exiting"
   rm -f $outputFile 2>/dev/null
   exit 1
fi

echo "Trace complete. Preparing Results..."

####
## Processing
####

sort $outputFile | uniq > $uniqueLinesFile

echo -e "\n--------  RESULTS --------\n\n  #\t Path " > $finalResults
echo -e " ---\t-------" >> $finalResults

while IFS= read -r currentLine; do

   echo -n $(grep -c "$currentLine" "$outputFile")
   echo -e "\t$currentLine"

done < "$uniqueLinesFile" | sort -rn >> $finalResults

####
## Presentation
####

resultSize=$(wc -l $finalResults | awk '{print $1}')
currentWindowSize=$(stty size | awk '{print $1}')

  # We put five literal lines in the file so if we don't have more than that, there were no results
if [ $resultSize -eq 5 ]; then

   echo -e "\n\n No Results found!"

elif [ $resultSize -ge $currentWindowSize ] ; then

   $PAGER $finalResults

else

   cat $finalResults

fi

  # Cleanup
rm -f $uniqueLinesFile $outputFile $finalResults

Vous pouvez utiliser iwatch utilisant iWatch

iWatch est très simple à utiliser, supposons que vous souhaitiez observer l'évolution du système de fichiers / etc, il vous suffit de l'exécuter dans la console.

$ iwatch /etc

et iwatch vous dira si quelque chose change dans ce répertoire. Et si vous souhaitez être averti par email:

$ iwatch -m admin@smsgw.local /etc

Dans ce cas, l’administrateur recevra une notification par courrier électronique (vous pouvez peut-être utiliser votre compte de passerelle sms afin que vous soyez immédiatement alerté à tout moment et n’importe où). Et si vous souhaitez surveiller plusieurs répertoires de différences, vous pouvez utiliser un fichier de configuration. Ce fichier de configuration est un fichier XML avec une structure facile à comprendre.