2 ポイント 投稿者 computerphilosopher 5 시간 전 | まだコメントはありません。 | WhatsAppで共有
  • ZFSの基本パラメータは、シーケンシャルアクセスとランダムアクセスの間の折衷案として設定されている
    • ワークロードの特性を明確に把握していれば、より積極的なチューニングが可能
  • シーケンシャルアクセス vs ランダムアクセスの違いを説明
    • HDDはヘッド移動のため、ランダムアクセス性能がシーケンシャルアクセスに比べて数十倍〜数百倍遅くなることがある
    • SSDもランダムアクセスは大幅に高速化されたが、シーケンシャルアクセスのほうが依然として効率的
    • 大きなファイルを順番に読むワークロードは、シーケンシャルアクセスの傾向が強い
    • 小さなファイルを複数頻繁に読むワークロードは、ランダムアクセスの傾向が強くなりやすい
  • ワークロード分析方法を紹介
    • コード/構造ベースの論理的推論
    • スループット(bps)+秒間IO数(iops)ベースの平均IOサイズ計算
    • zpool iostat -rベースのIOサイズ分布分析
  • zpool iostat -rの解釈
    • ind: 個別の論理リクエストサイズ
    • agg: 実際にマージされて実行されたIOサイズ
    • aggindより大きければ、隣接IOのマージがうまく起きていることを意味する
  • 例のワークロード分析結果
    • 同期読み取りの比率は約76%
    • 32KiB以下の読み取りが99%以上
    • 非同期書き込みも小さなIOの比率が高い
    • 全体としてランダムアクセスの傾向が非常に強いワークロード
  • zfs_prefetch_disable
    • ZFSはシーケンシャルアクセスパターンを検出すると、隣接ブロックをあらかじめARCに読み込む
    • ランダムアクセスのワークロードでは、先読みのヒット率が低く、不要なIOだけが増える可能性がある
    • arc_summaryベースで先読み効率を測定できる
    • ヒット率が低ければzfs_prefetch_disableを検討できる
  • recordsize
    • デフォルト値は128K
    • 例のワークロードでは大半のIOが32KiB以下のため、より小さいrecordsizeを検討できる
  • 最適値の選定
    • ベンチマークに基づいて決めることが重要
    • MySQL/PostgresのようなDBには、すでに検証済みのチューニング事例が多い
    • 一般的にDBページサイズに近いrecordsizeを使うことが多い

まだコメントはありません。

まだコメントはありません。