システムコール - みる会図書館

1. UNIX MAGAZINE 2002年1月号

exit(l); } else if (len break; len) ! = len) / * ネットワークから入力 * / } else { if if (write(fd, buf , / * ネットワークに出力 * / exit(l); perror ( "read") ; (errno ! = EAGAIN) { if ((len = read(fd, buf , BUFSIZ)) write(), buf, / * 端末への出力 * / } else { break ; } else if (len len) ; se 厄 ct システムコールく 0 ) { 上記のように修正したプログラムの入出力を処理するループに注目すると、 for の無限ルーフ。のなかで、非プロッキング入出力の 2 つのファイルの入力を試み続けるビジーウェイトと呼はれるループとなっています。標準入力とネットワークのいすれからも入力するデータがない場合、読込みを試みて EAGAIN を得たあと、さらに言もムみを試みて EAGAIN を得るという処理を繰り返すことになります。これでは CPU 資源の無驪貴いといわれても仕方がありません。入出力のデータがあるときだけ処理したい場合は、 se- lect システムコールを利用するのかイ甦リです。たとえは、サンフ。ル・プログラムの pr 。 cess 関数を図 1 のように変更すれは、端末からの入力とネットワークからの入力をどの順番でもおこなえるようになります。しかも、ビジーウェイトも起こりません。急にプログラムか難しくなったように感しるかもしれませんが、 select システムコールの動作を理解す川まさほど難しくはありません。それでは、 select システムコールについて詳しくみていきましよう。 fd-set 本体 select システムコールは、ファイル・ディスクリプタの集合に対して言も囚みや書込みが可能かどうかを調べること 78 かできます。さらに、帯域外データと呼ばれる朱なデータが到着したかどうかも調べられます。ファイル・ディスクリプタの集合を表現するために、 fd_set という専用のデータ構造が用意されています。このデータ構造に対する演算としては、以下のものカ甘是供されています (fd-set 型の変数 fds か旦言されているとします ) 。 FD ZERO(&fds) : ファイル・ディスクリプタの集合を空集合にネノ期化する。 UNIX MAGAZINE 2002.1 合に要素を追加するときにその最大値 &f 尉寺しておくガ去大値を得るガ去があります。それは、 FD-SET により集しかし、もっと簡単に集合の要素となる可能性のある最には、 sysctl 関数を利用して値を取得することになるで変数として取得できます。プログラム中で正しい値を使うす。これは sysctl コマンドでも kern. maxfilesperproc 許されているファイル・ディスクリプタの最大値になりま limit コマンドで得られる descriptors のイ直かフ。ロセスに過度に大きく見積もられた値となっています。実際には、のファイル・ディスクリプタを扱えます。ただしこれは、用している値です。 fd-set 型は、この値で示される数までもっとも簡単です。これは fd-set 型を定義するときに利ファイルで定義されている FD-SETSIZE を用いるのが値です。この値には、 /usr/include/sys/types. h ヘッダ素となる可能生のある値とはファイル・ディスクリプタの FD-ISSET を使って検査することになります。集合の要いません。要素となる可能性のあるすべての値について、どの操作がほしいところですが、残念ながら用意されてこのほかに、集合に属するすべての要素を処理するなす。構造体として宣言されているため、直接代入できるからでには、このマクロはあまり利用されません。 fd-set 型がんが FD-COPY(&src, &dst) カイ吏えます。しかし実際合全体をコピーするには、マニュアルには書いてありませを使って集合に含まれる要素を順に追加していきます。集通常は、ます FD-ZERO て集合を祺月化し、 FD-SET かを検査する。 FD-ISSET(fd, &fds) : 集合に fd が含まれるかどう FD-CLR(fd, &fds) : 集合から fd を削除する。 FD-SET(fd, &fds) : 集合に fd を追加する。

2. UNIX MAGAZINE 2002年1月号

s ele ct の利用した 3 つの集合に、みつかったファイル・ディスクリプには、ファイル・ディスクリプタの甫を渡すために利用該当するファイル・ディスクリプタがみつかったときおいてエラーが発生したことを示します。 select システムコールが負の値を返した場合は、呼出しにか満たされる前にタイムアウトとなったことを表します。れは、ファイル・ディスクリプタに対して指定した条件トを設定すると、この値が 0 になることがあります。常は、これは正の直になっているはすです。タイムアウを満たしたファイル・ディスクリプタの数を表します。通 select システムコールカ鮗了したときの戻り値は、条件ル・ディスクリプタがあるかどうかを即座に調べられます。せん。時間として 0 を指定すれば、条件を満たすファイステムコールは最大でも指定された時間しかプロックしま方、 timeval 構造体を使って時間を指定すると、 select シする条件が岡たされるまで、そこで処理は止まります。ます。つまり、いすれかのファイル・ディスクリプタに関 NULL を指定すると select システムコールはプロックしすファイル・ディスクリプタがない場合、最後の引数にテムコールはプロックせすにすぐに戻ります。牛を満たここ旨定した値に関係なく select シスプタがあれは、指定するわけです。条件を満たすファイル・ディスクリを満たすファイル・ディスクリプタがない場合の動作をイル・ディスクリプタを検査しますが、指定された条件テムコールでは言ムみ、書込み、帯域外データを扱うファするか、タイムアウトするかを指定します。 select シス最後の引数の timeout には、 select の処理をプロックなります。るかを指定します。さきほどの例でいえば、 fdmax 十 1 と値十 1 、つまりいくつのファイル・ディスクリプタを調べ nfds には、検査するファイル・ディスクリプタの最大 select(nfds, &rfds, &wfds, &efds, &timeout) 定します。 efds とすると、 select システムコールは以下の形式てオ日したかどうかを調べるファイル・ディスクリプタの集合をル・ディスクリプタの集合を wfds 、帯域外データか到着タの集合を rfds 、書込みが可能かどうかを調べるファイ言ムみか可能かどうかをヾるファイル・ディスクリプ 80 タかオ褓内されています。そのため、集合に含まれるすべてのファイル・ディスクリプタに対する処理としてさきほど紹介したループを使って、集合に残っているディスクリプタを調 , 、く、それを処理します。図 1 のプログラムでは、標準入力からの入力とネットワークからの入力を select システムコールで監視しています。このプログラムでは入力がなければはかに処理することはないので、 select システムコールは入力が到着するまでプロックするようになっています。 select システムコーノレから戻ってきた場合には、 FD-ISSET を使って標準入力やネットワークからの読込みが可能かどうかを調べ、入力があればそこからデータを読み込みます。そして、標準入力ならネットワークへネットワークからの入力なら標準出力へ書き出します。ほかにも、入力カ鮗了したときにプログラムを終了できるように残っているファイル・ディスクリプタの数を数えたり、 alarm を使ってタイムアウトを設定し、プログラムを終了できるようにしたりしています。図 1 のプログラムでは、標準入力とネットワークからの入力の 2 つを監視していました。一方、ネットワークや標準出力への出力についてはとくに見をおこなわす、いきなり出力しています。ネットワークの先に書き込めない場合、このプログラムでは書込みの段階でプロックしてしまいます。本来なら、入力を読み込んでもそれをすぐに書き込むのではなく、書込みが可能かどうかを調べてから書き込むべきです。この場合には、読み込んだデータを一引芋的にどこかにイ尉寺しておかなければなりません。入力が可能になったので読み込んだが、まだ出力できない状態だったということもあるためです。しつは、 telnet コマンドでこの情報を保持するために利用されるのが、前回紹介したリングバッフアです。それでは、 telnet コマンドでこの処理をおこなっている部分をみていきましよう。具イ勺には、 sys-bsd ファイルにある process-rings 関数です。この関数は TN3270 マクロが定義されているかどうかによる条件コンパイルが多く、見通しか懇くなっているので、関係のない部分を削除した状態でみることにしましよう。出力先の監視 UNIX MAGAZINE 2002.1

3. UNIX MAGAZINE 2002年1月号

連載 /UNIX Communication Notes—O との受信侍ち状態に戻り、もう 1 つのプロセスは処理をおこなうかたちになっていた。これを擬似コードて表現すると、次のようになる。 main() 初期処理 ; socket() ; S bind(s, listen(s) ; while ( 1 ) { / * socket の生成 * / / * s 。 cket に対する設定 * / accept(s, C S exit(O) ; close(cs) ; 実際の処理 ; close(s) ; / * 子プロセス * / if ((pid = fork() / * 受信待ちでプロックこのコードからも分かるように、子プロセスがクライア / * 親プロセスは実際に接続されたソケットをクローズ * / / * 受信待ちに戻る * / close(cs) ; システムコールを用いて起動するかたちにした。 inetd に理するプログラムを inetd が fork() し、さらに exec( 特定のポートへのアクセスがあった場合、そのポートを処をしなければならない複数のポートを監視する。そして、 inetd は、 select() システムコールを使って、受信待ち UNIX で標準的に使われるようになった。 inetd (lnternet super daemon) が開発され、 4.3BSD せておかなけれはならないという間題を解決するために上記の間題のうち、あまり使われないデーモンも不力さ inetd の登場かった。・プロセスを複製する fork() システムコールの実行が遅った。モリしかなかった衫琪月の UNIX システムには重荷となとして、プロセステープルか増えてしまい、わずかなメめ、デーモンとして稼動させるプロセスか増える。結果・ふだん利用しないサーバーもデーモンとして起動けるたこの方式には、以 - ドのような間題があった。のソケット接続要求だけを処理する構造になっている。ントからの要求を処理し、親プロセスはクライアントから 64 よって起動される処理プログラムは、標準入力からデータを読み込むと socket に届いたデータを読むことができ、標準出力に書き出すと相手にデータか送られるような形式 UNIX MAGAZINE 2002.1 グラムのなかでうまく処理できるようにすれはよい。このきなオーバーヘッドをともなう実装ではなく、 1 つのプロだけに fork() でプロセスを複製している。このように大さきはど窈疑似コードでは、処理をおこなう部分のためラムが考案された。 fork() によるプロセスの複製はしないサーバー・プログ間で通常のデーモン・プログラムとして実行されるが、その後カーネルに組み込むのではなく、ユーサー空ユーサー空間で作るネルに組み込まれることはあまりなかった。くい。そのため、 NFS 以外のサーバー・プログラムがカーへの糾込みは、作業か難しいだけでなく、デバッグもしにしかし、一殳的な処理をおこなうプログラムのカーネルていた。ファイルシステムを扱う NFS はカーネルへの実装に適しロセスの複製というオーバーヘッドを軽減した。しかも、常駐スレッド (thread) をカーネルに組み込むことで、プしようと考えたわけである。 NFS では、処理をおこなうるプロセスの複製はしないように実装し、処理性能を改善変わりはなかった。そこで、常駐はしても、 fork() によって複製される状況は、 inetd かイ吏われるようになってもサーバーへのアクセスがあるとプロセスが fork() によこれは、 NFS サーバーの実装の際に採られた方法である。次に考えられたのが kernel resident thread である。 kernel resident thread えなかった。にデーモンとして起動さ常駐するという形態をとらざるをなどの常駐すべきサーバーは、依然としてシステムのプート時けではない。たとえば、 UDP を用いたサービスや、 sendmail しかし、すべてのデーモンが inetd の管理下に置かれたわノート 5 わすかながら改善された。状態にしておくという間題カ黝夬さシステムの性能がきる。これにより、起動された大量のデーモンを受信待ち peername() などのライプラリ関数を用いて知ることがでの API が定められた。相手のアドレスなどの情報は、 get-

4. UNIX MAGAZINE 2002年1月号

プログラミング・テクニックしかし、接続するのが echo サーバーではない、つまり複数の入力行を読み込んでから数行ぶんの応答をまとめて返すサーバーの場合、このプログラムでは対応することができません。どの程度の入力をサーバーに送れは応答が返ってくるかカ吩からないため、標準入力からの入力を読み込みつつ、それをサ→ヾーに送る必要があります。さらに、サーバーからの返答を監視しなければなりません。そのためにおこなうのか非期の入出力てす。・ファイル言当子の複製・ close-on-exec フラグの取彳等と疋・ステータスフラグの取得と設定・入出力関連シグナルの受信プロセスの取得と設定・レコードロックの取得と解除があります。非プロッキング入出力は、ステータスフラグて蒲衂されています。実際の処理は次のようになります。 fcntl(fd, F—GETFL, 0 ) ) perror("fcntl") ; exit(l); if (fcntl (fd, F—SETFL , f ー O—NONBLOCK) perror("fcntl") ; exit(l); if ( (f = 非プロッキング入出力ます、実際に入出力をおこなっている process 関数が呼び出される状況と、この関数の重川乍について石忍しておきましよう。ます、 fcntl に対して F-GETFL コマンドを実行し、この関数か呼び出されるときには、 TCP を利用していファイル・ディスクリプタの現在のステータスフラグを取る場合はすでに接続か確立した TCP のソケットが引数得します。続いて、 F-SETFL コマンドによりステータとして渡されます。 UDP の場合には、接続という念はスフラグを設定します。このとき引数として、最初に取得ありませんが、バケットの送出先があらかじノ旨定されたしたフラグの値と非プロッキング入出力を示す O-NON- 状態て呼び出されます。つまり、いすれも read や write BLOCK とのビットごとの論理和をとった値を指定しまなどのシステムコールを使ってデータを読み書きできるよす。この処理により、もとのステータスフラグから非プロうになっています。ただし、相手側とのやりとりのなかッキング入出力のフラグのみを変更したものを設定するこで、ネットワークからの入力と標準入力の両方を順番に読とかできます。値を取得迂すに O-NONBLOCK だけをみ書きしていては正しく重川乍しなくなってしまいます。そ引数として F-SETFL を実行すると、ほかのフラグか設こで、ネットワークからの入力でも標準入力でも、言も囚み定されていた場合にこれらがクリアされてしまいます。上か可能になった段階で読み込んで対応する出力先に出力し己の処理は、このような問題を避けるための工夫です。ようとします。上に示したコードでは fd を非プロッキング入出力に設言ムみが可能かどうかを調べるのは、ネットワークや標定しました。次に、標準入力についても非プロッキング入準入力から読み込むべきデータがない場合にプロセスカワ・出力の設定をしたあと、サンプル・プログラムのような入ロック ( 入力待ちで停止 ) してしまうからです。逆にいえ出力に関するループを実行すればよいのですが、ループのば、プロックさえしなければいつ読み込んでもかまわない内部をすこし変更する必要があります。非プロッキング入はすです。そのためには、 fcntl システムコールを使って、出力をおこなうファイル・ディスクリプタは、読み出すファイル・ディスクリプタか非プロッキング入出力をおデータがないか書き込む準備ができていない場合にエラーこなうように設定します。を返し、 errno を EAGAIN に設定するためです。これ fcntl システムコールは次のような形式でイ吏います。は実際にエラーが発生したわけではなく、一日勺に実行で fcntl ()d , command, arg) きないことを表すのですから、エラーを無視しなけれはなりません。そのためのコードは次のようになります。 fd には処理の対象となるファイル・ディスクリプタを、 command にはおこないたい処理を表すマクロを指定しま for ( ; / * 端末から入力 * / す。さらに処理に対する引数を arg に指定します。 if ((len = read(), buf , BUFSIZ)) く 0 ) { if (errno ! = EAGAIN) { fcntl で可能な処理としては、 perror("read") ; 1 三ロ 77 UNIX MAGAZINE 2002.1

5. UNIX MAGAZINE 2002年1月号

連載 UNIX Communication N0tes—O ために利用できるのが、 select() システムコールである。 select() は、複数のファイル識別子で指定される入力ソケットを監視し、カーネル内でプロックする。読み出せるようになった ( 到着した ) ソケットがあるとプロックか外れ、処理ルーチンを同一プログラム内でおこなうようにするコードか書ける。これにより、複数のソケットを監視しながら処理を夫行するルーチンか書けるようになった。しかし、この実装には大きな問題がある。プログラムを実行しているコンテキストは 1 つしかないので、リクエスト処理ルーチンを実行しているあいだは、ほかのソケットに到着したデータや新たな接続要求はすべてカーネル内にイ尉寺される。けっきよく、 fork() は使わなくても、すべての処理がシリアライズされるため、高い性能か得にくくなった。もちろん、リクエスト処理ルーチンの処理量が大きいと、処理待ちになるリクエストも増えることになってしまう。そこで、登場するのがスレッドである。その考え方は実装により多少異なるが、おおまかには次のようなもので・スレッドを利用するプログラムでは、その実行時に複数のスレッドを起動することができる。・ 1 つのスレッドは、実行を管理するためのコンテキストをもつ。ここには、プログラム・カウンタとスタックだけが用意されている。つまり、現在、どの部分を実行しているかという情報と局所変数だけが各スレッドに割り当てられている。大域変数は、すべてのスレッドて共有される。したがって、或変数を使えばスレッド間での通信カそきる。・スレッドの生成や消去などは、プログラムで明カ勺に記述できる。スレッドを利用すると、ユーサー空間て稼動するプログラムで並列処理を簡単に記主できる。描丘の生能サーバーの世界では、スレッドの利用を目指す開発か続けられている。現在のスレッドの実装には、 BSD 系の pthread や Linux の linux pthread などがある。これらはそれぞれに実装形態か違い、長所もあれば短所もある。また、 BSD の pthread の実装のように、システムコールとの親和がやや悪いという欠点は解消されつつあるが、完全、解決されたわけではない。スレッドを利用するサーバー UNIX MAGAZIN E 2002 ユはまだ少ないが、高性能サ→ヾーの世界ではスレッドを用いた開発が一殳的になり始めている。 WWW サーバーの Apache 2.0 系列がその一例である。今後、高生能サーーを構築する際には、使用されるプログラム自体がスレノ、ッドを使う実装になると思われる。 ☆ 今回は、十分な処理性能が得られるサーバーの構築方法について述べた。むろん、厳選された性能のよいパーツを用いて高生能サーバーを構築するガ去もあるが、レイヤ 4 / 7 スイッチを使ったクラスタ化によって実現することも増えてきている。とくに、商用 WWW サービスを提供するサイトなどでは、常識といってもよいはどクラスタ化サーバーの利用が進んでいる。高生能サーバーを導入する場合は、レイヤ 4 / 7 スイツチを用いたサーバー構成のノウハウを応用するとよい。最近は、サーバー・プログラムそのものの高性能化もスレッドを用いた並列処理によって見されようとしている。スレッドを用いた処理は SMP 型システムとの整合生もよく、今後、高性能サーバー・プログラムの実装手法として普及する可能性がある。サーバーの実装を目指すソフトウェア技術者は、スレッドを用いたプログラム開発の腕を磨くべきであろう。 ( やまぐち・すぐる奈良先立斗 ! 物支彳大芋ギ完大学 ) [ 文献 ] [ 1 ] Lawrence S. Brakmo and Larry L. Peterson, "TCP Vegas: End t0 End Congestion Avoidance on a Global lnternet ” IEEE ノ 0 社ロ田 1 0 れ Selected Areas をれ Comm 社れを ca 0 れ , V01.13 , NO. 8 , Oct0ber 1995 (ftp: //ftp.cs.arizona.edu/xkernel/Papers/jsac.ps. Z) 65

6. UNIX MAGAZINE 2002年1月号

表 3 さまざまな構成の PC -733 でデータを週言したときの合計アイドル時間俿畴合 nettest 実行中のアイドル時間 PC ー 733 ・商化 VM/PC-733 IRQ 通知をおこなわない最適化 VM/PC-733 送信の結合と IRQ 通知をおこなわない最商化 VM/PC-733 VMware Workstation 2.0 の VM/PC-733 ク・リンクを一杯にするかなり前に CPU によって性能が制限される。しかし、最商化を施すと VM/PC-733 はネイテイプに匹敵するスルーブットを達成する。 VM/PC- 350 は最適化を施しても CPU の性能による制限を受けるが、 2 倍のスルーブットを維持し、最適化されていない V / PC ー 733 と同等の性能を達成している。 VM/PC -350 の 2 つの曲線はそれぞれ PC ー 733 の曲線の形状と一致する。図 6 は、 VM/PC-733 が CPU の性能による制限を受けすに 100Mbit のリンクを一杯にできることを示している。しかし、 VM/PC-350 は最直化を施しても CPU によって性能を左右される。ネイテイプの PC ー 733 と pc- 350 は 100Mbit のリンクを簡単に一にする。最後の実験では、さまざまな構成で CPU がどのように消費されるかについての情報を集めた。システムを詩ヾ、アイドル日判の正確な長さを得た。通常は、ゲストカ止命令 (HLT) を発行すると、 VMware Workstation は領域を VMApp に切り替える。そして、 VMApp はすべてのテンヾイスで select() をプロックする。こでは、ホスト OS に制御を戻す代わりに、ゲストの HLT 命令がスピンして VMM の CPU を停止させるオプションを有効にした。 TSC レジスタを使用して、ゲストが HLT 命令を発行してから次のハードウェア割込みが発生するまでのアイドル時間を測定した。このアイドル時間は、ゲスト OS がほかの計算をするのに利用できる CPU サイクルである。ホスト OS のはうは、このアイドル時間をすべてほかの引算に利用できるわけではない。ゲストの HLT 命令によって VMApp への切替えが発生した場合、いくっかの領域切替えやシステムコールによるオーバーヘッド (select() システムコールなど ) が発生するからである。ネイテイブマシンのアイドル時間については、 Linux 3.5 CPU 利用率 170 86 % 21.7 % 17.9 % 2.0 % 0 % カーネルに組み込まれている標準のプロファイラを拡張して、ユーサーコードの実行やカーネルのアイドルルーフに使われる時間を測定できるようにした。これによって、アイドルループに費やされた合言判間の割合カ昇られる。表 3 に示すように、送信サイズが 4KB の VM/PC- 733 では、 64Mbps で CPU に性能を制限されていたゲストが、 I/O を一杯にして 21.7 % のアイドル時間がある状態にまて改善された。これに対し、 PC -733 のアイドル時は 86 % である。こまでくると、残りのほはすべてのオーバーヘッドは、 CPU のイ反想化か、ホスト協調型アーキテクチャの生質によるものである。次節では、ホスト協調型アーキテクチャの枠の内側と外側で、さらなる描商化の可能性を検証する。前節て解説した最適化では、イ反想化による CPU のオーバーヘッドを、一ト分な I/O 性能か得られるところまて減らすことができた。本節では、 I/O 性能をさらに改善し、 CPU の利用率を減らすための手法について説明する。おもな最適化の対象としては、 1. CPU と割込みコントローラの仮想化のオーバーヘッドの轤成 2. ゲスト OS やそのドライバの修正 3. ホスト OS の修正 4. VMM からネイテイプ・ハードウェアへの直接アクセス力げられる。後半の 2 つの手法は、純粋なホスト協調型イ廨課マシン・アーキテクチャからは逸脱している。ホスト協調型アーキテクチャの言 t では、既存のホスト os が通常どおりに実行さイ廨課ソフトウェアがホスト OS の API を使ってハードウェア・テンヾイスにアクセスするということを思い出してほしい。 UNIX MAGAZINE 2002.1

7. UNIX MAGAZINE 2002年1月号

ますは関数の引数です。次のようにたいへん多くの引数をとります ( 誌面の都合長で折り返しています。以下 int process int netin —rings (netin, netout , netex, ttyin, = 〉 ttyout, P011 ) / * If 0 , then block P011 ; until something tO d0 * / 、 ttyin などの引数には、リングバッフアに空きプログラミング・テクニックここでは最初に netin や netout などの値を初期化していませんが、この関数の実行か開始される点では、れらはつねに空の状態になっています。これらは外部変数であり、一度ネ加月化されると以降は初期化せずに使い続けます。この段階では集合に要素が j 助日された状態になっていますが、後ろの部分の処理カ鮗ったときには FD-CLR を使ってかならす要素がない状態に戻しています。次が select システムコールです。引数のところでも説明したように、 p 。Ⅱ引数が真の場合にはさきほど定義した TimeValue をタイムアウトとして指定し、ポーリンク鋤作となるようにしています。があれは真の値カイに入されています。つまり、バッフアにオ褓内できるスペースがあるので、 netin ならネットワークから、 tty ⅲなら標準入力から言囚みをおこなってもよいという意味です。一方、 netout や ttyout はリングバッフアにデータがあるかどうかを表します。つまり、 netout ならネットワークへの、 ttyout なら標準出力への書込みをおこなってもよいという意味になります。 po Ⅱ引数は、コメントにもあるように、値カイ為なら select をプロックします。 select 関数のための引数としては、以下のものを定義しています。とくに注目してはしいのが TimeValue 変数です。 register int C ; int returnVa1ue = 0 ; static struct timeval TimeVa1ue = この変数は、あとで select のタイムアウト引数として利用します。タイムアウト値として 0 秒を指定しているため、実際の重川はポーリングになります。次に、 FD-SET を使って select に指定する集合を設定します。このとき、引数の値にもとづいてファイル・ディスクリプタを追加していきます。 if ((c if seIect(16, &ibits , ( P011 (struct timeval * ) 0 (c &obits, &xbits, &TimeVa1ue) ) く 0 ) { (netout) { FD_SET (net , if (ttyout) { FD_SET (tout , if (ttyin) { FD_SET(tin , if (netin) { FD_SET (net , (netex) { FD_SET (net , if if &obits) ; &obits); &ibits) ; &ibits) ; &xbits) ; UNIX MAGAZIN E 2002.1 if (errno return 0 ; printf ("s1eep(5) from telnet , - after select : %s\r\n" , strerror(errno) ) ; s1eep(5) ; = EINTR) { return 0 ; クリプタです。これはネットワークからの言もムみ用のファになります。ますは、例外条負 : を表すファイル・ディス以降は、各ファイル・ディスクリプタに関連した処理間を作ったあとに return で関数を終了しています。対処方法があるわけではないので、 sleep ですこし待ち時を石忍しています。とはいえ、それ以外の場合にもとくに返ると同時に errno に EINTR カ材褓内されるので、それます。割込みにより select の実行カ鮗了した場合、一 1 がこではその処理もしていが失敗したようにみえるので、られない状況もありえます。そのときも見かけ上は select ている場合には、割込みなどにより select の実行を続けラーが発生したときです。しかし、 select がプロックし select システムコールが一 1 を返すのは、基本的には工うがよいように思えます。ことも考えられます。もうすこし汎用的な手段をとったほのでしようが、別の部分を修正した場合は 16 以 E になるディスクリプタは 16 を超えることはないと石言しているこで扱うファイル・おそらく telnet コマンドの作者は、 select の第 1 引数として整数の 16 を指定しています。 81

8. UNIX MAGAZINE 2002年1月号

BØC マンドを利用する。言田は、それぞれに伺属のマニュアルを参照してもらいたい。この種のソフトウェアをとりあげるときは、できるかぎり詳細に説明するよう心トけてきた。しかし、今回のテーマは高性能 " サーバーの構築である。その観点から IPVS とハードウェア実装のレイヤ 4 スイッチを上交すると、残念ながら IPVS のバケット中幻当生能は著しく低い。現在のネットワークで、 UNIX システムを用いて糸各制御をおこなうことがはとんどないことからも分かるように、ソフトウェアでの実装では十分な註能か得にくいのである。そこで、今回はあえて細かな説明をしないことにした。 IPVS の成疋については、 Linux Vir- tual Server Project のサイトから多くのサンプルファイルがダウンロードできる。これらを読めば、すぐに使えるはすだ。 IPVS のもう 1 つの問題は、ロードバランサーか普通のコンピュータ上に実装されるため、ロードバランサー自身が Sin- gle Point ofFailure となってしまうことだ。つまり、ロードバランサーか沽郊章すると、サーバーはまったくサービスを提供できなくなる。ハードウェア実装されたレイヤ 4 スイッチも古郞章することはあるが、普通のコンピュータとくらべるとその確率はかなり低い。フラッシュメモリからプートできる PC を使い、機械的に下力する部分のない IPVS ロードバランサーを構築することもできる。しかし、これは別の意味で管理と実装が大変である。その労力も考えれば、ハードウェア実装されたレイヤ 4 スイッチを導入するほうが合理的であろう。連載 /UNIX Communication Notes—O ソフトウェアの根本的な高速化もう 1 つの方法は、サーバー・ソフトウェアの高速化である。ネットワーク・サービスを提供する現在のサーバーでは、 1 つのサーバープロセスが各クライアントに対する処理をおこなフ。このサーバー・プログラムの実装がますけ川ま、もちろん高い性能は得られない。これまでに、サーバープログラムの実装で高い処理性能を得るための試みが数多くおこなわれてきた。以下では、その一端を紹介する。原始時代 UNIX MAGAZINE 2002.1 ープロセスを fork() で複製し、 1 つのプロセスはも装されていた。クライアントからのアクセスがあると、サ (listen() システムコールでの待ち ) 状態となる形式で実てシステムのプート時に起動され、 socket の受信待ち 4.2BSD の時代には、サーバーはすべてデーモンとし JCIass [ 英語版 ] Enterprise Suite 5.0 ー」 ava アプリケーショッ開発のための最強コンポーネントコレクション一 JavaBeans コンポーネントとユーティリティ、 9 製品のセットさまざまな IDE 製品からピジュアルフログラミング JDBC を経由したあらゆるデータベースとの接続 ※グラフ / 3D クラフ / グリッド / 階層型グリッド / 入力フォーム / テータ連結 / メーター / 帳票印刷 / 」 a 「生成ユーティリティ www.bOC.co.jp/jclassenterprise/ 動作環境」 DK 1 . 1 .8 + Swing 1 . 1 . 1 / 」 DK 1 .2.2 / 」 DK 1 .3 標準価格 399 , 000 円 Bytecode Source COde 799 , 000 円開発元 : カナダ Sit 「 aka 社 BOC は文化オリエント株式会社の登録商標です / その他記載されている会社名およひ製品名は各社の商標または登録商標です / 表示の価格に消費税は含まれておりません製品のお求めは BOC オンラインショップにて BOC BuyDirect! www.bOC.CO.jP/shOP/ 文化オリエント株式会社 BØC 本社仙台市泉区七北田字白水沢 14- IAKAMA ヒル〒 981-3131 Td022-373-0360 F 022-373-1625 63

9. UNIX MAGAZINE 2002年1月号

VMwareWorkstation ホスト協調型 VMM における IIO テパイスの仮想化 ~ Jeremy Sugerman 、 Ganesh Ve 社 ac わ a m 、 Be 9- 村 0 9 Lim 要約仮想マシンは、メインフレーム・コンピュータへの対話型の同時アクセスを実現するために、 1960 年代に IBM によって開発された。個々のイ反想マシンはべースとなる物理マシンの複製であり、物理マシンを巣作しているような錯覚をユーサーに抱かせる。また、仮想マシンを使うと資源の分離や共有などの利点カ碍られ、不頁や構成の異なるオペレーティング・システムを実行することができるようになる。 VMware Workstation は、このようなメインフレーム・クラスの仮想マシン技術を、 PC べースのデスクトッフ・コンヒュータやワークステーションにもたらすものである。本論文は、 VMware Workstation による I/O テンヾイスのイ反想化に焦点を当てる。 PC はさまざまなハードウェイ反想マシンの概念は、きわめて高価なメインフレーム・アをもち、オペレーティング・システムカワ。レインストーハードウェアを時分割する方法として、 IBM が考案したルされている場合が多い。 VMware Workstation は、フものである [ 4 , 5 ] 。 IBM の定義によると、、、仮想マシン " レインストールされたオペレーティング・システムを置きとはべースとなる物理マシンのハードウェアの完全に保換えるのではなく、これを利用してユーザーレベルのアフ護、分離されたコピーである。そのため、各イ反想マシンのリケーション (VMApp) コンポーネントを重川させ、特ューサーは自分専用の物理マシンを使っているような感覚権モードの仮想マシンモニター (VMM) コンポーネントを得られる。また、ソフトウェア開発者は、物理マシンのをスケジューリングする。 VMM は高性能な CPU の仮クラッシュやほかのユーサーへの景グを心配せすにプログ想化を直接実現し、 VMApp はホスト・オペレーティンラムの開発とテストをおこなうことができる。グシステムを使って I/O デバイスを佖想化して、さまざまなデバイスから VMM を隠蔽する。このようなホスト従来の仮想マシンシステムの構成を図 1 に示す。 VMM 協調型アーキテクチャ (hosted architecture) によるテンヾ (Virtual Machine Monitor : イ反想マシンモニター ) と呼イスのイ反想化では、スルーブットカ吠きく遅延の小さなデはれるソフトウェア層がマシンのハードウェアを完全に制バイスに要求される性能を実現できるかどうかがきわめて御し、イマシンを作成する。イ反想マシンはそれぞ独重要な間題となる。自のオペレーティング・システム ( 以ード、 (S) を実行でこうした目的を達成するため、我々は VMware Work- きる完全な物理マシンのように振る舞う。 1 つの OS がマ station における Ethernet アタフタのイ反想、化とその性能について調査した。その結果、最適化をおこなえは、 VM- ware Workstation のホスト協調型イ反想化アーキテクチャは、オ剽勺な PC のネイテイプ I/O のスルーブットに匹敵することが明らかになった。 733MHz Pentium III のシステムで 100Mbps Ethernet を使用した場合、イ反想化にともなうオーバーヘッドのため、単純なホスト協調型の実装では CPU の性能による制約を受けるが、 CPU 利用率の肖鹹を目的とした一連の山も商化を施すと、ネイテイプのネットワーク・スルーブットに卩攵するシステムを実現できる。その他の最適化については、ホスト協調型アーキテクチャの内側と外側の両面から角見する。 158 UNIX MAGAZINE 2002 ユ

10. UNIX MAGAZINE 2002年1月号

放棄せすに、領域切替えの回数を大幅に減らすための最商化を実装した。 VMM での I/O ポートの里ホスト領域への領域切替えを要求するイ反想 I/O アクセスは、物理 I/O デバイスへのアクセスを要求するものだけであることを思い出してはしい。 I/O 命令の大半は Lance のデータポートへのアクセスであり、バケット送信の引き金になるのはこのうちの 3 分の 1 にすぎない。残りのアクセスはイ瓦想 Lance のデータポートの状態を変更するだけであり、領域を切り替えなくても VMM で簡単に直接処理できる。したがって、実際に I/O を要求しない OUT ・命令のエミュレーションは、 VMware Work- station 2.0 の 10 分の 1 以下の時間て夫現することができるようになった。また、 Lance のアドレスレジスタがもつ動 ( 信生を利用すると、 Lance のアドレスポートへの I/O アクセスの処理コストはさらに咸できる。 Lance の言翹 ( りと書込みには副作用がなく、最後に書かれた値をイ寺するだけである。そのため、 VMM にアクセスする命令か特権モードの命令であっても、 VMM は特別な場所に保存するだけの単純な MOV 命令としてそれらを処理できる。これにより、 VMM はいくつかのイ瓦想化層を不要にし、これらのアクセスを処理するための命令を減らすことかできる。言の結合第 2 の最適化は、大量の I/O をおこなうワークロードでは割込み率が高く、ホストの IRQ を受信するたびに VMM 領域からホスト領域に切り替える必要があるという事実を利用して、さらに領域切替えの回数を減らす。 VMware Workstation 2.0 では、 Lance アタフ。タにバケットが送信されるたびにホスト領域に切り替えて、プリッジて鮟続されたネットワークにバケットを送信する。 Lance のデータポートのエミュレーションの一部を VM て夫行するようにしたため、 VMM は割込みによって次にホスト領域への切替えが発生するまで、実際の送信を遅らせることかできる。具体的には、次のようにして送信の結合をおこなう。 VMM は、システムの領域切替え率が高いかどうかを調べる。切替え率 ( べき成袞カウンタで定期的に再言 t 算すーーー ~ ーる ) ~ ー ~ が一ト分に高い場合、 VMM はゲスト OS がバケット UNIX MAGAZINE 2002.1 I/O デバイスの仮を送信する際に、それをリングバッフアのキューに入イ反想マシンに制御を戻す。次に実際に割込みが発生し、制御が VMApp に戻されたら、リングバッフアにある未処理のバケットを送信する。これにより、バケット送信による領域切替えと、割込みによって発生した領域切替えをまとめることカきる。バケットをキューに入れる作業にはコピーは必喫ない。バケットをイ瓦想 Lance コントローラの送信リングバッフアに残せばよいのである。遅延させるバケットの数が多い場合訓点のデフォルトは 3 ) 、 VMM はネイテイプ NIC を有効に利用するために、強制的に領域を切り替えてバケットを送信する。また、ホストのシステムタイマーを利用して次の IRQ には領域切替えが保証されるため、バケットが 2 回以一日屋延することはない ( 遅延が 1 回発生すると、 VMApp は必要であれば送信の結合を中止する ) 。こうした最適化は、大量の I / O を扱うワークロードでとくに大きな保カ碍られる。割込み率カ皜いと、連続して I/O カリ用されるかぎり領域切替えが抑制されるからである。送信の結合は、ゲストとホストの IRQ にも効果がある。ゲストはバケットがキューに入れられると即座に実行を続けるため、次に強制的な領域切替えが実行されるまでに、ゲストがバケットを連続して送信できる可能生か咼い。そのため、 VMApp は複数の送信バケットを 1 回の領域切替えで処理することかできる。また、一 -- 漣の処理に対してイ反想 IRQ を 1 つだけ伝えればよい。前述のように、イ課 IRQ の伝達とそれに関連する襯在モードのイ廨課化命令は、コストの高い操作である。また、複数のバケットを同時に送信すると、ホスト領域での実行中にネイテイプの送信完ードウェア割込みがホスト領域了割込みか得られたり、で実行さ VMM 領域で実行した場合よりも高速に処理される可能性か増える。 IRQ 通知第 3 の最適化は、バケットの送受信通知を受け取るための、ホストのシステムコールを減らすことに照準を定めている。 VMApp はネノ測」化の際に VMNet ドライバとの共有メモリを設定し、バケットがくると VMNet ドライバはビットべクトルを設定する。次に、 NIC の IRQ ごとに select() をすべてのデバイスに対してイ月するというコス 167