☰

Analysieren des Disk-IO-Verkehrs

tag-icon • tag-icon ubuntu software-raid performance io
Analysieren des Disk-IO-Verkehrs

Ich betreibe einen Webserver (Ubuntu 11.04), der unerwartet hohen Schreibverkehr aufweist. Wenn der Server überhaupt nicht schreiben soll, ist die Menge des Schreibverkehrs vergleichbar mit dem Leseverkehr.

Besorgt über unnötige Schreibvorgänge habe ich versucht zu analysieren, was auf dem System schief läuft. Ich kann umfangreiche Apache-Protokollierungs- oder Zugriffszeitprobleme ausschließen (mitnoatimeMount-Konfiguration).

Um dem Problem auf die Spur zu kommen, wollte ich sehen, welche Dateien geschrieben wurden. Dafür habe ich das IO-Logging über block_dump aktiviert (nützlicher Blogeintrag zu diesem Thema:sprocket.io). Jede Dateisystemaktivität wird im Syslog protokolliert. Hier ein kurzer Auszug meines Systems:

21. Aug. 18:22:55 xxxxx Kernel: [3984721.590864] apache2(2761): Leseblock 1098502400 auf md2 (8 Sektoren)
21. Aug. 18:22:55 xxxxx Kernel: [3984721.594005] kjournald(316): Schreibblock 2224394648 auf md2 (8 Sektoren)
21. Aug. 18:22:55 xxxxx Kernel: [3984721.594029] md2_raid1(260): Schreibblock 2925532672 auf sdb3 (8 Sektoren)
21. Aug. 18:22:55 xxxxx Kernel: [3984721.594044] md2_raid1(260): Schreibblock 2925532672 auf sda3 (8 Sektoren)
21. Aug 18:22:55 xxxxx Kernel: [3984721.644244] apache2(2761): READ-Block 2242118744 auf md2 (8 Sektoren)

Ok, jetzt weiß ich, welche Blöcke geschrieben wurden. Aber gibt es eine Möglichkeit, die geschriebenen Dateinamen anhand dieser Block-IDs tatsächlich zu identifizieren?

Vielen Dank für Ihre Hilfe!

Übrigens: Ich verwende ein Software-Raid, das könnte Teil des Problems sein.

Antwort1

Angenommen, ext2/ext3/ext4, beginnen Sie mit

[406420.877412] vi(12496): READ block 4522288 on dm-1 (8 sectors)

Bestimmen Sie die Blockgröße des Dateisystems:

# /sbin/dumpe2fs /dev/dm-1 | grep 'Block size'
dumpe2fs 1.42.3 (14-May-2012)
Block size:               4096

Angenommen, Sie haben ein Laufwerk mit 512-Byte-Sektoren, teilen Sie den Block durch 4096/512, also 8, um 565286 zu erhalten.

Im debugfsEinsatz ist eine Kombination aus icheckund ncheck:

debugfs:  icheck 565286
Block   Inode number
565286  142506

debugfs:  ncheck 142506
Inode   Pathname
142506  /etc/security/time.conf

Bearbeiten: Tun Sie dies auf den md*-Geräten, nicht auf den sd*-Geräten. Die E/A des sd*-Geräts ist das Ergebnis eines Software-RAIDs.

Antwort2

Dateisysteme befinden sich auf einer höheren Abstraktionsebene als Blockgeräte und Software-RAIDs. Allerdings ist Software-RAID mit 99,9 %iger Wahrscheinlichkeit nicht Teil des Problems, sondern nur ein Blockgerät. Sie sollten also andere Tools verwenden, um Ihre E/A-Aktivität zu analysieren. Ich würde empfehlen, zunächst iotopden Top-Writer unter den laufenden Prozessen zu identifizieren. Dann können Sie verwenden lsofund straceidentifizieren, in welche Dateien geschrieben wird.

Antwort3

Linux hat ein Kernelsystem namensinoffiziellum Änderungen an einer Datei zu beobachten. Im Userland kann man deninotify-tools( apt-get install inotify-tools), um ein Verzeichnis zu überwachen. Allerdings muss jede Datei einzeln überwacht werden. Sie können sie rekursiv auf ein Verzeichnis anwenden (sogar auf das Stammverzeichnis), aber je weniger Sie überwachen, desto geringer ist der Overhead.

Weitere Möglichkeiten zur Eingrenzung sind:

  • atopDamit können Sie sehen, welche Prozesse Schreibvorgänge durchführen
  • auditctldie eine sehr geheimnisvolle Syntax hat, aber die Überwachung jedes Systemaufrufs ermöglicht

verwandte Informationen