Comments
Description
Transcript
修 士 論 文 概 要 書
修 士 論 文 概 要 書 2010 年 2 月提出 専攻名 情報理工学 氏名 大野 有輝 研究指導名 分散システム研究 学籍番号 5108B018 – 2 研 究 中島 達夫 CD 印 教 員 マルチコア環境におけるプロセス動作予測によるリソース配分最適化 題 目 1 指 導 2.1 データ収集 序論 近年，シングルコア CPU によるコンピュータの処理能力 まず，アプリケーションの動作予測に必要なデータの 向上が限界を迎えつつあり，CPU のマルチコア化によって 収集を行う．特定の処理の開始時および終了時にアプリ 処理能力を向上させる手法が一般的になっている．マルチ ケーションから SPLiT ライブラリ（SPLiT lib）のライブ コア環境では，リソースの競合による処理性能低下が発生 ラリ関数を呼び出すことで，その間の CPU サイクル数と するため，マルチコアの性能を活かすためには，シングル キャッシュミス回数を計測する．計測には，プロセッサ コアとは異なるリソース配分手法が必要である．しかし， のパフォーマンス計測用の機能である PMU（Performance 現在のオペレーティングシステムのプロセススケジューラ Monitoring Unit）を利用する．また，SPLiT lib の提供する の多くは，主に CPU の使用時間だけを見る，従来のシン 関数は，split init，split start，split end，split set，split get グルコアでのスケジューリング手法をそのまま流用して の 5 つである．アプリケーション初期化時に split init 関 いる． 数を呼び出すことで，PMU の初期化やデータ格納のた 本研究の目的は，マルチコア環境でのコンピュータの処 めのメモリ確保など，SPLiT システムの初期化が行われ 理能力向上手法の提案である．特に，プロセスの動作を解 る．次に，計測を行う処理の開始時と終了時に，それぞれ 析・予測することでリソース配分を最適化し，処理能力を split start 関数，split end 関数を呼び出す．各処理には処 向上させる手法の提案を目的としている． 理 ID が与えられ，split start 関数の引数に，関連する処理 の処理 ID を渡すことで，リソース配分の際のヒントとす 2 る．split end 関数呼び出しによる計測終了時に，共有メモ 設計 リへと計測データが記録される．データ収集や解析の際の 本研究では，マルチコア環境におけるリソース配分最適 化のシステムとして，SPLiT（Scalable Performance Library 設定値を参照，変更する場合は，split get 関数，split set 関 数を呼ぶ． Tool）を提案する．SPLiT は，アプリケーション内の処理 毎の動作を予測し，その結果から各処理を特定のコアで実 行させるようコア割当を行うことで，リソース配分を最適 化する．プログラマはライブラリ関数によって，処理に関 するヒントを SPLiT に提供する．SPLiT は，カーネルで 取得したハードウェアの情報と，プログラマからの情報を 利用して，各処理へのコア割当を行う． SPLiT は，データ収集，動作予測，リソース配分の 3 つ の処理によって，リソース配分最適化を実現する．リソー ス配分最適化の処理の流れを図 1 に示す． App App ... App Analyzer SPLiT lib PMU Support Kernel PMU Hardware Scheduler 1. データ収集 2. 動作予測 3. リソース配分 2.2 動作予測 Analyzer は，一定時間毎に計測データを収集，各処理の 動作予測を行い，予測結果をもとに各処理へのコア割当を 決定する．データ収集時，CPU サイクル数とキャッシュ ミス回数は，指数移動平均値として記録される．Analyzer は，次に同じ処理が実行される際，その処理が記録され た平均値と同様に振る舞うと予測する．また，2.1 節で述 べたように，関連する処理の情報を与えられた場合，関 連する処理はデータの一部を共有すると予測し，コア割 当のヒントとする．この予測結果から，システム全体の キャッシュの効率性を上げると共に，CPU 負荷が均一に 分散するよう，コアの割当を決定する．まず，各処理での キャッシュミス回数によって，キャッシュを有効利用する 処理（clean code）と有効利用できない処理（dirty code） 図1 リソース配分最適化の処理の流れ に分ける．次に，clean code と dirty code の処理にかかる CPU サイクル数の合計値の比率に合わせ，CPU コアを clean code 用（clean core）と dirty code 用（dirty core）の クセスパターンのシナリオを作成できる．本研究では，ア 2 種類に分ける．dirty code を dirty core 上で実行するこ クセス数が多い場合と，サーバ・クライアント間で送受信さ とで，clean code のキャッシュ利用を阻害することを防ぐ． れるデータ量が多い場合の 2 種類のシナリオについて応答 また，clean code は，さらに細かくコア割当を行う．各処 時間の計測を行った．ここで，応答時間とは，計測開始後， 理同士の関連性を考慮し，関連性の高いものはキャッシュ クライアントがシナリオに従って HTTP リクエストを送信 を共有するコア同士で実行させる．具体的には，同じ処理， し，全てのリクエストに対する応答を受信完了した時点ま 同じアプリケーション，関連するアプリケーション，関連 での時間を意味する．SPLiT 適用前の Apache，MySQL に する処理の順に優先して，各処理へのコア割当を決定する． よるシステムを「通常システム」，SPLiT 適用後のシステ ムを「SPLiT システム」とすると，アクセス数が多い場合 2.3 リソース配分 Analyzer は，コア割当が決定すると，共有メモリに割当 コアを指定するデータを書き込む．各アプリケーションで の split start 関数呼び出し時に，共有メモリ上のコア割当 データを参照し，実行中のスレッドを割り当てられたコア に移動する．これにより，それぞれの処理を特定のコアで 実行することができる． 実装 3 の応答時間は，通常システムでは 21,788[ms]，SPLiT シス テムでは 20,759[ms]（対通常システム 4.7% 短縮）となっ た．また，データ量が多い場合の応答時間は，通常システ ムでは 152,426[ms]，SPLiT システムでは 112,738[ms]（対 通常システム 26.0% 短縮）となった．この結果より，最適 化によって，いずれのシナリオでも応答時間が短縮し，最 大で 26% の応答時間短縮を達成したことから，SPLiT シ ステムが性能向上に有用であることがわかる． 4.2 コード変更量 本 研 究 で は ，カ ー ネ ル の PMU サ ポ ー ト と し て アプリケーションに SPLiT を適用する際のコード変更 Perfmon3[1] を用い，パフォーマンスモニタリング用フ 量は，Apache の場合，コード埋め込みによる実装では 10 レームワークである mBrace[2] を SPLiT lib のベースと 行，モジュール化による実装では 73 行，MySQL サーバ して，Linux 2.6.30 上に SPLiT システムの実装を行った． へのコード埋め込みによる実装では 54 行だった．また， また，開発環境のプロセッサとして Intel Core i7（以下， Apache から MySQL への SQL クエリ送信の際に，処理 ID Core i7）を用いた．Core i7 は，1 つの CPU の中に 4 つの を共に送信させるための MySQL ライブラリの変更が 162 コアを搭載し，さらに各コアが 2 つの論理プロセッサを 行だった． 持っている．これにより，8 つの処理を同時に行うことが できる．キャッシュは 3 段階あり，L1 キャッシュと L2 キャッシュはコア毎に持ち，L3 キャッシュは全コアで共 有する階層構造となっている． 5 結論 本研究では，プロセスの動作予測によりリソース配分を リソース配分を最適化する対象として，ウェブサーバ 最適化する手法の提案を行った．評価の結果，ウェブアプ の Apache とデータベースサーバの MySQL を採用した． リケーションの性能が最大 26% 向上し，提案手法が有用で Apache では，処理を識別するための値（code key）として， あることがわかった．将来課題として，予測精度の向上， リクエストされたページの URL を用いている．Apache の 他のハードウェアおよびソフトウェアへの対応などが挙げ 処理の計測開始は，HTTP リクエストのパース完了時，計 られる． 測終了はクライアントへの応答完了時とした．MySQL で は，code key として，クエリの種類（選択，追加，更新な 参考文献 ど）と，対象となるテーブルの組を用いる．MySQL の処 理の計測開始は，SQL クエリのパース開始時，計測終了は [1] Perfmon project. http://perfmon2.sourceforge.net/. クライアントへの応答完了時とした． [2] Andrej van der Zee, Alexandre Courbot, and Tatsuo Nakajima. 評価と考察 4 4.1 応答時間 オークションサイトプロトタイプである RUBiS と，パ フォーマンス計測ツールである JMeter を用いて，HTTP リ クエストに対する応答時間の計測を行った．JMeter は，ア mbrace: action-based performance moni- toring of multi-tier web applications. In WDDM ’09: Proceedings of the Third Workshop on Dependable Distributed Data Management, pages 29–32, 2009.