問題： 最近、サーバーの1つを改造しました。使用する前にテストされ、正常に機能しましたが、数日前に、ルートボリュームへの通常の書き込み量の約4倍に気付きました。これはパフォーマンスの問題ではありません-サーバーは正常に動作します。
私の改造はかなり広範囲（完全な再構築）だったので、原因に関して多くを続けることはできません。簡単に言うと、私の変更は次のとおりです。
- AmazonのLinuxのアップグレード（2011.02から2011.09へ）-ルートボリュームもext3からext4に変更されました
- php-fcgiからphp-fpmへの移行（現在はtcpを使用）
- リバースプロキシ（nginx-> apache）設定からnginxのみへの移行
- vsftpdをpure-ftpdで置き換える
- dkim-proxyをopendkimで置き換える
- isminconfigによるwebminの置き換え
- ワニスを動的ファイルのキャッシングレイヤーとして追加します（これらのサイトが受けるヒット数のオーバーキルですが、実験です）。
- スワップパーティションを追加する
基本セットアップ：
- 私のスワップ領域は独自のEBSボリュームにマウントされています-スワップボリュームへの書き込みはごくわずかです-本質的にこれを割り引いています（十分な空きメモリがあり、両方とも最小限のスワップ使用量
freeをiostat示しています）。 - 私のデータ（mysqlデータベース、ユーザーファイル（ウェブサイト）、すべてのログ（/ var / logから）、メール、およびvarnishファイルを独自のEBSボリュームに（を使用して
mount --bind）。基礎となるEBSボリュームは、/mnt/data - 私の残りのファイル-オペレーティングシステムとコアサーバーアプリケーション（nginx、postfix、dovecotなど）-は、ルートボリューム上にある唯一のファイル（合計1.2 GB）です。
新しいセットアップは、古いシステムより「スムーズ」（メモリが少ないなど）で実行され、20日間（10月中旬）安定しています-私の知る限り、昇格した書き込みはこの間ずっと存在していました。
予想とは逆に、読み取りボリュームが少ない（私の読み取りは、ルートボリュームのブロックとバイトの両方の点で、書き込みの約1.5％です）。過去数日間、ルートボリューム（たとえば、新規インストールなど）で何も変更していませんが、書き込みボリュームは予想よりはるかに多くなっています。
目的：ルートボリュームへの書き込みの増加の原因を特定する（基本的に、それがプロセス（およびプロセス）、別の（ext4）ファイルシステム、または別の問題（メモリなど）かどうかを把握する）。
システムインフォメーション：
- プラットフォーム：AmazonのEC2（t1.micro）
- O / S：AmazonのLinux 2011.09（CentOS / RHEL派生）
- Linuxカーネル：2.6.35.14-97.44.amzn1.i686
- アーキテクチャ：32ビット/ i686
- ディスク：3 EBSボリューム：
- xvdap1、root、ext4ファイルシステム（noatimeでマウント）
- xvdf、data、xfsファイルシステム（noatime、usrquota、grpquotaでマウント）
- xvdg、swap
ルートボリュームとデータボリュームは1日に1回スナップショットが作成されますが、これは「読み取り」操作であり、書き込み操作ではありません。（さらに、以前のサーバーでも同じ方法が使用されました。以前のサーバーもt1.microでした。）
I / Oを調べる原因となったデータは、前回のAWS請求の詳細に含まれていました（通常のI / Oを上回っていました-このサーバーをセットアップし、最初に多くのものをインストールしていたため、予期しないことではありませんでした）今月の）、その後、接続されたEBSボリュームのCloudWatchメトリクスで。11月（サーバーを変更していないとき）からのI / Oアクティビティを推定して月間値を推定し、それを作業していない過去の月のI / Oと比較することにより、「通常の4倍」の数値に到達します。以前のサーバーで。（以前のサーバーからの正確なiostatデータがありません）。同じ量の書き込みが11月まで持続し、170-330MB /時です。
診断情報（次の出力の稼働時間は20.6日です）：
Cloudwatchメトリック：
- ルートボリューム（書き込み）：5.5GB /日
- ルートボリューム（読み取り）：60MB /日
- データ量（書き込み）：400MB /日
- データ量（読み取り）：85MB /日
- スワップボリューム（書き込み）：3MB /日
- スワップボリューム（読み取り）：2MB /日
出力：（df -hルートボリュームのみ）
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 4.0G 1.2G 2.8G 31% /
このシステムがリリースされてから、使用済みスペースはそれほど増加していません（ファイルの作成/追加ではなく更新が行われていることを私は示唆しています）。
の出力：iostat -x（with Blk_read、Blk_wrtnadded）：
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
出力： 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
上記を要約すると（および1日の値に外挿すると）、10分間で次のようになります。
- [flush-202]書き込み26MB = 3.6GB /日
- php-fpmは17.5MB = 2.4GB /日を書き込みました
- MySQLは684KB = 96MB /日を書き込みました
- ワニスは580KB = 82MB /日と書きました
- [jbd2]は、528KB = 74MB /日を書き込みました
- Nginxは120KB = 17MB /日と書き込みました
- IMAPプロキシは8KB = 1.1MB /日を書き込みました
興味深いことに、間のように思われる[flush-202]とphp-fpm、それは書き込みの日々のボリュームを占めることが可能です。
を使用ftopして、flushまたはを追跡することはできませんphp-fpm（例：ftop -p php-fpm。
私の問題の少なくとも一部は、ルートボリュームに書き込んでいるプロセスを特定することから生じます。これらは、上記のうち、私は（該当するディレクトリが存在シンボリックリンクされているので）すべてのデータボリュームへの書き込みをすることが期待される（例えばnginx、mysql、php-fpm、varnish異なるEBSボリュームにディレクトリのすべてのポイント）
私はJBD2ext4のジャーナリングブロックデバイスでflush-202あり、ダーティページのフラッシュバックグラウンドであると考えています。dirty_ratio20でありdirty_background_ratio（〜10ダーティメモリである/proc/meminfo）は、典型的に50-150kBの間でした）。ページサイズ（getconf PAGESIZE）はシステムのデフォルト（4096）です。
出力： vmstat -s | grep paged
3248858ページがページイン104625313ページがページアウト
出力： 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
上記はページアウトされたページの数が多いことを示唆しているようですが、ページはルートボリュームではなく、必要に応じてスワップパーティションに書き込まれると思います。システムは通常、合計メモリのうち、35％が使用、10％がバッファ、40％がキャッシュ、15％が未使用（65％が空き）です。
出力： 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
vmstat一貫して0の値を表示siしsoます
出力： swapon -s
Filename Type Size Used Priority
/dev/xvdg partition 1048572 9252 -1
I / O書き込みがメモリ関連である可能性があるという予兆で、私はニスを無効にし、サーバーを再起動しました。これにより、メモリプロファイルが10％使用、2％バッファ、20％キャッシュ、68％未使用（つまり90％空き）に変更されました。ただし、10分の実行で、iotopは以前と同様の結果を示しました。
- [フラッシュ-202]は19MBを書いた
- php-fpmが10MBを書き込みました
再起動後1時間で、ルートボリュームに330MBの書き込みが行われ、370Kページがスワップアウトされました。
の出力 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/
上記をもう少し詳しく見てみると、ほとんどすべての書き込みは、5分ごとに実行され、さまざまなサービスのステータスをチェックしている（不明な）プロセス（chkservdcPanel など）が原因である可能性がありますが、cPanelは使用していません。これをインストールしませんでした）。これは、10分間に更新された4つのログファイル（cron、maillog、ftp、imapproxy）、およびいくつかの関連アイテム（postfixソケット、pure-ftpd接続）に相当します。その他の項目は、主に変更されたispconfigセッション、システムアカウンティングの更新、および無効な（存在しないserver_name）Webアクセス試行（/ var / log / nginxに記録）です。
結論と質問：
私は少し困惑していると言って始めましょう-私は通常かなり徹底していますが、これについて明白な何かを見逃しているように感じます。明らかに、flushそしてphp-fpmこのようなケースかもしれない理由の書き込みの大部分を占め、しかし、私は知りません。まず、php-fpmを取り上げましょう。ルートボリュームに書き込むこともできません。そのディレクトリ（ファイルとログの両方）は、別のEBSボリュームにシンボリックリンクされています。次に、php-fpmが書き込む必要がある主なものは、セッションとページキャッシュです。これらは数も少なく、どちらも1MB / minのオーダーではありません（1K / minのような場合はさらに多い）。ほとんどのサイトは読み取り専用で、たまにしか更新されません。最終日に変更されたすべてのWebファイルの合計サイズは2.6MBです。
次に、フラッシュを検討します-そこからの重要な書き込みは、ダーティページが頻繁にディスクにフラッシュされていることを示唆していますが、私は通常、65％の空きメモリとスワップスペース用の個別のEBSボリュームがあるため、これがなぜなのか説明できません特に発生している範囲で、ルートボリュームへの書き込みに影響します。一部のプロセスがダーティページを独自のスワップスペースに書き込む（システムスワップスペースを使用するのではなく）ことを認識していますが、確実に、メモリの大部分が解放された状態で再起動した直後は、かなりの量のメモリを実行する必要はありません。汚れたページ。これが原因であると思われる場合は、どのプロセスが独自のスワップ領域に書き込んでいるかをどのように特定できるかを教えてください。
ダーティページ全体のアイデアが単に赤いニシンであり、私の問題とはまったく無関係である可能性は十分にあります（実際にはそうだと思います）。もしそうなら、ext3にはなかったext4ジャーナリングに関連する何かがあるという私の唯一の他の考え。それを超えて、私は現在アイデアがありません。
更新：
2011年11月6日：
セットdirty_ratio = 10とdirty_background_ratio = 5; sysctl -p（/ procで確認済み）で更新されます。同様の結果で10分のiotopテストを再実行しました（フラッシュは17MBを書き込み、php-fpmは16MBを書き込み、MySQLは1MBを書き込み、JBD2は0.7MBを書き込みました）。
mount --bind代わりに使用するように設定したすべてのシンボリックリンクを変更しました。ニスを再度有効にし、サーバーを再起動しました。同様の結果で10分のiotopテストを再実行しました（フラッシュは12.5MBを書き込み、php-fpmは11.5MBを書き込み、ワニスは0.5MBを書き込み、JBD2は0.5MBを書き込み、MySQLは0.3MBを書き込みました）。
上記の実行時と同じように、私のメモリプロファイルは20％使用、2％バッファ、58％キャッシュ、20％未使用（つまり80％空き）でした。free -mこれは（これはt1.microです）の出力です。キャッシュされた使用済みの無料共有バッファの合計Mem：602 478 124 0 14 347-/ +バッファ/キャッシュ：116 486スワップ：1023 0 1023
追加情報：出力： 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)
また、ftopとiotopを同時に実行したところ、iotopに表示されるエントリがftopに表示されないことに驚いた。ftopリストはphp-fpmにフィルターされました。これは、そのプロセスの書き込みをかなり確実にトリガーできるためです。私はphp-fpmのページビューあたり約2MBの書き込みに気づきました-そして、それが何である可能性があるかをまだ理解していません-何が書き込まれているのかを確認する上でのアイデアはありがたいです。
私は今後数日でジャーナリングをオフにしようと試み、それが物事を改善するかどうかを確認します。とりあえず、私はI / Oの問題かメモリの問題（またはその両方）があるのかと思っていますが、メモリの問題がある場合、それを確認するのに苦労しています。
2011年11月13日：
ファイルシステムはエクステントを使用するため、ext3としてマウントすることはできませんでした。さらに、読み取り専用としてマウントしようとすると、単に読み取り/書き込みとして再マウントされました。
以下から明らかなように、ファイルシステムでは実際にジャーナリングが有効になっています（128MBジャーナル）。
出力： 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
次のように、1か月足らずで約140GBがこのボリュームに書き込まれました-わずか約5GB /日。
出力： 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
開いているファイルを探し続けてfuser、ルートボリュームで使用してみました。
出力： 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
残念ながら、予期しないことは何もありません。基盤となるハードウェアが原因であるというオフチャンスで、私は昨日のルートボリュームのスナップショットを復元し（最終日には何も変化していなかった）、インスタンスのルートボリュームを新しいボリュームに置き換えました。予想通り、これは問題に影響を与えませんでした。
私の次のステップはジャーナリングを削除することでしたが、それに到達する前に解決策を偶然見つけました。
問題は、ファイルベースのmmapを使用するAPCにありました。このドロップされたディスクI / Oを約35倍に修正-（推定）150MB /日（5GBではなく）。ジャーナリングを削除することを検討する可能性があります。これは、この値の残りの主な原因であると思われるためですが、この数は当面は十分許容できます。APCの結論に至るまでの手順は、以下の回答に掲載されています。
watch。少数のファイル（17）しかありませんでした-ほとんどがPIDファイルまたはロックファイルで、少数の（存在しない）一時ファイルがあります。watch -d -n 0.5 'lsof / | grep REG | awk '"'"'$4 ~ /.*[wu]/ { print $9}'"'"' | sort -u'