重大な書き込みパフォーマンスの問題

Question

[申し訳ありませんが、私は短くしようとしましたが、それは不可能でした]

Linux 2.6.22.19を linux-vserver 2.3.0.34 で Fujitsu Siemens Primergy RX200 S で実行しています。 Intel（R）Xeon（R）5140 @ 2.33Ghz、4GB RAM（ほとんどの場合500MBはまだ空き）サーバーには、ミラーリングRAID構成で使用される2つのホットプラグ250GBがあります。

dev:~# mpt-status --newstyle ioc:0 vol_id:0 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: OPTIMAL flags: ENABLED ioc:0 phys_id:0 scsi_id:1 vendor:ATA product_id:WDC WD2500JS-55N revision:2E01 size(GB):232 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0xff/0xff SMART ASC/ASCQ:0xff/0xff ioc:0 phys_id:1 scsi_id:8 vendor:ATA product_id:WDC WD2500JS-55N revision:2E01 size(GB):232 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0xff/0xff SMART ASC/ASCQ:0xff/0xff scsi_id:0 100% scsi_id:1 100%

私は [〜＃〜] lvm [〜＃〜] とext3を実行しています。

2007年7月/ 8月頃からこのマシンを使用しており、同じ日に修正された壊れたRAMのほか、問題はありませんでした。基本的に、すべてが私たちが持っていたマシンよりも優れていました。前。

ただし、パフォーマンスの問題は2008年8月頃に最初に気づき、問題の原因が少なくともある程度確信できるようになったのはつい最近のことです。現在、平均7台のvserverが実行されています（3台のMySQLマシン、2台のtomcat、3台のApache、Hudson、CruiseControl、MediaWiki、Sambaなど）。しかし、誤った印象を与えないために、私たちは開発者やサーバーにアクセスする他の人々の点で小さな会社なので、それほど多くは起こっていません（MediaWikiの閲覧、Hudsonの自動化は夕方に実行され、ほとんどのApache/PHPアプリには多くの機能があります静的コンテンツ）。

Muninをインストールすると、特に夜中に面白いものが見え始めました。すべてのvserver内でfindが実行されていたため（同時に、どこでも）、負荷は15、17、20などの非現実的な数値に急上昇しました。

しかし、最終的には、問題は夜間だけでなく（検索ジョブを無効にし始めましたが、とにかく使用されませんでした）、特に最近プロジェクトを開始したときは、データベースを操作する必要がありました。 500MBのMySQLダンプファイル。

勤務時間中に初めてダンプファイルをインポートしたとき（mysql < dump.sql; MySQLインスタンスが実行されていたvserverの1つ内）、時間出力は次のとおりでした。

real 71m28.630s user 0m15.477s sys 0m10.185s

私は注意を払っていなかったので、会議に参加していたので、彼がひどく遅かったので、サーバーの状態を尋ねてきたのは同僚だけでした。

私は夜間にテストを作り直し、Vanilla Debian MySQLをホストにインストールし（ゲストの内部ではなく、すべてをシャットダウンしました）、次の数値をヒットしました。

real 48m33.067s user 0m15.397s sys 0m13.517s

それでも私はのようでした。ええ、それは500MBのダンプファイルです。 InnoDBスペースへのダンプは約1GBを消費しますが、これはかなりのデータです。このようなテスト中にvimを使用してファイルに単一行を書き込み、straceを使用してキャプチャするなど、いくつかのテストを行いました。

 0.000048 write(1, "\33[?25l\"foo\" \33[78;7H\33[K", 22) = 22 0.000033 stat64("foo", 0xbfda1f04) = -1 ENOENT (No such file or directory) 0.000033 open("foo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 0.000035 write(4, "thios isthis ia a testa
", 24) = 24 0.000144 fsync(4) = 0 7737.631089 stat64("foo", {st_mode=S_IFREG|0664, st_size=24, ...}) = 0 0.000084 close(4) = 0 0.000117 write(1, "\33[78;7H[New] 1L, 24C written", 28) = 28 0.000051 lseek(3, 0, SEEK_SET) = 0 0.000022 write(3, "b0VIM 7.0\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0!\21\0\0mark"..., 4096) = 4096 0.000052 select(1, [0], NULL, [0], {0, 0}) = 1 (in [0], left {0, 0})

これは私にとって信じられないほどの事実数でした。 stat64 syscallは、ダンプ操作が終了するのを強制的に待機させられたようです。そのようなダンプ中にMediaWikiでページを提供することも数分かかることは言うまでもありません。

とにかく、私はホスティング会社とテスト時間枠を調整して、夜間に本番サーバーでテストしましたが、まったく異なる状況になりました。

real 7m4.063s user 0m2.690s sys 0m30.500s

私はびっくりしました。また、テスト用のAmazon EC2承認を取得し、さらに低い数値を取得しました（MySQLデータが永続的に維持するためにEBSボリュームに書き込まれたm1.largeインスタンスで約5分）。

さらに、データをインポートすると、他のすべての操作が非常に遅くなり、使用できなくなり、負荷が5または7まで急速に上昇します（実際にはそれほど多くは発生していないようですが、プロセスが互いにブロックし始めているようです。今理由）。

それから私は bonnie ++ tests を始めました、それはこのように見えました（私は実際に去年からテストを実行しましたが、ほとんど忘れていました）。だからここに2008年10月：

Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP vserver-Host 8G 12332 21 12600 3 10290 2 48519 74 52431 6 235.8 0 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ vserver-Host,8G,12332,21,12600,3,10290,2,48519,74,52431,6,235.8,0,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

これが2009年4月の現在のものです：

Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP vserver-Host 8G 9705 16 7268 1 4823 1 29620 45 41336 5 73.1 0 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 11678 15 +++++ +++ +++++ +++ +++++ +++ +++++ +++ 27739 31 vserver-Host,8G,9705,16,7268,1,4823,1,29620,45,41336,5,73.1,0,16,11678,15,+++++,+++,+++++,+++,+++++,+++,+++++,+++,27739,31

本当の問題がどこにあるのか、何なのかまだ完全にはわからないので、問題を取り除くためにどこを調整すればよいのかわかりません。私は木のために木を見るのに失敗し始めたと思います。

更新1：

これまでのフィードバックに感謝し、メンテナンス時間をスケジュールせずに簡単にテストできるものを最初に選びました。

まず、MySQLダンプを/dev/nullに対してテストしました。

dev01:~$ time mysqldump -u root -h db01 database-p >/dev/null Enter password: real 0m18.871s user 0m12.713s sys 0m0.512s

システムの負荷はほとんど目立たなかった：

 10:27:18 up 77 days, 9:10, 7 users, load average: 0.16, 0.75, 0.67 [...] 10:27:33 up 77 days, 9:10, 7 users, load average: 0.52, 0.79, 0.69

また、このテスト中のsar出力では、特別なことは何も明らかになりませんでした。

12:11:45 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 12:11:46 PM dev8-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:11:46 PM dev254-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:11:46 PM dev254-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:11:46 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 12:11:47 PM dev8-0 5.00 0.00 200.00 40.00 0.18 36.00 20.00 10.00 12:11:47 PM dev254-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:11:47 PM dev254-1 25.00 0.00 200.00 8.00 0.74 29.60 4.00 10.00

次に、ファイルにダンプするときにテストを実行しました。

dev01:~$ time mysqldump -u root -h db01 database -p >foo.sql real 1m7.527s user 0m13.497s sys 0m2.724s

かかった時間は私にはそれほど珍しくはありませんが、ダンプは570MBのファイルで終了しました。

しかし、負荷はかなり面白かったです...

 10:30:49 up 77 days, 9:14, 7 users, load average: 0.76, 0.89, 0.75 10:30:57 up 77 days, 9:14, 7 users, load average: 1.34, 1.01, 0.79 10:31:05 up 77 days, 9:14, 7 users, load average: 2.13, 1.19, 0.85 10:31:13 up 77 days, 9:14, 7 users, load average: 2.68, 1.32, 0.89 10:31:21 up 77 days, 9:14, 7 users, load average: 3.79, 1.60, 0.99 10:31:29 up 77 days, 9:14, 7 users, load average: 4.05, 1.69, 1.02 10:31:37 up 77 days, 9:14, 7 users, load average: 4.82, 1.93, 1.10 10:31:45 up 77 days, 9:15, 7 users, load average: 4.54, 1.97, 1.12 10:31:53 up 77 days, 9:15, 7 users, load average: 4.89, 2.08, 1.16 10:31:57 up 77 days, 9:15, 7 users, load average: 5.30, 2.22, 1.21 10:32:01 up 77 days, 9:15, 7 users, load average: 5.12, 2.23, 1.22 10:32:05 up 77 days, 9:15, 7 users, load average: 5.03, 2.26, 1.24 10:32:13 up 77 days, 9:15, 7 users, load average: 4.62, 2.22, 1.23

... sar ..のように.

12:16:47 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 12:16:48 PM dev8-0 116.00 0.00 21712.00 187.17 134.04 559.31 8.62 100.00 12:16:48 PM dev254-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:48 PM dev254-1 3369.00 0.00 26952.00 8.00 3271.74 481.27 0.30 100.00 12:16:48 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 12:16:49 PM dev8-0 130.00 0.00 17544.00 134.95 143.78 752.89 7.69 100.00 12:16:49 PM dev254-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:49 PM dev254-1 1462.00 0.00 11696.00 8.00 2749.12 1407.78 0.68 100.00 12:16:49 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 12:16:50 PM dev8-0 128.00 0.00 18400.00 143.75 143.68 1593.91 7.84 100.40 12:16:50 PM dev254-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:50 PM dev254-1 810.00 0.00 6480.00 8.00 1598.99 4911.94 1.24 100.40

このテスト中に、私はすぐにvimを起動して、簡単な書き込みテストを実行しました。 vim自体の読み込みも遅かったのですが、この情報をstraceから適切に抽出することができませんでした。保留中のstat64呼び出しのみが再びはっきりと表示されました。

0.000050 stat64("bla", 0xbf98caf4) = -1 ENOENT (No such file or directory) 0.000038 open("bla", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 0.000053 write(4, "fooo
", 5) = 5 0.000051 fsync(4) = 0 5.385200 stat64("bla", {st_mode=S_IFREG|0664, st_size=5, ...}) = 0 0.000073 close(4) = 0

できるだけ早くファイルシステムテストを追加します。

アップデート2 /解決策：

MTPデバイスとRAID構成に関するMihaiからのフィードバックに基づいて、私はそのトピックをもう少し掘り下げました。 lspciを介して、RAIDコントローラー情報を取得しました。

dev:~$ Sudo lspci|grep -i lsi 05:05.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01)

真っ青になって、 http://www.ask.com/web?q=linux+problem+performance+SAS1068 でショットを出し、 LSI LogicSAS1068でパフォーマンスの問題を書く。バグの説明は、 SAS1068も使用するDell PE860のパフォーマンスの問題について話しているブログにさらにリンクされています。

この記事では、 lsi.comから入手できるLSIUtil の使用について説明しています。この記事には、書き込みキャッシュをオンにする方法を説明したlsiutilメニューについても詳しく説明しています。

当然のことながら、これはパフォーマンスに大きな影響を及ぼします。 Beforeアクティブ化：

dev:~# time (dd if=/dev/zero of=bigfile count=1024 bs=1M; sync) 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 180.902 seconds, 5.9 MB/s real 3m8.472s user 0m0.004s sys 0m3.340s

書き込みキャッシュを有効にした後：

dev:~# time (dd if=/dev/zero of=bigfile count=1024 bs=1M; sync) 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 43.7899 seconds, 24.5 MB/s real 0m46.413s user 0m0.000s sys 0m3.124s

これは昼と夜のようで、黒と白です。時々バカを感じても大丈夫です。 RAIDコントローラーには、デフォルトで書き込みキャッシュが無効になっていることを知っているはずです。

更新3：

むしろ偶然に、すべてのブロックデバイスの詳細なIO、読み取り/書き込み/待機などのグラフを提供する diskstat というmuninプラグインを見つけました。著者からの非常に素晴らしく詳細なブログ投稿もあります Muninを使用したLinuxディスクI/O統計のグラフ化。

Jon Topper · Accepted Answer

ソフトウェアを除外し、RAIDパフォーマンスを微調整することについて、他のポスターからここにいくつかの良い提案があります。ワークロードが書き込み負荷の高い場合、キットの交換を検討している場合は、バッテリーでバックアップされた書き込みキャッシュを備えたハードウェアを使用するのが適切である可能性が高いことを言及する価値があります。

Mihai Limbăşan · Answer

これは私にとっては信じられないほどの事実番号でした。stat64システムコールはダンプ操作が終了するのを待たされたようです。

それがあなたが探している手がかりです。私の賭けは、ここでの犯人はext3だということです。デフォルトでは、ext3では、任意のユーザーアカウントで任意のアプリケーションによって発行されたfsyncは、ジャーナル全体をディスクに強制します。これは、fsync（）呼び出しを頻繁に発行する必要があるデータベースを実行している場合に特に厄介です。これは、書き込みバリアをサポートしていないRAIDデバイス上で実行する場合はさらに厄介です（MPTデバイスがそれらをサポートしているかどうかはわかりません。申し訳ありません）。

UPSとサーバーの安定性についてある程度確信がある場合は、デフォルトのdata=writebackの代わりにdata=orderedマウントオプションを使用してそのファイルシステムをマウントしてみてください。サーバーのクラッシュに直面すると信頼性が犠牲になりますが、とにかくパフォーマンスがこれほど悪くなったとしても、大きな損失にはなりません。

ただし、長期的な解決策は、より優れたファイルシステムに切り替えることかもしれません。現在、XFSをお勧めします。何年も問題なく使っています。唯一の欠点は、ext2/3を縮小できるように縮小できないことですが、拡張することはできます。

David Schmitt · Answer

Mysqlダンプを実行してみてくださいdo/dev/null。これにより、書き込み部分と読み取り部分のどちらが責任を負うかがわかります。
ダンプを別の論理ボリューム/ファイルシステムまたはRAMディスクに書き込んでみてください。
ファイルシステムのjournallingオプションを確認してください。
ファイルシステムのnoatime/atimeステータスを確認します
ファイルシステムがいっぱいになっていますか？通常、パフォーマンスは、データ量が特定のしきい値に達すると低下します。

womble · Answer

IO容量がいっぱいになっているようです。まず、ディスクの1つが停止していないことを確認し（セクターの再マッピングはIOに悪影響を与える可能性があります）、sar -d 1 0を実行します。物理ディスクの%util番号を確認します。それが約100％になっている場合は、さらにスピンドルを投入してRAID-10に入れます。パフォーマンスは2倍にはなりませんが、パフォーマンスは向上します。最近では、250GBのディスクはそれほど高価ではありません。

ああ、そして私の仕事をもう少しポン引きして、テキストの壁をあなたのテキストの壁と戦うために、パフォーマンスの問題を追跡するために私が書いたガイド： http://www.anchor.com.au/ hosting/development/HuntingThePerformanceWumpus は、パフォーマンスの問題の追跡について知っておく必要のあるすべてを網羅しています。