Linuxカーネルの性能と拡張性の改善

企業内でのLinux利用を促進

Linuxの性能を改善するための第一歩は、性能を数量化することです。しかし、Linuxやそれと同様のシステムの性能を正確に数量化するには、どうすればよいのでしょうか。本稿では、IBM Linuxテクノロジー・センターのスタッフがそれぞれの専門的な知識を出し合い、昨年暮れにLinuxカーネル2.4と2.5で何種類ものベンチマークを実行したときのことを紹介します。

Sandra JohnsonIBM Linux Technology Center

Sandra K. Johnsonは、テキサス州オースチンにあるIBM Linuxテクノロジー・センター、Linux性能のマネージャーです。彼女には、メモリー・システム、キャッシュ一貫性プロトコル、パラレルI/O、パラレル・ファイルシステム、Javaサーバーの性能、アプリケーション・サーバー/データベースの統合、およびLinuxの性能に関する設計および性能評価など広範な分野で14年以上の経験があります。IBM Academy of Technologyのメンバーでもあります。



William Hartner (bhartner@us.ibm.com)IBM Linux Technology Center

Bill Hartnerは、IBM Linuxテクノロジー・センター、性能チームの技術主任です。Billは、オペレーティング・システムの性能の分野に10年、Linuxの性能の分野に約4年従事してきています。Billのメール・アドレスはbhartner@us.ibm.com です。



William Brantley (Bill.Brantley@amd.com)Advanced Micro Devices

Bill Brantleyは、1985年以来UNIXの性能に関係する仕事に従事しています。ニューヨーク州Yorktown HeightsにあるIBM T. J. Watson研究センターに勤務した後、テキサス州オースチンのIBMに勤務しています。この3年間は、もっぱらLinuxの性能に関する研究に従事しています。現在は、Advanced Micro Devicesでx86-64 Linuxの性能に関する研究を行っています。彼のメール・アドレスはBill.Brantley@amd.com です。



2001年 3月 01日

Linuxオペレーティング・システムは、現時点で最も成功を収めたオープン・ソース・プロジェクトの1つです。Linuxは、Webサーバーのオペレーティング・システムとして高い信頼性を示しており、この市場で大きなシェアを占めています。Webサーバーには、通常、小規模あるいは中規模のシステムが使われ、搭載される対称マルチプロセッサー (SMP) も4ウェイまでです。それに対して、企業レベルのシステムには、プロセッサー数やI/O構成の点でもっと規模が大きく、メモリーやバンド幅も格段に高いものが求められるなど、もっと複雑な仕様のものが使われます。Linuxが企業仕様に対応し、SMP市場で生き残っていくためには、SMPの拡張性、ディスクやネットワークI/Oの性能、スケジューラー、仮想メモリー・マネージャーを、商用のUNIXシステムと比肩できるほどに改善する必要があります。

こうしたLinuxカーネルの懸案に取り組むために8ウェイ以上の拡張性を備えた企業クラスのマシンの開発を目指すオープン・ソース・プロジェクトに、Linux Scalability Effort (LSE) (リンク先は、参考文献参照) があります。

IBM Linuxテクノロジー・センター (LTC) のLinux性能チーム (リンク先については参考文献参照) も、このLSEの活動に積極的に参加しています。また、このチームは、とくにSMPの拡張性を重点的にLinuxカーネルの性能を改善することで、Linuxをもっと優れたものにすることを目標としています。

本稿では、Linuxカーネルの性能と拡張性を測定、分析、改善するためにこのチームが採った戦略と手法を、プラットフォームには係わらない問題に焦点を絞って紹介します。この作業を進めるにあたっては、一連のベンチマークが使用されます。これらのベンチマークでは、Webサーバー機能、データベース、ファイル・サーバー機能など、さまざまな種類の作業負荷が測定対象となります。また、各ベンチマークによって、カーネルのどのコンポーネントに負荷がかけられるのか (たとえば、ディスクI/Oサブシステム) についても説明を加えます。

分析方法

最初に、われわれがSMPの拡張性に関するLinuxの性能を数量化するときに使用した分析方法を説明しておきます。お望みならば、この説明を飛ばして、ベンチマークの結果に進んでいただいてもけっこうです。

Linuxの性能と拡張性を改善するためのわれわれの方策には次のものが含まれています。すなわち、業界ベンチマークとコンポーネント・レベルのベンチマークをいろいろと実行すること、適当なハードウェアとソフトウェアを選択すること、ベンチマークの実行ルールを決めること、性能と拡張性の目標を定めること、そして、性能と拡張性を測定、分析、改善するということです。ここでは、これらの手順について詳しく説明していきます。

性能 とは、ユニプロセッサー (UP) またはSMPでの生のスループットのことです。ここでは、SMPの拡張性 (CPUの数) と資源の拡張性 (ネットワーク接続の数など) とは、区別されます。

ハードウェアとソフトウェア

今回の大半の作業で使用されるアーキテクチャーはIA-32 (すなわちx86) で、1?8個のプロセッサーが使用されます。われわれは、非均一メモリー・アクセス (NUMA) のIA-32アーキテクチャーおよびNUMA IA-64アーキテクチャーが、今後使用される場合に生じる問題についても検討します。ハードウェアは、通常、ベンチマークを選択したり、ベンチマークが対象とする作業負荷を選択するのに合わせて選択されます。ソフトウェアは、IBMのLinuxミドルウェア戦略やオープン・ソース・ミドルウェアに合わせて選択されます。たとえば、以下のような選択を行います。

  • データベース
    われわれは、database queryベンチマークを使用し、ハードウェアは8ウェイSMPシステムで、大規模なディスク構成を使用します。データベース・ソフトウェアにはIBM DB2 for Linuxを使用し、SCSIコントローラーには、IBM ServeRAID 4Hを使用します。データベースは、8ウェイSMP用に設定されます。
  • SMBファイル・サーバー機能
    ベンチマークにはNetBenchを使用し、ハードウェアは4ウェイSMPシステムとし、48クライアントがSMPサーバーにアクセスするものとします。ミドルウェアはSamba (オープン・ソース) です。SMBファイル・サーバー機能は4ウェイSMP用に設定されます。
  • Webサーバー機能
    ベンチマークにはSPECweb99を使用し、ハードウェアは8ウェイで、大規模なメモリー構成にし、クライアント数は32とします。このベンチマーク作業は、研究のためだけに行われたもので、実行ルールに則してはいません (これについては、ベンチマーク以下の節を参照してください)。WebサーバーはApacheで、その上にIBM HTTP Serverが構築されます。拡張性を調べるために8ウェイを選択しました。Apacheを選択したのは、次世代のposixスレッド (NGPT) の測定と分析を可能にしてくれるからです (NGPTについては、参考文献参照)。Apacheがオープン・ソースであり、最も一般的なWebサーバーであるからということもあります。
  • Linuxカーネルのバージョン
    今回は、ベンチマークに合わせてLinuxカーネルのkernel.orgのレベル (2.2.x、2.4.x、および2.5.x) を使用しました。これについては、ベンチマークのところで詳しく説明します。Linuxディストリビューションには、管理を簡単化するために、Red Hat 7.1または7.2を選択しました。われわれの研究対象は、カーネルの性能であり、ディストリビューションの性能ではありません。われわれは、Red Hatのカーネルをkernel.orgのものに置き換え、われわれのところで評価済みのパッチも当てました。

実行ルール

ベンチマークの進め方を計画する際、ベンチマークをどのように組み立て、設定、実行し、結果をどのように解釈すべきかについての詳細を規定する実行ルールを作成しました。実行ルールは、いろいろな目的で利用されます。

  • ベンチマークの性能および拡張性を測定するのに使用される測定基準を定義する (メッセージ / 秒など)。
  • ベンチマークの結果が作業負荷やカーネル・コンポーネントの性能や拡張性の測定に適したものとなっているかどうかを確認する。
  • 人が替わっても同じ性能テストを実行できるように一連の手続きを文書化する。
  • テスト対象システム (SUT: System Under Test) の性能と拡張性を分析し、どこにボトルネックが存在するのかを決定するために収集されるデータ・セットを定義する。

目標の設定

ベンチマークの性能および拡張性の目標は、個々のSUT (ハードウェアとソフトウェアの構成) との関係で決まってきます。性能および拡張性の目標を設定するには、以下のものが必要となります。

  • 基準となるカーネルのバージョンでベンチマークの性能を決定するための基準となる測定値。基準となる拡張性は、それを基に計算されます。
  • 性能の向上が期待できる方向を決定するための最初の性能分析 (たとえば、スケジューラーの使用率が非常に高いことをプロファイルが示していれば、O(1) のスケジューラーを試すべきであることを意味しているかもしれません)。
  • 基準となる結果と公表されている同様の結果との比較 (たとえば、spec.orgが公表している同様の8ウェイ・システムでの同じWebサーバーについてのSPECweb99を探してくる)。

外部に公表されている結果がない場合には、社内の結果を使用してみます。また、他のオペレーティング・システムとの比較も行ってみます。対照データとわれわれの基準データとを基に、UPマシンおよびSMPマシンの性能目標を選択します。

最後に、アプリケーションに変更があった場合、目標は予測できるかもしれません。たとえば、アプリケーションの非同期I/Oの処理が効率的でないことがわかっている場合、I/Oの処理方法が変更されるものとして、性能の目標を公表できるかもしれません。

調整、測定、分析

測定を始める前に、ハードウェアとソフトウェアの両方の構成を調整します。調整は、調整と測定の繰り返しサイクルとなります。このサイクルには、CPUの利用率やメモリーの使用量などのシステムのコンポーネントを測定したり、場合によってはシステム・ハードウェアのパラメーターやシステム資源のパラメーターやミドルウェアのパラメーターを調整することが含まれます。調整は、性能分析を行うときの第1歩として行われることの1つです。調整を行わないと、結果が誤って評価されることになるかもしれません。つまり、その場合の結果は、カーネルの限界を示しているのではなく、何か別の問題を示しているのかもしれません。

性能も拡張性も、定義した性能の測定基準に基づいて測定されるようにするために、ベンチマークは、実行ルールにしたがって実行します。マシンのSMP拡張性を計算する際、われわれは、この測定基準をUPカーネルの性能に基づいて計算するのか、それともプロセッサー数が1の (1Pの) SMPカーネルの性能に基づいて計算するのかを選択する必要がありました。われわれは、SMPカーネルの性能改善をより正確に反映させるために、SMP拡張性をUPの測定値を使って計算することにしました。

基準となる測定は、予め決定しておいたバージョンのLinuxカーネルを使用して行います。ほとんどのベンチマークで、UPとSMPの両方の基準測定を行います。いくつかのベンチマークでは、UPの性能データの収集に時間がかかりすぎるため、8ウェイの性能だけを測定します。他のほとんどのベンチマークでは、特定の時間内に実行された作業量が測定されます。この場合、UPでの測定が8ウェイでの測定より長くかかることはありません。

SUT (テスト対象システム) の性能と拡張性を分析するときの第1段階は、テストされたベンチマークと作業負荷を理解することです。最初の性能分析を、調整されたシステムに対して行います。分析によって、調整用のパラメーターに変更を加えなければならないことが判明することもあります。

SUTの性能と拡張性を分析するには、一群の性能ツールが必要です。われわれは、可能なかぎり、オープン・ソース・コミュニティー (OSC) のツールを使用するという戦略を採りました。そうすれば、分析データをOSCに公表し、性能や拡張性のボトルネックを明らかにすることができることになります。他方、OSCの人々も、同じツールを使ってわれわれの結果を再現したり、同じツールを別のアプリケーションで試してみることで、われわれの結果を理解できるようになります。特別な性能ツールが開発され、特定の性能的なボトルネックを的確に把握できるようになると、そのツールは、OSCで広く共有されます。特別な性能ツールとは、通常、Linuxカーネルの特定のコンポーネントを測定するための単純なツールのことです。われわれは、以下の性能ツールを使用しました。

  • /procのファイルシステム
    meminfo、slabinfo、interrupts、network stats、I/O statsなど。
  • SGIのlockmeter
    SMPのロック分析から
  • SGIのカーネル・プロファイラー (kernprof)
    時間ベースのプロファイル作成、性能カウンター・ベースのプロファイル作成、カーネル空間だけの注釈付きの呼び出しグラフ (ACG: annotated call graph)
  • IBMトレース・ユーティリティー
    シングル・ステップ (mtrace) およびユーザー空間とシステム空間の両方に対する時間ベースおよび性能カウンター・ベースのプロファイル作成

特別な性能ツールは、システムの特定の側面についての理解を深めるために開発されます。

たとえば、以下がその例です。

  • sstat
    スケジューラーに関する統計を収集する
  • schedret
    アイドル時間の分析のために、どのカーネル機能が中断しているのかを判断する
  • acgparse
    kernprofのACGを後処理する
  • copy in/outの計測
    バッファーのアラインメント、コピーのサイズ、copy in/outアルゴリズムのCPU利用率を調べる

これらの特別な性能ツールで得られた性能分析データを使って、性能および拡張性のボトルネックがどこにあるのかが調べられます。性能ボトルネックがどこに存在するのかを理解するためには、SUTを幅広く理解するとともに、ベンチマークによってLinuxカーネルの個々のコンポーネントに負荷をかけることで、それらのコンポーネントをより具体的に理解することが必要となります。また、ボトルネックの原因となっているLinuxカーネルのソース・コードを理解する必要もあります。さらに、ボトルネックを解消するためのパッチの開発につなげるために、われわれは、LTC Linuxカーネル開発チームやOSC (オープン・ソース・コミュニティー) と非常に緊密に連携します。

撤退作戦

Linuxカーネルの性能を評価するためには、ベンチマーク実行のサイクルを何回も繰り返さなければならない場合もあります。すなわち、結果を分析して性能および拡張性のボトルネックの所在を突き止め、Linuxカーネルにパッチを当ててボトルネックに対処し、もう一度ベンチマークを実行するといったサイクルです。パッチは、OSCに用意されている既存のパッチを見つけ出すことで得られる場合もあれば、Linuxカーネル開発チームのスタッフやOSCと緊密に協力しながら性能チームのスタッフが新しいパッチを開発する場合もあります。いつLinuxが「十分良好な」性能を示すようになり、この評価の工程を終了すべきかについては、一連の基準を設けています。

まず、われわれが設定した目標を達成し、大きな性能改善につながりそうな特定のベンチマークが存在するというような顕著な問題がLinuxカーネルになければ、Linuxは「十分良好」であると判断し、他の問題に移ります。次に、性能分析のサイクルを何度か繰り返してみても顕著なボトルネックが残っている場合には、この工程を続行する場合の開発コストと、性能をさらに向上させた場合の利益とを天秤にかけます。開発コストが、達成された場合の性能改善に比して高すぎる場合には、分析を中止し、その理由を適切な方法で明確化します。

いずれの場合も、対処する必要があると思われるその他のすべての顕著なLinuxカーネル関係の問題について再検討し、それらのカーネル・コンポーネントの問題に対処するために利用できそうな適当なベンチマークの評価を行い、それらの問題に関してすでに収集されているかもしれないデータを調べ、そのデータに基づいて、カーネル・コンポーネント (群) の分析を行うかどうかを判断します。


ベンチマーク

ここでは、今回扱ったボトルネック、および今回のスイートに含まれるベンチマークで負荷をかけたカーネル・コンポーネントのうち、ボトルネックに関係したものについて説明します。また、Linux性能チームが使用したいくつかのベンチマークでの性能の結果と分析も紹介します。

表1.Linuxカーネルの性能ベンチマーク
Linuxカーネル・コンポーネントDatabase queryVolanoMarkSPECweb99 Apache2NetBenchNetperfLMBenchTioBench IOZone
スケジューラー XXX   
ディスクI/OX     X
ブロックI/OX      
生の直接的な非同期I/OX      
ファイルシステム (ext2 & ジャーナル型)  XX XX
TCP/IP XXXXX 
Ethernetドライバー XXXX  
シグナル X   X 
パイプ     X 
Sendfile  XX   
pThreads XX X  
仮想メモリー  XX X 
SMP拡張性XXXXX X

ベンチマークについての説明

どんなベンチマークを使用するかは、いろいろな基準にしたがって決定されます。まず、複雑な作業負荷に対する信頼性の高い指標となる業界ベンチマーク (industry benchmarks) と個別的なカーネルの性能の問題の指標となるコンポーネント・レベルのベンチマーク という基準があります。業界ベンチマークは、特定の作業負荷の性能と拡張性の測定用として、業界から一般に認知されているものです。これらのベンチマークは、多くの場合、ほとんどのOSC (オープン・ソース・コミュニティー) が利用することのできない複雑で高価なセットアップを必要とします。われわれがOSCに対して寄与できることの1つとして、このような複雑なセットアップを提供することがあります。以下がその例です。

  • SPECweb99
    Webサーバー機能性能測定の典型となるシステム
  • SPECsfs
    NFS性能測定の典型となるシステム
  • Database query
    データベース・クエリー性能測定の典型となるシステム
  • NetBench
    SMBファイル・サーバー機能性能測定の典型となるシステム

コンポーネント・レベルのベンチマークは、Linuxカーネルの中でも、さまざまな種類の作業負荷に大きな影響を及ぼすと思われる個別的なコンポーネントの性能と拡張性を測定します。以下がその例です。

  • Netperf3
    TCP、IP、ネットワーク・デバイス・ドライバーなどのネットワーク・スタックの性能を測定
  • VolanoMark
    スケジューラー、シグナル、TCP送受信、ループバックの性能を測定
  • Block I/O Test
    VFS、生の直接的なI/O、ブロック・デバイス層、SCSI層、低レベルのSCSI/ファイバー・デバイス・ドライバーの性能を測定

OSCで広く使用されているベンチマークもいくつかあります。それらのベンチマークが好んで使用されるのは、OSCがすでにベンチマークの重要性を認識しているからです。したがって、ベンチマークによって明らかになる性能や拡張性のボトルネックをOSCに納得してもらうことは比較的容易です。また、通常、生データの公表を阻むようなライセンスの問題がありません。これらのベンチマークは、多くの場合、セットアップが簡単であり、必要なハードウェアも最小限で済みますので、OSCでも、これらのベンチマークを実行することができます。他方、これらのベンチマークが、企業システム向けとしてのわれわれの仕様に合致しないこともよくあります。以下がその例です。

  • LMBench
    Linux APIの性能を測定するのに使用される
  • IOZone
    ネイティブのファイルシステムのスループットを測定するのに使用される
  • DBench
    NetBenchのファイルシステム・コンポーネントを測定するのに使用される
  • SMB Torture
    SMBファイル・サーバー機能の性能を測定するために使用される

われわれが目標とする作業負荷には、数多くのベンチマークの選択肢があります。使用できるリソースと私たちの任務に最適であることから、上記のベンチマークを選択しました。われわれが使用しないことにしたベンチマークにも、重要なものがいくつかあります。また、IBMの他の性能チームがすでに研究を行っているため、実行しないことにしたベンチマークもいくつかあります (たとえば、IBM Solution Technologiesのシステム性能チームは、LinuxでのSPECjbbは「十分良好」であるとしています)。表1に掲げたものは、現在Linux性能チームが使用しているベンチマークおよびそれらのベンチマークが対象としているカーネル・コンポーネントです。

ベンチマークの結果

以下では、われわれがLinuxカーネルの性能を数量化するためにスイートに含めたdatabase query、VolanoMarkおよびSPECweb99の3つのベンチマークについて説明します。これら3つのベンチマークでは、ベンチマークの結果を示す以下の各図に詳細を示してありますが、8ウェイのマシンを使用しました。

図1. ベンチマークDatabase queryの結果
図1

図1は、ベンチマークdatabase queryの結果を示したものです。図には、使用したハードウェアとソフトウェアの構成についての説明も示してあります。図には、われわれが目標を達成するまでの経過がグラフで示されています。われわれが対処した問題のいくつかからは、DB2のいろいろな最適化の他、バウンス・バッファーの回避、ips、io_request_lock、readv、kiobufあるいはO(1) スケジューラーといったカーネル・パッチを追加するなどの改善が実現されました。

VolanoMarkベンチマーク (参考文献参照) は、クライアント数20のチャット・ルームを10個作成するというものです。それぞれのルームでは、1つのクライアントからのメッセージが、同じルームの残りの19個のクライアントにエコーされます。このベンチマークは、まだオープン・ソースのベンチマークとはなっていませんが、VolanoChatサーバーとチャット・ルーム内のクライアントをシミュレートする2つ目のプログラムとからなります。このベンチマークは、サーバーの生の性能とネットワークの拡張性を測定するために使用されます。VolanoMarkは、ループバック・モードとネットワーク・モードの2つのモードで実行することができます。ループバック・モードでは、サーバーの生の性能がテストされ、ネットワーク・モードでは、ネットワークの拡張性がテストされます。VolanoMarkでは、チャット・ルームのサイズと数を制御するための2つのパラメーターが使われます。

VolanoMarkベンチマークは、クライアント接続を20個のグループ単位で作成し、サーバーが順番にクライアントのすべてのメッセージをグループ内でブロードキャストするのにどの程度の時間がかかるのかを測定します。ループバック・テストが終わると、1秒あたりに転送された平均メッセージ数が得点として報告されます。ネットワーク・モードでは、クライアントとサーバーの間の接続数が測定基準となります。このベンチマークでは、Linuxカーネルの中でも、スケジューラー、シグナル、TCP/IPといったコンポーネントに負荷がかけられます。

図2. VolanoMarkベンチマークの結果 -- ループバック・モード
図2

図2は、VolanoMarkベンチマークのループバック・モードの結果を示したものです。図には、使用したハードウェアとソフトウェアの構成およびこのベンチマークでのわれわれの目標についての説明も示してあります。われわれは、この目標を達成することを目指して、Linuxカーネル開発チームのスタッフとの緊密な協力関係を確立しました。われわれが指摘した問題の中で改善が実現したものとしては、O(1) スケジューラーの追加、SMPに拡張可能なタイマー、調整可能な優先順位プリエンプション、ソフトな親和性が高いカーネル・パッチがあります。図に示すように、このベンチマークでは、目標以上の結果を達成しましたが、Linuxのカーネル・コンポーネントやJavaに関係する問題で、われわれが現在対応を進めている顕著な問題もいくつかあり、それによって、このベンチマークの性能はさらに改善されることになると思います。

SPECweb99のベンチマーク作業は、研究のためだけに行われたもので、実行ルールには則していません。ルールから逸脱しているのは、以下の点です。

  1. このベンチマークは、SPEC社の一般に公開されている基準には合致しないハードウェア上で実行された。マシンには、開発中のサンプル品が使用された。
  2. access_logは、完全なアカウント処理用として記録されなかった。書き込みは行われたが、200秒ごとに削除された。

このベンチマークは、Webサーバーに対して大きな作業負荷を要求します。この作業負荷は、70%の静的なページと30%の単純な動的ページを要求します。Webページのサイズは、102バイトから921,000バイトまでの範囲です。動的なコンテンツは、GIFの回転広告 (advertisement rotation) をモデルにしています。SSLのコンテンツはありません。Linuxサーバーの最も一般的な利用方法の1つが、とくにApacheといっしょ使用される場合のWebサーバー機能ですので、SPECweb99は関係のあるベンチマークです。Apacheは、機能は豊富ですが、高い性能を出せるようには設計されていませんが、現在のところ、インターネット上のWebサイトのホストでは、他のどんなWebサーバーよりも数多く利用されていますので、今回のベンチマークでは、ApacheをWebサーバーに選びました。SPECweb99は、Webサーバー機能用として一般に認知されている標準的なベンチマークです。SPECweb99は、スケジューラー、TCP/IP、いろいろなスレッド処理モデル、sendfile、zero copy、ネットワーク・ドライバーといったカーネル・コンポーネントに負荷をかけます。

図3. WebサーバーにApacheを利用したときのSPECweb99ベンチマークの結果
図3

図3は、SPECweb99の今回の結果を示したものです。図には、使用したハードウェアとソフトウェアの構成およびこのベンチマークでの目標についての説明も示してあります。われわれは、Linuxカーネル開発チームおよびIBM Apacheチームと緊密に協力しながら、このベンチマークの性能改善を図っています。われわれが指摘した問題の中で改善が見られたものとして、O(1) スケジューラーの追加、read copy update (RCU) dcacheといったカーネル・パッチ、、およびmod_specwebという新しい動的なAPIモジュールをApacheへ追加などがあります。図3に示されるように、このベンチマークでは、目標以上の結果を達成しましたが、Linuxのカーネル・コンポーネントに関係する問題で、われわれが現在対応を進めている顕著な問題もいくつかあり、それによって、このベンチマークの性能はさらに改善されることになると思います。


まとめ

Linuxは、とくに小規模あるいは中規模のシステムで、大いに人気を博しています。たとえば、Linuxは、そうしたマシンをWebサーバーとして使うのに適した信頼性の高い安定したオペレーティング・システムとして見られています。一方、高性能の企業レベルのシステムは、ギガバイトとかペタバイトとかエクサバイトのデータにアクセスします。これらシステムでは、たくさんのプロセッサーを必要とするだけでなく、メモリー量やバンド幅も大きなものを必要とする別の種類のアプリケーションやソリューションが必要となってきます (参考文献には、この種のアプリケーションのことを取り上げたdeveloperWorks の記事「生物科学におけるオープン・ソース」を掲げてあります)。

この種のシステム・アプリケーションには、それに固有な問題が発生し、それより小さなシステムで起こるのとは桁違いに複雑な問題となったりします。Linuxを企業市場で競争力のあるものにするには、性能と拡張性を改善する必要があります。

これまでわれわれが経験したことから考えると、Linuxカーネルの性能は、大いに改善が可能です。われわれは、オープン・ソース・コミュニティーと協力しながらLinuxカーネルの性能を数量化したり、性能低下の原因を解消するためのパッチを開発してLinuxを改良することでこの目標に貢献し、Linuxを企業用として利用できるようにしていることを誇りに思っています。

謝辞:
この記事を作成するにあたり、情報を提供していただいたKaivalya Dixit、Dustin Fredrickson、Partha Narayanan、Troy Wilson、Peter Wongの諸氏およびLTC Linuxカーネル開発チームに感謝の意を表します。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=228932
ArticleTitle=Linuxカーネルの性能と拡張性の改善
publish-date=03012001