パスワードを忘れた？ アカウント作成
Close
250742 story

Linuxにおける10億ファイル問題 97

ストーリー by hylom
量は暴力 部門より

あるAnonymous Coward 曰く、

ファイルシステムが大容量に対応し、ハードディスクの容量あたりの価格が安くなるにともない、1つのパーティションに入るファイル数も増えている。しかし、Red HatのRic Wheeler氏によると、100万ファイルではしっかりと動くファイルシステムも、10億ファイルともなるとスケーラビリティの問題が発生してくるとのこと。

詳細はLinuxcon 2010での発表スライド（PDF）及びLWNの記事を参照。

大量のデータを扱いたければデータベースを使うか、複数のパーティションに分割して使え、という話があると思われるが、発表スライドでは「ファイルシステムは無料で多くの人々にとって親しみやすく分かりやすい、また複数のパーティションに分割するとユーザーによるデータの管理が面倒になり、またディスクシークの最適化が難しくなる」とし、大容量のファイルシステムの必要性が説かれている。

現在でもRAIDやJBODを使って複数台のHDDを束ねれば「単一ファイルシステム内で10億ファイルを格納できるストレージ」は構築可能だが、その場合ファイルシステムの作成や大量のファイルの作成、ファイルシステムの修復などに時間がかかるという問題があるとのこと。Linux向けの最新ファイルシステムの1つであるext4では多量のファイルを格納できるように設計・開発が進められているが、とある大容量システムでテストした結果、それでもファイルシステムの作成に4時間、10億のファイルを書き込むのに4日、ファイルシステムのチェック（fsck）に2.5時間かかったそうだ。さらにfsckで大量のメモリを要するのも問題とのことだ。

ちなみに、このような大量のファイルを含むディレクトリに対して「ls」を実行すると最悪な結果になるそうで、lsはreaddir()とstat()でディレクトリ内のファイルを取得するために毎秒数千ファイル程度の処理しかできないそうだ。そのため、10億のファイルに対してlsを実行すると実行完了まで数日かかるという。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Linuxにおける10億ファイル問題 More

  • データをファイルとしてたくさん格納するようなシステムはそもそも作ってはなりません。
    そのような場合にはDBMSを用いてblob形式でデータベースに格納すべきです。

    1. DBMSはロールバック・コミット等、ジャーナリングの情報を基に迅速に
      障害から復旧できます。最近のファイルシステムにはジャーナリング
      なども行われつつありますが、fsckなどのジャーナリングに頼らない
      古いチェック方法が残っているので、ディレクトリの循環などを
      チェックする必要がありチェックを終えるまでに時間がかかります。
    2. fsckのツリーの循環チェックのため、ディレクトリとビットマップの
      情報をメモリ内に格納しなくてはなりませんが、この際大量のメモリが必要です。
      32bitシステムでは、運用当初問題ない場合でも、使い込んでいく
      うちにファイル数が増加し、ある日、メモリが足りずfsckを終えられず
      マウントできない現象が発生する場合があります。
    3. ファイルシステムのデータ構造が破壊されたことを知ることが困難です。
      ファイルシステムのバックアップを取っていても、バックアップ
      が壊れていないことを知ることはできません。DBMSなら運用中チェックを
      行うことができますし、なにより、ファイルシステムでなんらかの
      異常が検出される確率はDBMSで障害が検出される確率よりもはるかに
      高いものです。

    FreeBSDならbackground fsckが使えますので、時間の問題はないかも?
    でも、おそらくDBMSを使ったほうがよいでしょうね。今ならHadoop
    なんかも面白いかもしれないけどOracleなんかと比較するとまだまだ
    信頼性に欠ける部分もあるような気はします。

  • Linuxの問題なの？ (スコア:3, 興味深い)

    by Driver (32138) on 2010年08月30日 19時05分 (#1817318) 日記

    殆どのOSで問題になりそうな気がするんですけど。（FileSystemの種類毎に程度は違うだろうけど）
    10億ファイルをディスク内に記録しておいても大きな問題にならないOSを知っている人がいたら教えてください。

    • Re: (スコア:0)

      by Anonymous Coward
      たぶんこれに呼応して様々なFSでベンチしてくるのでは。直観的に化石NTFSが一番ウンコな気がする。
      ZFSはどうかなと思ったけど、似ているといわれてるBtrfsも同様に遅いみたいですね。
      HAMMERは構造的にDBに近い気がするので速いかも？

      • Re:Linuxの問題なの？ (スコア:4, 興味深い)

        by Anonymous Coward on 2010年08月30日 23時09分 (#1817493)

        Windows(NTFS)で一日数千件のログファイルを単一フォルダに吐き出すシステムを知ってる。ファイルのサイズは100byte未満。
        1ヶ月もするとそのフォルダをエクスプローラで表示するのに数十分かかるようになり、3ヶ月もするとログの書き出しに時間がかかり過ぎてシステムが止まった。

        シェア
        親コメント

  • コア数のたくさんあるCPUが普通にあるから、じういう時も
    処理能力だけは余ってるんじゃないかと思ったりするのですが。

    • Re: (スコア:0)

      by Anonymous Coward
      並列処理が効果を発揮できる条件なのでしょうか

      • Re:マルチスレッド化するとか (スコア:3, 興味深い)

        by Anonymous Coward on 2010年08月30日 20時45分 (#1817385)

        「並列化すればいいんじゃないか」というような単純な一言というのは背景にある理解と対象の範囲によって適切にも不適切にもなってしまうので判定が難しいです。

        単純にストレージの性能限界にぶつかっている場合はCPU側のファイルアクセスを並列化すると状態は悪化します。
        ストレージはシーケンシャルアクセスが得意でランダムアクセスは苦手だからです。この性能差はSSDを利用すれば大幅に緩和されますが、それでもなくなるわけではありません。
        ストレージに限らずネットワークなどもを含めてI/Oは一般的に小容量の大量アクセスを行うと実効性能が落ちます（余談ですがCPU処理を考える場合はメインメモリもI/Oの一つとして考える必要があるぐらい遅いですね）。

        まじめに大幅な高速化を考えるなら既存のファイルシステムの部分的な並列化を目指すよりも、現代的なコンピューターの性能の絶対値やバランスの変化に最適化されたファイルシステムを設計するところからになるでしょう。

        以前に比べると現在のPCは一般的にはCPUの並列処理能力が活用されずに余力があり、メモリとストレージの容量はユーザーが使用するデータ量に対して余裕があります。
        ファイルシステムの多くは省資源が基本でストレージの容量やCPUの計算能力の消費を最低限で済ませることが志向されていますので、その考え方、使用する資源の許容量の基準を変える中の一つに「CPUの処理を並列化する」というのも出てくると思います。
        ただし、PC用のOSのファイルシステムの場合、それが利用されるシステムの規模は現行製品だけでもPCとは言い難いCPU数を搭載したシステムからシングルコアのAtom搭載のネットブックまでの幅があります。過去の製品を数年前のものまで含めるだけでその性能差はさらに大きく広がります。ストレージも同様です。
        コンピューターの資源を積極的に利用するファイルシステムを導入したら大規模なシステムでは速くなったが自分のPCでは遅くなった、というようなことは歓迎されませんので実用を目的とする開発の場合、資源の利用に対しては保守的になるのが普通です。

        素人の思いつきのようなものは既に考慮や取り組みがされていることが多いわけですが、実際の取り組みの例がZFS以降の最近実用化されたファイルシステムになるでしょう。並列処理についてもZFSでは圧縮ファイルシステムで活用されています。

        ファイルシステムの歴史的な発展については連続的かつ活発に開発されているLinuxがわかりやすいと思いますが、ext2/3の世代、ReiserFS他の世代、BtrFSの世代でファイルシステムの設計が大きく異なっています。

        昔は性能のバランスが違っていたという例を挙げると1998年にはUltra160 SCSIが提唱されており、その転送速度は160/MB/secに達していました。RAIDなどを用いた高価なストレージを接続すればそのインターフェース速度を十分活かせましたが、PCに接続した場合はCPUがそれを処理するのは大変でした。当時のメインメモリはPC100 SDRAMでインターフェース速度が800MB/sec、実効性能はその数分の一ですからメモリに読み込むだけで一仕事になってしまいます。

        シェア
        親コメント

      • なるほど、HDD側に並列処理が必要なわけね。

        シェア
        親コメント

    • Re: (スコア:0)

      by Anonymous Coward
      RAIDにすれば症状が軽減されると書いてあるので、HDD側の問題だと思う。
      RAMディスクで処理する(いくらかかるんだ・・・？)ならCPU側の問題になりそうだけど。

      • 某商用UNIXでの話ですが、一つのディレクトリの下に32K個程のサブディレクトリを作ったら、それ以上ディレクトリが作れなくなりました。これはそのOSの仕様だそうです。ファイルは32K個以上作れるのに。
        で、そのディレクトリで

        # ls

        と実行すると、サブディレクトリ名が表示され始めるまでに十数秒～数十秒かかっていました。

        シェア
        親コメント

    • Re: (スコア:0)

      by Anonymous Coward

      lsってオプション無しでもファイル名でソートされて出てくるんだし、
      最大10億のinode情報をメモリに展開しなきゃいけないわけでしょう。
      それだけでメモリ何十GBとか必要になるんじゃないのかな・・。

      実装知らないから推測ですけど、
      ページングおきまくってて重いんじゃないのかな、と。

  • タイトル毎にフォルダを作成して整理 (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2010年08月30日 20時24分 (#1817365)
    > 複数のパーティションに分割するとユーザーによるデータの管理が面倒になり

    10億個のファイルがある時点で、管理がすごく面倒だと思うんだけど。
    パーティション云々の問題じゃない気がするのは俺だけかな？

  • "問題"ではなく"今後の課題"では？ (スコア:2, すばらしい洞察)

    by t-wata (10969) on 2010年08月31日 1時20分 (#1817546) 日記
    しかし10億というと1日10万ファイル作成するとして1万日かかるわけで、そんなファイルシステムのfsckに2.5時間かかるのは妥当でしょう。
    表示に数日かかるというlsは問題だとは思いますが。
    まぁ、それでもファイル名が10文字だったとして、ファイル名の出力だけで10GBあるから、ある程度は仕方ないですね。

    私はcdした直後に反射的にlsを打ってしまうので、こういうシステムには関わりたくないですが。
  • 求めるファイルが画面に出てきた所で[Ctrl+C]でlsを殺せば幾分時間は減ると思われます。

    ファイル数が億のオーダーであることがわかっているなら「ls > hogehoge.txt」するよね。普通。
    もうちょっと気が利くなら「ls hoge* > hoge_list.txt」でしょ。

    画面で見ようとするならそれはオペレータが問題ありすぎると思います。

    # 表示文字数の少ないコンソールと重たい回線は否応が無しに小技スキルを蓄積させるよねぇ…(泣)
    --
    ---- ばくさん！＠一応IT土方
    • ls hoge* > hoge_list.txt
      って、まずシェルがディレクトリを読んで、hoge*にマッチするファイル一覧を作ってアルファベット順にソートして、それからlsをfork&execして、lsが引数の各ファイルを順次statする・・・という処理になります。 ファイル数が億なディレクトリでこんな事を行うのはもっとドツボじゃ？ なおexecの引数に渡せるデータサイズは128KB～2MB(OSによって違う)ので、hoge*にマッチするファイルが10000個とかあればもうそれでexecできません。

      すでに指摘されているように、ls -f(statもsortもしない)がとりあえず一番速くファイル名一覧が得られます。

      シェア
      親コメント

  • ls (スコア:1)

    by nox_dot (11614) on 2010年08月30日 22時12分 (#1817450) 日記

    場合にも寄るのでしょうが、alias で --color が入っていたら、これを切るだけでだいぶ早くなります。
    表示はだいぶ味気なくなりますが。

  • 通過したメールをpostfixのalways_bcc使ってアーカイブし、検索はIMAPクライアントで行うようなことしたらすぐに体験できますよ。

    メーリングリストサーバーのメールやメルマガを通過したらそりゃあもう。。。

  • ここで*BSDの優位性をアピールっ！ (スコア:0)

    by Anonymous Coward on 2010年08月30日 18時38分 (#1817301)

    T/O

    • *BSD の優位性というより UNIX の基礎な気がします。

      /, /boot しか切られていないサーバを稀に見つけますが、
      /var のログがパンクして login できなくなるとか怖くなります。

      ファイルの数にしたって一つのディレクトリに数万ファイルで ls は実用に耐えません。
      bash の補完も「何万ファイルあるけど、マジで？」と聞いてくるまでに数時間かかります。

      FreeBSD は fsck に関してはBackground fsck [wikipedia.org]があるので、
      優位と言えば優位なのかも知れません。
      Solaris の恩恵を受けて ZFS を利用すれば、もっと色々と便利なのかも知れません。

      Linux も LVM でパーティションの容量管理は比較的容易になったので、
      パーティショニングは昔のように千里眼である必要はありません。

      シェア
      親コメント

      • 昔のUNIXにありましたね。/があふれると、挙動が不安定になるやつ。だから、/var, /tmp, /homeは/と同じにするんじゃない、と。

        他の方が書いている通り、最近のは無いと思いますよ。でも、慣例で分けてしまいます。VM上のテスト環境で、お任せモードでのインストールをするときだけ/の単発が出来上がりますが。

        --
        -- gonta --
        "May Macintosh be with you"
        シェア
        親コメント

      • Re:ここで*BSDの優位性をアピールっ！ (スコア:1, 興味深い)

        by Anonymous Coward on 2010年08月30日 21時30分 (#1817419)

        > /, /boot しか切られていないサーバを稀に見つけますが、
        > /var のログがパンクして login できなくなるとか怖くなります。

        単一パーテーションのDebian Lenny で確認しました。
        領域がパンパンになるまで一般ユーザでファイルをたくさん作りましたが、
        スーパーユーザになると予約領域が使えるらしく、もう少し沢山書き込みができました。

        続いて、スーパーユーザでも書き込めなくなるまで埋めましたが、コンソールログインには支障ありませんでした。

        # 流石に再起動するとカーネルパニックになったけどw

        シェア
        親コメント

      • > /var のログがパンクして login できなくなるとか怖くなります。

        どのファイルシステムがfullになっても、ログインが出来なくなることはないと思いますよ?
        ログは残らないですが。

        シェア
        親コメント

      • Re:ここで*BSDの優位性をアピールっ！ (スコア:1, 参考になる)

        by Anonymous Coward on 2010年08月30日 22時42分 (#1817478)

        background fsckはまったくスケーラビリティがなく、
        起動前のsnapshotsにinode数に比例した時間がかかります。

        十億ものファイルを持つファイルシステムをfsck -Bなんかしたら
        丸1日くらいピクリとも動かないんじゃないですかね。

        background fsck前提のファイルシステムは
        newfs時に思い切りinodeの数を減らしましょう。
        減らせば減らすほどsnapshotsが速くなります。
        そうしないと使えたもんじゃありません。
        なんというかその、使わないのが一番です。

        シェア
        親コメント

    • Re: (スコア:0)

      by Anonymous Coward

      *BSDで10億程度のファイルを上記の基準で処理したら、どうなるの？

      • Re:ここで*BSDの優位性をアピールっ！ (スコア:5, おもしろおかしい)

        by Sukoya (33993) on 2010年08月30日 19時21分 (#1817332) 日記

        マジレスすると、そんなことをしなければいけないサーバを構築をしたニンゲンの首が吹き飛ぶ
        処理できる様にしろと客から光の速度でクレームがくる

        お前の設計で会社がマジやばい

        シェア
        親コメント

        • Re:ここで*BSDの優位性をアピールっ！ (スコア:2, おもしろおかしい)

          by bitterbeer_sweetwine (37563) on 2010年08月30日 20時36分 (#1817378)

          >マジレスすると、そんなことをしなければいけないサーバを構築をしたニンゲンの首が吹き飛ぶ

          以前、あるシステムを見てくれといわれて...
          あのぉ、lsが返ってこないんですけど...
          で、ディレクトリを一個あがって、ls -lしてみたらそのディレクトリのサイズが異常。
          リンクの数も、7桁。

          「なんかいっぱいファイルが入っているみたいですけど、分割できませんか？」
          「それをしようとして、出来ないので困ってる」...

          なんでも、社員情報を、社員番号.name.txt 社員番号.address.txt 社員番号.phone.txt
          社員番号.緊急連絡先.address.txt 社員番号.緊急連絡先.phone.txt 社員番号......
          １０万人(正社員／契約社員／外注出向者等)分程度を、ひとりについて20ファイルくらい
          にわけて、一カ所に入れて、簡易DBかわりに使っていたらしい。

          なんでも、「下手にDB使うより簡単だし、検索もシェルでやるから簡単なんだ」とのことでした。
          もちろん、全部、平文なわけで、「どうしてこーゆーの作ったの？」と聞いたら、「前任者が、
          社員を一度に検索できるシステムを安く作れという命令で作った」そうだ。

          各部署ではマル秘扱いの社員データを、毎日ダウンロードしてはマッチングして更新かけて
          いたのが、どうも遅いし、終わった気配がないので心配で聞いてきたらしい。

          シェア
          親コメント

          • ある日再起動時にfsckが起動されて、丸1日かかったが何とかfsckを終えた。
            月末恒例の処理しようとしたら、何かエラーがでる。と。
            原因を調べたらファイルが存在しておらず、/lost+foundにファイルの残骸が。
            バックアップのtarファイルから復元しようとしたが、tarでバックアップを取っていた時点では既にメタデータがおかしかったらしくファイルとして存在していなかった。

            ※ 作り話ですが、ふつうにありそうですよね。

            シェア
            親コメント

            • >バックアップのtarファイルから復元しようとしたが、tarでバックアップを取っていた時点では既にメタデータがおかしかったらしくファイルとして存在していなかった。

              当時のtarにはたしか、8GB上限があってtarでは取れなかった。
              部分だけバックアップしようとして、tar cvf /dev/rmt0 10*.*.txtで取っていたらしいのだが、ある日「too many arguments」で落ちたらしい。
              その時は、もっと細分化してバックアップをとるとかで逃げたらしいけど、逃げ方が場当たりで、「1*は、100,101,102...で分けて、2番台は二桁で...9番台はそのまま」みたいなことやっていたね。

              > ※ 作り話ですが、ふつうにありそうですよね。

              本当にあった怖い話の一種かもね。

              シェア
              親コメント

          • Re:ここで*BSDの優位性をアピールっ！ (スコア:2, すばらしい洞察)

            by harutin_99 (34900) on 2010年08月31日 8時58分 (#1817594) 日記

            従業員10万人て、超大企業じゃないですか。
            #開発費けちりすぎ。

            シェア
            親コメント

          • これほど、データベースを使った方が簡単な事例も少なそうですよね…。
            本当にご苦労様です。

            シェア
            親コメント

          • Re:ここで*BSDの優位性をアピールっ！ (スコア:1, 興味深い)

            by Anonymous Coward on 2010年09月01日 0時08分 (#1818018)

            なんでも、「下手にDB使うより簡単だし、検索もシェルでやるから簡単なんだ」とのことでした。
            もちろん、全部、平文なわけで、「どうしてこーゆーの作ったの？」と聞いたら、「前任者が、
            社員を一度に検索できるシステムを安く作れという命令で作った」そうだ。

            性能やセキュリティが要件に入っていなかったのなら正しいかも。
            性能はともかくちゃんと動いていたわけだし、いろんな部署の人が使っていたわけだし。
            設計者もDBの方がいいことは知っていて（あるいは安く作れる方は破綻することを知っていて）、敢えてこういう実装にしたのではないかと深読みしてみました。

            モデしてしまったのでAC

            シェア
            親コメント

  • SONY NEWSでls /dev (スコア:0)

    by Anonymous Coward on 2010年08月30日 19時26分 (#1817334)
    SONY NEWSで ls /devってやっても１０秒ぐらいかかっていたような希ガス
typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー