Täglich 5,5 GB auf 1,2 GB Root-Volume geschrieben - viermal so viele wie zuvor

Problem: Ich habe kürzlich einen meiner Server überarbeitet, er wurde vor der Verwendung getestet und funktioniert einwandfrei. Vor einigen Tagen habe ich jedoch ungefähr die vierfache Anzahl von Schreibvorgängen auf das Root-Volume festgestellt. Dies ist kein Leistungsproblem - der Server läuft einwandfrei.

Meine Überarbeitung war ziemlich umfangreich (ein vollständiger Umbau), so dass ich in Bezug auf die Ursache nicht viel zu tun habe. Kurz gesagt, meine Änderungen umfassten:

• Upgrade von Amazon Linux (von 2011.02 auf 2011.09) - was auch zu einem Wechsel von ext3 zu ext4 für das Root-Volume führte
• Wechsel von php-fcgi zu php-fpm (derzeit mit tcp)
• Übergang von einem Reverse-Proxy-Setup (Nginx -> Apache) zu Nginx
• Ersetzen von vsftpd durch pure-ftpd
• Ersetzen von dkim-proxy durch opendkim
• Webmin durch ispconfig ersetzen
• Hinzufügen von Lack als Caching-Ebene für dynamische Dateien (Overkill für die Anzahl der Treffer, die diese Websites erhalten, aber es ist ein Experiment)
• Hinzufügen einer Swap-Partition

Grundeinstellung:

• Mein Swap-Speicherplatz ist auf einem eigenen EBS-Volume bereitgestellt - die Schreibvorgänge auf das Swap-Volume sind vernachlässigbar - ich habe dies als Ursache im Wesentlichen ausgeschlossen (es gibt ausreichend freien Speicher - und beides freeund iostatzeigt eine minimale Swap-Nutzung).
• Meine Daten (MySQL-Datenbank, Benutzerdateien (Websites), alle Protokolle (von / var / log), E-Mail- und Lackdateien auf ihrem eigenen EBS-Volume (mit mount --bind). Das zugrunde liegende EBS-Volume wird unter bereitgestellt/mnt/data
• Meine verbleibenden Dateien - Betriebssystem- und Core-Server-Anwendungen (z. B. Nginx, Postfix, Dovecot usw.) - sind das einzige, was sich auf dem Root-Volume befindet - insgesamt 1,2 GB.

Das neue Setup läuft "flüssiger" (schneller, weniger Speicher usw.) als das alte System und ist seit 20 Tagen (Mitte Oktober) stabil - soweit ich das beurteilen kann, waren die erhöhten Schreibvorgänge die ganze Zeit über vorhanden .

Entgegen meiner Erwartung habe ich ein geringes Lesevolumen (meine Lesevorgänge machen etwa 1,5% meiner Schreibvorgänge aus, sowohl in Bezug auf Blöcke als auch auf Bytes auf meinem Root-Volume). Ich habe in den letzten Tagen nichts am Root-Volume geändert (z. B. Neuinstallationen usw.), aber das Schreibvolumen ist weiterhin viel höher als erwartet.

Ziel: Ermittlung der Ursache für die erhöhten Schreibvorgänge auf dem Root-Volume (im Wesentlichen herausfinden, ob es sich um einen Prozess handelt (und welchen Prozess), das andere (ext4) Dateisystem oder ein anderes Problem (z. B. Speicher)).

System Information:

• Plattform: Amazon EC2 (t1.micro)
• Betriebssystem: Amazon Linux 2011.09 (von CentOS / RHEL abgeleitet)
• Linux-Kernel: 2.6.35.14-97.44.amzn1.i686
• Architektur: 32-Bit / i686
• Festplatten: 3 EBS-Volumes:
  • xvdap1, root, ext4 Dateisystem (mit noatime gemountet)
  • xvdf, data, xfs Dateisystem (gemountet mit noatime, usrquota, grpquota)
  • xvdg, tauschen

Das Root- und das Datenvolumen werden einmal täglich mit einem Snapshot versehen. Dies sollte jedoch eine Leseoperation sein, keine Schreiboperation. (Außerdem wurde dieselbe Vorgehensweise auf dem vorherigen Server angewendet - und der vorherige Server war auch ein t1.micro.)

Die Daten, die mich veranlassten, in die E / A zu schauen, befanden sich in den Details meiner letzten AWS-Rechnung (die über der normalen E / A lag - nicht unerwartet, da ich diesen Server eingerichtet und zu Beginn viele Dinge installiert habe des Monats) und anschließend bei den CloudWatch-Metriken für die angehängten EBS-Volumes. Ich erreiche die 4-fache Normalzahl, indem ich die E / A-Aktivität vom November (wenn ich den Server nicht geändert habe) extrapoliere, um einen monatlichen Wert zu schätzen, und diesen mit dem E / A der letzten Monate vergleiche, als ich nicht arbeitete auf meinem vorherigen Server. (Ich habe keine genauen Iostat-Daten von meinem vorherigen Server). Die gleiche Anzahl von Schreibvorgängen blieb bis November 170-330 MB / h bestehen.

Diagnoseinformationen (Betriebszeit für die folgenden Ausgaben beträgt 20,6 Tage):

Cloudwatch-Metriken:

• Root-Volume (Schreiben): 5,5 GB / Tag
• Root-Volume (gelesen): 60 MB / Tag
• Datenvolumen (Schreiben): 400 MB / Tag
• Datenvolumen (gelesen): 85 MB / Tag
• Swap-Volumen (Schreiben): 3 MB / Tag
• Swap-Volumen (gelesen): 2 MB / Tag

Ausgabe von: df -h(nur für Root-Volume)

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            4.0G  1.2G  2.8G  31% /

Der verwendete Speicherplatz hat seit dem Start dieses Systems nicht merklich zugenommen (was für mich darauf hindeutet, dass Dateien aktualisiert, nicht erstellt / angehängt werden).

Ausgabe von: iostat -x(mit Blk_read, Blk_wrtnhinzugefügt in):

Linux 2.6.35.14-95.38.amzn1.i686  11/05/2011      _i686_

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s   Blk_read   Blk_wrtn avgrq-sz avgqu-sz   await  svctm  %util
xvdap1            0.00     3.42    0.03    2.85     0.72    50.19  2534636  177222312   17.68     0.18   60.93   0.77   0.22
xvdf              0.00     0.03    0.04    0.35     1.09     8.48  3853710   29942167   24.55     0.01   24.28   2.95   0.12
xvdg              0.00     0.00    0.00    0.00     0.02     0.04    70808     138160   31.09     0.00   48.98   4.45   0.00

Ausgabe von: iotop -d 600 -a -o -b

Total DISK READ: 6.55 K/s | Total DISK WRITE: 117.07 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
  852 be/4 root          0.00 B     26.04 M  0.00 %  0.42 % [flush-202:1]
  539 be/3 root          0.00 B    528.00 K  0.00 %  0.08 % [jbd2/xvda1-8]
24881 be/4 nginx        56.00 K    120.00 K  0.00 %  0.01 % nginx: worker process
19754 be/4 mysql       180.00 K     24.00 K  0.00 %  0.01 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
 3106 be/4 mysql         0.00 B    176.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19751 be/4 mysql         4.00 K      0.00 B  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
 3194 be/4 mysql         8.00 K     40.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
 3156 be/4 mysql         4.00 K     12.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
 3099 be/4 mysql         0.00 B      4.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
24216 be/4 web14         8.00 K     10.43 M  0.00 %  0.00 % php-fpm: pool web14
24465 be/4 web19         0.00 B      7.08 M  0.00 %  0.00 % php-fpm: pool web19
 3110 be/4 mysql         0.00 B    100.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
  579 be/4 varnish       0.00 B     76.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
  582 be/4 varnish       0.00 B    144.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
  586 be/4 varnish       0.00 B      4.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
  587 be/4 varnish       0.00 B     40.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
 1648 be/4 nobody        0.00 B      8.00 K  0.00 %  0.00 % in.imapproxyd
18072 be/4 varnish     128.00 K    128.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
 3101 be/4 mysql         0.00 B    176.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19749 be/4 mysql         0.00 B     32.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19750 be/4 mysql         0.00 B      0.00 B  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19752 be/4 mysql         0.00 B    108.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19788 be/4 mysql         0.00 B     12.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
  853 be/4 root          4.00 K      0.00 B  0.00 %  0.00 % [flush-202:80]
22011 be/4 varnish       0.00 B    188.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish

Um das Obige zusammenzufassen (und auf Tageswerte zu extrapolieren), sieht es so aus, als ob es über den Zeitraum von 10 Minuten:

• [flush-202] schrieb 26 MB = 3,6 GB / Tag
• php-fpm schrieb 17,5 MB = 2,4 GB / Tag
• MySQL schrieb 684 KB = 96 MB / Tag
• Lack schrieb 580KB = 82MB / Tag
• [jbd2] schrieb 528 KB = 74 MB / Tag
• Nginx schrieb 120 KB = 17 MB / Tag
• IMAP-Proxy schrieb 8 KB = 1,1 MB / Tag

Interessanterweise scheint es möglich zu sein, das tägliche Schreibvolumen zwischen [flush-202]und php-fpmzu berücksichtigen.

Mit ftopkann ich weder das flushnoch das php-fpmSchreiben aufspüren (z ftop -p php-fpm.

Zumindest ein Teil meines Problems ergibt sich aus der Identifizierung, welche Prozesse auf das Root-Volume schreiben. Von den oben genannten, würde ich erwarten , dass alle auf das Datenvolumen zu schreiben (da die entsprechenden Verzeichnisse gibt es symbolische Links) (zB nginx, mysql, php-fpm, varnishVerzeichnisse alle auf ein anderes EBS Volumen)

Ich glaube, es JBD2ist das Journaling-Block-Gerät für ext4 und flush-202der Hintergrund für schmutzige Seiten. Das dirty_ratioist 20 und das dirty_background_ratioist 10. Der schmutzige Speicher (von /proc/meminfo) lag typischerweise zwischen 50 und 150 kB. Die Seitengröße ( getconf PAGESIZE) ist die Systemvorgabe (4096).

Ausgabe von: vmstat -s | grep paged

3248858 Seiten in 104625313 Seiten ausgelagert

Ausgabe von: sar -B | grep Average

                pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
Average:         1.38     39.57    113.79      0.03     36.03      0.38      0.02      0.29     73.66

Das Obige scheint darauf hinzudeuten, dass eine große Anzahl von Seiten ausgelagert wurde. Ich würde jedoch erwarten, dass Seiten bei Bedarf auf meine Swap-Partition und nicht auf mein Root-Volume geschrieben werden. Vom Gesamtspeicher hat das System normalerweise 35% in Gebrauch, 10% in Puffern und 40% zwischengespeichert, 15% nicht verwendet (dh 65% frei).

Ausgabe von: vmstat -d

disk- ------------reads------------ ------------writes----------- -----IO------
       total merged sectors      ms  total merged sectors      ms    cur    sec
xvda1 105376  14592 2548092  824418 10193989 12264020 179666824 626582671      0   7872
xvdf  126457    579 3882950  871785 1260822  91395 30081792 32634413      0   4101
xvdg    4827   4048   71000   21358   1897  15373  138160  307865      0     29

vmstatkonsistent anzeigt siund soWerte von 0

Ausgabe von: swapon -s

Filename                                Type            Size    Used    Priority
/dev/xvdg                               partition       1048572 9252    -1

In der Annahme, dass die E / A-Schreibvorgänge möglicherweise speicherbezogen sind, habe ich den Lack deaktiviert und den Server neu gestartet. Dies änderte mein Speicherprofil auf 10% in Gebrauch, 2% in Puffern und 20% zwischengespeichert, 68% unbenutzt (dh 90% frei). Über einen 10-minütigen Lauf ergab iotop jedoch ähnliche Ergebnisse wie zuvor:

• [flush-202] schrieb 19 MB
• php-fpm hat 10MB geschrieben

In der Stunde seit dem Neustart wurden bereits 330 MB auf das Root-Volume geschrieben, wobei 370 KB Seiten ausgetauscht wurden.

Ausgabe von inotifywatch -v -e modify -t 600 -r /[^mnt]*

Establishing watches...
Setting up watch(es) on /bin /boot /cgroup /dev /etc/ home /lib /local /lost+found /opt /proc /root /sbin /selinux /src /sys /usr /var
OK, /bin /boot /cgroup /dev /etc/ home /lib /local /lost+found /opt /proc /root /sbin /selinux /src /sys /usr /var is now being watched.
Total of 6753 watches.
Finished establishing watches, now collecting statistics.
Will listen for events for 600 seconds.
total  modify  filename
23     23      /var/log/
20     20      /usr/local/ispconfig/server/temp/
18     18      /dev/
15     15      /var/log/sa/
11     11      /var/spool/postfix/public/
5      5       /var/log/nginx/
2      2       /var/run/pure-ftpd/
1      1       /dev/pts/

Wenn Sie etwas genauer hinschauen, können fast alle Schreibvorgänge einem (unbekannten) Prozess zugeordnet werden, der alle 5 Minuten ausgeführt wird und den Status einer Vielzahl von Diensten überprüft (wie chkservdbei cPanel, aber ich verwende cPanel nicht). und habe dies nicht installiert). Es handelt sich um 4 Protokolldateien (cron, maillog, ftp, imapproxy), die während der 10 Minuten aktualisiert wurden - und einige verwandte Elemente (Postfix-Sockets, reine FTPD-Verbindungen). Bei den anderen Elementen handelt es sich hauptsächlich um geänderte ispconfig-Sitzungen, Systemabrechnungsaktualisierungen und ungültige (nicht vorhandene Servername) Webzugriffsversuche (protokolliert in / var / log / nginx).

Schlussfolgerungen und Fragen:

Lassen Sie mich zunächst sagen, dass ich etwas ratlos bin - ich bin normalerweise ziemlich gründlich, aber ich habe das Gefühl, dass mir hier etwas Offensichtliches fehlt. Klar, flushund php-fpmich mache den Großteil der Schreibvorgänge aus, aber ich weiß nicht, warum dies der Fall sein könnte. Nehmen wir zunächst php-fpm - es sollte nicht einmal auf das Root-Volume geschrieben werden. Die Verzeichnisse (sowohl Dateien als auch Protokolle) sind mit einem anderen EBS-Volume verknüpft. Zweitens sind die wichtigsten Dinge, die php-fpm schreiben sollte, Sitzungen und Seiten-Caches - die sowohl wenige als auch kleine sind - sicherlich nicht in der Größenordnung von 1 MB / min (eher 1 KB / min, wenn das so ist). Die meisten Websites sind schreibgeschützt und werden nur gelegentlich aktualisiert. Die Gesamtgröße aller am letzten Tag geänderten Webdateien beträgt 2,6 MB.

Zweitens kann ich angesichts des Flushs - die signifikanten Schreibvorgänge deuten darauf hin, dass schmutzige Seiten häufig auf die Festplatte geleert werden - nicht erklären, warum dies der Fall ist, da ich normalerweise 65% freien Speicher und ein separates EBS-Volume für den Swap-Speicher habe Auswirkungen auf die Schreibvorgänge auf meinem Root-Volume, insbesondere in dem Maße, in dem dies auftritt. Mir ist klar, dass einige Prozesse schmutzige Seiten in ihren eigenen Swap-Bereich schreiben (anstatt den System-Swap-Bereich zu verwenden), aber sicherlich sollte ich unmittelbar nach einem Neustart, bei dem der größte Teil meines Speichers frei ist, nicht auf eine wesentliche Menge davon stoßen schmutzige Seiten. Wenn Sie glauben, dass dies die Ursache ist, lassen Sie mich bitte wissen, wie ich feststellen kann, welche Prozesse in ihren eigenen Swap-Bereich schreiben.

Es ist durchaus möglich, dass die ganze Idee mit den schmutzigen Seiten einfach ein roter Hering ist und nichts mit meinem Problem zu tun hat (ich hoffe, dass es tatsächlich so ist). Wenn dies der Fall ist, meine einzige andere Idee, dass es etwas im Zusammenhang mit ext4-Journaling gibt, das in ext3 nicht vorhanden war. Darüber hinaus habe ich derzeit keine Ideen mehr.

Aktualisierung):

6. November 2011:

Setze dirty_ratio = 10und dirty_background_ratio = 5; aktualisiert mit sysctl -p(bestätigt über / proc); Wiederholen Sie den 10-minütigen Iotop-Test mit ähnlichen Ergebnissen (Flush schrieb 17 MB, PHP-Fpm schrieb 16 MB, MySQL schrieb 1 MB und JBD2 schrieb 0,7 MB).

Ich habe alle Symlinks geändert, die ich mount --bindstattdessen eingerichtet habe. Lack wieder aktiviert, Server neu gestartet; Reran 10-minütiger Iotop-Test mit ähnlichen Ergebnissen (Flush schrieb 12,5 MB, PHP-Fpm schrieb 11,5 MB, Varnish schrieb 0,5 MB, JBD2 schrieb 0,5 MB und MySQL schrieb 0,3 MB).

Wie beim obigen Lauf wurde mein Speicherprofil zu 20% verwendet, zu 2% in Puffern und zu 58% zwischengespeichert, zu 20% nicht verwendet (dh zu 80% kostenlos). Nur für den Fall, dass meine Interpretation des freien Speichers in diesem Zusammenhang fehlerhaft ist. Hier ist die Ausgabe von free -m(dies ist ein t1.micro). insgesamt verwendete freie gemeinsam genutzte Puffer zwischengespeichert Mem: 602 478 124 0 14 347 - / + Puffer / Cache: 116 486 Swap: 1023 0 1023

Einige zusätzliche Informationen: Ausgabe von: dmesg | grep EXT4

[    0.517070] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[    0.531043] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[    2.469810] EXT4-fs (xvda1): re-mounted. Opts: (null)

Ich habe auch gleichzeitig ftop und iotop ausgeführt und war überrascht zu bemerken, dass Einträge, die in iotop angezeigt wurden, nicht in ftop angezeigt wurden. Die ftop-Liste wurde nach php-fpm gefiltert, da ich Schreibvorgänge dieses Prozesses ziemlich zuverlässig auslösen konnte. Ich habe ungefähr 2 MB Schreibvorgänge pro Seitenaufruf für php-fpm festgestellt - und ich muss noch herausfinden, was möglicherweise geschrieben wird -. Ideen zur Feststellung, was geschrieben wird, wären willkommen.

Ich werde versuchen, das Journaling in den nächsten Tagen auszuschalten und zu sehen, ob dies die Dinge verbessert. Im Moment frage ich mich jedoch, ob ich ein E / A-Problem oder ein Speicherproblem (oder beides) habe - aber es fällt mir schwer, das Speicherproblem zu erkennen, wenn es eines gibt.

13. November 2011:

Da das Dateisystem Extents verwendet, war es nicht möglich, es als ext3 bereitzustellen. Außerdem wurde versucht, es als schreibgeschützt bereitzustellen, was lediglich dazu führte, dass es erneut als schreibgeschützt bereitgestellt wurde.

Das Dateisystem hat tatsächlich das Journaling aktiviert (128 MB Journal), wie aus dem Folgenden hervorgeht:

Ausgabe von: tune2fs -l /dev/sda1 | grep features

has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

Wie im Folgenden beschrieben, wurden in etwas weniger als einem Monat ungefähr 140 GB auf dieses Volume geschrieben - nur ungefähr 5 GB / Tag.

Ausgabe von: dumpe2fs -h /dev/sda1

Filesystem volume name:   /
Last mounted on:          /
Filesystem UUID:          af5a3469-6c36-4491-87b1-xxxxxxxxxxxx
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              262144
Block count:              1048576
Reserved block count:     10478
Free blocks:              734563
Free inodes:              210677
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      511
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              32582
Flex block group size:    16
Filesystem created:       Wed Sep 21 21:28:43 2011
Last mount time:          Sun Nov 13 16:10:11 2011
Last write time:          Sun Oct 16 16:12:35 2011
Mount count:              13
Maximum mount count:      28
Last checked:             Mon Oct 10 03:04:13 2011
Check interval:           0 (<none>)
Lifetime writes:          139 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       18610
Default directory hash:   half_md4
Directory Hash Seed:      6c36b2cc-b230-45e2-847e-xxxxxxxxxxx
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0002d91c
Journal start:            1

Ich suchte weiter nach geöffneten Dateien und versuchte, sie fuserauf dem Root-Volume zu verwenden:

Ausgabe von: fuser -vm / 2>&1 | awk '$3 ~ /f|F/'

root       1111 Frce. dhclient
root       1322 frce. mysqld_safe
mysql      1486 Fr.e. mysqld
root       1508 Frce. dovecot
root       1589 Frce. master
postfix    1600 Frce. qmgr
root       1616 Frce. crond
root       1626 Frce. atd
nobody     1648 Frce. in.imapproxyd
postfix    1935 Frce. tlsmgr
root       2808 Frce. varnishncsa
root      25818 frce. sudo
root      26346 Fr.e. varnishd
postfix   26925 Frce. pickup
postfix   28057 Frce. smtpd
postfix   28070 Frce. showq

Leider nichts Unerwartetes. Da dies nicht auf die zugrunde liegende Hardware zurückzuführen war, stellte ich den gestrigen Snapshot des Root-Volumes wieder her (am letzten Tag hatte sich nichts geändert) und ersetzte das Root-Volume der Instanz durch das neue. Wie erwartet hatte dies keine Auswirkungen auf das Problem.

Mein nächster Schritt wäre gewesen, das Journaling zu entfernen, aber ich bin über die Lösung gestolpert, bevor ich dazu gekommen bin.

Das Problem lag in APC mit dateibasierter mmap. Behebung dieser fehlgeschlagenen Festplatten-E / A um etwa das 35-fache - auf (geschätzte) 150 MB / Tag (anstelle von 5 GB). Ich könnte immer noch in Betracht ziehen, Journale zu entfernen, da dies der wichtigste verbleibende Beitrag zu diesem Wert zu sein scheint. Diese Zahl ist jedoch vorerst durchaus akzeptabel. Die Schritte, die unternommen wurden, um zum APC-Abschluss zu gelangen, sind in einer Antwort unten aufgeführt.

Da die Hauptursache das Journaling zu sein schien, wäre das mein nächster Schritt gewesen. Um das Journaling zu entfernen, müsste ich das EBS-Volume jedoch an eine andere Instanz anhängen. Ich habe mich entschlossen, die Prozedur mit einem (ein Tag alten) Schnappschuss zu testen. Bevor ich jedoch das Journal entfernt habe, habe ich den 10-minütigen iotop-Test (auf der Testinstanz) erneut ausgeführt. Zu meiner Überraschung sah ich normale (dh nicht erhöhte) Werte, und dies war das erste Mal, dass flush-202nicht einmal auf der Liste auftauchte. Dies war eine voll funktionsfähige Instanz (ich habe auch Snapshots meiner Daten wiederhergestellt) - in den ungefähr 12 Stunden seit ihrer Aufnahme wurden keine Änderungen am Root-Volume vorgenommen. Alle Tests zeigten, dass auf beiden Servern dieselben Prozesse ausgeführt wurden. Dies führte mich zu der Annahme, dass die Ursache in einigen Anfragen liegen muss, die der "Live" -Server verarbeitet.

Betrachtet man die Unterschiede zwischen den iotop-Ausgaben des Servers, auf dem das Problem angezeigt wird, und dem scheinbar identischen Server, der kein Problem hatte, so waren die einzigen Unterschiede flush-202und php-fpm. Dies brachte mich zu dem Gedanken, dass es sich bei weitem um ein Problem im Zusammenhang mit der PHP-Konfiguration handelte.

Dieser Teil war nicht ideal - aber da keiner der auf dem Live-Server ausgeführten Dienste unter einigen Minuten Ausfallzeit leiden würde, war dies nicht wirklich wichtig. Um das Problem einzugrenzen, wurden alle wichtigen Dienste (Postfix, Dovecot, Imapproxy, Nginx, PHP-Fpm, Lack, Mysqld, Varnishncsa) auf dem Live-Server gestoppt und der Iotop-Test erneut ausgeführt - es gab keine erhöhte Festplatten-E / A. . Die Dienste wurden in 3 Stapeln neu gestartet, wobei php-fpm bis zum Ende übrig blieb. Nach jedem Neustart bestätigte der iotop-Test, dass kein Problem aufgetreten ist. Sobald php-fpm gestartet wurde, kehrte das Problem zurück. (Es wäre einfach genug gewesen, ein paar PHP-Anfragen auf dem Testserver zu simulieren, aber zu diesem Zeitpunkt war ich mir nicht sicher, ob es tatsächlich PHP war).

Leider wäre der Server ohne PHP ziemlich sinnlos, so dass dies keine ideale Schlussfolgerung war. Da flush-202ich jedoch etwas in Bezug auf den Speicher vorzuschlagen schien (obwohl genügend freier Speicher vorhanden war), entschied ich mich, APC zu deaktivieren. Das erneute Ausführen des Iotop-Tests zeigte, dass die Festplatten-E / A-Werte normal waren. Ein genauerer Blick auf die Angelegenheit zeigte, dass mmap aktiviert und apc.mmap_file_maskauf /tmp/apc.XXXXXX(die Standardeinstellung für diese Installation) eingestellt war. Dieser Pfad legt fest, dass APC eine dateibasierte mmap verwendet. Durch einfaches Kommentieren dieser Zeile (daher mit dem Standard - anonym gespeicherter Speicher) und erneutes Ausführen des iotop-Tests wurde das Problem behoben.

Ich weiß immer noch nicht, warum keiner der Diagnoseläufe die Schreibvorgänge nicht als von PHP stammend identifiziert hat und zu den APC-Dateien im Verzeichnis / tmp gegangen ist. Der einzige Test, der sogar das Verzeichnis / tmp erwähnte lsof, war, dass die aufgelisteten Dateien nicht existierten.