タグ

IOに関するwebmarksjpのブックマーク (5)

  • Linux I/O のお話 write 編 - naoyaのはてなダイアリー

    write はページに dirty フラグを立てるだけなので決してユーザープロセスを待たせない って、当にそうなんでしょうか?(否定しているわけではなく、純粋な疑問です。) と質問をもらったので、最近追ったことをここでまとめます。かなり長文です、すいません。また、まだまだ不勉強なので間違っているところもあるかもしれません。ツッコミ大歓迎です。 まず、オライリーのカーネルの 15章 ページキャッシュ 15.3 汚れたページのディスクへの書き込み から引用。 ご存知のように、カーネルは、ブロック型デバイスのデータを含むページをページキャッシュに蓄えています。プロセスが何らかのデータを更新した場合は、必ず対応するページに汚れている印をつけます。すなわち、PG_dirty フラグを設定します。 UNIX システムでは、汚れたページのブロック型デバイスへの書き込みを遅延することができます。この方

    Linux I/O のお話 write 編 - naoyaのはてなダイアリー
  • ほえほえ LinuxファイルI/Oチューニング

    Linuxは私の使っている範囲ではファイルI/Oがパフォーマンスボトルネックになっていることが多い。で、チューニングの情報を集めてみるのだが、なかなか役立つ情報を入手できない。 決まって全般的なチューニングの進め方について述べ、次にボトルネックの調べ方について述べる。 最後にチューニングパラメータ設定手順のヒントだけを非常に簡単に挙げておわってしまう。いや、どこがボトルネックなのか最初に一発で分かればいいよ? でも全般的なチューニングの進め方でそうしたドキュメントが述べている通り、色々な可能性を繰り返しチューニングしながらつぶしていかなきゃいけないんだよね。 そのためには具体的なチューニングパラメータの設定手順がなきゃできないんだよね。それを教えろよ!それを! ということで、今回はLinuxファイルI/Oチューニングについて調べた。大きなファイルの書き込み(ex. cpコマンド)を行うと、

  • 404 Blog Not Found:perl - In-Memory File

    2006年11月08日04:30 カテゴリLightweight Languages perl - In-Memory File Perl 5.8以降では、このような場合にin-memory fileが使えます。 【続】やはり Perl はメモリ喰いな言語。データ型の内部構造 :: Drk7jp DB上の全レコードをいったん perl 側の配列に格納して、その結果を返す。ってコードなのですが、当然ながらレコード数が多くなればメモリをうのは当たり前なのですが、以前の記事の内容を完全に忘却してました。ここには落とし穴があるのです。使い方は、簡単です。 my @array = (0x21..0x7e); my $memfile; open my $wfh, '>', \$memfile or die $!; print $wfh chr($_), "\n" for (@array); clos

    404 Blog Not Found:perl - In-Memory File
  • blog.8-p.info: Comet 勉強会

    日曜日は Comet 勉強会でドリコムに行ってきた。「勉強会」というものに参加するのは初めて。発表者を会場で決められるほどの層の厚さは、さすがに Comet や Erlang ではきびしめで、自分ももっと勉強しておくとよかったな。 DRECOM Chat に Comet 勉強会の部屋があって、話題になったページはそこに載ってたりします。 ShootingStar 瀧内さんの作っている Rails と組み合わせて使える Comet 実装について。 大量のコネクションをさばけること イベント通知に専念すること 通知されたクライアントが、改めてイベントの内容をサーバーに問い合わせる すぐに使える Rails との組み合わせで便利 「5分でチャット」とか Rails 風マーケもやってみたり Flash 不要 Flash は Linux では動かない、と Juggernaut のひとがいってた でも

  • libaio(Linuxの非同期I/Oライブラリ)の使い方 - moratorium

    libaio(Linuxの非同期I/Oライブラリ)の使い方 2007-06-05 (Tue) 4:53 Unix Linuxで非同期I/Oを行うためのライブラリ「libaio」の使い方を書いてみる事にする。少し昔の話になるが、lighttpdが使用し、スループットを80%も上げたらしい。 TOEFLに向けて転置ファイルについての論文(Inverted files for text search engine [moffat 06])でReading対策をしていたところ、意外とスニペット(検索にヒットした箇所の前後の文章)を作るところが時間がかかるという事を教えてもらったので、適当にそれを例題にしてみる。具体的には以下のようなコードを非同期I/Oを使用して速くなるかどうか見てみる。 for (unsigned int i = 0; i < files.size(); i++) { FILE*

  • 1