SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Glenn Paulley氏 データベース関連ブログ 翻訳記事(AD)

Linuxに関する問題と対応するべき理由

原文:Our Troubles with Linux and Why You Should Care

  • このエントリーをはてなブックマークに追加

 この前の月曜日、Tim Brechtの発表を聞きました。(原文:Our Troubles with Linux and Why You Should Care、2011/07/05投稿)

  • このエントリーをはてなブックマークに追加

 本稿はデータベースソフトウェア「SQL Anywhere」およびデータベース全般に関する英語ドキュメントを翻訳する形で提供しています。図など、部分的に英語のままになっていますが、製品のSQL Anywhere自体は完全に日本語化されていますのでご安心ください。
※編集部注:掲載しているブログ内容は執筆時点での情報のため、現在とは異なる場合があります。

 Tim Brechtは、ウォータールー大学のSchool of Computer Scienceに所属しています。発表された論文は「Linuxに関する問題と対応するべき理由(Our Troubles with Linux and Why You Should Care)」(PDF)というものです。この論文[1]は、Tim、Peter Buhr、およびAshif Harjiの共同執筆によるもので、上海で開催される第2回ACM SIGOPSアジア太平洋システムワークショップで2011年7月11日(月)に発表される予定です。

 Timの主要な関心事はコンピューターシステムのパフォーマンスであり、この発表では、Timとウォータールー大学の彼の研究グループがさまざまなバージョンのLinuxを使用していて遭遇した問題について語られました。つまり、この論文は、彼のチームがコンピューティングプラットフォームとしてのLinuxに抱いた欲求不満から生み出されたものです。驚くには値しないことですが、彼のチームの経験は、私たちがLinuxシステムを使っていて経験したことと完全に一致します。次に、Timの講演中に私が書き留めたメモを示します。

  • 論文の概要:

    Ashif Harjiは、博士論文のための実証テストの最中に、パフォーマンスに重大な影響を持つLinuxカーネルのバグを3つ発見した。この発見のせいで、以前の実験をすっかりやり直すことになり、かなりの労力が無駄になった。というのも、それまでに生成したWebサービスパフォーマンスの指標が無意味になってしまったからだ。

  • 対応するべき理由:
    • パフォーマンスに関わるバグはすべてのオペレーティングシステムに存在するが、Linuxの場合にはこの点が特に顕著であるように思われる。Linuxカーネルのパフォーマンスの退化をモニターするプロジェクトすら生まれている。
    • Linuxコミュニティでは、「最新の」Linuxカーネルが最善であるという認識がある。しかし、実証テストは、その想定が完全に誤りであることを示している。今回見つかったLinuxのパフォーマンスに関わるバグは重大なものであり、深刻なパフォーマンスの劣化と再現性のない事象の両方が起こっていた。これらのバグの一部は、3年もしくはそれ以上にわたる複数のバージョンのカーネルに存在し続けてきた。あくまでも推測だが、他のオープンソースプロジェクトでも、パフォーマンス退行テストが十分でなければ、パフォーマンスの退行が発生しているかもしれない。
  • 研究プラットフォームとしてのLinuxには、重要な長所がいくつかある。たとえば、Linuxはオープンソースであり、実環境で使用されている。またカーネルの開発サイクルが迅速なので、新しいハードウェアプラットフォームに対応する最新の状態に保たれている。ただし、Linuxには短所もある。つまり、Linuxは大規模で複雑であり、適切に構成して調節することが困難である。また、プロジェクトのカーネル開発サイクルが迅速であるために、バグやパフォーマンスの退行が紛れ込む可能性がある。

  • Ashifらが発見したカーネルのバグ:
    • 小さなファイルの排除 ― 2005年3月2日から2007年8月4日まで存在。Linuxカーネルは、LRUをバイパスすることによって、小さなファイルをファイルシステムキャッシュから常に排除していた。
    • 先読みの無効化 ― 2005年6月17日から2008年2月26日まで存在。sendfile()関数を使用した場合に、入力ファイルの先読みが失敗していた(コーディングエラーのため)。
    • 不規則なページの排除 ― 2007年10月9日から2010年12月9日まで存在(後者の日付は最後にテストした日付なので、現在も問題が存在している可能性あり)。sendfile()関数が、ファイルのページに対してアクセス中とマークできない。したがって、カーネルはページをランダムに排除し、結果的にパフォーマンスがランダムで予測不可能な状態に陥っていた。
  • これらのバグの影響:
    • 公開された論文に問題があることは疑問の余地がない。研究者はパフォーマンスの変化の隠された原因を突き止める必要がある。さもないと、単にカーネルのバグが存在することを確認するだけになってしまう。
    • より新しいカーネルへのアップグレードに大きな影響がある。一般的には新しいほうが良いものだと信じられているが、これは誤解である。ときには古いバグが修正されずに、新しいバグが現れることもある。
    • 研究者としてはLinuxカーネルの問題をデバッグする必要があるが、これは困難で時間がかかり、結局のところはそれほど利益をもたらさないだろう。
  • 研究者が行うべきこと:
    • 十分に考えつくされたパフォーマンス退行テストを使用してアプリケーションのパフォーマンスを検証する。
    • カーネルをアップグレードするごとに結果を再チェックする。
    • 実験結果の再現可能性をチェックする(科学的方法を採用するときのように)。
    • 直観力に訴え、「この結果は自分の予測を超えているだろうか」と自問する。
    • 適切な実験環境を確保する(たとえば、アドレス空間のランダム化をオフにする)。

 Timは、講演後の質疑応答の時間に、こうした問題の部分的な影響としてLinuxフォークの数が急増しているように思われると指摘しました。Linuxの状況が今後数年間でどうなるかは、引き続き注目されるでしょう。

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
Glenn Paulley氏 データベース関連ブログ 翻訳記事連載記事一覧

もっと読む

この記事の著者

Glenn Paulley(Glenn Paulley)

カナダ オンタリオ州 ウォータールー R&DセンターにてSQL Anywhere 開発における Director of Engineering としてクエリ・オプティマイザなどの開発をリードしている。・IvanAnywhere

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/6086 2011/09/01 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング