インプレス ビジネスメディア

第8回：Linuxの性能評価 (3/4)

TOP＞比較データ＞ CPUビジー型の考察
OSS評価手法
オープンソースソフトウェアの性能・信頼性評価手法

第８回：Linuxの性能評価
 著者：ミラクル・リナックス  吉岡 弘隆   2005/7/5
前のページ  1  2  3   4  次のページ
CPUビジー型の考察

   アドレス0xc0160de8の命令が最も頻度が高い結果となった。ソースコードとの突き合わせを行った結果、この処理はdo_generic_file_write()の中で呼ばれている__copy_from_user()であり、__copy_user_zeroing()にマクロ展開される。
ssize_t
do_generic_file_write(struct file *file,const char *buf,size_t count, loff_t *ppos)
{
        （中略）

        status = mapping->a_ops->prepare_write(file, page, offset, offset+bytes);
        if (status)
                goto sync_failure;
        page_fault = __copy_from_user(kaddr+offset, buf, bytes); ←ここ
        flush_dcache_page(page);
        status = mapping->a_ops->commit_write(file, page, offset, offset+bytes);

        （中略）
}
#define __copy_user_zeroing(to,from,size)            \
do {            \
        int __d0, __d1;            \
        __asm__ __volatile__(            \
                 "0:    rep; movsl\n" ←ここ             \
                 "      movl %3,%0\n"            \
                 "1:    rep; movsb\n"            \
                 （後略）      

   __copy_from_user()は、ファイルに書き込もうとしているユーザ空間のデータをカーネル空間のページキャッシュに書き込む（コピーする）処理である。

   このコピーはI/Oの書き込み処理の中でも最も中心といえる処理であり、これがプロファイリングのトップにあるということは書き込み処理に効率よくCPUが費やされていることを表している。厳密な意味では、この__copy_from_user()が呼ばれる回数自体に無駄がないかどうかなど、さらなる追及の余地があるが今回の評価ではそこまでは及ばなかった。

   OProfileの実行結果より、CPUビジー型の場合は容易に実行ボトルネックを発見できることがわかる。
CPUアイドル型（I/Oビジー型）

   CPUアイドル型については、パターンID 1を取り上げる。

   プロファイリング結果より、CPUはhlt命令による休止状態にあることが多かった。これは、I/Oリクエストが処理されるスピードよりも、CPUを使ったデータコピー処理のスピードのほうが速かったため、I/Oリクエストが累積してCPU側が待たされていた状態にあったと考えられる（I/Oがビジーであると言える）。

   そこで、実際にどれだけのI/Oリクエストの蓄積があったのかをLKSTによって調査した。マスクセットとしてbufferとblkqueueを使用して測定し、CPUアイドル型（I/Oビジー型）パターンとCPUビジー型パターンとの比較を行った。

   頻度を回数から割合に変換してグラフ化すると図3のようになる。CPUアイドル（I/Oビジー）であるパターン1はCPUビジーであるパターン9に比べて所要時間のオーダが1近く長いことがわかる。それだけI/Oリクエストの処理が相対的に遅かったことが見てとれる。

I/Oリクエスト到着からI/O完了までの時間（buffer）
図3：I/Oリクエスト到着からI/O完了までの時間（buffer）
   次に、I/O要求が来た時のリクエストキューの長さ（blkqueue）についても比較する。平均値についてグラフ化すると図4のようになる。

   パターン1（CPUアイドル型）はディスクが1台のI/O、パターン9（CPUビジー型）はディスクが4台のI/Oである。パターン1の平均値が非常に高く、常にI/Oリクエストがほぼ上限（512）近くまで溜まっていたことが見てとれる。これはデバイスドライバのルーチンによるI/Oリクエストの処理が飽和状態にあったことを表しており、一般的にデバイス側の処理限界に突き当たっていることが多い。

I/O要求が来た時のリクエストキューの長さ（blkqueue）
図4：I/O要求が来た時のリクエストキューの長さ（blkqueue）
   この比較は、ディスクコントローラの条件が同一で、ディスクドライブの数が異なるケース同士の比較であるため、ディスクドライブの転送速度の上限に達していると推定される。このように、OProfileとLKSTを組み合わせることによってI/Oの挙動の差を明確化することが可能となる。
ロック競合型

   誌面の関係で詳細は省略するが、LKSTを利用することによって、ロックを待つ場所（busywait）とロックの時間（spinlock）を測定することができた。その分析結果より性能上問題となるグローバルなカーネルロックを発見した。

   グローバルなカーネルロックは、これまでにカーネルの改良によってその数を減らしてきたが、MIRACLE LINUX V3.0にもまだある程度残っている。カーネル2.6.10と比較すると、さらにいくつかのグローバルロックが削除されている。これらについてMIRACLE LINUXでも削除を検討することが可能と考えられるため、今後の課題のひとつとしたい。
関数 MIRACLE LINUX V3.0での位置 2.6.10カーネルでの状態
sys_ioctl() fs/ioctl.c 残留
sync_old_buffers() fs/buffer.c sync_old_buffers()がない
permission() fs/namei.c 削除
schedule() kernel/sched.c 残留
ext3_delete_inode() fs/ext3/inode.c 削除

表7：グローバルなカーネルロック
前のページ  1  2  3   4  次のページ

ミラクル・リナックス株式会社 吉岡 弘隆
 著者プロフィール
ミラクル・リナックス株式会社  吉岡 弘隆
2000年6月ミラクル・リナックス(株)設立、それ以前は日本オラクルにてOracleデータベースのサポートを担当していた。オープンソースとの出会いは、1998年米国Oracle出向時にNetscapeのソースコード公開がきっかけ。
ミラクル・リナックス株式会社 取締役
日本OSS推進フォーラム ステアリングコミッティ委員
OSDL Japan アドバイザリボードメンバー
INDEX
第8回：Linuxの性能評価
  はじめに
  ベンチマーク結果と分類
CPUビジー型の考察
  評価手法のまとめ
オープンソースソフトウェアの性能・信頼性評価手法
第1回 開発基盤ワーキンググループインタビュー
第2回 Java AP層の評価 〜 概要とカーネル比較
第3回 JBossと商用APサーバの比較
第4回 アプリケーション・プログラムの動作解析機能の開発とそれを用いた解析
第5回 DBT-1によるMaxDBの評価
第6回 PostgreSQLは使えるのか？ 〜 あなたの環境での性能特性を調べる
第7回 大規模データベースにおけるPostgreSQLの性能評価
第8回 Linuxの性能評価
第9回 LinuxのI/O信頼性・性能評価

人気記事トップ10

外部から「WSL1/2」のサーバーにネットワークアクセスをしてみよう AI搭載のスマートグラス「Even G2」が国内発売ほか 日本初開催の「KubeCon＋CloudNativeCon Japan 2025」、ボランティア視点で運営の裏側をちょっとのぞいてみた話 新たな自動化で熱視線！ AIエージェントの「推論能力」を支える2つのコンポーネントとは？ オープンソースの電子書籍管理ソフト「Calibre 8.15」リリース メガネ型オーディオが特別セール実施中、Metaが新モデル群を公開ほか 「Rocky Linux 10.1」リリース IoTに生成AIを掛け合わせる「AI-driven IoT」で現場のIoTデータ活用を加速 米Red Hat、「Red Hat Enterprise Linux 9.7」を発表 AI時代のエンジニアに求められるものとは？「生き残る」ためのキャリア戦略
AI搭載のスマートグラス「Even G2」が国内発売ほか 外部から「WSL1/2」のサーバーにネットワークアクセスをしてみよう 新たな自動化で熱視線！ AIエージェントの「推論能力」を支える2つのコンポーネントとは？ Linux Foundation Education、無料オンラインコース「Linuxカーネル開発 初心者向けガイド」の提供を開始 【ビジョンなき導入の末路】データが暴く日本企業の課題と次の一手 【序論】なぜ今、監視は「再発見」されるのか 「AIを導く」のはオープンソース ー実証に基づいた明確な解を示したレポート「ソブリンAIの現状」を公開 Linuxカーネル「Linux 6.18」リリース メガネ型オーディオが特別セール実施中、Metaが新モデル群を公開ほか 日本初開催の「KubeCon＋CloudNativeCon Japan 2025」、ボランティア視点で運営の裏側をちょっとのぞいてみた話
AI搭載のスマートグラス「Even G2」が国内発売ほか 外部から「WSL1/2」のサーバーにネットワークアクセスをしてみよう 新たな自動化で熱視線！ AIエージェントの「推論能力」を支える2つのコンポーネントとは？ Linux Foundation Education、無料オンラインコース「Linuxカーネル開発 初心者向けガイド」の提供を開始 【ビジョンなき導入の末路】データが暴く日本企業の課題と次の一手 アイレット、KDDIの属人化問題を生成AIアシスタントの精度を高め解消へ 世界中の「欲しい」を10秒で叶える ─株式会社SAZOが描く越境ECの新時代 「Terraform」でコードをモジュール化して、環境を分離することで適切に管理しよう IoTに生成AIを掛け合わせる「AI-driven IoT」で現場のIoTデータ活用を加速 【序論】なぜ今、監視は「再発見」されるのか
人気記事ランキングをもっと見る

新着記事

位置情報の基本中の基本となる「点」の情報の扱い方を学ぼう 12月5日 6:30 Kubernetesコミュニティのグループ構成と活動領域の見つけ方 12月5日 6:30 AIには別の顔を見せるWebサイト: エージェントを狙う間接プロンプトインジェクション 12月4日 6:30 【CNDW2025】なぜCloudNative DevSecOpsを推進するのか？ 米軍の事例が示す「速度と安全性」の必然 12月4日 6:00 【序論】なぜ今、監視は「再発見」されるのか 12月3日 6:30

企画広告も役立つ情報バッチリ！ Sponsored

新たな自動化で熱視線！ AIエージェントの「推論能力」を支える2つのコンポーネントとは？ 11月28日 6:30 IoTに生成AIを掛け合わせる「AI-driven IoT」で現場のIoTデータ活用を加速 11月26日 6:30 アイレット、KDDIの属人化問題を生成AIアシスタントの精度を高め解消へ 11月21日 6:30 「Grafana Cloud」の先進的ユーザーであるグリーが10年をかけて到達した「オブザーバービリティ」とは 5月15日 6:30 Grafana Labs CTOのTom Wilkie氏インタビュー。スクラップアンドビルドから産まれた「トラブルシューティングの民主化」とは 4月21日 6:30 API管理をより簡単にする「Kong Konnect」が解決する課題とその主要機能 3月5日 5:30 目指すはプロセス連結によるサイロ化の打破! ガバナンス強化にも寄与する自動化プラットフォームとは 1月15日 6:30 AIで激変する「DevOpsの未来」と「IT組織のリーダーが備えるべきこと」とは 2024年11月26日 8:53 仕様書からテストケースを自動生成! Autify Genesisが変えるソフトウェアテストの未来 2024年11月21日 8:04 LLMを自由に切り替え! Kongが提案するAIゲートウェイ活用法 2024年11月15日 6:12