大規模 DB サーバへの Linux 適用 ~Kernel2.6 の実力を探る ~ 25.11.11 オープンソースソフトウェア推進部野呂昌哉
はじめに Linux Kernel2.6 の登場により エンタープライズ分野における大規模 DB サーバへの Linux 適用の加速が期待されている 今回は DB 性能ベンチマークテスト結果をまじえ Linux の適用範囲が従来の Web/AP サーバ系フロントエンドシステムから DB サーバ系バックエンドシステム へ拡大可能であることを説明する -2-
アジェンダ DB 性能ベンチマーク IA32 サーバ +Kernel2.4/2.6 の DB 性能 IA64 サーバ +Kernel2.6 の DB 性能 考察 まとめ -3-
DB 性能ベンチマーク
ベンチマークテスト概要 DB サーバの単位時間あたりのトランザクション数 ( スループット ) を測定 SQL 発行クライアント DB サーバ ストレージ NTT コムウェア独自ベンチマークツール SQL 発行 商用 DBMS + Linux ディストリビューション -5-
ベンチマークテストモデル 典型的な卸売り業を想定したテスト 1, 種類の商品 (Item) 商品 企業 WH 個の倉庫 (Warehouse) 在庫 在庫在庫在庫 倉庫 1 倉庫 2 倉庫 3 倉庫 W 配送区域配送区域 1 配送区域 2 配送区域 3 配送区域 12 配送区域配送区域 3 配送区域 12 配送区域 1 配送区域 3 配送区域配送区域 2 3 配送区域 1 配送区域 1 配送区域 1 配送区域 1 注文データ 注文明細 注文履歴 倉庫あたり 1 個の配送区域 (District) 顧客 3, 人 1 配送区域あたり 3, 人の顧客 (Customer) -6-
DB スキーマ テーブル構成 (WH*1,) 8.STOCK( 在庫 )..* 1 1..* 倉庫 商品ごとの在庫数を格納 ( 倉庫 1 つあたり商品数分のレコードを持つ ) (1,) 7.ITEM( 商品 ) 商品名 価格 商品概要を格納 1, レコード ( 固定 ) (WH) 1.WAREHOUSE( 倉庫 ) 倉庫の名前 住所などを格納 ( データベース規模の基準値となる )..1 (WH*3, 程度 ) 9.ORDER_LINE ( 注文明細 ) 注文された商品ごとの商品番号 数量を格納 ( 注文 1 回あたり平均 1 種類の商品を購入し 初期値から単調増加 ) 1..*..* (WH*1) 2.DISTRICT( 配送区域 ) 配送区域の名前 住所などを格納 ( 倉庫 1 つあたり 1 の配送区域を持つ ) 顧客の個人情報を格納..1 ( 配送区域 1つあたり 3, 人の顧客を持つ )..1 (WH*3,)..* 5.ORDERS( 注文 )..* 注文データを格納 1 ( 顧客 1 人あたり1レコードの初期値から単調増加 ) 1 (WH*3,) * 3.CUSTOMER( 顧客 ) () 内の値は WAREHOUSE テーブルのレコード数を WH とした場合の初期レコード数..1 1..1..*..* (WH*3,) 4.HISTORY ( 注文履歴 ) 日付 注文内容を格納 ( 顧客 1 人あたり 1 レコードの初期値から単調増加 ) (WH*9,) 6.NEW_ORDERS ( 新規注文 ) 注文されたが まだ配送されていない注文データを格納 ( 顧客数.3 の初期値からランダムに増減 ) -7-
発行 SQL スループット =New-Order の 1 分あたりの件数 (Tpm) トランザクション SELECT INSERT UPDATE DELETE 小計 実行比率 レスポンスタイム New-Order 22 回 12 回 11 回 - 45 回 (45% 以下 ) 9% が5 秒以内 Payment 3 回 1 回 3 回 - 7 回 43% 以上 9% が5 秒以内 Order-Status 3 回 - - - 3 回 4% 以上 9% が5 秒以内 Delivery 3 回 - 3 回 1 回 7 回 4% 以上 9% が5 秒以内 Stock-Level 22 回 - - - 22 回 4% 以上 9% が2 秒以内 -8-
測定方法 安定するまでランプアップを確保 試験開始 測定開始 試験および測定終了 ランプアップ時間 測定時間 スループット 各種リソースを収集 試験時間 15 分 15 分 -9-
測定ポイント リソース DBMS 統計情報 ストレージ性能を収集し ボトルネックを解析 データ収集項目 クライアント DBサーバ ストレージ 収集用途 sarコマンド vmstatコマンド iostatコマンド - - - CPU 使用率 / ディスク使用状況 / メモリ使用状況などを確認する free コマンド ps コマンド DBMS 統計情報 - - 検証目的以外のプロセスでCPUに負荷 をかけているプロセスがないか確認す る - - DBMSの統計情報を収集し DBMSの 状態を確認する ストレージ - - ストレージ側からみたI/Oの状態を確認 する ( 凡例 ) : 収集する - : 収集しない -1-
IA32 サーバ +Kernel2.4/2.6 の DB 性能
目的 Kernel2.4 2.6 に伴う DB 性能向上度合いを確認する ハードウェア DBMS は同一条件とし Linux ディストリビューションのみ Kernel2.4/2.6 対応の 2 種類を使用 DB サーバ以外の部分でボトルネックにならないように高速なストレージ 複数台の高速クライアントを使用 Kernel2.6 の I/O スケジューラの違いによる DB 性能差を確認する Kernel2.6 で選択可能となった 4 種類の elevator アルゴリズムを変更し 性能に与える影響を確認 -12-
試験環境 IA32 サーバ 2 SQL 発行クライアント CPU Memory NIC Intel Xeon3.2GHz 2 5GB Ethernet 1Mbps Full Duplex Ethernet 1Mbps Ethernet 1Mbps L2Switch Linux OS L2Switch Speed IA32サーバ Kernel 2.4.21-32..1 (smp) Ethernet 1Mbps DB サーバ CPU Memory Intel XeonMP3.GHz 4 16GB Host Bus Adapter NIC Ethernet 1Mbps Full Duplex ストレージ FibreChannel 2Gbps Fibre Channel Switch 72GB 4 HBA Linux OS DBMS Setting ストレージ HDD RAID 2Gbps Full Duplex Kernel 2.4.21-32..1 / 2.6.9-11 (smp) AsyncI/O & DirectI/O 72GB(15rpm) 4 RAID1+ FileSystem ext3 (mount mode=ordered, noatime) -13-
- Kernel2.4/2.6 の比較 -
Kernel2.4/2.6 の DB 性能比較 Kernel2.4 のスループットを 1 とした性能比 6 性能低 1. 122 性能高 WH3 Kernel2.6の処理性能は Kernel2.4の最大 1.6 倍 その要因は後ほど考察で... 同時接続数同時接続数 4 2 6 4 2 1. 137 1 149 WH5 1. 135 1. 157 1 143 2 4 6 8 1 12 14 16 Kernel2.6 Kernel2.4 Linux Kernel Conference 25-15- Copyright NTT COMWARE 25
Kernel2.4/2.6 の CPU 使用率の比較 CPU 使用率時間推移をグラフ化 Kernel2.4では負荷 ( 接続数 ) を増やしてもスループットは頭打ちでCPUを使い切れない I/Oが先にボトルネックに! 同時接続数 2 同時接続数 4 同時接続数 6 Kernel2.4 (WH3) iowait idleが残る CPU 使用率 (%) 1 9 %idle 8 7 6 %iowait 5 4 %sys 3 2 1 %user 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] Kernel2.6 (WH3) CPU 使用率 (%) 1 9 8 7 6 5 4 3 2 1 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] CPU 使用率 (%) 1 9 8 7 6 5 4 3 2 1 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] Kernel 2.4は負荷を上げても CPUリソースのiowait idleが残る CPU 使用率 (%) 1 9 8 7 6 5 4 3 2 1 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] CPU 使用率 (%) 1 9 8 7 6 5 4 3 2 1 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] CPU 使用率 (%) 1 9 8 7 6 5 4 3 2 1 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] 時間時間時間 -16-
I/O の状態について (Kernel2.4/2.6) サーバのiostat CPU 使用率からはKernel2.4の方がI/O 処理がボトルネックに見えるが実際には余裕の状態 I/O 要求発行が遅延 3 3 25 25 iostat(avgqu-sz) 2 2 Kernel2.4 DB データ格納領域 3 3 25 25 2 2 Kernel2.6 iostat(avgqu-sz) 15 15 1 1 5 I/O 要求が Kernel2.4 の方が少ない 15 15 1 1 5 ブロック数 / 秒 45 4 vmstat(bi, bo) 35 3 25 2 15 1 5 2 4 6 8 時間経過 [sec] bi bi bo bo 2 4 6 8 時間経過 [sec] bi bi bo bo -17- ブロック数 / 秒 45 4 35 3 25 2 15 1 5 WH3 同時接続数 6 vmstat(bi, bo)
I/O の状態について (Kernel2.4/2.6) ストレージの I/O キューの状態 待ちキュー数 [ [ 個 ] ] Kernel2.4 8 6 4 2 読込キューサイズ I/O 要求が Kernel2.4 の方が少ない DB データ格納領域 待ちキュー数 [ [ 個 ] ] Kernel2.6 8 6 4 2 読込キューサイズ 待ちキュー数 [ [ 個 ] ] 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 経過時間 [sec] 経過時間 [sec] 8 8 6 4 2 書込キューサイズ 待ちキュー数 [ [ 個 ] ] 6 4 2 書込キューサイズ 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 経過時間 [sec] 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 経過時間 [sec] WH3 同時接続数 6-18-
- Kernel2.6 の I/O スケジューラ -
Kernel2.6 の I/O スケジューラ Kernel2.6 には I/O スケジューラ (elevator アルゴリズム ) が 4 種類ある elevator 概要適用範囲 cfq (Complete Fair Queuing) deadline I/O 要求を各プロセス毎で時間に対して均一に割り当てる I/O 要求がディスパッチされる期限を設定して応答性を確保する 読み込みを優先する 中 ~ 大規模のマルチプロセッサシステム 複数のLUNとI/Oコントローラ間に均衡な I/O 性能を要求するシステム DBMS リアルタイムシステム用途 noop (No Operation) as (Anticipatory) I/O 要求の単純なマージ作業を行うだけでそのままディスパッチする deadline をベースにしており 遺伝的アルゴリズムを利用したマージや順序入れ替えのパターンを学習する 組み込み向け 高性能なディスクや不規則にアクセス可能なメモリディスク 小規模あるいは遅いディスクサブシステムを持つシステム 例えばファイルサーバ -2-
Kernel2.6 の I/O スケジューラ性能比較 Kernel2.6 の I/O スケジューラ毎の性能比較 (cfq のスループットを 1 とした ) 性能高 12. 1. 8. 1. 1.5 1.1 74. 97.2 試験時間を延長し CPU 使用率が安定した後のスループット 6. 4. 2. 性能低. cfq deadline noop as as' I/O スケジューラ 詳細データ測定対象 WH3 同時接続数 4-21-
I/O スケジューラ毎の CPU 使用率の比較 CPU 使用率時間推移を I/O スケジューラ毎にグラフ化 CPU 使用率 (%) 1 as は測定開始当初は %user が低い = スループットが劣る原因 測定時間を長く取れば 他と同程度の CPU 使用率となり スループットも追いつく 9 8 7 6 5 4 3 2 1 deadline 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] CPU 使用率 (%) 1 9 8 7 6 5 4 3 2 1 cfq %sys %user %sys %user 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] noop 時間時間 Linux Kernel Conference 25-22- Copyright NTT COMWARE 25 CPU 使用率 (%) CPU 使用率 (%) 1 9 8 7 6 5 4 3 2 1 as 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] 1 9 8 7 6 5 4 3 2 1 %iowait %sys %user %sys %user 2 4 6 8 %user %system %iowait %idle 時間経過 [sec]
noop/deadline の DB 性能比較 noop と deadline の性能を測定 性能低 性能高 WH3 6 143 1384 noop deadlineの違いによる性能差はほとんどない理由は... 同時接続数同時接続数 4 2 6 4 2 14847 14773 13411 13585 2 4 6 8 1 12 14 13183 16 13264 13229 13343 11141 1885 WH5 2 4 6 8 1 12 14 16 deadline noop Linux Kernel Conference 25-23- Copyright NTT COMWARE 25
noop アルゴリズム noop スケジューリングの概要 プロセス 1 I/O 要求 プロセス 2 I/O 要求 凡例 書込 I/O 要求 ファイルシステム (ext3) I/O 要求 1 I/O 要求 1 読込 I/O 要求 I/O スケシ ューラ I/O 要求キュー 2 マージ 途中に挿入 I/O 要求 I/O 要求 I/O 要求 I/O 要求 2マージ一番後へ I/O 要求 I/O 要求 3 デバイスへディスパッチ 5 デバイスへディスパッチ デバイス ブロックデバイス独自の I/O 要求キュー I/O 要求 I/O 要求 4 ディスク -24-
deadline アルゴリズム deadline スケジューリングの概要 プロセス 1 I/O 要求 プロセス 2 I/O 要求 凡例 書込 I/O 要求 ファイルシステム (ext3) I/O 要求 1 I/O 要求 1 3 各リストに登録 読込 I/O 要求 I/O スケシ ューラ I/O 要求キュー 2 マージ 途中に挿入 I/O 要求 I/O 要求 I/O 要求 I/O 要求 2マージ一番後へ I/O 要求 I/O 要求 読み出し I/O 要求 FIFO リスト I/O 要求 I/O 要求 書き出し I/O 要求 FIFO リスト I/O 要求 I/O 要求 読み出し I/O 要求ソート二色木 I/O 要求 I/O 要求 書き出し I/O 要求ソート二色木 I/O 要求 I/O 要求 4 デバイスへディスパッチ 6 デバイスへディスパッチ I/O 要求 I/O 要求 I/O 要求 I/O 要求 デバイス ブロックデバイス独自の I/O 要求キュー I/O 要求 I/O 要求 5 ディスク -25-
まとめ 検証結果より Kernel2.4 2.6 の変更に伴い I/O デバイスを効率良く使うことができ 最大 1.6 倍の性能向上が得られた Linux の I/O スケジューラはヘッドが 1 つの単純なディスクを想定しているため I/O 要求をセクタ順に並び替える必要のない高速 インテリジェントなストレージを用いる場合 I/O スケジューラは noop deadline のどちらを選択しても大差はない -26-
IA64 サーバ +Kernel2.6 の DB 性能
目的 Kernel2.6 の DB サーバ性能における CPU スケーラビリティを確認する ハードウェア DBMS は同一条件とし CPU 数のみ 2, 4, 8 に変更 DB サーバ以外の部分でボトルネックにならないように高速なストレージ 複数台の高速クライアントを使用 -28-
試験環境 SQL 発行クライアント DB サーバ ストレージ Ethernet 1Mbps Ethernet 1Mbps Host Bus Adapter FibreChannel 2Gbps L2Switch 2 ノード 1 セット構成 (OS は NUMA サポート ) Fibre Channel Switch 146GB 32 IA32サーバ 2 CPU Intel Xeon3.4GHz 2 Memory 6GB NIC Ethernet 1Mbps Full Duplex Linux OS Kernel 2.4.21-32 (smp) L2Switch Speed Ethernet 1Mbps IA64サーバ CPU Intel Itanium2 1.3GHz 8 (4+4CPU) Memory 18GB (9+9GB) NIC Ethernet 1Mbps Full Duplex HBA 2Gbps Full Duplex Linux OS Kernel 2.6.9-11 (smp) DBMS Setting AsyncI/O & DirectI/O ストレージ HDD 146GB(1rpm) 32 RAID RAID FileSystem ext3 (mount mode=ordered, noatime) -29-
CPU スケーラビリティ DB 規模 WH1/WH3 のスループット 性能高 16 WH1 12 2CPU / 4CPU のスループット比 1.9 倍 性能低 8 4 2CPU 4CPU 4CPU / 8CPU のスループット比 1.7 倍 性能高 16 WH3 12 8 4 4CPU 8CPU 性能低 -3-
CPU リソースの使用状況 CPU 使用率推移 CPU 使用率 (%) CPU 使用率 (%) 1 9 8 7 6 5 4 3 2 2 1 1 CPUリソースを使い切る状態 2 4 6 8 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] %user %system %iowait %idle 時間経過 [sec] 1 9 8 7 6 5 4 3 2 1 2CPU/WH1 4CPU/WH1 %sys %user -31- CPU 使用率 (%) 4CPU/WH3 8CPU/WH3 %sys %user 2 4 6 8 %user %system %iowait %idle 時間経過 [sec] CPU 使用率 (%) 1 9 8 7 6 5 4 3 1 9 8 7 6 5 4 3 2 1 %sys %user %sys %user 2 4 6 8 %user %system %iowait %idle 時間経過 [sec]
まとめ 検証結果より Kernel2.6 を使用することで 8CPU までスケーラビリティを確保できる -32-
考察
なぜ Kernel2.6 は 2.4 と比較して DB 性能が向上したか? Kernel2.4 と比較して Kernel2.6 の DB サーバ性能が優れていた要因を Kernel の観点から探る ボトルネックにならないように高速なストレージを使用したにもかかわらず Kernel2.4 ディストリビューション環境下では I/O 要求発行が遅延してしまったのはなぜか? Kernel2.6 ディストリビューションでは I/O 処理に関して何が改善されたのか? -34-
DBMS の I/O 方式 DBMS の I/O 方式同期 or 非同期 Process Process Process Page Cache I/O File I/O Page Cache FileSystem Direct I/O Device Driver Raw I/O 今回の DBMS の I/O 方式設定 = 非同期 I/O かつ DirectI/O Storage Device -35-
Kernel2.4/2.6 の 非同期 I/O+Direct I/O の実装の違い Kernel2.4/2.6 ディストリビューションの 非同期 I/O と Direct I/O の組み合わせの実装の違い DBMS は Kernel2.4/2.6 で libaio ライブラリの同じ関数を使用 ファイルオープンモード :O_SYNC O_DIRECT システムコール :io_submit(), io_getevents() まったく同じにみえるものの 実は 今回使用した Kernel2.4 ディストリビューションは 非同期 I/O かつ DirectI/O の設定をしても DirectI/O がサポートされていなかった ページキャッシュを使用するため メモリを大量消費 メモリを大量消費すること自体は必ずしも性能劣化につながらない -36-
メモリ使用量の違い Kernel2.4/2.6 ディストリビューションのメモリ使用量の違い 今回使用した Kernel2.4 ディストリビューションは DirectI/O が有効にならず ページキャッシュに使用されるので free が少ない メモリ [KByte] 1 9 8 7 6 5 4 3 2 1 Kernel2.4 free 2 4 6 8 時間経過 [sec] vmstat (free) 1 9 8 7 6 5 4 3 2 1 Kernel2.6 2 4 6 8 時間経過 [sec] 時間 時間 WH3, 同時接続数 6-37-
DBMS の特徴 DBMS の特徴 今回の DBMS は 1 つの巨大なファイルを複数プロセスが共有する仕組み Process Process Process Process DBMS を構成するファイル DB File DB File DB File ファイルサイズが大きく 複数のプロセスが共有する -38-
メタデータを格納していたキャッシュの解放 Kernel2.4 でページキャッシュにメモリが消費される影響 メモリが大量消費され free がなくなる メタデータを格納していたページが解放される メタデータ = 実データのディスク上の位置やファイルサイズ 更新日時等の ファイルに関するデータ -39-
CPU リソースの iowait が発生する要因 (1) メタデータが格納されていたページが解放される影響 1 今回使用した DBMS は 非同期 I/O+DirectI/O 設定時にもサーバプロセスが同期 I/O となる pread システムコールを同時に大量発行していた メタデータがメモリ上にないため メタデータの再読込 I/O 完了待ち合わせでプロセスがブロックされる CPU リソースの %iowait の増加 Process pread 間接ブロックなどのメタデータ Memory 再読込 Storage Device 実 I/O 発生 本事象は raw デバイス場合は発生しない ただし 運用面を考慮すると raw デバイスは選択しづらい -4-
CPU リソースの idle が発生する要因 (1) メタデータが格納されていたページが解放される影響 2 pread システムコールはメタデータアクセス中 セマフォを獲得してファイルをロック 今回の DBMS は同一ファイルを 複数プロセスが共有 他のプロセスが同一ファイルに I/O 要求しても 別のプロセスがメタデータの再読込処理をしている間 ファイルがロックされているため処理が進まない CPU リソースの %idle の増加 Process Process Process pread ファイルをロック pread DB File pread 待ち状態 -41-
CPU リソースの iowait/idle が発生する原因 (2) メタデータが格納されていたページが解放される影響 3 非同期 I/O 処理もメタデータアクセス中 セマフォを獲得してファイルをロック (Kernel2.4/2.6 共通 ) メタデータがメモリ上にないため メタデータの再読込 I/O 完了待ち合わせでプロセスがブロックされる CPU リソースの %iowait の増加 他のプロセスが同一ファイルに I/O 要求しても 別のプロセスがメタデータの再読込処理をしている間 ファイルがロックされているため処理が進まない CPU リソースの %idle の増加 Process io_submit Memory 間接ブロックなどのメタデータ 再読込 実 I/O 発生 Storage Device Process Process Process io_submit ファイルをロック DB File io_submit 待ち状態 -42-
CPU リソースの使用状況 CPU 使用率の違い ( 再掲 ) iowait, idle が残る CPU 使用率 (%) 1 9 8 7 6 5 4 3 2 Kernel2.4 %idle %iowait %sys %user WH3, 同時接続数 6 Kernel2.6 %sys %user 1 1 2 4 6 8 2 4 6 8 %user 時間経過 %system %iowait %idle [sec] %user %system %iowait 時間経過 %idle [sec] CPU 使用率 (%) 1 9 8 7 6 5 4 3 2 時間 時間 -43-
- 参考 -
Kernel2.4 ディストリビューションの非同期 I/O かつ DirectI/O の仕組み (1/2) Kernel2.4 ディストリビューションの非同期 I/O(O_SYNC O_DIRECT) の仕組み 今回の DBMS は主に DB ファイル トランザクションログの書込に非同期 I/O が使用されている 1 Process Process Process 2 Buffer page Buffer page Buffer page Process Process Process Buffer page Buffer page Buffer page io_submit (READ) io_submit (WRITE) io_submit (READ) io_submit (READ) io_submit (WRITE) io_submit (READ) page page 1 読込 2 書込 3 要求 要求 PageCache Storage Device page 読込要求 keventd page page page 1 読込 2 書込 3 要求 要求 PageCache Storage Device 読込要求 I/O 要求 I/O 要求 I/O 要求 -45-
Kernel2.4 ディストリビューションの非同期 I/O かつ DirectI/O の仕組み (2/2) I/O 処理を担当する keventd はシステムに 1 個のみ シリアライズされる 3 Process Process Process 4 Buffer page Buffer page Buffer page Process Process Process Buffer page Buffer page Buffer page io_getevents() io_getevents() io_getevents() io_getevents() io_getevents() io_getevents() wait wait wait page page 1 2 3 読込完了処理 書込完了処理 PageCache Storage Device page 読込完了処理 I/O 完了通知 I/O 完了通知 I/O 完了通知 page page page 1 2 3 読込完了処理 書込完了処理 keventd PageCache I/O 要求 I/O 要求 I/O 要求 Storage Device 読込完了処理 -46-
Kernel2.6 ディストリビューションの非同期 I/O かつ DirectI/O の仕組み (1/2) Kernel2.6 ディストリビューションの非同期 I/O(O_SYNC O_DIRECT) の仕組み 今回の DBMS は主に DB ファイル トランザクションログの書込に非同期 I/O が使用されている 1 Process Process Process 2 Process Process Process Buffer page Buffer page Buffer page Buffer page Buffer page Buffer page io_submit (READ) io_submit (WRITE) io_submit (READ) io_getevents() io_getevents() io_getevents() page page page wait wait wait page page page I/O 要求 I/O 要求 I/O 要求 Storage Device Storage Device -47-
Kernel2.6 ディストリビューションの非同期 I/O かつ DirectI/O の仕組み (2/2) 各プロセスが個別に I/O 処理できる 3 Process Process Process Buffer page Buffer page Buffer page io_getevents() io_getevents() io_getevents() page page page 読込完了処理 書込完了処理 読込完了処理 I/O 完了通知 I/O 完了通知 I/O 完了通知 Storage Device -48-
まとめ
まとめ スケールアップが必要な大規模 DB サーバへの Linux 適用拡大が期待できる Kernel2.6 ディストリビューションを使用することで大規模 DB サーバに Linux が適用できる Kernel2.4 ディストリビューションを使用せざるを得ない場合は 非同期 I/O の設定は行わず DirectI/O のみの設定をする方がよい DirectI/O が有効になっているか確認すべき ページキャッシュを大量に消費する処理は同時に動かさない 非同期 I/O と言えどもメタデータアクセス中はファイルをロックしてしまう 運用性を犠牲にしても性能向上を求めたい場合は raw デバイスを用いることで Kernel2.4 ディストリビューションの問題点を回避できる raw デバイスの場合 メタデータのアクセスは行われない -5-
謝辞 今回発表した内容の実機検証を実施するにあたっては 日本電信電話株式会社 NTT サイバースペース研究所 加藤謹詞様 東出治久様に多大なご協力をいただきました 厚く御礼申し上げます -51-
ご静聴ありがとうございました オープンソースソフトウェア推進部野呂昌哉 e-mail : noro.masaya@nttcom.co.jp URL:http://www.nttcom.co.jp/ Linux は Linus Torvalds の米国およびその他の国における登録商標または商標です その他 記載されている会社名 製品名は 各社の商標または登録商標です -52-