The Implementation of epoll (1)
In this series of blog posts, I will be taking notes about the internals and implementation details of the Linux event poll (epoll) subsystem. Prerequisites Please note that I am assuming the audiences of those articles are familiar with epoll APIs and usages. I will be focusing on the actual kernel implementation of the epoll subsystem, not it's usages. If you are not familiar with the usage of e
Epoll - from the kernel side
The document discusses the basics of I/O and event-driven I/O models in Linux like blocking I/O, non-blocking I/O, I/O multiplexing using select/poll and their internals. It then introduces epoll as a more efficient alternative to select/poll and describes its user-space API, kernel structures and how it works by adding file descriptors to an epoll instance and waking up blocked processes on I/O e
個人的epollめも - 愛と勇気と缶ビール
仕事柄、「ああいうデカいサイズのファイルアップロードとか、preforkでやるべきじゃないよね。イベントモデルじゃないと厳しい」とかそんな話をすることがあって、「確かにpreforkだとあの場合すぐプロセスが埋まっちゃいますよね」とか自分も分かったようなことを言うのだけども、裏側のことは特にはっきりと理解しているわけでなく、イベントモデルだと1プロセスで大丈夫だとか、下手にブロックしちゃうと死んじゃうとか、聞きかじっただけの知識でそういうことを何となく語ってしまう自分に不意に背筋がゾッとする、そのようなことも秋の夜長にはございます。 そのような良心の問題とは特に関係なく、ネットを漂流してほどよいサンプルを見つけたのでふんわりとした自分用のメモ。 http://www.oreilly.co.jp/community/blog/2010/03/pthread-epoll-inet-server
カーネル２．６の実力を探る NTTコムウェア株式会社 Linuxセンタ 佐々木博正
Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003/10/10 Copyright NTT COMWARE 2003 Linux Kernel Conference 2003
カーネル/VM Advent Calendar 一日目: eventfd, timerfd, signalfd - Emacs ひきこもり生活
ひ、日付? な、なんのことです…!? 最初はfutex()とかカーネルの変更でpostgresqlが遅くなったとかの話をからめようかと思ってたんですがfutex()調べてたらどんどん大きくなってしまったので今回はスキップして(そのうちあるであろう)2回目にまわしとくことに。 ということで、今回はfutex()から似たところ?で、 epoll, kqueue, *fdあたりを簡単にまとめてみようと思います。 select まずはselect()のおさらいを。 こんなふうにサーバにクライアントが5つぶらさがっています。クライアントは常時接続はしていますが、ずっとサーバと通信しているわけではありません。時々サーバにリクエストを投げ、サーバは適宜リクエストに応答します。サーバはsocketを作ってクライアントと通信をしています。 言うまでもないことですが、こんなコードではうまく動きません。 for
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
c10k problem memo
C10K とか, Web サーバ (あるいは Node.js みたいなフレームワーク) とか, Web システムのパフォーマンスとかを議論するときには, いかに並列処理するか (スレッドとか) と いかに IO をうまくハンドリングするか (multiplexing とかノンブロッキング・非同期とか) の知識が共通で必要になる気がするのでここを抑えておきたい. ここからイベントドリブン (libev とか) -> 実際のサーバやフレームワーク・ライブラリの実装 という風に進んでいけばいい気がする 結論 これを読むのが一番近道感がある. UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI - W.Richard Stevens Process & Thread どちらも処理の並行実施の単位 プロセスを復習すると 処理の実行単位 メモリを個別に持つ 1 つ以上
I/Oを多重化するためのシステムコール(select, poll, epoll, kqueue) - $shibayu36->blog;
サーバ周りの勉強していると、たまにselectとかepollとか言葉が出てきて、理解できてなかったので調べてみた。 I/Oの多重化 例えばサーバ周りの実装を、特に何も考えずにやると、I/Oでブロッキングが発生し、一つのクライアントとしか通信できないということが起こります。これを解決するために fork threads I/Oの多重化 非同期I/O といった方法があります。 この中のI/Oの多重化を実装するためのシステムコールとして、select, poll, epoll, kqueueなどは実装されているようです。 少し調べてみると、次のような記述のような機能をそれぞれが実装するようです。 プログラムで複数のファイルディスクリプタを監視し、 一つ以上のファイルディスクリプタがある種の I/O 操作の 「ready (準備ができた)」状態 (例えば、読み込み可能になった状態) になるまで待つ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scaling Userspace @ Facebook