はじめに

はじめまして。Retty株式会社の鹿島と申します。今回からこのblogに記事を書かせていただくことになりました。今後、読者の皆さんのご意見なども取り入れつつ、何か役に立つような内容を書いていければと思っていますので、よろしくお願いします。

この記事の内容ですが、我々が開発しているRettyというWebサービスでの実例を通じて、教科書にはあまり載っていないtips、落とし穴等を紹介したいと思います。対象読者として以下のような方を想定しています。

• Webサービス開発に興味がある人
• これからはじめようと思っている人（比較的初心者の方）

具体的には以下のような経験があることを前提としています。

• （言語を問わず）プログラミングの経験
• Facebook等のWebサービスの使用経験

このサイトに来ている方の大多数は、この前提をクリアしているだろうと思います。

Rettyのサービス概要

Rettyのサービスページ

まずは、我々が開発しているRettyというサービスについて少し紹介させて下さい。Rettyは「行ったお店を共有する、記録するソーシャルグルメサイト」です。具体的な機能は以下のようになります。

• 行ったお店のレビューを投稿する
• 「友達」や「嗜好の合う人」をフォローして、その人達の投稿をタイムライン（TL）上で閲覧する
• 行きたい店があった場合には、行きたいリストに追加する
• スマートフォンで、現在地付近の人気のお店、行きたいリストに追加したお店を検索する

サービスはWeb、iPhone、Androidのマルチプラットフォームで展開していますが、以下のように使い分けている方が多いようです。

• TLの閲覧やお店の行きたいリストへの追加 → Web
• 現在地付近のお店検索 → スマートフォン
• 投稿 → Web、スマートフォン両方

外部APIの活用

ここ最近のほとんどのWebサービスが何らかの形で外部のAPIを使用しています。大雑把に分類したものが以下の表1です。ここに書いた以外にも多数のサービスがAPIを提供しており、有名なサービスであればほとんど全てが何らかの形でAPIを公開しているのではないでしょうか。

表1：主なWebサービスが外部に提供しているAPI

以下、Rettyで使っているものを中心にいくつか紹介していきます。

rate limitsとは

各種サービスのAPIドキュメントを読んだことがある方はご存知かと思いますが、各APIによって投げられるリクエストの数に制限があります。その制限を超えると

• APIが一時的に使用不可となる
• （頻繁にlimitを超えると）以後のアクセスが拒否される

など、サービス継続にとって致命的な事態となります。

rate limits対策

サービス継続にとって致命的なrate limit超過を避けるには何か対策を施す必要がありますが、Rettyでは主に以下の2つの対策をとっています。

• キャッシュ（cache）
• クライアントからのAPI呼び出し

今回はこのうち「キャッシュ」に焦点を当ててお話していきます。

外部APIにおけるキャッシュ使用とは以下のようなことを指します。

• 外部APIを呼び出して返って来た結果をシステム内部のキャッシュに保存
• 「同じリクエスト」があった場合は外部APIを再度呼び出さずに内部のキャッシュに保存した結果を返す

基本的にはリクエストに対するレスポンスをキャッシュに保存しておき、「同じリクエスト」が来た場合にはキャッシュに保存したデータを返します。

キャッシュを使用するメリットとしては以下の2つです。

• 外部API呼び出し回数の低減
• レスポンスタイムの低減（外部API呼び出しにかかる時間 > キャッシュからの読み出し時間）

今回はRettyにおけるfoursquare検索結果のキャッシュを例に、説明していきます。

キャッシュのキーと内容

次にキャッシュを検索する際のキーと、キャッシュする内容について説明します。先ほど「『同じリクエスト』があった場合は外部APIを再度呼び出さずに内部のキャッシュに保存した結果を返す」と書きましたが、何をキーにして「同じリクエスト」と判定すれば良いのでしょうか。 まずはキャッシュするデータに関して考えてみます。Rettyでは以下のような場面でfoursquare APIを使用しています。

• スマートフォン → 現在地周辺のお店検索
• Web → エリアとキーワードによるお店検索

foursquareに投げるリクエストとしてはそれぞれ以下のようになります。

• スマートフォン

  • 現在地の情報（lat、lng）[1]
  • キーワード（オプション）

• Web

  • エリア・駅の位置情報（lat、lng）
  • キーワード

[1]	lat=latitude=緯度、lng=longitude=経度

以下の擬似コードのように、lat、lng、キーワードの3つの組み合わせをキャッシュのキーとしてその結果を返す方法が考えつきます。

$key = "$lat:$lng:$keyword";
//キャッシュの読み出し
if (($result = getMyCache($key)) === false) {
  //キャッシュなしの場合・・・
  //foursquareのAPIを呼び出して
  $result = callFoursquareAPI($lat, $lng, $keyword);
  //結果をキャッシュに保存
  saveCache($key, $result);
}
return $result;

キャッシュの有無をチェックする

この方法で単純に実装してしまうと、スマートフォンの場合に期待したようには上手く動作しません。なぜかと言うと、全く同じ位置（=同じlat、lng）からお店検索が呼び出されることはほとんどないため、キャッシュにヒットすることもほとんどないからです。

そのため、キャッシュの有無をチェックする際にlat、lngにある程度の幅を持たせて検索する必要があります。例えば、100m以内で実行した検索結果があればそれを返す、といった感じです。

またキーワードに関しては、それを単純にキーにしてしまうと「焼肉」と「焼き肉」が違うキャッシュになってしまうという問題があります、Rettyでは、全文検索エンジンであるSolrと組み合わせてこの辺を解決していますが、これに関してはここでは触れません。

まとめ

今回は以下について説明しました。

• 私が開発に携わっているRettyというWebサービスの内容、およびWebサービス開発上で必要と思われる事項
• 最近のWebサービスで使われている主な外部APIについて
• 外部APIのアクセス数制限の超過を避けるためのキャッシュの設計

次回はMySQLSpatial Extensionsを使用して、位置情報を検索する方法について説明します。

フリーソフトウェア/オープンソースソフトウェアの集合体としてのシステム

ePUBの作成にはいろいろな手法がありますが、制作を支えるシステムを構築する上で最も重視したのは、できる限り自動化し、手作業による調整を最小限にするということでした。そのため、このシステムでは原稿を常に最新マスターデータとしてそこから一方向にePUBを作成するバッチ型としており、たとえばSigilなどでePUBを後で細かに手直しする、といった手法は採用していません。

また、将来にわたって保守・改良が制作関係者自身の手でできるよう、中核部分をフリーソフトウェア/オープンソースソフトウェアで構成し、原稿の形式もオープンなものであることも当然の前提です。

さらに、訳者や編集者など制作にかかわる人たち（このシステムのユーザ）は、文章についてはプロフェッショナルであるもののソフトウェアについてはそうではありません（逆もまた真なり、ですね）。新しくツールを導入したことでそれに振り回されないように、ユーザ側から見て新しく導入するものを最小限にし、面倒な部分はできるだけシステムの内部に置くとともに、原稿の文法エラーチェックなどを自動化し、原稿更新に合わせて即座にePUBやHTMLのプレビューもできるようにする必要もありました。

こうした背景からできあがったのが、次の図に示すシステムです。

オライリー・ジャパンのePUBを制作しているシステム

このシステムで採用している技術やソフトウェアの概要をまとめてみます。

原稿からePUBができるまで

前記のように、このシステムではePUBを生成するための原稿データ形式として「ReVIEW」と「DocBook」の2つをサポート対象としています。このたび発表した最初のePUB電子書籍ラインナップ3冊のうち、『Flex 4.5によるAndroidアプリケーション開発』『スケーリングMongoDB』がReVIEW、『マネージャーのための仮想化ガイド』がDocBookを採用しています。ある書籍についてどちらの形式を採用するかは、制作関係者の作業スタイルに大きく依存しており、またそれぞれに利点・欠点があります（次表）。

まずはReVIEWの場合の工程から説明しましょう。

ReVIEWのサンプル

翻訳者または編集者は、ReVIEW形式の翻訳原稿を、まずその書籍専用のSubversionリポジトリに登録（コミット）します（SubversionにもReVIEWにも抵抗ない、という翻訳者はまだそういないので、これを行うのはほぼ編集者ですが）。編集作業も同様に、原稿ファイルを修正してはSubversionリポジトリにコミット、という作業を繰り返すだけです。

さて、何らかのコミットが行われると、Subversionリポジトリにあらかじめ設定してあるフックで、制作関係者のメーリングリストにコミット内容（以前のバージョンとの差分）が送られるとともに、CIサーバのJenkinsに通知が届きます。これを受けてJenkinsは、該当リポジトリに付随するMakefileをGNU Makeで実行します。Makefileの中では、ePUBを生成するために、次のような手続きを呼び出します。

1. ReVIEW形式ファイルを別形式に変換する「review-compile」コマンドを実行し、汎用XHTML形式に変換する
2. 1.で生成されたXHTMLファイルは汎用的なもので、オライリー・ジャパンの電子書籍のデザインとは異なる部分が多いため、フィルタスクリプト（Rubyで記述したもの）に通して加工する
3. リポジトリにあるメタ情報ファイル（YAML形式のファイル）に従い、カバーや奥付などを生成する
4. リポジトリに特定の最終調整プログラムが存在するなら、ファイル群をePUBとしてパッキングする直前に、それを実行する（たとえば「カバーの書名の特定箇所で改行する」）
5. ePUBとしてパッキングする
6. 制作関係者のためのWeb公開領域に、ePUBファイルおよびその展開物をプレビューのために配置する

この手続き中に何らかの失敗が起きた場合は、警告とともにその経緯のログが自動でメーリングリストに送付されます。これにより、ユーザはどの時点のコミットで問題が発生したかがすぐにわかるわけです。

続いてDocBookのほうの工程も見てみましょう。

DocBookのサンプル

こちらもほぼReVIEWの場合と変わりません。翻訳者または編集者がDocBook形式の翻訳原稿をSubversionリポジトリにコミットし、編集作業ではやはりこの原稿ファイルを修正してコミット、を繰り返します。ただし、DocBook形式はまだ作業者にタグのミスや、当初は想定していなかった要素処理が必要になることもあり、度重なるJenkinsのエラーにユーザが落胆してしまう恐れがあります。そのため、現時点ではJenkinsのビルドを有効化する前に、筆者がまずデータの検証と大まかな調整をかけるようにしています。

コミットに対するSubversionリポジトリのフックで、メーリングリストへの通知と、Jenkinsへの通知が行われ、Jenkinsは次の手続きを行うmakeを実行します。

1. DocBook形式ファイルをePUB形式に変換する「dbtoepub」コマンドを実行する。オリジナルのdbtoepubコマンドに各種のフックやパラメータ指定の機能を加え、カスタマイズしたものとなっている
2. dbtoepubコマンドでのePUB形式への変換の実体は、XSLTによるものである。オライリー・ジャパンの電子書籍のデザインに合わせたXSLTのセットを呼び出し、XHTMLへの変換を行う
3. リポジトリにあるメタ情報ファイルに従い、カバーや奥付などを生成する
4. リポジトリに特定の最終調整プログラムが存在するなら、ファイル群をePUBとしてパッキングする直前に、それを実行する
5. ePUBとしてパッキングする
6. 制作関係者のためのWeb公開領域に、ePUBファイルおよびその展開物を配置する
7. DocBookの場合、原稿のXMLの書き方によっていくつかの問題（リンクテキストが空になるなど）が発生することがあるため、チェッカーを実行して可能性のある問題を検査する

こちらも、途中で何か問題があれば経緯のログが自動でメーリングリストに送付されます。

ユーザはこうしてできたePUBファイル、あるいはプレビュー用のHTMLファイルをWebブラウザやePUBリーダで確認し、修正すべき箇所があれば原稿ファイルに手を入れてコミットする、ということになります。そして、読者の皆さんに販売できる品質になったとオライリー・ジャパンが判断した時点で、そのときの最新のePUBファイルがそのまま販売用のePUB電子書籍商品となるわけですね。

まとめ

いかがでしたでしょうか。「ReVIEWあるいはDocBook形式の原稿ファイルからePUBファイルを作る」という工程だけ見れば自動化は果たせたものの、選定、翻訳、編集といった大半の部分は、現代のテクノロジーでは（そしておそらく今後とも）人間の手が必要です。今後のePUBフォーマット電子書籍制作を継続させていくためにも、シリーズの順調な販売を祈りつつ、読みやすさのさらなる向上や、ePUBバージョン3への対応なども進めていきたいと思います。本稿やePUB電子書籍についてのご意見・ご感想、お待ちしております！

参考

本稿で紹介したシステムで制作した書籍と、関連する書籍を以下にご紹介します。

本稿のシステムで制作した書籍

Flex 4.5によるAndroidアプリケーション開発

スケーリングMongoDB

マネージャーのための仮想化ガイド

入門 ソーシャルデータ

関連書籍

GNU Make 第3版

Head First Rails

初めてのRuby

実用 Subversion 第2版

武藤健志

株式会社トップスタジオ執行役員。編集業務のほか、自動DTPシステム構築、社内インフラ管理、技術コンサルティング、3時のおやつ作り、その他諸事雑用と手を広げて自分の首を絞めている。Debian Project公式開発者だが、最近その作業に充てる時間を取れないのが悩み。Twitter: @kmuto

対象環境

この記事では、 Python 2.7.2 でソースコードを実行して確認しています。

コーディングスタイルについて

名前空間やスコープの前に、まずは基本的なコーディングスタイルについて軽くお話しします。

Python のコーディングスタイルというと、 PEP 8 – Style Guide for Python Code (日本語訳は こちら )が有名です。 これは、 Python でプログラムを書く上で守っておくとよいお作法について書かれており、 Python のコーディングスタイルとしてはデファクトスタンダードといえるでしょう。

この PEP8、例えば以下のようなことが書かれています。

• インデントは 4 スペースで
• タブとスペースを混ぜて使わない

といったような Python らしいインデントの話から

• 演算子の前後にスペースを入れる
• 代入演算子を縦にそろえるためスペースを入れることはしない
• モジュール・クラス・変数・関数などの名規則
• 推奨される例外処理方法

などの書き方に関することまで広範に及びます。

Python で開発をするのであれば一読しておくことをオススメします。 また、このスタイルを守ると多くの Pythonista にとって読みやすいソースコードになるのではないでしょうか。

C++ でのスコープ

例えば C++ では、波括弧で囲まれたブロック単位でスコープを作ることができます。 以下のように if 文のブロック内という局所的なスコープが存在します。

const int y = 20;

if (condition)
{
    // if 文のブロック内のスコープ
    const int x = 10;
}

std::cout << x + y << std::endl; // x が見つからず、エラーになる

同様に for, while, do, try 等でもスコープが導入されますし、以下のように波括弧を付けただけであっても局所的なスコープが作られます。

const int y = 20;

{
    const int x = 30;
}

std::cout << x + y << std::endl; // x が見つからないためにエラー

Python のスコープ

Python においては、モジュールのスコープと関数のスコープしかないため、以下のようなソースは実行できます。

def test():

    if condition:
        x = 20
    else:
        x = 30

    print x

if のようにブロックを伴う文の中であっても外側と同じスコープであるため、 if のブロック内で初めて出てきた変数名であっても、 if 文が終わった後であっても使えます。 for, while, try 等のその他の制御構文であっても同様です。

try:
    import cPickle as pickle
except ImportError:
    import pickle

スコープ中の名前空間

Python においては、スコープの範囲が関数単位と大きく、中に含まれる変数の数が増えがちです。 変数の数が増えるということは、一つの関数の中で把握するべき状態の組み合わせが増えるということですので、なるべく細かな単位で関数に分け、それらを呼び出すようにした方がいいでしょう。 また、そうした細かな関数を多く定義する方がユニットテストを書く上でも楽になります。

私の場合は、細かくするときは一つの分岐する処理 for, if ごとに関数で分けることもあり、関数が増えがちです。 あまりに細かな関数が増えてしまうような場合は、次章で紹介する関数中関数を定義することによって、外にその関数を見せないようにするという手も使えます。

関数の中の関数

Python では、関数の中で関数を定義できます。

def outer(x):

    def inner(y):
        return x + y # 外側の環境の x と y を足す

    return inner # outer 関数の中で定義した inner 関数を返す

result = outer(10)

print result(20) #=> 30

outer 関数の中で定義した inner 関数では、 inner 関数のローカルスコープだけでなく、外側にある outer 関数のスコープも参照できます。 また、 outer 関数を呼ぶと inner 関数を生成して返し、 outer 関数を抜けてしまいますが、 return 文で返された inner 関数では生成されたときの outer 関数実行時の環境を持っており、 inner 関数ではその保持された環境を参照します。

このような仕組みは「クロージャ」や「レキシカルスコープ」と呼ばれ、関数型言語などでよく見られます。

このような関数は、関数の中で局所的に使うような map, filter, reduce 等の高階関数に渡すための関数を定義する場合によく使います。

def list_mul(items):

    def mul(x):
        return x*2

    return map(mul, items)

print list_mul(range(5)) #=> [0, 2, 4, 6, 8]

この程度であれば mul 関数を定義せずに、 lambda x: x*2 と無名関数を使うこともできますが、煩雑な処理が増えてるような場合は関数として定義します。

このように、ネストした関数を定義しておくと、関数のスコープに限定した名前空間ができ、その内部のみで完結するようになるため、ネストの外側のスコープと切り離して考えることができます。

ネストした関数の使いどころ

ネストした関数は、上記のような用法の他に主にデコレータの定義などで使われることが多いですが、私の場合は GUI アプリケーション開発などで使っています。

例えば、以下のような PySide のソースコードがあるとします。

#-*- coding:utf-8 -*-

import sys
from PySide import QtGui as gui, QtCore as core

app = gui.QApplication(sys.argv)


window = gui.QFrame(None)

layout = gui.QVBoxLayout(None)

b1 = gui.QPushButton('add')
b2 = gui.QPushButton('remove')
listw = gui.QListWidget()
text = gui.QLineEdit()

layout.addWidget(listw)
layout.addWidget(text)
layout.addWidget(b1)
layout.addWidget(b2)

window.setLayout(layout)

window.show()

app.exec_()

これを実行すると以下のようなリストボックス, テキストボックス, ボタン二つを持つウィンドウが表示されます。

サンプルのスクリーンショット

ここで、「add ボタンをクリックしたらリストにアイテムを追加」、「remove ボタンをクリックしたら選択したアイテムを削除」という動作を付けようと思います。

これを実装する際はクリック時のイベントを定義して、それぞれボタンに適用するという処理を書く必要があります。 これを、ただ関数を定義するのではなく、関数とその中で定義した関数で書くと以下のようになります。

#-*- coding:utf-8 -*-
def create_event(itemlist, text, add, remove):
    u'''
    リストコントロール、テキストボックス、ボタン二つにイベントを追加する
    '''

    def add_clicked():
        u'''
        追加ボタンがクリックされたら入力されたテキストをリストに追加する
        '''

        value = text.text()
        itemlist.addItem(value)


    def remove_clicked():
        u'''
        削除ボタンがクリックされたら選択されたアイテムを削除する
        '''

        index = itemlist.currentRow()

        if index > 0:
            itemlist.takeItem(index)

    # イベントハンドラを追加
    add.clicked.connect(add_clicked)
    remove.clicked.connect(remove_clicked)

そして、以下のように使います。

create_event(listw, text, b1, b2)

このように、ただ関数を二つ定義するのではなく、「4つのコントロールに対するイベントハンドラ生成関数」として定義してあげると、これらのコントロールのセットが増えた際にも同じ関数を呼び出すだけでイベントが適用できるため、手間が省けます。 処理を生成する関数を呼び出す、と言った感覚でしょうか。

このように、イベントハンドラの定義と適用を生成関数に閉じこめることで、再利用性の高いコードになります。 また、ロジックと関連するデータが小さな範囲にまとめられるため、見るべき変数が減って、わかりやすくなります。

ただし、このような関数の中で行う処理が増えてきたり、一つの関数が長くなったりするとソースコード上であっちこっちに処理が飛んでしまい、デバッグ時の見通しは悪くなってしまうので注意が必要です。 あまりに長くなるような生成関数を使う場合は、素直にクラス化してまとめた方がよいでしょう。

モジュールインポート

モジュールのインポートというものは、対象のスコープの名前空間に対して変数を導入するという構文であると捉えることができます。 ここでは、私なりのモジュールのインポートスタイルについて語ってみます。

import os
import sys

from subprocess import Popen, PIPE

import os, sys

# 標準モジュール
import sys
import os

# サードパーティモジュール
from lxml import etree, html
from zope.pagetemplate import pagetemplate

# アプリケーション or ライブラリ固有のモジュール
from myapp.mymod import somefunc

from module import *

# module.py
values = ['aaa']

# source.py
from module import values

import module
module.values = {}

class SomeClass(object):

    # 省略

    def some_method(self, x, y):

        v = y * x

        return function(self.x) + mod.calc(v)

from outermodule import innermodule as inner

import os

# 省略

def func():
    u'''
    os.listdir を大量に呼ぶ関数であるとする
    '''

    listdir = os.listdir

    # ローカル変数 listdir を使って os.listdir を呼び出すようにする

まとめ

私の書くソースコードの基本的な方針としては、「スコープと名前空間に気を遣うことでソースコードを俯瞰したときに、状態を把握しやすくし、ソースコードを読む効率を上げる」ことであるといえると思います。 ソースコードは書くよりも読むことが多いため、読みやすくすることが開発効率を上げることにつながります。

以上、私が Python でソースコードを書く上で気にしているスコープと名前空間に関してお話しました。

Mac OS へのインストール

Mac OS では homebrew か MacPorts を使って簡単にインストールできます。

homebrew:

$ brew install git-flow

MacPorts:

$ port install git-flow

Linux へのインストール

Linux へは 利用しているディストリビューションのパッケージ管理システム、 もしくは以下のコマンドによってインストールできます。

$ wget --no-check-certificate -q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | sudo bash

Windows へのインストール

Windows の場合は git 本体のインストールを Cygwin 、 msysgit どちらで行ったかによってインストール方法が異なります。

Cygwin:

$ wget -q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

git-flow を利用する

簡単な利用方法を例示するために、 github 上に spam というプロジェクトを作成します。

最後に

今回は git-flow に触れてみました。同様のツールとして、ほかに Sotaro Karasawa 氏が公開されている git-daily 等もあります。最初に戻りますが、git の長所の一つはブランチモデルです。自分やチームにあったツールを使い、 git のブランチモデルを最大限活用してみてください。

Union機能の比較

aufsとdm-snapshotの比較は、前述のようにcopy-upの際のコピー量が異なるため、サイズの大きなファイルの書き換えはdm-snapshotの方が良好な結果となることは容易に想像がつきます。同様にreaddir(3)もdm-snapshotの方が有利と予想できます。その他は上位から下位へとレイヤを辿る処理が実質的な差となると思われ、ブロックデバイスレベルとファイルシステムレベルの比較となり、これも全般的にdm-snapshotの方が有利と予想できます。ファイルシステムへのアクセスは内部でブロックデバイスへアクセスするわけですから、ファイルシステムレベルの方がオーバヘッドが大きくなることはまず間違いないでしょう。

読み取り専用圧縮レイヤの比較

比較項目

上記を踏まえ、比較項目を以下のとおりとします。

1. ext2
2. squashfs-4.0 GIP
3. squashfs-4.0 GIP -no-fragments
4. squashfs-4.0 GIP + parallel decompression patch
5. squashfs-4.0 GIP -no-fragments + parallel decompression patch
6. ext2 + cloop GZIP
7. ext2 + squashfs-4.0 GIP + nested loopback
8. squashfs-4.0 LZMA (linux-2.6.34-rc6)
9. squashfs-3.4 + sqlzma patch (linux-2.6.27.4)

squashfsのブロックサイズやLZMAの辞書サイズを調節すると所要時間を短縮できますが、バリエーションを増やすと測定の手間がかかりますし、条件が同一ならば傾向は変化しないだろうと思われるため、デフォルト値のみを採用することとします。

カーネルバージョンは、squashfs 4.0LZMAおよびsquashfs 3.4+sqlzmaを除き、すべて2.6.33とします。squashfs 4.0 LZMAは2.6.34-rc6、squashfs 3.4+sqlzmaは2.6.27.4とします。cloop-2.636はそのままではコンパイルできなかったので、2.6.33用に修正を加えました（cloop-2.636-2.6.33.patch）。

比較方法は次の通りとし、圧縮結果サイズと、読み取り／展開時の所要時間、CPU消費に注目します。 CPU時間の大半は別カーネルスレッドにより消費され、find(1)やcat(1)を対象とするtime(1)による単純測定では測定範囲外となるので、若干粗くなりますが、vmstat(8)も併用することにします。カーネルレベルのプロファイラなどを使用すれば、より精度の高い測定が可能かもしれませんが、今回は粗いレベルで留めます。

1. 複数ファイルをreaddir(3)で見つかった順にread(2)する（シーケンシャルアクセスとして）。
2. 複数ファイルをreaddir(3)とは異なる順序でread(2)する（ランダムアクセスとして）。

それぞれ、シングルプロセスで繰り返しcat(1)する場合と、cat(1)を複数同時に並列実行（マルチプロセス）する場合の二通りを測定します。 Union機能の比較と同様に複数回実行した測定結果を図6、図7に示します。測定スクリプト一式は添付ファイルに含めてあり（decomp.sh）、測定データは本記事末表3に掲載していますので、必要に応じて参照してください。

図6 読み取り専用圧縮レイヤの比較（シングルプロセス、クリックすると拡大）

図7 読み取り専用圧縮レイヤの比較（マルチプロセス、クリックすると拡大）

ファイルサイズ 当然ですが、squashfsの-no-fragmentsオプションを用いない方がサイズは小さくなります。これは圧縮対象内に小さなサイズのファイル数に依存します。LZMAを用いると-no-fragmentsオプションを用いなくとも、更に小さくなっています（11.1%削減）。ハイブリッド圧縮方式を採用しているsqlzmaパッチでは更に小さくなります（11.2%削減）。

cloopはsquashfsよりも大きなサイズになっていますが、これは今回の測定方法にも一因があります。元のファイルシステムイメージをext2で作成しましたが、ピッタリのサイズにするのは手間がかかるため、イメージファイルはやや大きめにしてあり、未使用領域が含まれます（今回の測定に使用した元イメージのファイルサイズは約732MBで、その内の約75MBが未使用領域です）。この未使用領域が圧縮結果サイズにどれだけ影響するかは調べていませんが、恐らくは圧縮結果サイズを削減できる余地があると思われます。squashfsを作成する場合は未使用領域はゼロもしくは最少になります。ファイルシステム種別もiso9660などに変更することでサイズを削減できる期待があります。今回の測定では前述の通り特に圧縮時にパラメータは与えていませんが、もちろんブロックサイズを指定する方がずっと簡単なサイズ削減方法です。

cloopの元ファイルシステムイメージは ext2ですが、これを圧縮／squashfs化したものがフラグメントブロック不使用とキャッシュ効果を狙ったsq40nestedです。同じ ZLIB圧縮なのにsq40nestedの方がcloopよりも圧縮結果サイズが小さくなっているのは、デフォルトブロックサイズの違いが主な要因と思われます。

所要時間 まず、sq40（Squashfs4.0 in vanilla linux-2.6.33）に注目すると、シングルプロセスのシーケンシャルアクセス以外の遅さが目立ちます。マルチプロセスシーケンシャルアクセスでは二倍以上、ランダムアクセスでは四倍以上時間がかかっています。測定環境はdual coreで、理想的にはマルチプロセスはシングルプロセスの半分の所要時間になって欲しいところですが、マルチプロセスの場合でもあまり短縮されておらず、CPUを充分に使い切っていないことが分かります。ランダムアクセスが遅い理由は前述のフラグメントブロックにあり、マルチプロセスが遅い理由は並列展開に対応していないことにあると思われます。CPUコア数が一つのシステムでは、当然ですが、マルチプロセスや並列展開は決して性能向上に貢献しません。

フラグメントブロックを使用しないsq40nofragを見ると、マルチプロセスでの劣化が抑えられており、シングルプロセスと同等になっています。またランダムアクセスでもシーケンシャルアクセスの二倍程度の時間に抑えられています。（本当はdual coreなのですからマルチプロセスの場合はもっと改善されて良いはずですが）恐らく並列展開に対応していないことが原因だと思われます。

並列展開の効果についてはsq40para、sq40nofrag_paraと比較すると分かります。それぞれlinux-2.6.33のsquashfsに前述のparallel decompression patchをあてたもので、用いたsquashfsイメージファイルはsq40、sq40nofragと同じものです。シングルプロセスの所要時間はsq40、sq40nofragと同等ですが、マルチプロセスの方は大きく改善されています。もちろんその分CPUを多く消費しています。

sq40nestedは二重ループバックによるキャッシュが威力を発揮し、非圧縮のext2と同等の結果となりました。ただ、搭載RAMが少ない環境ではやはり劣化すると恐れがあります。

cloopはデフォルトの圧縮ブロックサイズがsquashfsよりも小さいためか、より長く時間がかかっています。マルチプロセスの場合に遅くなってしまうのは、やはり並列展開未対応が原因と思われます。しかし、ランダムアクセス時の劣化は少なくなっています。ブロックデバイスレイヤでの圧縮/展開という点が有利に働いたと思われます。

ext2では最初に測定したシングルプロセスシーケンシャルリードだけが時間がかかっていますが、これはディスクアクセスが影響したと思われ、実際CPUのio-waitが大きくなっています。以降の測定は（ほぼ？）全てのファイルがキャッシュされたようで、io-waitが発生していません。

参考：LZMA対応 参考程度ですが、sq40lzma（linux-2.6.34-rc6のsquashfs4.0 LZMA対応）とsqlzma34（2.6.27.4 squashfs3.4用の sqlzmaパッチ）も同様に測定してみました。やはりLZMA展開処理が原因と思われる遅さが目立ち、sq40（2.6.33の squashfs4.0 ZLIB）の二倍以上遅い結果となりました。sqlzma32はハイブリッド圧縮、並列展開を実装しており、CPUをほぼ使い切っても、それでも遅い結果です。sq40lzmaは更に悪い。

しかし、 sq40lzmaは正式リリースされたものではありませんので、この簡単な測定 /比較だけをもってして遅いと決めつけるのはフェアではありません。今回は測定対象とはしませんでしたが、squashfsはLZMA以外の圧縮方法にも対応を進めており、mainlineにも取り込まれています。

本記事では既に広く利用されている squashfsを中心に、LiveCDの複数の実現法法を見直してみました。 cloopも dm-snapshotも、squashfsも aufsもどれも悪いものではありません。当然ながら、ユーザがサイズ、展開速度、メモリ消費などに明確に優先順位をつけ、最適な圧縮方法を決定するのが肝要となることは変りません。

（初出H22/12）

Copyright © 2010-11 SENJU Jiro

本記事のサンプルコードは、以下のリンクよりダウンロードすることができます。記事と合わせてご参照ください。
[サンプルコード]
また、本稿で取り上げた内容は、記事の執筆時の情報に基づいており、その後の実装の進展、変更等により、現在の情報とは異なる場合があります。
本連載「プログラマーズ・ハイ」では読者からのご意見、ご感想を切望しています。今後取り上げるテーマなどについてもご意見をお寄せください。

表3:読み取り専用圧縮レイヤの比較（図6および7の元データ）

	size (blocks,KB)			elaspsed time	CPU(dual core)
					usr	sys	idle	io-wait
ext2	-	seq	single	27.8	4	22	59	15
			multi	2.2	10	57	33	0
		rand	single	4.2	6	34	60	0
			multi	2.4	10	57	33	0
sq40	437512, 218536	seq	single	9	3	41	53	3
			multi	23.7	1	85	5	9
		rand	single	44.6	1	48	51	0
			multi	42.8	1	87	7	5
sq40para (parallel decompression)	同上	seq	single	8.9	3	42	55	0
			multi	8	4	85	11	0
		rand	single	44.6	1	49	50	0
			multi	23.4	1	93	5	1
sq40nofrag	458264, 228904	seq	single	8.6	3	40	53	4
			multi	8.7	4	77	11	8
		rand	single	16.3	2	45	53	0
			multi	13.4	3	85	9	4
sq40nofrag_para (parallele decompression)	同上	seq	single	8.6	3	41	55	1
			multi	7.6	4	74	13	9
		rand	single	16.4	2	44	53	1
			multi	10.3	3	82	10	5
cloop	521632, 260552	seq	single	15.2	1	38	23	38
			multi	22.7	1	37	7	54
		rand	single	22.8	1	46	21	32
			multi	25.7	2	52	4	42
sq40nested	515336, 257412	seq	single	11.7	2	36	29	33
			multi	2.7	8	59	33	0
		rand	single	5.1	5	36	56	3
			multi	2.9	8	59	33	0
sq40lzma (2.6.43-rc6)	391616, 195612	seq	single	29.7	1	47	51	1
			multi	297.5	0	70	8	22
		rand	single	280	0	50	50	0
			multi	305.1	0	70	25	5
sqlzma34 (2.6.27.4)	390592, 195100	seq	single	21.1	1	47	52	0
			multi	23.4	1	94	4	1
		rand	single	184.8	0	50	50	0
			multi	94.7	0	98	1	1

古代の構成

一般的にLinux LiveCDではシステムをインストールした状態のファイルシステムを圧縮し、読み取り専用ファイルシステムイメージとして収納してあります。この際に用いられるのがsquashfsなどのファイルシステムですが、ここからそのままシステムを起動しても読み取り専用ですから、使用できない部分が生まれます。

圧縮の反対動作を指す言葉は伸長とも表現されますが、本記事では展開と表現します。

例えば、システムを起動すれば各種ログファイルや/var/wtmpファイルに対する書き込みが発生しますし、ファイルシステムをマウントすれば/etc/mtabというファイルも更新されます。デーモンが起動されればサービスに必要な各種ファイルなども作成されます。それぞれを一つづつ調査し、書き込みが発生しないように対処して行くことも不可能ではないかもしれませんが、もちろん手間がかかります。そもそもLinux（UNIX）システムは書き込み可能ファイルシステム上で動作することを前提としているのですから、この努力は有意義とは言えないでしょう。

かつてはシャドウディレクトリ方式で対応しようという時代もありました。シャドウディレクトリとはやや古い呼び方かもしれませんが、X.Org/XFree86以前のX11 Window Systemのビルドなどにも用いられていた（と思うけど、記憶に自信がなくなってきた ）形態です。例えば、ソースファイルが置かれたsrc/下でそのままビルドすると、他のアーキテクチャ用にビルドする際には全オブジェクトファイルを削除しなければなりません。そうすると、先のアーキテクチャ用のリビルド時にはまた初めからすべてをコンパイルしなければならず、この手間暇を節約するための方策として、obj/を別に用意し、全てのソースファイルのシンボリックリンクをobj/下に作成する方法が採られました。この形態がシャドウディレクトリで、ビルドされるオブジェクトファイルはobj/下に作成され、ソースファイルを書く場合にもディレクトリの差異を気にする必要もありません。lndir(1)を用いると、子ディレクトリ、孫ディレクトリも含んだシャドウディレクトリを作成できます。

squashfsとAUFS

その後に用いられるようになったのがUnion機能を備えたファイルシステムである、AUFS、Unionfsです。この機能については以前の記事「UnionMountとUnion-type Filesystem」で取り上げました。簡単に振り返ると、CD-ROM内の読み取り専用ファイルシステムイメージをループバックマウントし、その上に書き込み可能なファイルシステムを透過的に重ねてマウントし、上述の読み取り／書き込みを実現します。既存ファイルを変更する際のコピーもUnion機能が備えるcopy-upにより自動的に行われます。レイヤは複数指定できるので、アプリケーション／パッケージの取捨選択にも応用できます。例えばSLAX LiveCDではコンパイラパッケージ、オフィススートなどを個別の読み取り専用ファイルシステムイメージに分割しており、ユーザが必要に応じレイヤとして追加します。

現在のLiveCDでは、上位の書き込み可能なレイヤにはtmpfsやHDD上のファイルシステムを指定し、下位の読み取り専用ファイルシステムには圧縮機能を備えたsquashfsを、Union機能にはAUFSをそれぞれ用いるのが一般的です。

squashfs作成例

$ mksquashfs /bin /dev /etc /lib /sbin /usr /tmp/squashfs.img \
   -no-progress -noappend -keep-as-directory -comp gzip

squashfsと aufsのマウント例 (LiveCD)

(initramfs内の起動スクリプト)
# mount -o ro /dev/cdrom /cdrom
# mount -o ro,loop /cdrom/squashfs.img /squashfs
# mount -t tmpfs none /tmpfs
# cd /tmpfs; mkdir -p tmp var/log; chmod 1777 tmp; cd /
# mount -t aufs -o br:/tmpfs:/squashfs none /aufs
(以降、/aufsをルートディレクトリしてシステム起動)

上の例を実行した結果構築されるファイルシステムとブロックデバイスのレイヤ関係を図示します（図1）。比較、参考のため、通常マウントのデバイス／レイヤ関係と、ループバックマウントの場合も図示します（図2、図3）。通常、ファイルシステムはブロックデバイスと一対一に対応しますが、ループバックマウントの場合は/dev/loopNという特殊なブロックデバイスを用い、このデバイスが別途マウントされたファイルシステム内に存在する1ファイルに対応します（図3では/dev/sda1内に存在するsquashfs.img）。

図1:squashfsとaufsのマウント例（LiveCD）

図2：通常のファイルシステムマウント例

図3：ループバックマウント例

しかし、上記のようなファイルシステム環境はこの組み合わせ以外でも実現可能です。本章では二つの方法を紹介します。

cloop：ループバックブロックデバイスの圧縮機能

一つ目は圧縮機能をファイルシステムではなく下位に位置するブロックデバイスに実装したcloop（compressed loopback block device）というモジュールです。標準ではLinuxカーネルには含まれていません。

http://debian-knoppix.alioth.debian.org/packages/cloop/cloop_2.636-1.tar.gz

ブロックデバイスレベルでの機能なのでファイルシステム種類を問いません。一度ファイルシステムイメージを作成し、必要ファイルをコピーした後に、create_compressed_fsコマンド（別名advfs）でファイルシステムイメージを圧縮し、cloopイメージを作成します。

cloopイメージの作成/マウント

$ dd if=/dev/zero of=/tmp/ext2.img bs=10M count=1   ---ファイル領域確保
$ mkfs -t ext2 -F -m0 -q -O dir_index /tmp/ext2.img ---ext2イメージ作成
$ sudo mount -o loop /tmp/ext2.img /mnt             ---/mntへマウント
$ tar -C /bin -cf - . | sudo tar -C /mnt -xpf -     ----/binを/mntへコピー
$ sudo umount /mnt
$ create_compressed_fs -q -L9 /tmp/ext2.img /tmp/ext2.cloop.img ---cloopイメージ作成
$ sudo losetup -r /dev/cloop0 /tmp/ext2.cloop.img   ---cloopデバイスと関連付け
$ mount -o ro /dev/cloop0 /mnt                      ---cloopデバイスをマウント（以降/mntをext2として使用可能)

レイヤ関係は基本的に図3と変らず、squashfs以外の任意のファイルシステムを圧縮、使用できます。ループバックブロックデバイスは/dev/loopNから/dev/cloopNへ変更します。上の例では/dev/cloop0というデバイスを用いていますが、これはcloopモジュールがロード時に作成するものです。

また、cloopは書き込みには対応していませんので、cloopでループバックマウントしたファイルシステムは読み取り専用になるため、（疑似的に）書き込みを実現するには、AUFSなどスタッカブルファイルシステムを用いる必要があります。

cloopモジュールを採用しているLiveCDにはKnoppix（とその派生物）があります。

dm-snapshot：デバイスマッパのスナップショット機能

もう一つの方法はスタッカブルファイルシステムの代わりにデバイスマッパのスナップショット機能を用いるものです。デバイスマッパは、やはりブロックデバイスレベルの機能で、論理ボリューム管理（LVM）などの上位ツールから利用されるのが一般的ですが、dmsetup(8)コマンドを用い、デバイスマッパを直接操作することも可能です。

デバイスマッパはファイルシステムの下位に位置するブロックデバイスを操作するもので、スナップショット以外にも暗号化、リニア、ストライプ、ミラーなどの機能があります。暗号化機能はデバイスに対する書き込み/読み取りをデバイスマッパが符号化/複合化するもので、デバイス上には符号化された結果が書き込まれます。リニア／ストライプ／ミラーはRAID一般の機能なので、本記事では割愛します。

スナップショット機能は、デバイスマッパに二つのブロックデバイス、それぞれオリジナルデバイス、COWデバイスと呼びます、を指定し、書き込みはすべてCOWデバイスへ向け、読み取りは対象がすでにCOWデバイスに存在すればCOWデバイスから、存在しなければオリジナルデバイスから読み取ります。まさに、スタッカブルファイルシステム内の読み書き動作が上位/下位レイヤへ振り分けられる動作です（図4）。COWデバイスには変更差分が蓄積され、オリジナルデバイスは変化しません。

デバイスマッパには zeroという機能（dm-zero）もあり、/dev/zeroに似た動作をするブロックデバイスを作成できます（/dev/zeroはキャラクタデバイスです）。すなわち、書き込みは何もせずに単に成功を、読み取りには常に0を返すデバイスです。筆者は有効性を確認していませんが、dm-zeroとスナップショットを組み合わせ、ブロックデバイスやファイルシステムのテストに応用する方法があります。実デバイスよりもサイズが大きな zeroデバイスを作成し、これをCOWデバイスとし、実デバイスのスナップショットを作成します。もし、実デバイスの範囲を越えた位置に I/Oが発生すると、そのI/OはCOWデバイスへ向けられ、結果的に正常に処理されず、エラーを検知できるという方法です。

図4：dm-snapshotマウント例

デバイスマッパによるブロック単位の Copy-on-Write（COW）

（16MBのext2イメージを作成）
$ dd if=/dev/zero of=/tmp/ext2.img bs=1M count=16
$ mkfs -t ext2 -F -q /tmp/ext2.img
$ sudo mount -o loop /tmp/ext2.img /mnt
$ > /mnt/fileA
$ sudo umount /mnt

（サイズが1MBのCOWイメージを作成、sparseファイル）
$ dd if=/dev/zero of=/tmp/cow.img bs=1 count=1 seek=$((1024 * 1024 -1))

（ファイルとループバックデバイスを結合）
$ sudo losetup -r /dev/loop0 /tmp/ext2.img
$ sudo losetup /dev/loop1 /tmp/cow.img

（二つのデバイスを結合）
$ echo 0 $(du /tmp/ext2.img | cut -f1) snapshot /dev/loop0 /dev/loop1 p 0 | sudo dmsetup create dm-cow
（結合したデバイスをマウント）
$ sudo mount /dev/mapper/dm-cow /mnt
（以降/mntへの書き込みは/tmp/cow.imgへ蓄えられ、/tmp/ext2.imgは変更されない）

動作がスタッカブルファイルシステムとほぼ同じだとしても、操作対象が異なります。すなわち、デバイスマッパではブロックデバイス／セクタを対象とするのに対し、スタッカブルファイルシステムではファイルシステム／ファイルを対象とします。例えば、ブロックサイズを512バイトとし、サイズが2KBのファイルがオリジナルデバイスにあったとします。つまりファイルシステム上の4ブロックを消費しているファイルです。このファイルの先頭から1KB目の1バイトだけを書き換えると（3ブロック目の先頭バイト）、デバイスマッパのスナップショット機能は、3ブロック目だけをCOWデバイスへ書き込みます。変更されない他のブロックは書き込まれません（厳密に言えば、ファイル更新時刻などinodeが持つ情報も更新されるため、inodeブロックも書き込まれます）。言い換えるとオリジナルデバイスはファイルシステムが構築されマウント可能な状態であっても、COWデバイスにはファイルシステムが構築されずファイルシステム内の一部のブロックだけが保存されており、それだけをマウントすることができません。一方、スタッカブルファイルシステムではファイル単位で操作をするので、下位レイヤからファイル全体（2KB）を上位へコピーし、その後上位レイヤで本来要求された書き換えを処理します。

実行効率を考えれば、ファイル全体をコピーしないデバイスマッパの方が有利ですが、変更差分だけを確認したいといった場合の利便性では不利となる場合も考えられます。スタッカブルファイルシステムでは上位レイヤに対し、ls(1)すれば変更されたファイル一覧が得られますし、下位レイヤとdiff(1)することもできます。この機能は差分バックアップにも応用できます。デバイスマッパではCOWデバイスだけをマウントすることはできず、当然ls(1)もできません。COWデバイスは常にオリジナルデバイスと組み合わせて使用する必要があります。また、COWデバイスと結合していない時などに、オリジナルデバイスに直接変更を加えてしまうと、整合が取れなくなり、それまでのCOWデバイスが使えなくなる恐れもあります。

COWデバイスの内容をオリジナルデバイスへ書き戻す、スナップショットマージ機能もありますが、本記事では割愛します。

デバイスマッパは既存のデバイスから新たにデバイスを作成しますが、この新デバイスに対してもデバイスマッパは動作します。この特徴を活かし、スナップショットを複数重ねることも可能です。スタッカブルファイルシステム風に言うと、レイヤ（ブランチとも呼ぶ）を複数使用できます。

下位レイヤは読み取り専用デバイスですが、デバイス内に構築するファイルシステムには書き込み機能が必要となる点には注意が必要です。ファイルを書き込むのはファイルシステムの機能なので、オリジナルデバイスに構築するのがsquashfsのような読み取り専用ファイルシステムだと、COWデバイスを追加してもマウントするのはsquashfsとなり、書き込むことができません。しかし、圧縮機能は是非とも欲しいところです。Linuxシステムを一般的にインストールしたファイルシステムを圧縮せずにLiveCDに収めるのは随分窮屈になってしまいます。デバイスマッパを採用しているLiveCDにはFedoraがありますが、Fedora(少なくともバージョン12)ではインストールした状態をext3（名前と異なり中身はext4です）イメージとして作成し、このファイル一つだけを含むsquashfsを作成しています。この場合、マウント時に二重にループバックマウントします。若干簡略化した例をレイヤ図（図5）と共に示します。

デバイスマッパとsquashfsを併用した例

$ sudo mount -o ro /dev/cdrom /cdrom
$ sudo mount -o ro,loop /cdrom/squashfs.img /squashfs
$ sudo losetup -r /dev/loop1 /squashfs/ext3.img
$ dd if=/dev/zero of=/tmp/cow.img bs=1 count=1 seek=$((1024 * 1024 -1))
$ sudo losetup /dev/loop2 /tmp/cow.img
$ echo 0 $(du /tmp/ext3.img | cut -f1) snapshot /dev/loop1 /dev/loop2 p 0 | sudo dmsetup create dm-cow
$ sudo mount /dev/mapper/dm-cow /mnt

少し面倒ですが、この例は文章でも補足しておきます。図5を下から上へ追ってみます。 cd-romをマウントすると、squashfs.imgというファイルがあり、これをループバックマウントします。するとそこにはext3.imgというファイルだけがあり、これを/dev/loop1と結合し、ブロックデバイスとして扱えるようにします。別途作成した空ファイルも/dev/loop2と連結し、loop1をオリジナルデバイス、loop2をCOWデバイスとして、新デバイスdm-cowを作成し、これをマウントすると（やっと）読み書き可能なファイルシステムとして利用可能になります。

図5：デバイスマッパと squashfsを併用した例

二重ループバックマウントとsquashfsのキャッシュ

二重ループバックマウントのメリット、デメリットを考えてみましょう。

まず資源消費が思い当たります。ブロックデバイスが増えると言うことは、そのデバイス用にキャッシュすることになり、これは不必要な二重キャッシュの恐れがあります。システム内部ではマウント毎にオブジェクトを作成し、内部のマウントツリーに追加します。すなわち、メモリを消費し、アクセス時にはツリーを辿る処理が増えます。また、ループバックブロックデバイスも一つ余計に消費します。一般的にデバイスにはその種類毎に0から番号が振られ、この番号には上限があります。ループバックブロックデバイスの場合、デフォルトでは0-7まで八つのデバイスが作成され、モジュールパラメータを明示的に指定すれば255まで拡張可能ですが、二重ループバックマウントの場合は、大雑把に言って二倍の消費量となります。更にloopNという名前のカーネルスレッドがループバックマウント毎に起動され、常駐します。これもメモリ消費、プロセス ID空間消費、スケジューラの処理増加につながります。

デメリットを先に挙げましたが、悪いことばかりではありません。もっとも大きな効果は、圧縮されたsquashfsを展開した結果をキャッシュする点です。mksquashfsは圧縮効率を高める（結果サイズをより小さくする）ため、指定されたサイズごと（squashfsのブロックサイズ。デフォルトでは128KB）に圧縮しますが、圧縮対象ファイルサイズがこのブロックサイズよりも小さい場合は、他のサイズが小さいファイルとまとめて圧縮します。これをフラグメントブロックと言います。このため、サイズが1KBのファイルfileAと同じく1KBのfileBが存在する場合、fileAにアクセスしても、squashfs内部動作としてはfileBも同時に読み取り/展開することになります。展開結果はキャッシュされますが、フラグメントブロックについては一般に使用されるキャッシュ機構（ページキャッシュ）を用いず、squashfsが独自に実装したキャッシュ機構（フラグメントキャッシュ）を用います。この点についてはページキャッシュを利用した方が良いと言う指摘が度々あるようですが、現在までsquashfsは独自路線を維持しています。

このフラグメントキャッシュ量はconfig時に変更可能です。CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZEがそれで、デフォルト値は3です。

展開されたfileAについては一般的なファイル読み取り処理の一環としてページキャッシュに蓄えられますが、同じフラグメントブロックに存在する他のファイルについてはページキャッシュにはキャッシュされず、squashfs独自のフラグメントキャッシュにのみ残されます。次にfileBへアクセスし、ファイルデータがfileAの場合と同じフラグメントブロックに存在する場合、フラグメントキャッシュに残っていれば良いのですが、残っていなければ再び読み取り、展開します。フラグメントキャッシュのデフォルト値は大きくありませんから、アクセスパターンがランダムの場合にはキャッシュから追い出されている場合が多くなり、結果的に実行速度が犠牲になってしまいます。フラグメントキャッシュサイズを大きくすれば良いと言えばその通りですが、このキャッシュは squashfs内で固定的に確保され、ページキャッシュの様に動的に増減はしないので、メモリ圧迫の恐れがあります。

しかし、二重ループバックマウントすると、二番目のループバックブロックデバイスがフラグメント部分を含め展開結果を全てキャッシュ対象（ページキャッシュ）とするため、同じブロックを展開する機会が減り、アクセス速度は犠牲になりにくくなります。もちろん、不必要に二重、三重にキャッシュする恐れはあります。しかし、キャッシュによる速度改善は大きなものですし、またページキャッシュは参照頻度の低いものから順に破棄されるため、二重ループバック環境では下位キャッシュ（squashfs）から先に破棄され、上位キャッシュ（上例のext3）は生き残りやすい傾向が予想できます。このため前述のデメリットを補って余りある速度性能向上が期待できます。また、squashfs内に含まれるファイルがサイズの大きなファイルシステムイメージ一つとなるため、フラグメントブロックは実質的に発生しません。

mksquashfsにはフラグメントブロックを使用しない-no-fragmentsオプションが用意されており、圧縮サイズは犠牲になりますが、アクセスパターンがランダムの場合には効果を発揮します。

ブロックデバイス読み取り速度と CPU展開速度

一般にCPU動作はブロックデバイス動作よりも高速で、また展開処理はCPUを多く消費します。圧縮されたファイルまたはファイルシステムを読み取る際にはこの点が重要となる場合があります。

一般的なデスクトップPC環境では、圧縮しないファイルを読み取る場合の方が、展開処理に時間がかかるため、圧縮した場合よりも高速となる場合が多いのですが、低速なブロックデバイスを使用する環境ではCPU/ブロックデバイスの速度差が開き、圧縮した場合の方が動作が高速になるという逆転が発生する場合があります。例えば、サイズが4KBのファイルを圧縮して1KBになった場合、低速なブロックデバイスから4KBを読み取るよりも、1KBを読み取り、展開した方が短時間で済む場合があります。つまり、展開処理に時間をかけることになっても、ブロックデバイスからの読み取り時間短縮の方が効果が大きいということです。

（初出H22/12）

自己紹介

現在、私はクロスリスティングという会社で、広告配信システムとか、その周辺の新規商品関連の研究開発をやっています。メインのプログラミング言語はPythonです。自社でのシステム開発は基本的に全てPythonを使っています。自分は研究開発的なポジションですが、技術チームが開発しているプロダクションシステムもほぼ100% Pythonで開発されています。

「Pythonはバイトコードインタプリタのランタイムで動作するので、（JITを含めて）ネイティブコードにコンパイルする言語に比べて、実効速度の点で不利でありハイトラフィックなWebサービスの実装言語として向かないのではないか」という話を良く聞きます。今回は、Pythonで構築されているWeb広告配信サーバと、その周辺ツールについて、すこし紹介できればと思っています。

鴨射ちにバズーカ砲はいらない

Google、Yahoo、mixi、Facebook等の超巨大サイトの場合、ユーザの行動履歴データは膨大な量になるでしょうが、我々のシステムでは、検索が1日あたり数千万件単位、表示される広告の数は検索のおよそ数倍、クリックは数十万件単位、識別しているユーザ数は、だいたい一千万弱という規模です。

このくらいの量のデータは、ちょっとした検索や集計を行いたい場合に、最近はやりのHadoopとかHiveといった分散系システムを持ち出して、ノードマシンに投資するには微妙なラインです。また日々増えていくデータをアーカイブしながら、それをそのまま利用したいという要望もあるので、RDBMSで全部やるというのも無理がありそうという、なんとも悩ましい規模感なわけです。

あまり大きな会社ではないので、サーバマシンへの投資は節約したいですし、「戦車にバズーカ砲で挑む」というような規模でもないので、小回りが効いて使い勝手のいい「鴨射ち散弾銃」をこしらえて問題を解決しています。

ログデータというのは、一度生成されると以後変化が無いという性質があります。お客さんへの請求や、メディアサイトへの収益分配の基本となるデータなので、変更があっては困ります。日常的に行うちょっとした分析や、状況の確認等に使っている「鴨射ち散弾銃」は、このログデータの静的な性質を利用して、コンパクトに仕立てています。逆に言うと、随時更新される動的な対象には全くもって向いていないということでもあります。

CDBを使う

CDBをご存知ですか？ CDBはConstant DataBaseの略語で、qmailや djbdnsで有名なDaniel J. Bernstein氏の開発した、Unix系OSでは昔からよく使われているDBM系と言われるデータベースです。Key - Valueの単純なマップを提供するDBで、基本的なコンセプトは最近流行のKVSと同じです。ただしサーバがいて、ネットワーク越しにアクセスするものではなく、プログラムにライブラリとして組み込んで、ローカルファイルをストレージとしてデータの入出力を行います。ちょうどクライアントサーバ型のRDBMSとSQLiteのような関係です。GDBMやBerkeley DBなどの実装が有名で良く使われており、TokyoCabinetなど日本発の高速＆高機能なシステムもあります。

そのような中でCDBを選択したのにはちゃんとした理由があります。

• CDBはその名のとおりConstantなDBです。
  • CDBは作成フェーズと参照フェーズに分かれています。
  • 作成が完了した後に、DB内に格納されているエントリの修正、追加、削除はできません。
  • そのかわり作成、参照は超速いです。
• 生成されるストレージファイルが比較的コンパクトです。
• 1つのキーに対して複数の値を設定可能です。

という特徴が、静的なログ処理には向いています。作成フェーズと参照フェーズに分かれているという部分は実行例を見るのがよいでしょう。ここでは CDB-0.75、Python 2.6.5、 python-cdb-0.34（http://pilcrow.madison.wi.us/#pycdb）をつかっています。

# -*- coding: utf-8 -*-
import sys
import time
import random
import hashlib
import cdb

def printExecTime(target_function):
    def caller(*args, **kw):
        print("Start : %s" % target_function.__name__)
        start_time = time.time()
        result = target_function(*args, **kw)
        print("End   : %8.4f secs" % (time.time() - start_time))
        return result

    return caller


@printExecTime
def addRecords(cdb_builder):
    for i in xrange(1000000):
        cdb_builder.add(str(i),
                        hashlib.sha1("%s%s" % (time.time(),
                                               random.random())).hexdigest())


@printExecTime
def finalize(cdb_builder):
    cdb_builder.finish()


@printExecTime
def sequentialReadTest(cdb_reader):
    for i in xrange(1000000):
        value = cdb_reader.get(str(i))


@printExecTime
def randomReadTest(cdb_reader):
    for i in xrange(1000000):
        value = cdb_reader.get(str(random.randint(0, 1000000)))


@printExecTime
def iterationTest(cdb_reader):
    key = cdb_reader.firstkey()
    while key is not None:
        value = cdb_reader.getall(key)
        # do something...
        key = cdb_reader.nextkey()


def main():
    cdb_file_name = "/tmp/test.cdb"
    tmp_file_name = "/tmp/test.cdb.tmp"

    builder = cdb.cdbmake(cdb_file_name, tmp_file_name)

    addRecords(builder)
    finalize(builder)

    del builder

    reader = cdb.init(cdb_file_name)

    sequentialReadTest(reader)
    randomReadTest(reader)
    iterationTest(reader)


if __name__ == "__main__":
    main()

目の前にあるワークステーションとして使っているマシンでの実行結果はこのようになりました。

ransui@capella$ python cdbexample.py
Start : addRecords
End   :   6.9454 secs
Start : finalize
End   :   0.8811 secs
Start : sequentialReadTest
End   :   0.7764 secs
Start : randomReadTest
End   :   3.4778 secs
Start : iterationTest
End   :   1.4590 secs

バックグラウンドで色々動かしているマシンなので、最高速は出ていませんが100万エントリの操作スピードとしてはまずまずでしょうか。ちなみにこの時のCDBファイルのサイズは67MBほどでした。

このソースコードを見て分かることは、CDBの生成と参照が完全に分離されているということです。データを追加したら最後にfinish()メソッドを呼びます。このメソッドが最終的なCDBファイルをディスク上に生成します。生成が完了したら、生成用オブジェクトはもはや不要です。なぜならCDBはいったん生成したデータの修正はできないためです。

上の例では値へのアクセスはcdb_reader.get(KEY)のようにメソッド呼び出しを使っていますが、cdb_reader[KEY]のように辞書風にアクセスすることもできます。イテレーションは最初のキーを取得してから、次々とキーを取り出していくスタイルになっています。Pythonのイテレーションプロトコルに対応するためには、__iter__とか__next__メソッドを定義したクラスでラップしてしまったり、yieldを使ってジェネレータにしてしまうのもいいでしょう。

CDBの特徴のうち、1つのキーに複数の値を割り当てられるという性質は、色々な目的に使える便利な機能です。数え上げと簡単な検索の例を見てみましょう。

例題:

あるログファイルがあって、以下のようなフィールドがTABで区切られている。

Column No.	内容
0	ユーザID
1	時刻情報 (hh:mm:ss 形式の文字列)
2	検索語

このファイルはログデータからあるプログラムによって毎日1ファイルずつアーカイブサーバ上に作成される。ディスク領域を節約するためにファイルはbzip2形式で圧縮されているこのような条件下で、ログを処理して以下のようなデータを得たい。

1. ユーザIDのバリエーション数の正確な値
2. ある特定のユーザIDを指定して、そのユーザが何回検索したか、また検索語は何であったか。

ファイルは全体で1200万行あり、ユーザIDのバリエーションは100万種類くらいと見積もられている。検索語の平均長は400bytesである。ファイルはbzip2圧縮された状態のまま取り扱いたい。ディスク容量を節約したいのでインデックスファイルは巨大化させたくない。

このような場合、ユーザIDをキーにしたKey-Valueマップを作ればOKということは分かります。単純にKeyをユーザIDとして、時刻情報と検索語をValueとしたCDBデータベースを構築してしまえば問題は解決できますが、これだと容量の大半を占める検索語をデータベースに取り込んでしまっています。

CDBはコンパクトなストレージファイルを生成するといっても、検索のためのオーバーヘッドがありますから、データそのものをCDBに入れてしまっては、ディスク容量を節約するためにデータファイル自体をbzip2圧縮している意味がなくなってしまいます。

問題のポイントは、ユーザIDが指定されたときに、実データを素早く参照できればOKという部分と、実データファイルは更新されないという点です。これを踏まえてちょっとしたプログラムを書いてみます。

# -*- coding: utf-8 -*-
import sys
import os.path
import bz2
import cdb

class BZ2Index(object):
    def __init__(self, target_file_name=None, key_column=0):
        self.target_file_name = target_bz2_file_name
        self.index_file_name = "%s.cdb" % os.path.splitext(target_file_name, ".bz2")[0]
        self.key_column = key_column


    def buildIndex(self):
        cdb_builder = cdb.cdbmake(self.index_file_name,
                                  self.index_file_name + ".tmp")
        pos = 0
        archive_file = bz2.BZ2File(self.target_file_name, "r")

        for line in archive_file:
            key = line.strip().split("\t")[self.key_column]
            cdb_builder.add(key, str(pos))
            pos = target_file.tell()

        cdb_builder.finish()
        del cdb_builder
        archive_file.close()


    def openIndex(self):
        self.cdb_reader = cdb.init(self.index_file_name)
        self.archive_file = bz2.BZ2File(self.target_file_name, "r")


    def getRecords(self, key):
        result = list()
        for position in (int(pos) for pos in self.cdb_reader.getall(key)):
            self.archive_file.seek(position, 0)
            result.append(self.archive_file.readline())

        return result

このクラスはbzip2圧縮されたTSVファイルに索引をつけて、指定したキーに対応する実データを取得する機能を提供します。インデックスであるCDBには、キーに対応する値として、実データファイル先頭からのオフセット値を格納します。こうすることで、インデックスには整数(文字列化されていますが)のみが格納されるので、コンパクトに仕上がります。

データを読み出す場合は、インデックスをキーでひくと実データのオフセット位置のリストが返ってくるので、それぞれについてseekして1行読み出します。ISAMに似ていますが、実データの編成は固定長レコードではなく、行指向となっています。

CDBは1つのキーに対して、複数のaddがあると値の置き換えではなく追加として処理し、getallメソッドを使うことで複数の値をリストとして取り出すことができます。この性質をうまく使えばキーのユニーク化や、数え上げを手軽に処理できます。わざわざRDBMSやKVSなどのクライアントサーバシステムを準備しなくても、こんな単純な仕組みと少ない道具建てでそれなりにこなせるものです。もっともより本格的な分析とかになれば話は別です。戦車を相手にするときは迷わずバズーカ砲を使いましょう。

ちょっとした道具を自分で作ってみることの大切さ

今回は、CDBをつかってものすごく単純なインデックス付きファイル処理について紹介してみました。例示したプログラム片は「弓矢」レベルですが、社内で使っている道具は、もう少し色々できるようになっていて、「散弾銃」くらいになっています。

このようなデータの取扱い方法は、それこそ大昔から普通に行われてきたことですが、最近はRDBMSやKVSや分散システムなど、抽象度の高いインタフェースの裏に隠れてしまっています。さらに言えば、CDBそれ自身もよりハッシュマップの詳細な実装に対するを抽象度の高いインタフェースなわけです。

これらの便利につかえる道具について、どんな風に動いているのか、どんな原理なのかということを理解しておくことは、大きなフレームワークをより良く使いこなすための、大きなアドバンテージになるはずです。そして、それを理解するためにはプログラムを自分で実際に書いてみるのが一番いいことだと信じています。もちろん「道具を使うコード」ではなく「道具を実現するコード」をです。

最初に作った「弓矢」から「散弾銃」レベルまで拡張していくと、おおよそ似たようなシステムのコアな部分や、必須の機能、実現が難しい所、性能のボトルネックなどが見えてくるようになってきます。

「鴨を撃つのにご自慢のバズーカ砲持ってこなくていいよ。
　　だいたい、俺っちの車には、そのデカいケース載らないよ。
　　　前に作った散弾銃があって、ちょうど良さそうなんだ。
        調整するから5分待ってて！」

なんていうこともできるようになるわけです。こうして世界中のHackerたちが作り出した、より洗練された道具についてもよく理解できるようになり、本当は全然プアなのに「俺様の作ったライブラリ・フレームワーク最強」な自前主義や、「よくわからないけど、なんか流行っている・実績あるらしいから、これ使っとけ」的な外部依存体質に陥らないための視点も養成できるのではないかと思っています。

磯　蘭水 (Ransui Iso)
株式会社クロスリスティング（http://www.xlisting.co.jp/）
技術戦略グループ・ディレクター
PC-6001mk2のBASICでプログラミングデビュー。 その後Z80アセンブリ、C on MS-DOS,SunOS、CommonLisp(GCL) on SunOSと変遷して、最近10年はPython on GNU/Linuxがメイン環境。
最近またCommon Lispに回帰して仕事に使おうと画策中のアラフォー ソフトウェアデベロッパ。@ransui/twitter, Ransui Iso/facebook

>>> "abc\tdef"
'abc\tdef'
>>> datetime.datetime.now()
datetime.datetime(2010, 7, 9, 13, 37, 49, 107000)

>>> [1,2,3]
[1, 2, 3]

>>> {1:'abc', 2:'def'}
{1: 'abc', 2: 'def'}

>>> "はろー"
'\x82\xcd\x82\xeb\x81['

>>> print '\x82\xcd\x82\xeb\x81['

はろー

>>> open("はろー")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>

IOError: [Errno 2] No such file or directory: '\x82\xcd\x82\xeb\x81['

Python 3.0からのオブジェクト文字列表現

そこでPython 3.0以降では、文字列中の非ASCII文字もエスケープしないように変更され、日本語文字列を出力すれば、日本語としてそのまま出力できるようになっています。

>>> "はろー"
'はろー'
>>> open("はろー")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>

IOError: [Errno 2] No such file or directory: 'はろー'

ただし、タブや改行のような空白文字などは、Python 2と同様にエスケープされます。

>>> "は\tろ\tー"

'は\tろ\tー'

これで日本語を扱うプログラムの開発は楽になったのですが、実はまだ問題があります。

Python2では全てのオブジェクト文字列表現はASCII文字しか含まなかったため、通常の環境では出力時にエラーが発生することはありませんでした。しかし、Python3では文字列に使用中のコンソールでサポートされていない文字が含まれていると、エラーが発生するようになってしまったのです。

>>> "\u0550" # ARMENIAN CAPITAL LETTER REH
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>

UnicodeEncodeError: 'cp932' codec can't encode character '\u0550' in position 1:
 illegal multibyte sequence

これではデータの中身によってデバッグ時にエラーが発生してしまうため、非常に不便です。このため、Python3ではコンソールでサポートされている文字はそのままで、サポートされていない文字のみ16進形式にエスケープする方法が用意されました。

Pythonを起動する時、環境変数PYTHONIOENCODINGをエンコーディング名:backslashreplaceと指定すると、エンコーディング名でサポートされない文字だけが16進形式でエスケープして出力されます。

$ export PYTHONIOENCODING=euc-jp:backslashreplace
$ python
>>> "はろー \u0550" # ARMENIAN CAPITAL LETTER REH
"はろー \u0550"

backslashreplaceはUnicodeエラーハンドラと呼ばれ、Unicode変換エラーが発生した場合の対処方法を指定します。通常のファイルではデフォルトでstrictとなっており、変換エラーがあればそのままUnicodeEncodeError例外を送出します。backslashreplaceは、例外を送出せずに16進形式にエスケープして出力するための指定です。

標準出力ファイルのエンコードとエラーハンドラは環境変数PYTHONIOENCODINGで指定しますが、標準エラー出力のエラーハンドラはbackslashreplace固定となっており、変更することはできません。[2]

自分でファイルをオープンする場合は、

>>> open(filename, "w", errors='backslashreplace')

のように、errors=でエラーハンドラを指定することができます。テキストデータ出力時、どんなデータでもUnicodeEncodeErrorが発生しないようにするのならbackslashreplaceやignoreなどのエラーハンドラを指定するようにします。

Python 2.xと同様に、全ての非ASCII文字をエスケープしてしまいたい場合は、組み込み関数ascii()を使用します。

>>> print(ascii("hello, はろー"))

'hello, \u306f\u308d\u30fc'

Python 改善提案書 (Python Enhancement Proposal)

ここで解説したPython3.xでの文字列表現の変更は、実は私が提案し、実現した機能です。たまたまPython開発者メーリングリストでオブジェクトの文字出力についての話題が上がっているのを目にし、そのとき思いついた日本語出力が可能になる実装方法をメールに書き、簡単なパッチを作成したのが始まりでした。

その後、あわよくばそのままPython本体に取り込んでもらえるのではないかと期待していたのですが、Python2との互換性面で影響が大きいためPEPが必要と言われてしまいました。PEPとは 「Python改善提案書」（Python Enhancement Proposal）の略で、Python言語の改訂や標準モジュールの追加など、影響の大きな修正を行う場合には作成することが要求されます。PEPには改善の目的や具体的な実装方法、互換性への影響などを詳しく記述し、開発者メーリングリストで議論を求めます。議論の過程で得られた意見や改善点もPEPに記録し、議論が落ち着いたところでPythonの産みの親であるGuido van Rossum氏の裁定によって導入の可否が決定されます。

Guido van Rossum氏は慈悲深き終身独裁官（Benevolent Dictator For Life:BDFL）としてPython開発者コミュニティに君臨しています。Guidoの裁定は"BDFL裁定"（BDFL pronouncement）と呼ばれ、最終的な判断として尊重されます。議論で合意に達することができなかった場合でも、投票は行われません。開発者たちはメーリングリストで自分の意見を表明しますが、賛否の数に関係なくBDFLの判断によって裁定が下されます。

PEPは2000年頃から導入された制度で、修正の目的や議論をきちんと文書化することによって正しいBDFL裁定を下し、後からなぜこのような修正が加えられたのかを明確に記録することができるようになりました。またPEPが認められなかった場合でも、同じ提案が何度も何度も繰り返し提出されることを防いだり、却下されたPEPを元にもっと優れたPEPを作成して再度チャレンジすることができるようになりました。[3]

けっこう気軽にパッチを投稿したつもりが「PEP書け」と言われてちょっとうろたえてしまった私でしたが、ここまで来ては後に引けません。英語はかなり苦手ですがPEPのドラフト版を作成し、PEP管理者にPEP番号の発行を依頼します。このPEPは「3138」という番号で登録され、Pythonのウエブサイト上で公開されました。[4]

次にこのPEPをPythonの開発者メーリングリストに投稿し、コメントを求めます。ヨーロッパ語圏のユーザにとってはあまりメリットが無く、既存のアプリケーションへの影響も大きな修正だったので反対もありましたが、おおむね賛同を得ることができました。メーリングリストで上がった反対意見や改善点は順次PEPに反映し、パッチもあわせて更新を繰り返します。この間、英語圏の開発者が何度もPEPを添削してくれて、ちゃんと読める英語に直すことができました。議論がある程度進んだところでGuidoの"BDFL裁定"により承認され、Pythonのソースツリーにめでたく登録されることになりました。

英語でのフィードバック

PEPの有無にかかわらず、利用者からPython開発者たちへのフィードバックを送るのはPythonの発展のために非常に重要です。特にアジア圏からのフィードバックはあまり多くないため、Python開発者たちから高い関心を持って読んでもらえることが多いようです。

フィードバックにはある程度の英語力は必要となりますが、技術的なバックボーンがしっかりしていれば私と同程度の英語力―おそらく中学生程度―で十分ではないでしょうか。みんな下手くそなメールを読むのは慣れていますし、相手から揚げ足取りがある訳ではありません。議論の目的はPythonを改善することで、議論の相手もその気持ちは一緒です。利害の対立があるわけではありませんから、下手に議論や文章のテクニックを使ったりする必要もありません。文章がつたなくても、こちらに良い点があれば、相手が積極的に拾い上げてくれます。

長年、色々な英語のメーリングリストを読んできましたが、非英語圏の投稿者の文法や語彙を批判するメールというのは一度も目にした記憶がありません。コミュニケーションですから、できるだけわかりやすい英語を書くように努力する必要はあるでしょうが、完璧な英語を目指すのは無意味です。時制とか定冠詞とか三単現のSだとか、細かいところで間違えるのは仕方ない、とあきらめてしまえば英語を書くのは楽になりますし、文法にこだわるよりもその時間を議論の論理構成やポイントを把握するために使った方が良い結果につながるのではないでしょうか。

昔から言われる話ですが、日本にはかなりの数のオープンソース開発者・利用者がいる割には、バグ報告をしたりパッチを送ったりという活動があまり活発ではありません。Pythonに限らず、いろいろな開発コミュニティにもっと気軽に参加してみましょう。英語でコミュニケーションを取る経験をほんの何回か積むだけで、「あ、なにを怖じ気づいていたんだろう」という気持ちになれると思います。

執筆者紹介:
石本敦夫 @atsuoishimoto
アクシスソフト（株） シニア アーキテクト
日本におけるPythonのメーリングリストやユーザ会を立ち上げた、古株Pythonユーザ。現在もPythonによるメール・情報管理ツールInfoPile（http://www.infopile.jp/）の開発などを活発に行っている。

LinuxネイティブAIOライブラリliblaioの試作

Linux AIOを使用する場合、現在では前述のlibaioの利用が第一候補になりますが、やや使い勝手が悪いため、本記事でPOSIX AIOインタフェース準拠のライブラリを試作してみます。Linux AIOではO_DIRECTが前提となるため、この点もやや使い勝手が悪いのですが、SSDなどメモリベースのファイルシステムもありますし、動作は非同期になりませんがio_submit(2)はO_DIRECTがなくとも使用可能ですから、まぁ試しにやってみましょう。

ライブラリ設計要点を挙げます。

AIO完了通知

シグナル、スレッド起動の通知機能に対応するため、本ライブラリ内部でスレッドを起動します。

Linux AIO 非同期動作条件

表2に示した条件（O_DIRECT、アラインメント）はそのまま受け継ぎます。このため多くの場合で、量は多くないとはいえ、アプリケーションの変更とリビルドが必要になると思われます。しかし、非同期動作にならないbufferd I/Oの場合にも、io_submit(2)が対応しているので、本ライブラリも対応します。

前掲の表1で述べたように、IOCB_CMD_FSYNC、IOCB_CMD_FDSYNCに対応しているファイルシステムは現在存在しないため、aio_fsync(3)の実装として、本ライブラリ内部でio_submit（IOCB_CMD_FSYNC）、io_submit（IOCB_CMD_FDSYNC）を発行するとエラーになってしまいます。このため、本ライブラリでは特例として扱うことにします。すなわち、O_DIRECTを使用する場合、aio_fsync(3)の必要性はないため、処理せず常に成功を返すことにします。O_DIRECTを指定せず本ライブラリを使用する場合は省略できません。ライブラリ内部でサイズが0のIOCB_CMD_PWRITEを発行し、別スレッドでio_getevents(2)後にfsync(2)、fdatasync(2)を発行することにします。

また、/dev/null、fullなどもAIOに対応していません。これらに対するio_submit(2)はエラーとなります。

ソースレベル互換

ヘッダファイルのインクルードなど、量は少なくても、多くの場合アプリケーションの変更およびリビルドが必要になると思われます。この点は、変更量を最小限に抑えるため、ライブラリヘッダファイル内でマクロによりPOSIXインタフェースシンボルを本ライブラリのものへ置き換えることで対応します。

Glibc AIO 実装との非互換

POSIXによればaio_cancel(3)にはパラメータstruct aiocbを渡す場合とそうでない場合（NULLを渡す）があります。しかしio_cancel(2)ではNULLはエラーとなります。すなわちLinux AIOは指定されたファイルディスクリプタに対する全AIOリクエストをキャンセルする方法を提供していません。本ライブラリ内で対応策が考えられないこともないのですが、手間がかかるため（現時点では）本ライブラリの制限事項とします。

Glibcのlio_listio(3)は不正なファイルディスクリプタ（EBADF）などのエラーのチェックを別のI/Oスレッドで行っているので、lio_listio(3)はエラーを返しません。もちろん最終的にはエラーになり、aio_error(3)でEBADFが返されます。一方、本ライブラリのlio_listio()（io_submit(2)）はAIOリクエストをキューにつなぎ、直後にI/Oを開始するためこの種のエラーを検知します（早期発見ということです）。

liblaioの使用

上記を踏まえ、試作したものが同梱ソースファイル一式に含まれるlib/laio/です。前掲の6aio_signal.cを書き換え、試作したliblaioをリンクしてみます。

6aio_signal.cの書き換え ― 11laio_signal.c 要約

    :::
+#include <stdlib.h>
    :::
+#include "lib/laio/laio.h"
    :::
+#ifdef Laio
+#define OpenFlag O_DIRECT
+#else
+#define OpenFlag 0
+#endif
+
int main(int argc, char *argv[])
{
    int err, sigfd;
-   char a[BUFSIZ];
    ssize_t ssz;
    struct aiocb aio = {
        .aio_offset = 0,
-       .aio_buf = a,
-       .aio_nbytes = sizeof(a),
+       .aio_nbytes = BUFSIZ,
        .aio_reqprio = 0,
        .aio_sigevent = {
            .sigev_notify = SIGEV_SIGNAL,
        :::
-   aio.aio_fildes = open(argv[1], O_RDONLY);
+   aio.aio_fildes = open(argv[1], O_RDONLY | OpenFlag);
    assert(aio.aio_fildes >= 0);
    aio.aio_sigevent.sigev_value.sival_int = aio.aio_fildes;
+   err = posix_memalign((void *)&aio.aio_buf, 512, BUFSIZ);
+   assert(!err);

    sigemptyset(&mask);
    sigaddset(&mask, aio.aio_sigevent.sigev_signo);
    (以下略)

11laio_signal.cのコンパイルと実行

$ cc -I../lib/.. - L../lib/laio 11laio_signal.c -llaio -lrt \
    -o 11laio_signal
$ ./11laio_signal /mnt/test
main: aio_read from fd 3 completed
/mnt/test, 1466 read

$ ln -f 11laio_signal.c 11 laio_signal_dio.c
$ cc -I ../lib/.. -DLaio -L ../lib/ laio11laio_signal_dio.c -llaio -lrt \
    -o 11laio_signal_dio
$ ./11laio_signal_dio /mnt/test
main: aio_read from fd 3 completed
/mnt/test, 1466 read

書き換えのポイントはlaio.hのインクルードです。このヘッダファイルがaio_read(3)などをlaio_read()へ変換するため、書き換え量は極小で済みます。ただし、動作は非同期にはなりません。

非同期動作にするためにはO_DIRECTとアラインメントを加える必要があります。11laio_signal.cではコンパイル時に-DLaioを加えると非同期になるようにしました。同様の方法はliblaioに添付のテストプログラムのlaiotest.hでも用いています。

簡単に性能比較

本ライブラリの実行性能をGlibcと比較してみましたが、Direct I/Oを用いると、やはり速度面では不利でした。通常のbuffered I/Oではそれほど差は見られませんでした。

有意な差が見えたのはlio_listio(3)です。POSIX AIOの中では、いやシステムコール、ライブラリ一般から言っても、lio_listio(3)は非常に強力です。一度に多数のI/Oを発行する機能は実装も悩ましいところです。Glibcの実装では指定された分だけスレッドからI/Oする、複数のaio_read(3)のように処理するという比較的単純なアプローチですが、Linux AIOのio_submit(2)ではネイティブに複数I/Oに対応しているため、本ライブラリのlio_listio(3)はこの機能を活用しています。少数のAIOを発行する場合は、Glibcの複数スレッドアプローチでも、スレッド起動は通常充分に軽いため、満足な性能が得られるでしょう。しかし、大量になると単発のaio_read(3)を複数繰り返すよりもlio_listio(3)が威力を発揮します。この場合の性能はGlibcの実装では不満を感じるかもしれません。libaioや本記事で試作したliblaioの有効性が活きる場面です。liblaio付属テストプログラムでもlio_listio(3)の性能は、大きくとは言えませんが、Glibcよりも常に良好な結果を示しました。ただし、 この簡単なテストは同じファイルに 対する読み取りを一度に多数発行しただけで、差が見えにくい内容です。大量に発行して、やっとこれだけの差が見えたという程度の結果で、性能測定としては信頼に足るものではありません。

テストプログラムaio3_lioの実行結果部分だけ抜粋します。aio3_lioがGlibcを、nonlaio3_lioがO_DIRECTを指定せず本ライブラリを、laio3_lioがO_DIRECTを指定して本ライブラリを、それぞれ用いた場合です。

liblaio付属テストプログラム実行結果（抜粋）

$ make -s test
aio2_fsync + suspend
    :::
aio3_lio
2.65user 0.06system 0:03.42elapsed 79%CPU (0 avgtext+0 avgdata 0maxresident)k
0inputs+0outputs (0major+31412minor)pagefaults 0swaps
nonlaio3_lio
0.16user 1.68system 0:02.68elapsed 68%CPU (0avgtext+0 avgdata 0maxresident)k
0inputs+0outputs (0major+41636minor)pagefaults 0swaps
laio3_lio
0.17user 4.25system 0:05.57elapsed 79%CPU (0avgtext+0avgdata 0maxresident)k
4915200inputs+0outputs (0major+41718minor)pagefaults 0swaps
aio1_read + cancel
    :::

本記事ではファイルI/O全般からAIOまで解説し、さらにAIOライブラリを試作してみました。ライブラリには制限事項も複数残っており、まだ試用レベルですが、将来発展すればpthreadのようにNATL（Native POSIX AIO Library）と名乗る日が来るかもしれません。

もちろん興味を失えばこれで終わりになってしまうかもしれません　:-)

（初出: H22/4）

Copyright © 2010 SENJU Jiro

本記事のサンプルコードは、以下のリンクよりダウンロードすることができます。記事と合わせてご参照ください。
[サンプルコード]
また、本稿で取り上げた内容は、記事の執筆時の情報に基づいており、その後の実装の進展、変更等により、現在の情報とは異なる場合があります。
本連載「プログラマーズ・ハイ」では読者からのご意見、ご感想を切望しています。今後取り上げるテーマなどについてもご意見をお寄せください。

Glibc(RT)のAIO実装

GNU Libc（厳密には同梱のlibrt）はすでにPOSIX AIOインタフェースを実装しています。そのv2.7でのaio_read(3)の動作を要約してみます。

• 内部キューのメモリ確保
• pthread_create(3)をコールし、内部スレッドを起動
• AIOリクエストをキューへつなぐ

内部キューへAIO リクエストをつなげばaio_read(3)はリターンします。内部スレッドは次のように動作します。

• キューからAIOリクエストを取り出す
• 内容に応じpread(2)などを発行
• 内容に応じ通知
• 上記処理の繰り返し

内部スレッドがキューからAIOリクエストを取り出そうとした時にもうリクエストが一つも存在していなければ、内部スレッドは短時間の眠りに着きます。起床してもまだAIOリクエストがなければ終了します。これはスレッドを終了／再作成／起動するコストを節約するため、今は用がなくても近い将来出番が来るかもしれないので、少しの間は待つという動作です。

逆に起床したら複数のAIOリクエストが溜っていた場合には、自分一人では手が足りないため、内部スレッドが別の内部スレッドを起動します。新たに起動された内部スレッドも同じように動作します。

POSIXでは定義されていませんが、Glibcではstruct aioinit、aio_init(3)を定義し、内部動作も制御可能としています。例えば内部スレッド数、キューに保持可能なAIOリクエスト数の上限を設定可能です。

この実装で注目すべき点は、AIOが多用されることにより、内部では複数回pthread_create(3)がコールされ、複数の内部スレッドが起動される点でしょう。上限を設定可能とはいえ（デフォルトでは20）、スレッド数を不用意に多くしてしまうと性能劣化を招く恐れがあります。

LinuxカーネルのAIO対応

LinuxはカーネルレベルでAIOをサポートしています。すなわち上述のGlibcによる ユーザ空間でのスレッドによる実装ではありません。Glibcの実装ではライブラリ内部でpread(2)など対応するシステムコールを発行しますが、カーネルレベルのAIOサポートではio_submit(2)一つで全種類のI/Oに対応します。

LinuxのAIO システムコール

# include <linux/aio_abi.h>

long io_setup(unsigned nr_events, aio_context_t *ctxp);
long io_submit(aio_context_t ctx_id, long nr, struct iocb **iocbpp);
long io_getevents(aio_context_t ctx_id, long min_nr, long nr,
    struct io_event *events, struct timespec *timeout);
long io_destroy(aio_context_t ctx);
long io_cancel(aio_context_t ctx_id, struct iocb *iocb,
    struct io_event *result);

struct iocb {
    /* アプリケーションが使用しないメンバについては省略 */

    __u64aio_data; /* io_eventのdataへ代入される */

    __u16 aio_lio_opcode; /* IOCB_CMD_を代入する */
    __s16 aio_reqprio;    /* 未使用 */
    __u32 aio_fildes;
    __u64 aio_buf;
    __u64 aio_nbytes;
    __s64 aio_offset;

    __u32 aio_flags;      /* aio_resfdを使用するか否か */
    __u32 aio_resfd;      /* eventfd (使用する場合) */
};

struct io_event {
    __u64 data;           /* iocbのaio_dataが代入される */
    __u64 obj;            /* iocbポインタ */
    __s64 res;            /* I/Oの戻り値 */
    __s64 res2;           /* gadgetfsしか使用していない */
};

io_setup(2)

パラメータのnr_events 個の非同期 I/Oに対応したメモリ領域をシステム内に確保し、aio_context_tディスクリプタ（ハンドル）としてctxpに返します。渡すctxpは事前に0で初期化しておきます。また、システムワイドの非同期I/O数の上限は/proc/sys/fs/aio-max-nrから設定／参照可能です。

io_submit(2)

AIOリクエストをシステム内部のキューへつなぎます。AIO発行の本体に相当します。厳密に言うと、キューへつないだ直後にI/Oが開始されますが、この動作は非同期性を損なう恐れがあります。LinuxがAIOを実装した当初は動作は違ったと思うのですが。また、このため、異常なファイルディスクリプタ（EBADF）などのエラーはio_submit(2)が検知します。後述するように、この点には注意が必要となる場面があり得ます。

struct iocbはAIOリクエストごとに一つづつ必要で、I/O完了前に再利用はできません。このパラメータが構造体配列ではなく構造体ポインタ配列である点も一つの特徴と言えます。リクエストの内容、構造体メンバは前述のPOSIX AIOと同様ですが、aio_reqprioは使用されません。GlibcのAIOでは、おかしな値が代入されていた場合はエラーとされますが、io_submit(2)では無視します。またaio_lio_opcodeには次の値が指定可能です（表1）。

表1 io_submit(2)のI/O種類

現在IOCB_CMD_FSYNC、IOCB_CMD_FDSYNCに対応しているファイルシステムは存在しないため、指定してもエラーになる。

aio_flags、aio_resfdについては後述します。非同期動作はDirect I/Oの場合にのみ有効となり、O_DIRECTを指定しないファイルディスクリプタに対するio_submit(2)は非同期にもエラーにもならず、通常のI/Oとして処理されます（表2）。Direct I/Oの場合の動作については3節で述べました。ただし、io_submit(2)、またはO_DIRECTに対応していないものも存在し（パイプや/dev/nullなど）、これらに対するio_submit(2)はエラーとなります。

表2 Linux AIOの非同期動作条件

言い方を換えると、io_submit(2)はAIO専用ではなく、O_DIRECTを指定しない同期的ファイルI/Oの場合にも使用でき、大量のI/Oを一度に発行できるという強力なシステムコールです。

io_getevents(2)

処理を完了したAIO リクエストの情報を読み取ります。POSIX AIOとは異なりシグナルなどの通知はなく、アプリケーションがio_getevents(2)を発行するか、または後述するeventfdを用い、AIO完了を自ら問い合わせます。

io_destroy(2)

渡されたaio_context_tハンドルに対応するシステム資源を解放します。未実行のAIOリクエストがキュー内にあればキャンセルされます。

io_cancel(2)

io_submit(2)に渡したAIOリクエストをキャンセルします。キャンセルできた場合は成功（0）を、できなかった場合はエラー（EAGAIN）を、それぞれ返します。Linux AIOのサンプルコードを挙げます。

Linux AIOによるファイル読み取り ― 7raw_laio.c要約

main ()
{
    aio_context_t laio;
    struct io_event ev;
    struct iocb *pcb, laiocb = {
        .aio_lio_opcode = IOCB_CMD_PREAD,
        .aio_nbytes = BUFSIZ,
        .aio_offset = 0
    };

    laiocb.aio_fildes = open(argv[1], O_RDONLY | O_DIRECT);
    laiocb.aio_data = laiocb.aio_fildes;
    posix_memalign((void *)&laiocb.aio_buf, 512, BUFSIZ);

    memset(&laio, 0, sizeof(laio));
    io_setup(1, &laio);
    pcb = &laiocb;
    io_submit(laio, 1, &pcb);

    /* do other jobs */

    // err = io_getevents(laio, 0, 1, &ev, NULL);
    err = io_getevents(laio, 1, 1, &ev, NULL);

    printf("%s: io_submit from fd %llu completed\n",
        __func__, ev.data);
    printf("%s, %lld read\n", argv[1], ev.res);
}

GlibcはLinux AIOシステムコールに対応していませんので、前述のio_submit(2)などのシステムコールを発行するには、システムコールラッパーを別途定義する必要があり、7raw_laio.cではsyscall(2)を用いています。

LinuxカーネルレベルAIOはPOSIX AIOとは異なり、シグナルまたはスレッド起動による通知機能はありません。7raw_laio.cではio_getevents(2)のmin_nrに1を渡しているため、ここでAIO完了を待ち合わせる動作になります。min_nrを0にすると、まだ完了していなくても待ち合わせません。

min_nrを変更すればブロックする／しないを制御できるので、これだけでも用は足りると思われますが、Linux AIOではeventfd(2)を経由する方法も提供されています。7raw_laio.cにeventfd(2)を追加した8raw_laio_ev.cもサンプルコード一式に含めておきます。

Glibcはすでにeventfd(2)に対応しており、eventfd_read(3)、eventfd_write(3)なども追加されていますが、定義/実装されたのがv2.7から、しかしヘッダファイルが提供された（インストールされるようになった）のはv2.8からという経緯があります。実は筆者はGlibc v2.7 環境（えぇ、古典派と呼ばれようがDebian stable（lenny）を使っていますとも）なので、ちと不便があります。v2.7ではeventfd(2) を使おうとsys/eventfd.hをincludeしようとしても存在しないためコンパイルエラーになりました。一時しのぎですが8raw_laio_ev.cではGlibc v2.7のソースからsys/eventfd.hの一部をコピーすることでこの問題を回避しています。

Glibcのaio_read(3)の動作を要約したように、Linux AIOの動作も要約してみます。io_submit(2)は複数のAIOリクエストを受け取れます。その一つづつに対し次のように処理します。

• AIOリクエストのメモリ領域を確保
• ファイルシステムへAIOリクエストを渡す
• O_DIRECTが指定されていない、またはサイズを拡張する書き込みの場合は完了を待つ。すなわち非同期動作にならない
• それ以外の場合は完了を待たず非同期動作になる

ここで処理の流れはひとまず終了し、アプリケーションへ制御が返り、処理を進められます。以降の動作は基本的に前述のDirect I/Oと同じです。ファイルシステムの下位に位置するブロックデバイスがAIOリクエストを処理し、その後ブロックデバイスからI/O完了の通知を受けると、AIOはシステム内部のリングバッファ内に完了情報を蓄えます。

ここで前述のaio_flags、aio_resfdが関係する動作になります。aio_resfdにeventfdを、aio_flagsにIOCB_FLAG_RESFDをそれぞれ指定すると、そのeventfdに完了通知が届きます。eventfdへの完了通知はio_getevents(2)で得られる詳細な情報 ではなく単なる完了カウンタですが、select(2)、poll(2)、epoll(2)などでeventfdが読み取り可能か見張るイベントループに使用できます。eventfdは面白い動作を備えており、カウンタが0の場合にeventfdから読み取ろうとするとブロックし、epoll(2)などでも読み取り可能とは判断されません。

io_getevents(2)はシステム内部に蓄えられた完了情報を取り出します。情報の型は前掲のstruct io_eventです。I/Oしたバイト数など対応するシステムコールの戻り値はresメンバに代入されます。詳細は7raw_laio.c, 8raw_laio_ev.cを参照してください。

Linux AIOではaioという名前のカーネルスレッドも使用しますが、現状ではファイルクローズくらいしか主な仕事がありません。これはアプリケーションがio_submit(2)後、かつAIO完了前にO_DIRECTのファイルをclose(2)した場合に対応する処理で、アプリケーションが対象ファイルをもう使用しないと言ってもAIOリクエストが生きている限りはシステムはファイルをクローズしません。io_submit(2)時に参照カウンタをインクリメントしてあるためです。AIO完了時に参照カウンタをデクリメントし、0になればファイルをクローズし、対応するシステム資源を解放します。それ以外にaioカーネ ルスレッドを使用するのはgadgetfs（USB Gadget。LinuxをUSB master（host）ではなく、slaveとして使用する場合に使うものらしい）しかないようです。

その後、NFS も aio カーネルスレッドを使用するらしいということがわかりましたが、詳細は未確認です。

# include<libaio.h>

/* libaioコア(と言って良いと思う) */
/* その他Linux AIOシステムコールも利用可能な様に定義されている */
int io_queue_init(int maxevents, io_context_t *ctxp);
int io_queue_release(io_context_t ctx);
int io_queue_run(io_context_t ctx);

/* もう一つのコア:コールバック */
typedef void(*io_callback_t)(io_context_t ctx, struct iocb *iocb,
    long res, long res2);
void io_set_callback(struct iocb *iocb, io_callback_t cb);

/* 初期化関数 */
void io_prep_pread(struct iocb *iocb, int fd, void *buf, size_t count,
    long long offset);
void io_prep_pwrite(struct iocb *iocb, int fd, void *buf, size_t count,
    long long offset);
void io_prep_preadv(struct iocb *iocb, int fd, const struct iovec *iov,
    int iovcnt, long long offset);
void io_prep_pwritev(struct iocb *iocb, int fd, const struct iovec *iov,
    int iovcnt, long long offset);
void io_prep_fsync(struct iocb *iocb, int fd);
void io_prep_fdsync(struct iocb *iocb, int fd);

/* その他 */
int io_fsync(io_context_t ctx, struct iocb *iocb, io_callback_t cb, int fd);
int io_fdsync(io_context_t ctx, struct iocb *iocb, io_callback_t cb, int fd);
void io_set_eventfd(struct iocb *iocb, int eventfd);

#include <libaio.h>

char *fname;
void libaio_cb(io_context_t ctx, struct iocb *iocb, long res, long res2)
{
    printf("%s: io_submit from fd %d completed\n",
        __func__, iocb -> aio_fildes);
    printf("%s, %ld read\n", fname, res);
}

int main (int argc, char *argv[])
{
    int fd;
    char *p;
    io_context_t libaio;
    struct iocb *pcb, laiocb;

    fd = open(argv[1], O_RDONLY | O_DIRECT);
    posix_memalign((void *)&p, 512, BUFSIZ);

    fname = argv[1];
    io_queue_init(1, &libaio);
    io_prep_pread(&laiocb, fd, p, BUFSIZ, 0);
    io_set_callback(&laiocb, libaio_cb);

    pcb = &laiocb;
    io_submit(libaio, 1, &pcb);

    /* do other jobs */

    io_queue_run(libaio);
}

{
    char a[N];

    fd = open(path, O_RDONLY);
    read(fd, a, N)
    printf("%.*s\n", N, a);
}

{
    char *p;

    fd = open(path, O_RDONLY);
    p = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ, MAP_SHARED, fd, 0);
    printf("%.*s\n", N, p);
}

{
    int fds[2];
    pid_t pid;

    pipe(fds);
    pid = fork();
    if (!pid) {
        /* 子プロセス */
        write(fds[1], ...);
        return 0;
    } else if (pid > 0) {
        /* 親プロセス */
        wait(NULL);
        read(fds[0], ...);
    }
}

Direct I/O

Direct I/Oはバッファキャッシュを介さないファイルI/Oで、ブロックデバイスと直接データをやりとりします。詳細は後述しますが、LinuxネイティブなAIOシステムコールio_submit(2)では、Direct I/Oが指定されなければ、非同期動作にはなりません。

Direct I/Oは二重バッファリングを無駄とみなす考えから、システムレベルのバッファリングを省き、アプリケーションレベルのバッファリングと併用されることがあります。バッファリングを一切せずにDirect I/Oを使用しても単に性能を落とすだけです。同じファイルに通常のI/O（buffered I/O）やmmap(2)によるメモリマップI/Oと混在させても性能低下が考えられます。

Direct I/Oによるファイル書き込みは、まずバッファキャッシュがあれば、これをディスクへ書き戻し、そのバッファキャッシュを無効（invalid）にします。その後本来要求されたデータをディスクへ書き込み、この際に使用したバッファキャッシュも再び無効にします（図6）。同様にファイル読み取りも、まずバッファキャッシュをディスクへ書き戻し（有効なバッファキャッシュがあれば）、その後ディスクから直接読み取ります。

図6 Direct I/Oの動作

mmap(2)でも必要とされたアラインメントはDirect I/Oでも必須となり、特に（よくbufferと名付けられる）アプリケーション内作業領域のアドレスにもアラインメントが要求されます。これにはposix_memalign(3)などを用いると良いでしょう。現在のLinuxでは512バイトでアラインメントします。簡単な例を挙げておきます。

4dio.c 要約

{
    char *p;

    fd = open(path, O_RDWR | O_DIRECT);
    posix_memalign((void *)&p, 512, BUFSIZ);
    memset(p, 'a', BUFSIZ);
    write(fd, p, BUFSIZ);
}

一般に、Direct I/Oはデータベースなど専用の形式を持つファイルへのI/Oなどに有効と言われています。データベースソフトウェア（形態は単独アプリケーションかもしれませんし、専用ライブラリかもしれません）が自身でバッファリングを実装し、ディスクへ書き出す内容、順序も充分に意識すれば、電源断など不意の事故が発生しても、ディスク上での整合性を完全に、もしくは容易に修復可能な程度に維持できるでしょう。この場合一度のシステムコールで複数のアプリケーションバッファをI/Oするreadv(2)、writev(2)の利用が考えられます。しかし、引数のstruct iovecではファイル内オフセットを指定できませんので、pread(2)、pwrite(2)を繰り返すことになるかもしれません。Linux 2.6.30以降では、両システムコールを合体させたpreadv(2)、pwritev(2)が追加されたので、こちらの方が役に立つかもしれません。後述するio_submit(2)に渡すstruct iocbでも、オフセット指定可能です。

また、ブロックデバイスがハードディスクではなく、近年普及しているSSD、フラッシュメモリの場合にも有効と考えられます。ブロックデバイスがメモリの場合には、バッファキャッシュの有効性がずっと下がるため、使用しなければメモリ節約につながりますし、バッファキャッシュの管理コストを削減できれば、速度面での向上もさらに期待できます。

同様の目的をもった機能は、実行形式のファイルに対しても実装されています。通常コマンドを実行する際には、実行形式のファイルをメモリ上にロードしますが、このときブロックデバイスがすでにメモリならばロードを省略しようという機能で、XIP（execute in place）と呼ばれます。ただしXIP対応のデバイス、ファイルシステムが必要になります。Linuxのtmpfsでは対応していませんが（というかバックエンドとなるブロックデバイスを持たない）、ramdiskでは対応しています（CONFIG_BLK_DEV_XIPを有効にする必要がある）。繰り返しになりますが、自身でバッファリングしないアプリケーションがディスク上のファイルに対してDirect I/Oを使用しても、通常は遅くなるだけでメリットがない点に注意してください。

その他のI/O

ディスク上の通常ファイル以外に対する使用が主ですが、上記のI/O方式以外にも、I/Oが可能になったことをシグナルで通知するシグナルドリブンI/O、データが存在しないなどの理由でI/Oをブロックするような場合でもブロックさせないノンブロッキングI/Oがありますが、本記事では割愛します。

さて、ここまでファイル I/O全般を簡単に振り返りました。思ったよりも長くなってしまいましたが、次回はいよいよ本題のAIOに取り掛かります。

（初出: H22/4）

Copyright © 2010 SENJU Jiro

本記事のサンプルコードは、以下のリンクよりダウンロードすることができます。記事と合わせてご参照ください。
[サンプルコード]
また、本稿で取り上げた内容は、記事の執筆時の情報に基づいており、その後の実装の進展、変更等により、現在の情報とは異なる場合があります。 本連載「プログラマーズ・ハイ」では読者からのご意見、ご感想を切望しています。今後取り上げるテーマなどについてもご意見をお寄せください。

stdioのFILEが持つ内部バッファ

1rwと2frwの実行結果の違いはどこから来るのでしょうか。fwrite(3)が期待通りにファイルへ書き込んでくれない、もしくはfread(3) が期待通りに読み取ってくれないのでしょうか。実はこの挙動の違いはstdioのFILE *が持つ内部バッファの存在がための動作で、仕様通りなのです。

FILEは通常fopen(3)によって返され、ユーザプログラム（アプリケーション）はFILEを用いファイルI/Oを行います。ではFILEとは何でしょうか？ おっと、GNU Libcはその内容をユーザプログラムには隠蔽しており、単に構造体ポインタであるという以上のことはよく分かりません。マニュアルにもFILEを引数とするライブラリ関数はいくつも記述されていますが、FILE構造体の定義は記述されていません。えぇ。定義の詳細は知らなくとも良いのです。しかし、機能はしっかり把握する必要があります。

FILEは、ファイルディスクリプタを用いたファイルI/Oに対し、高水準I/O、ストリームI/Oなどとも呼ばれており、printf(3)に代表される強力なフォーマットI/Oインタフェースは広く使用されています。本記事で注目するのは「FILE構造体は内部にバッファを持つ」という機能です。操作ライブラリとしてのsetvbuf(3)が重要と言う意味ではなく、内部バッファの存在が上記のような動作の違いを生んでいるのです。

例えば、fopen(3)したファイルへ1から100までの数字を（可読文字列として）書き出すとします。1行に数字1つです。サンプルコードを提示するまでもなくfprintf(3)をforループでまわすコードが一般的でしょう。この時fprintf(3)はFILEが持つ内部バッファへ文字列を付け足すように振る舞います。つまり"1\n"、"1\n2\n"、と成長していき、最終的に"1\n2\n3\n...100\n"という文字列が内部バッファに作成されます。この時点では書き出す内容は内部バッファに留まり、実際のファイルへは書き出されていません（図1）。

fwrite(3)やfprintf(3)は毎回write(2)を発行するわけではなく、この場合でも、この時点ではwrite(2)はまだ発行されておらず、ユーザプログラムがメモリ内でstrcat(3)などを用い文字列を作成した場合と変りません。

上例の2frw.cでもfwrite(3) は渡されたデータを内部バッファへメモリ間コピーしたに過ぎず、ディスク上のファイルは作成された直後のサイズが0バイトのままです。 このため、fread(3) は1 バイトも読み取れません（図2）。

図1 内部バッファへ蓄えられる書き込み

図2 FILEを用いた書き込み ― 2frwの動作

対して1rw.cではFILEを用いないため、内部バッファは存在しません。write(2)を発行し、ファイルシステムへデータを渡します（図3）。

図3 ファイルディスクリプタを用いた書き込み ― 1rwの動作

では、1rw.cは前掲のバッファのプログラミング入門に沿わない悪いプログラムで、遅いディスクに引きずられるようにCPUの速度が犠牲になっているのでしょうか。実はそうではありません。1rw.cはシステム側で管理される本来のバッファの恩恵を受けており、決して悪いプログラミングではありません。

2frw.cの動作は仕様通りですが、プログラマの意図とは異なる、アプリケーションバグかもしれません。1rw.cと同じ結果にしたい場合は、後述するfflush(3)をコールし、内部バッファをwrite(2)する必要があります。

これまでは一般に「バッファ」と呼ばれるものを指すのに、「本来のバッファ」、「stdio FILEの内部バッファ」、「単なる作業用のメモリ領域」などと言葉を使い分けてきましたが、次節からはひとつづつ解説します。

システムレベルのバッファリング

CPUに対してディスクの速度が遅いことは広く知られており、ディスクの内容をメモリに保持するバッファリングと言う動作もよく知られています。このバッファは、アプリケーションが直接操作するものではなく、システム側が管理します。アプリケーションがファイルへ書き込んだ場合のシステム動作を、階層構造から簡単におさらいしてみましょう。大雑把に言えば、ファイル名（オープン後はファイルディスクリプタ）と書き込むデータという2つの入力が、ディスク上のブロックに到達するまでの流れです。

基本的には現代のOSに共通する話だと思いますが、筆者はすべてのOSを熟知しているわけではないので :-) 当世のLinuxを前提とします。

図4 ファイルへの書き込み ― バッファキャッシュまで

アプリケーション

名前によりファイル名を識別し、オープン後はファイルディスクリプタによりファイルを操作する。ファイルディスクリプタと書き込むデータをファイルシステムへ渡す。

ファイルシステム

アプリケーションから受け取ったファイルディスクリプタをinode(アイ-ノード) へ変換する。ファイル内容（ファイルデータ）を保存するディスクブロックはinodeが保持、管理する。ディスクブロックに対応するメモリ（バッファ）内容を書き換え、そのバッファとinodeがdirtyである（書き込む必要がある）とマークする。

ファイルシステムがバッファとinodeをdirtyにすれば、制御はアプリケーションへ返ります（図4）。つまりこの時点では書き込んだ内容はまだディスクへ到達しておらず、システムが管理するメモリ内に留まっています。ファイルシステムが書き換えたこのメモリが前掲の「本来のバッファ」、すなわちCPUとディスクの速度差の吸収を目的とした緩衝体です。バッファキャッシュとも呼びます。

バッファキャッシュはシステムが管理するもので、ディスクへの実際の書き出しはシステムにより非同期に行われます。すでに制御はアプリケーションへ返っており、別の流れになりますが、データがバッファキャッシュからディスクへ到達するまでの流れを追います（図5）。

図5 ファイルへの書き込み ― バッファキャッシュの書き戻し

dirtyバッファキャッシュ書き戻しカーネルスレッド

ディスクへ書き込む必要がある（dirty）とされたけれど、メモリ（バッファキャッシュ）内に留まったままにされているデータは、一定時間経過後、または空きメモリが一定量よりも少なくなった時点でブロックデバイスへ渡す。明示的に書き戻しを指示することもできる。

ブロックデバイス

渡されたデータをディスクなどのデバイスへ書き込み、永続的に保存する。

デバイスが内部に持つバッファキャッシュ（ハードウェアレベルのバッファリング）も存在しますが、本記事では取り上げません。

バッファキャッシュ書き戻し処理は、それまでのpdflushスレッドに代わり、平成21年12月にリリースされたLinux 2.6.32からbdiスレッド（backing_device_information）に置き換えられました。per-bdi flusherとも呼ばれます。役割／位置付けは変りませんが、構造的な変化は大きく、dirtyなinode、バッファを小分けに管理、書き戻すことにより、速度性能改善を目的とした変更です。この方向性はその後も維持され、変更作業は継続されています。

開始の契機など書き戻し処理には/proc/sys/vm下にいくつかのパラメータが用意されています。詳細は割愛しますが、環境に応じたチューニングは一考の価値があります。

取り上げられる機会が少ないようですが、laptop_modeなども有用でしょう。

書き戻しの契機は上記以外にもMagic SysRqキーによる緊急remount、緊急syncがあります。

バッファキャッシュ内に留まっているデータは放っておいても、最終的にはディスクへ書き戻されますが、この間に電源断などの事故により正常に書き戻されなければ、ディスク上のファイルシステムは整合性を保てなくなる恐れがあります。

この場合に、ファイルシステムの整合性の確認／修復、また可能ならばファイルデータの救済などを行うのが、通常システム起動時に実行されるfsckです。

ディスクI/O回数を増やしシステムパフォーマンスを犠牲にしてでも、ファイルシステムが不整合になる可能性を減らしたい場合には、明示的に書き戻しを指示するfsync(2)、sync(8)が有効です。ファイルオープン時にO_SYNCを指定しても同等の効果が得られますが、書き込み回数が多い場合には性能劣化が大きくなるため注意が必要です。

Linux固有のシステムコールですが、対象範囲を指定できるsync_file_range(2)というのもあります。

書き戻し後にdirtyからclean（ディスクとメモリの内容が一致しており、もう書き戻す必要がない）になったバッファはそのままメモリ上に残るかもしれませんし、システムが空きメモリを必要としている場合には破棄されるかもしれません。

バッファキャッシュにはシステムの空きメモリを流用します。

空いていればどんどんバッファキャッシュにまわされ、別の用途にメモリが必要になれば使用頻度が低いバッファキャッシュは破棄され、必要な用途に割り当てられます。

破棄されるのは使用頻度が低い順ですが、この破棄とディスクからの再読み取りが頻発してしまうと、システムのパフォーマンス低下の一因となり得ます。

I/O単位サイズ

I/Oでは単位サイズも重要です。アプリケーションが書き込むデータサイズは任意ですが、ファイルシステムでのI/Oはブロック単位、またブロックデバイスへ渡されるのはセクタ単位です。

いずれも512よりも大きい2の累乗が使用されますが、具体的な値は環境に依存します。例えばファイルシステム作成時にブロックサイズを512バイト、1KB、4KB...64KBなどにも指定可能です。デフォルトではファイルシステム容量からブロックサイズを自動的に決定するファイルシステムが多いようです。通常はメモリページサイズがファイルシステムブロックサイズ上限になります。実際のブロックサイズはstat(2)が返すst_blksizeで確認できます。

アプリケーションレベルのバッファリング

システムが管理するバッファキャッシュをシステムレベルのバッファリングと呼ぶのに対し、アプリケーションが自身で管理することをアプリケーションレベルのバッファリング、またはユーザレベルのバッファリングと呼びます。stdioのFILEは厳密にはライブラリレベルのバッファリングですが、アプリケーションレベルのバッファリングの一種 です。

2frw.cをFILEの内部バッファのため期待通りに動作しない例として取り上げたため、印象が悪くなってしまったかもしれませんが、FILEは決して悪いものではなく、それどころか内部バッファが威力を発揮し、性能／効率に大きく貢献する場合が多くあります。例えば小さいサイズのデータを数多く読み書きする場合を考えます。その度にread(2)、write(2)を発行することももちろん可能ですが、システム内部では既定のI/O単位サイズに丸めあげられるため、コスト高になる場合があります。

ファイルの10バイト目だけを変更する場合に、write(2)で1バイトだけ書き込むと、システムはバッファを完成させるため前9バイト、後ろ502バイト（最低でも）を補填します。補填とはつまりファイルを読み取り、バッファ内をファイルデータで満たすことです。ファイルがすでに読み取られており、バッファが存在していれば新たな読み取りは発生しませんが、I/O単位サイズに一致しない書き込みは遅い読み取り動作を待たなければなりません。書き込みをI/O単位サイズに一致させると、バッファ内容を現在のファイル内容で補填する必要がなくなり、読み取りの待ち時間を削減できます。

また、システムコールは一度制御がカーネルへ移るため、多少なりともオーバヘッドを伴います。I/O結果は同じでも、I/O単位サイズに注意し、システムコール発行回数を削減した方が効率面では有利です。このことはddを使って簡単に確認できます。

write(2) のサイズと回数比較例

$ dd if=/dev/zero bs=1M count=1 2> /dev/null | \
    time dd of=/dev/null obs=1
2048+0 records in
1048576+0 records out
1048576 bytes (1.0 MB) copied, 0.282584 s, 3.7 MB/s
0.11user 0.16system 0:00.28elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0 outputs (0 major+211minor) pagefaults 0swaps

$ dd if=/dev/zero bs=1M count=1 2>/dev/null | \
    time dd of=/dev/null obs=512
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.00376508 s, 279 MB/s
0.00user 0.00system 0:00.00elapsed 50%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0 outputs (0major+213 minor)pagefaults 0swaps

単純すぎて比較が見えにくいかもしれませんが、1バイトの書き込みを1M回実行した場合と、512バイトづつの書き込みを2K回実行した場合の資源消費を示した例です。入出力先はディスク上の通常ファイルではないため、実質的にwrite(2)と若干のメモリ操作だけの比較となります。write(2)を1M回実行した場合よりも2K回実行した場合の方が短時間で終了し、CPU使用率も少ないことがわかります。書き込みサイズを512の倍数にしておけばほぼ同等の効率が得られます。上記の単純比較も付属ソースコード一式に含めてあります。

上例から、小さいサイズのwrite(2)を多数繰り返すよりも、大きいサイズでまとめて行う方が効率的であることがわかります。stdioのFILEはまさにこの動作をアプリケーションに提供するものです。FILEへの書き込みは内部バッファへ蓄積され、一杯になった時、または明示的に掃き出しを要求された場合にのみ、内部バッファをwrite(2)へ渡します。読み取りの場合も内部バッファサイズでread(2)し、アプリケーションへは内部バッファからデータを返します。

FILEのバッファフラッシュ

それでは内部バッファのサイズはいくつで、掃き出し要求は具体的にどう行うのでしょうか。アプリケーションはファイルシステムへデータを渡すのですから、I/O サイズはファイルシステムのブロックサイズの倍数で、かつ大きい方が速度面では有利です。以前は/usr/include/stdio.hで定義されているBUFSIZがそのサイズだったと思うのですが（あまりにも古い記憶だから自信がありません）、手元のGNU Libc v2.7で確認するとfopen(3)がstat(2)を発行し、得られたst_blksizeを内部バッファサイズとしていました（少なくとも通常ファイルの場合は）。前述のようにst_blksizeはファイルシステムに依存しますから、固定されているわけではなく、対象ファイルに最適な値を内部バッファサイズとしています。アプリケーションのI/O単位では文字、行といった概念が一般的で、ブロックデバイスのセクタは通常意識しません。FILEでの内部バッファリングは、性能劣化を防ぎつつ任意サイズでのI/Oをプログラマに提供するものとも言えます。内部バッファリングのレベルも指定可能です。全バッファリング（fully buffered）、行バッファリング（line buffered）、バッファリングなし（unbuffered）の三段階が提供されており、デフォルトは全バッファリングとされており、内部バッファが一杯になると内部でwrite(2)を発行して書き出しますが、出力先が端末の場合はデフォルトで行バッファリングとされます。このため改行コードで終わる文字列を標準出力（通常は端末画面）に書き込むと、バッファリングされず即座に表示されます。バッファリングのサイズ、動作の変更詳細については、setvbuf(3)を参照してください。

FILEの書き込みエラー

内部バッファが一杯でなくとも明示的に書き出す場合は、fflush(3)をコールします。見落とされがちですがこの戻り値は重要です。write(2)の戻り値は、例えばファイルシステムの容量不足が原因で書き込めなかったなどのエラーを期待するため、あまり見落とされることはありません。fwrite(3)、fprintf(3)の戻り値も、write(2)のようなエラーが期待されるようで、これもあまり見落とされることはないようです。しかし、fwrite(3)は内部バッファへ書き込んだだけで、write(2)を発行しない場合が多くあります。このため、ENOSPCなどのエラーを正しく検知できるかは期待できません。エラーを調べるにはfflush(3)の戻り値が重要です。fwrite(3)の戻り値にももちろん意味はありますので、両方とも確認すべきでしょう。ferror(3)も有効です。さらにfflush(3)をコールしてもデータがディスクへ確実に保存されたとは限りません。実質的にwrite(2)に相当するものであり、データはバッファキャッシュへ留まります。ディスクへ到達させるには前述のようにfsync(2)を発行する必要があります。

またFILEクローズ時にも内部バッファは掃き出されるため、fclose(3)の戻り値も重要です。同様に見落とされがちですが、fwrite(3)の戻り値は確認するけれど、fclose(3)の戻り値を確認しないのは、アプリケーションバグです。だいぶ昔の話ですが、FILEを用いた実装のメールクライアントがメールを受信し、ユーザのホームディレクトリへ書き込んだのは良いけれど、fclose(3)の戻り値を確認しなかったため、ホームディレクトリが一杯になっていることがわからず、その時に受信したメールをすべて失ってしまい、著者の周囲で悲鳴が上がったことがあります。2frw.cのようなプログラムが、ライフラインと呼ばれることもあるメールを扱うならば、fflush(3)やfsync(2)も発行した方が良いでしょう。同様に見落とされがちですが、FILEを使用せずwrite(2)、close(2)する場合でもclose(2)の戻り値確認は重要です。write(2)ではエラーを返さずclose(2)で初めてエラーを検知できるファイルシステムもあります。実装にもよりますが、NFSなどがそれにあたります。

初めに挙げた「単なる作業用のメモリ領域」は変数名こそbufferと名乗っていますが、動作的にはバッファとは言い難く、強いて言えばアプリケーションレベルのバッファリングと呼べなくもないという程度のものです。

シーケンシャルアクセスの効率化

ファイルシステムではブロック単位、ブロックデバイスではセクタ単位でI/Oが発行されるのは前述の通りですが、このことはアプリケーションがファイルからデータを1バイト読み取るだけでも、システム内部ではもっと多くのバイト数が読み取られことを意味します。さらに1ブロックだけが必要とされる場合でも、自動的にその続きの数ブロックも同時に読み取り、本来要求されたI/Oを阻害しない範囲でバッファキャッシュへ蓄えておく先読み（read-ahead）という機能もあります。この機能はディスクのヘッドシーク時間を考えると非常に効果的です。さらにLinuxではアプリケーションのファイルアクセスパターンに応じて動的に先読み量を変化させ、シーケンシャルアクセスの場合には自動的に先読み量を増加させて、より多くのデータを先読みします。

初めからシーケンシャルにアクセスすると決まっているアプリケーションならば、事前にシステムに通知することにより、先読み効果を最大限に活かせます。この通知にはmadvise(2)、fadvise(2)、readahead(2)などを用います。シーケンシャルアクセス以外の場合でもその用途を通知することで、効率向上が図れます。書き込みの場合でもディスクブロック割り当てをあらかじめ要求するfallocate(2)というのもあります。詳細は各システムコールのマニュアルを参照してください。

先読みを活用しても、読み取るデータが常にバッファキャッシュ内に存在するとは限りません。システムがメモリ不足になった場合はやはり破棄される恐れがあります。後述のmmap(2)に加え、mlock(2)も用いると、プロセスアドレス空間をメモリ上に保つことができ、読み取るデータをバッファキャッシュ内に保持できます。もちろん、これはメモリ消費とのトレードオフです。

ここまで 「バッファ」という言葉に解説を加えました。次回ではバッファキャッシュを意識したさまざまなファイルI/Oを解説します。

（初出: H22/4）

Copyright © 2010 SENJU Jiro

本記事のサンプルコードは、以下のリンクよりダウンロードすることができます。記事と合わせてご参照ください。
[サンプルコード]
また、本稿で取り上げた内容は、記事の執筆時の情報に基づいており、その後の実装の進展、変更等により、現在の情報とは異なる場合があります。
本連載「プログラマーズ・ハイ」では読者からのご意見、ご感想を切望しています。今後取り上げるテーマなどについてもご意見をお寄せください。

signalfd

子プロセスが終了すると親プロセスにはシグナルSIGCHLDが送られます。 sigaction(2) によりシグナルハンドラを登録するのが従来より一般的な処理方法ですが、本記事ではepoll同様、Linuxに比較的新しく実装された signalfd(2) を用い、epollによるイベントループ内でシグナルを処理してみます。

epoll インタフェースには select(2) / pselect(2) 、 poll(2) / ppoll(2) の関係同様に、シグナルマスクを指定できる epoll_pwait(2) も用意されていますが、本記事では取り上げません。

signalfd(2) はファイルの open(2) 同様に、ファイルディスクリプタを返します。このファイルディスクリプタを read(2) すると、シグナルが届いていれば、そのシグナルに関する詳細な情報を読み取れます。届いていなければ、届くまで read(2) は待ち続けます（ブロックする）。epollによるイベントループでsignalfdのファイルディスクリプタを見張り、読み取り可能を検知した時がシグナルが届いた時です。ここで wait(2) を発行すれば、ブロックすることはありませんし、必ず終了した子プロセスのプロセスIDが得られます。

しかし、この方式には注意が必要です。現代のシグナルはシステム内部で「保留」（suspend）されることがあります。シグナルハンドラは通常単純でごく短時間で完了する処理しか行いませんが（多くの処理をすべきではない）、この間に同じシグナルがもう1つ届いた場合には、システム側で保留し、シグナルハンドラ完了後に改めて届けてくれます。

この動作はシグナルを失わず信頼性を高めるものですが、すでにシグナルを保留している時に、さらにもう1つ同じシグナルが発生すると、保留せずに破棄します。つまり（シグナル種類ごとに）複数は保留しないという動作です。

一般にシグナルの宛先はプロセスでもスレッドでも良いのですが、2pthread-unlimited、3pthread-poolでは子プロセスを起動するのがスレッドのため、SIGCHLDはスレッドに届けられます。また同期的に待ち合わせるため保留されることもありません。

しかし、4epollはシングルスレッドで複数の子プロセスを起動します。さらにシグナルハンドラを用いず、signalfdをイベントループで見張るため、発生したSIGCHLDはすぐには処理されず、システム内でまず保留されます。多くのセッションを同時に処理する状態では、続くSIGCHLDが破棄されてしまうことはまず間違いないでしょう。

SIGCHLDは標準シグナルという種類ですが、リアルタイムシグナルという種類はすでに保留済みのシグナルが新たに発生しても破棄されず、順序も維持したまま届けられます。

シグナルの保留、破棄は理屈の上ではいつでもどこでも起こり得るものですが、通常のシグナルハンドラを登録する方式を用い、ハンドラ内の処理も少なければ、破棄される機会はずっと少なくなり、実際にはそれほどお目にかからないと思われます。言い換えるとsignalfdを見張るイベントループでは当り前のように破棄されてしまいます。

注意は必要ですが、この点については、「signalfdが読み取り可能になった時には wait(2) すべきゾンビプロセスが複数存在するかもしれない」ということを意識すれば、対応は困難ではありません。

epollでsignalfdを見張る場合の注意点はもう1つあります。signalfdから読み取れる情報（siginfo）は必ず読み出さなければならないことです。従来の sigaction(2) で登録するシグナルハンドラのパラメータを考えるとわかります。 struct sigaction の sa_handler ではなく、 sa_sigaction の方です。パラメータには siginfo_t * があります。この情報はシステム側が領域を確保し、シグナルハンドラ実行後に破棄されるものです。

epollによるイベントループではシグナルハンドラを使用しないため、この情報はシステム側に留まったままとなり、これを参照可能にすると同時に破棄するのがsignalfdからの読み取りです。signalfdから情報を読み出してやらないと情報がシステムが領域を解放できず、また当然ながらepollがいつまでも読み取り可能を検知し続けてしまいます。

サンプルプログラムの改造では、signalfdが読み取り可能になる度に、signalfdからの読み出しを一度、その後 wait(2) を（その時点の）ゾンビプロセスが居なくなるまで何度でも実行することとします。

セッションソケットの状態遷移

以上の注意点を踏まえ、4epoll.cのどこへどのようにダミー処理を追加するかを考えます。epollによるイベントループでは、セッションソケットはもともと次のように処理されていました。

1. acceptしたソケットをepoll対象へ加える
2. 読み取り可能（HTTPリクエストが届いた）かを見張る
3. 読み取り可能になった

• HTTPリクエストを読み取り、
• 対象ファイルパスを確認する

4. 書き込み可能（送信できるか）を見張る
5. 書き込み可能になった

• 対象ファイルを送信する

6. ソケットをepoll対象から外しcloseする

ダミー処理の追加位置は、リクエスト読み取り後、かつファイル送信前ですが、その間にイベントループが回ります。セッションソケットはすでにepoll対象に含まれており、そのままではepollがI/O可能かどうかを検知して、ダミー処理完了前にイベントループが処理してしまいます。このため、一時的にepoll対象から外すように変更します。

関連して、epoll に指定していたエッジトリガをレベルトリガへ戻します。

1. signalfdを見張る
2. acceptしたソケットをepoll対象へ加える
3. 読み取り可能（HTTPリクエストが届いた）かを見張る
4. 読み取り可能になった。

• HTTPリクエストを読み取り
• 対象ファイルパスを確認する
• セッションソケットをepoll対象から外す
• forkしダミー処理実行

5. SIGCHLDが到着し、signalfdが読み取り可能になった

• セッションソケットを再びepoll対象へ加える

6. 書き込み可能 (送信できるか) を見張る
7. 書き込み可能になった

• 対象ファイルを送信する

8. ソケットをepoll対象から外しcloseする

ソースコードの変更 (2)

4epoll.cへのダミー処理追加の内容が決定できました。いよいよ変更します。まず、新規関数 dummy_wait() を追加します。内容はsignalfdの読み出し、ゾンビプロセスの破棄、ソケットセッションの復帰です。

前述の 1base.cでは同期的に子プロセスの終了を待つため、 waitpid(2) の option には 0を渡していましたが、こちらではいくつあるかわからない子プロセスを繰り返し waitpid(2) するため、 WNOHANG を渡します。

厳密には、 dummy_wait() が wait(2) してもすでにゾンビプロセスが居なくなっている場合があり得ます。これは前回の dummy_wait() コールですべてのゾンビプロセスを破棄している際中にSIGCHLDが発生した場合に起こります。

wait(2) 発行はゾンビプロセスが居なくなるまで繰り返されますから、ループ中に終了した子プロセスはすぐに wait(2) されますが、siginfoはシステム内に保留されたままになります。これはsignalfdからの読み出しと複数回の wait(2) の順序に起因する状態で、余分な wait(2) 以外に問題はなく、実害はありません。

仮に複数回の wait(2) の後でsignalfdを読み出すようにすると、子プロセスの終了を検知できなくなる恐れがあります。

dummy_wait()要約

/* 子プロセスとセッションソケットの対応 */
int sock_child [];

dummy_wait(sigfd, epfd)
{
    /* siginfo 読み出し */
    read(sigfd);

    ev.events = EPOLLOUT;
    while (1) {
        /* 子プロセスの破棄 */
        pid = waitpid (pid, &status, WNOHANG);
        if (pid <= 0)
            break ;

        /* 子プロセスに対応するソケットを再び見張る */
        ev.data.fd = sock_child [ pid ];
        epoll_ctl(epfd, EPOLL_CTL_ADD, ev.data.fd, &ev);
    ｝
}

また、前述の dummy_busy() のイベントループ対応も加えます。

dummy_busy()のイベントループ対応要約 (2)

dummy_busy(sock, do_wait)
{
    pid = fork();

    if (pid > 0) {
        /* 親プロセス */
+       if (!do_wait)
+           /* イベントループの場合 */
+           /* セッションと子プロセスの対応を記録する */
+           /* 子プロセスの終了を待ち合わせずリターンする */
+           sock_child [ pid ] = sock ;
        else
            /* 子プロセスの終了待ち合わせ */
            waitpid (pid, &status, 0);
    } else

        /* 子プロセス --- ダミー処理 */
        exec "find /tmp > /dev/null 2>&1";
}

4epoll.c では signalfd(2) の発行とイベントループへの追加、および dummy_wait() コールを追加します。セッションソケットのepoll対象から外し、ダミー処理を起動するのは do_read() です。

4epoll.c へのダミー処理追加要約

do_read(sock, epfd)
{
    read(); /* HTTPリクエスト読み取り */
+   /* このソケットはもう見張る必要がない */
+   epoll_ctl(epfd, EPOLL_CTL_DEL, sock, NULL);

+   dummy_busy(sock, /* do_wait */0);
}

main ()
{
    /* リスニングポートへのデータ到着を見張る */
    epfd = epoll_create(1);
    ev.events = EPOLLIN;
    ev.data.fd = lsock;
    epoll_ctl(epfd, EPOLL_CTL_ADD, lsock, &ev);

+   /* SIGCHLDを見張る */
+   sigemptyset(&mask);
+   sigaddset (&mask, SIGCHLD);
+   sigprocmask(SIG_BLOCK, &mask, NULL);
+   sigfd = signalfd (-1, &mask);
+   ev.events = EPOLLIN;
+   ev.data.fd = sigfd ;
+   epoll_ctl(epfd, EPOLL_CTL_ADD, sigfd, &ev);

    while (1) {
        struct epoll_event e[];
        /* I/O可能なソケットを処理する */
        nfd = epoll_wait(epfd, e);
        for (i = 0; i < nfd; i++) {
            sock = e[i].data.fd ;
            if (sock == lsock)
                do_accept(sock, epfd);
+           else if (sock == sigfd)
+               dummy_wait(sigfd, epfd);
            else if (e[i].events &EPOLLIN)
                do_read (sock, epfd);
            else if (e[i].events & EPOLLOUT )
                do_sfc( sock, epfd );
        }
    }
}

5epoll-multi.cへのダミー処理追加は4epoll.cと基本的に変りません。

ただし、今回は測定環境がデュアルコアであり、4epoll.cと差をつけるために子プロセス数はCPU数に一致させました（前回は起動する4epoll相当の子プロセスをCPU数-1としていた)。上記の変更を加えたサンプルプログラムは、付属ソースコード一式に含めてあります。

測定/比較

ダミー処理を追加し、いよいよサンプルプログラムへ負荷を加え測定してみます。負荷生成/測定プログラムには比較的古典的な httperf を用い、同一ファイルをHTTP GETで連続して要求し、HTTPクライアントから見た応答性（1TCPコネクションの開始から終了まで）に注目します。また、HTTPサーバ側では同時に vmstat を起動し、HTTPサーバとして動作するサンプルプログラムの資源消費に注目します。付属ソースコード一式にはこの測定方法と結果も含めてあります。

おわりに

測定結果について補足しておきます。応答にバラツキがあり、数秒もかかるものがあるからと言っても、それだけでそのサーバがまるでダメとは言い難いものがあります。

これは考え方次第かもしれませんが、大半のものが設定した上限、例えば1秒以内に応答が返され、ごく少数のものだけがそれを越えるという状況ならば、許容できるかもしれません。言い方を替えると、設定した上限に100%収まることが条件か、それとも95%ならば合格とするのかということになると思います。100%を条件とすると、サーバ台数など過剰に設備投資することになり、通常状態では多くの設備が遊んでしまうという無駄を生みかねません。

前記事の内容を確認する意味もあり、今回改めて測定してみました。結果はおおむね予想通りですが、ダミー処理の追加など新たな技術的テーマも追加しています。マルチスレッドを否定するわけではありませんが、高性能を期待する場合は epoll によるイベントループの方が適切な場合も考えられ、読者のソフトウェア開発において、前記事、本記事が一助となれば幸いです。

（初出: H22/2）

Copyright © 2010 SENJU Jiro

本稿で取り上げた内容は、記事の執筆時の情報に基づいており、その後の実装の進展、変更等により、現在の情報とは異なる場合があります。 本連載「プログラマーズ・ハイ」では読者からのご意見、ご感想を切望しています。今後取り上げるテーマなどについてもご意見をお寄せください。

tag:www.oreilly.co.jp,2010:/community/blog//4.621 2010-05-17T06:19:29Z 2011-06-30T00:11:33Z

「インターネットサーバでのPthreadとepoll」の記事（以下、前記事と呼びます）を書いた時点では、手元の環境がプアなためマルチプロセス/マルチスレッドを採用したサンプルプログラムの真価を発揮さ...

千住治郎

「インターネットサーバでのPthreadとepoll」の記事（以下、前記事と呼びます）を書いた時点では、手元の環境がプアなためマルチプロセス/マルチスレッドを採用したサンプルプログラムの真価を発揮させられず、適切に比較できませんでしたが、その後デュアルコアマシンを借りることができたので、改めて比較してみました。 また、比較の際にサンプルプログラムに追加したダミー処理ではシグナルも使用したので、やはりLinuxに追加された signalfd(2) もepollによるイベントループで処理してみました。

本記事のサンプルコードは、以下のリンクよりダウンロードすることができます。記事と合わせてご参照ください。
[ サンプルコード ]

前記事のサンプルプログラム

前記事 ではHTTPサーバを例に並列性/多重性のサンプル実装を5種類提示しました。簡単に振り返ります。サンプルプログラムがデュアルコアシステム上で動作しており、HTTPリクエストがほぼ同時に3件届いた場合のインタリーブ例を挙げてみます。毎回必ずこの通りにインタリーブされるわけではなく、あくまでもそれぞれの動作の違いを示すための一例です（ 図1.1 から 図1.5 ）。 また、5epoll-multiはCPU数-1個の4epoll（相当）を子プロセスとして起動しますが、デュアルコアシステムでは子プロセスの4epollを1つしか起動せず、4epollとの比較がしにくくなるため、今回は測定用にCPU数分の4epollの子プロセスを起動することにします。

]]> 図1.1 インタリーブ例―1base

• シングルスレッドで一セッションづつ処理する
• 1セッションを完了しないと次のセッションへ進まない、同時に処理しない
• CPU2を使用しない

図1.2 インタリーブ例―2pthread-unlimited

• スレッド数に上限を設けず、要求を受ける度に新規スレッドを作成し、1スレッドが1セッションを専門に処理する。上例では3スレッドを作成する
• セッションA、Cを担当する2スレッドは同じCPU上で同時に実行される
• セッションA、Bを担当する2スレッドはそれぞれ異なるCPU上で実行される

図1.3 インタリーブ例―3pthread-pool

• CPU 数分のスレッドをあらかじめ作成しておき、各スレッドが要求を受け付け逐次処理する。上例では2スレッドを作成済み
• セッション A、B は並列化されるが、セッションCは逐次的に処理される

図1.4 インタリーブ例―4epoll

• シングルスレッドで epoll によるイベントループを用い I/O を多重化し、複数セッションを同時に処理する
• 1セッションの完了を待たずに次のセッションの処理を開始する
• 全セッションが同じ CPU 上で同時に処理される

図1.5 インタリーブ例―5epoll-multi(子プロセス数増加後)

• 上記4epoll.cをCPU数分の、スレッドではなく、子プロセスとして起動し、親プロセスで要求を受け付け、ソケットを子プロセスへ渡す。上例では2プロセスの4epollを起動済み
• 1セッションの完了を待たずに次のセッションの処理を開始する
• セッションA、Cは同じCPU上で同時に処理される
• 2pthread-unlimited.cではシステムが三スレッドをスケジューリングした結果としてセッションA、CがCPU1、セッションBがCPU2上で処理されたが、5epoll-multi.cではそれぞれのCPU上で4epollが動作し、1プロセス内のI/Oの多重化により同時処理が実現されている点が異なる

構造をまとめると次の表になります（ 表1.1 ）。

表1.1 前記事サンプルプログラムの構造

サンプルプログラム	スレッド or プロセス数	要求受付役	同時処理可能 セッション数
1base.c	1		1
2pthread-unlimited.c	無制限	マスタスレッド	無制限
3pthread-pool.c	CPU数	各スレッド	CPU数
4epoll.c	1		OPEN_MAX
5epoll-multi.c	CPU数 + 1	親プロセス	CPU数×OPEN_MAX

• OPEN_MAX = 1 プロセスがオープン可能なファイル数。
• 比較のため5epoll-multi.cには子プロセス数を増加してある。

人為的な処理追加

HTTPサーバとして前記事のサンプルプログラムを動作させると、その1セッションあたりの内容は若干数のシステムコールだけと言ってもよいものなので、サーバ側でのCPU使用率は user% 、 sys% の内、 sys% ばかりが増加します。さらにサーバ側が負荷らしいレベルに達する前にHTTPクライアント役のCeleronの方が一杯になってしまい、充分な負荷を生成できません。

クライアント役には古いPentium 4も加え2台としましたが、サンプルプログラムにもう少し仕事をさせないと、まともな比較ができません。何もせずに時間だけを稼ぐ sleep(3) を加えようか、いやそれではやはりCPU負荷にはならないし、スケジューリングにもおかしな影響を与えてしまう。ではCPU負荷を与えるために単純な計算、例えば32ビット整数がオーバフローするまで1ずつ足し算をしようか。いやそれではCPUを必要以上に手放さなくなるので、やはりおかしなダミー処理だろう、などと考えた結果、子プロセスを作成し、 /tmp を find(1) することにしました。

ちょうど、手元の環境の /tmp を df -i した時に15個のinodeを使っていることが目に止まり、これを find するとごく短時間で終了するシステムコールばかりを発行することになり、HTTPサーバが動的コンテンツとして純粋な外部モジュールを起動し、ディレクトリリストを得る動作っぽいかなという程度の着想です(そんなモジュールが現実に存在するかは知りませんが)。

1セッションごとに毎回fork/execするのはあまり現実的とは言えませんし、また一般的に考えてもこういう人為的な操作はよろしくないとは思いますが、目的は比較測定と割り切り、この条件を測定環境/方法として固定することにします（ 図1.6 ）。

図1.6 ダミー処理

fork(2) 後の部分（図中では"..."）は別のCPU上で実行されることもありますが、HTTPリクエスト読み取りとファイル送信の順序が変るわけではなく、サンプルプログラムの基本的構造に変化はありません。

子プロセス生成により実際にはすべてのサンプルプログラムがマルチプロセス化し、スケジューリングに影響を与えますが、ここでは追及しないことにします。

1base

1baseへのダミー処理の追加は比較的容易です。また、先のインタリーブ例も基本的には変化しません。セッションを同期的に処理するため、ダミーの子プロセスの終了も単にその場で待ち合わせます。先のインタリーブ例（ 図1.1 ）と比較のため、 図1.7 を示します。

もちろんダミーの子プロセスが別のCPU上で実行されることもあり得ますが、ここではシングルスレッドで同期的に待ち合わせる点に注目してください。

図1.7 ダミー処理の追加―1base

2pthread-unlimited

同様にダミー処理を容易に追加できます。ソースコード上の変更は 1baseと変らず、やはり同期的に子プロセスの終了を待ち合わせるにも関わらず、マルチスレッド構造が効果を発揮し、複数のセッションを同時に処理できます。インタリーブを考えると子プロセスの存在が影響を与えますが、前述のようにここでは追及せず、2pthread-unlimitedのソースコード上は同期的に待ち合わせるようになっていても、マルチスレッドのおかげで複数のセッションを同時に処理できる点に注目してください。同様に比較インタリーブ例を示します（ 図1.8 ）。

図1.8 ダミー処理の追加―2pthread-unlimited

（CPU2 上のセッション B は割愛）

dummy_busy(sock, do_wait)
{
    pid = fork();
    if (pid > 0){
        /* 親プロセス */
        /* epollの場合 ... 後述 */

        if (do_wait)
            /* 子プロセスの終了待ち合わせ */
            waitpid(pid, &status, 0);
    } else {
        /* 子プロセス―ダミー処理 */
        exec "find /tmp > /dev/null 2>&1";
    }
}

main()
{
    /*リスニングポート作成... */

    while(1) {
        accept();                 /* 接続受付 */
        read();                   /* HTTPリクエスト読み取り */
+       dummy_busy(/* wait */1);  /* ダミー処理 */
        write();                  /* HTTP レスポンスヘッダ送信 */
        sendfile();              /* 静的ファイル送信 */
        close();                 /* 接続切断*/
    }
}