差分

このページの2つのバージョン間の差分を表示します。

--- blog:2014:2014-11-05 [2014-11-05 14:46]
Decomo
+++ blog:2014:2014-11-05 [2020-12-03 16:20] (現在)
Decomo
@@ 行 7: / 行 7: @@
 ===== ZFSの断片化問題 - ZILの分析 =====
-<align right>
+<WRAP rightalign>
 //Original Post: [[http://thomas.gouverneur.name/2011/06/20110609zfs-fragmentation-issue-examining-the-zil/|ZFS Fragmentation issue – examining the ZIL]]// \\
 //Author: Thomas Gouverneur// \\
 //Date: June 9, 2011, 2:32 pm// \\
-</align>
+</WRAP>
 このところ私は、重いデータベースで使われている幾つかのZFSプールのトラブルシューティングに取り組んでいました。
@@ 行 48: / 行 48: @@
 背後にあるSANディスクは大量のI/Oを捌くことが可能で、またSANはあらゆる不具合について点検がなされましたが異常はなく、この問題はLUNにおける大量のI/O処理負荷でした。
-続いて、私たちの考えの裏付けを取るために<ilcode>zpool iostat -v i-ora-pro06-dat1-pl 2</ilcode>を実行し続けました。
+続いて、私たちの考えの裏付けを取るために''zpool iostat -v i-ora-pro06-dat1-pl 2''を実行し続けました。
 これにより、vdevに対する激しい書き込みを確認しました。
@@ 行 72: / 行 72: @@
 Oracle DBの階層では、データベース書き込みスレッド群が、ディスクの大変なサービス時間が原因で書き込み操作を抱えている事実を除き、特に何も見られませんでした。
-Oracle DB自身は、ある意味ではあらゆる書き込み操作後にディスクを使用しますが、データベースが<ilcode>fsync()</ilcode>を呼ぶと、OSによる書き込み操作のディスクへの直接コミットが生じます。
+Oracle DB自身は、ある意味ではあらゆる書き込み操作後にディスクを使用しますが、データベースが''fsync()''を呼ぶと、OSによる書き込み操作のディスクへの直接コミットが生じます。
 これは全てのOracleデータベースについて言えます。
@@ 行 88: / 行 88: @@
 マウント毎にZFSはZILエントリーの存在を確認しますが、エントリーがあれば、それはファイルシステムが正しくアンマウントされなかった事を示し、ファイルシステムがマウントされる前に見つかったZILエントリーはコミットされます。
-リクエスタが<ilcode>fsync()</ilcode>を発行すると、ZILトランザクションはワークメモリの代わりに強制的にディスクに書き込みされるという事も知っておくと良いでしょう。
+リクエスタが''fsync()''を発行すると、ZILトランザクションはワークメモリの代わりに強制的にディスクに書き込みされるという事も知っておくと良いでしょう。
 ==== 3. どのように断片化が起こるのか？ ====
@@ 行 110: / 行 110: @@
 これが断片化の生じる場所です！
 ディスクに確保と解放が行われる全てのZILトランザクションは、ZILエントリーおよびプールのデータの間に隙間を生じます。
-我々の<ilcode>zpool iostat</ilcode>が以前に報告した膨大な書き込み操作数についても説明します。
+我々の''zpool iostat''が以前に報告した膨大な書き込み操作数についても説明します。
 これら書き込み操作はディスクを読み込み、そしてアプリケーションが使用可能なプールの実帯域幅を狭めます。
@@ 行 119: / 行 119: @@
 別の方法で、私たちはより深くへ行くことが可能です。
-実際にギャンギングがシステム全体のレベルで問題を起こしているかどうか見つけ出すには、<ilcode>lockstat</ilcode>を使います:
+実際にギャンギングがシステム全体のレベルで問題を起こしているかどうか見つけ出すには、''lockstat''を使います:
 <code bash>