基本情報技術者 2019年 春期 午前（科目A） 問15

データ格納状況の確認【午前解説】

正解の理由

解法ステップ

1. まず想定原因（フラグメンテーション）を論点化する：断片化は「連続領域の欠如」による追加 I/O を引き起こす。
2. OS・ストレージ・DBそれぞれで格納状態を調査する項目を洗い出す。
   • ファイルシステムレベル：ファイルの断片化（extent 分割状況）や空き領域の分散。
   • ブロック/デバイスレベル：パーティションの配置、RAID/ボリュームの断片化、LVM の断片化。
   • DBレベル：テーブル/インデックスのページ散在、内部フリースペースの増加。
3. 実測で影響を確認する：I/O 指標（例：await と avgqu-sz は意味が異なるため両方を確認）やアクセスパターンを併せて評価する。
4. 必要なら整理（デフラグ、テーブルの再構成、再割付け、パーティショニング）を実施し、性能改善を検証する。

選択肢別の誤答解説

• ア（遅い処理の特定）
  遅い SQL 文や非定型検索が原因のときに有効です。実際の想定原因がフラグメンテーションであれば、処理そのものの特定ではなく、格納レイアウトの確認が優先されます。よって c に対しては不適切。
• イ（外的要因の変化の確認）
  他システムの共存や接続クライアント数の増加など「外的要因」を調べる項目であり、表の1行目に対応します。フラグメンテーションの検証とは目的が異なります。
• ウ（キャッシュメモリのヒット率の調査）
  データベースバッファの不足やキャッシュ効率の問題を疑うときに用いる項目です（バッファ不足により I/O が増えるケースに該当）。フラグメンテーションそのものの有無や配置の偏りは直接は分からないため、c の想定原因には不十分です。
• エ（データの格納状況の確認）
  ファイル/ブロック/テーブルの断片化を直接検出できるため、フラグメンテーションによるディスク I/O 増加を特定するために最も適切です。

よくある誤解

1. SSD ではフラグメンテーションを無視してよいと思い込む
   • SSD はシーク遅延が小さいため影響が HDD より小さいことが多いが、ファイルシステムのメタデータ肥大やガーベジコレクション、書込 amplification により性能影響を受けることがある。無条件に無視して良いわけではありません。
2. I/O 指標を一つだけ見れば十分と考える
   • 例えば iostat の await は平均 I/O 待ち時間、avgqu-sz は平均キュー長であり意味が異なります。両者やスループット、CPU待ち、コンテキストスイッチ等を総合的に見る必要があります。

補足コラム

• 代表的な確認ツール例（Linux）
  • ファイル断片化確認:

    filefrag -v /path/to/file
    

  • ブロックデバイス状況:

    lsblk; blkid; hdparm -I /dev/sdX
    

  • I/O 指標:

    iostat -x 1 3   # await, avgqu-sz などを確認
    sar -d 1 3
    vmstat 1 3
    

  • データベース側:
    • MySQL: SHOW TABLE STATUS、OPTIMIZE TABLE、InnoDB のフラグメント（innodb_file_per_table の有無）
    • PostgreSQL: pgstattuple、VACUUM (FULL) や REINDEX
• 対策の考え方
  • 最小侵襲で効果がある順に試す：インデックス再構築→テーブル再編成→ファイルシステムのデフラグ/再配置。運用影響（停止時間）を考慮して段階実施すること。

FAQ