1
毎日5.5 GBが1.2 GBのルートボリュームに書き込まれる-以前のレベルの4倍
問題： 最近、サーバーの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 …