Java ブロッキングとかノンブロッキングを理解したい - SIerだけど技術やりたいブログ
この記事はブロッキングやノンブロッキンクとは何か、Servlet3.0の Async Servletや Servlet3.1の NonblockingI/Oとは何か、を理解することが目的です。 検証バージョン ブロッキングI/O コード例(シングルスレッド) 実行例 コード例(マルチスレッド) 実行例(マルチスレッド) ブロッキングI/Oで何がいいか ブロッキングI/Oで何が困るか ノンブロッキングI/O コード例 実行例 ノンブロッキングI/Oで何がいいか ノンブロッキングI/Oで何が困るか Tomcatのコネクタ実装 ブロッキングI/O HTTP Keep-alive 今までありがとうBIOコネクタ ノンブロッキングI/O SocketProcessorの実行タイミング HTTP Keep-alive BIOとNIOを比べる その他の仕組み Servlet3.0 Async Servl
Serializing accept(), AKA Thundering Herd, AKA the Zeeg Problem — uWSGI 2.0 documentation
After having forked itself a bunch of times, each process will generally start blocking on accept() The funny problem is that on older/classic UNIX, accept() is woken up in each process blocked on it whenever a connection is attempted on the socket. Only one of those processes will be able to truly accept the connection, the others will get a boring EAGAIN. This results in a vast number of wasted
Thundering herd 対策の本命、 EPOLLEXCLUSIVE を試してみた : DSAS開発者の部屋
epoll を使った prefork 型アプリケーションサーバーにおける Thundering herd 対策の決定版として注目されていた EPOLLEXCLUSIVE が、 3/13 にリリースされた Linux 4.5 で導入されました。 昨年 SO_REUSEPORT というソケットオプションが登場して、 Thundering herd 対策として話題になったものの、ワーカーごとに listen キューが作られるため graceful restart するときに listen キューに入ってるリクエストを取りこぼす可能性があり利用するのが難しい状況でした。 参考: epoll の thundering herd 問題について解説しているサイト http://tech.geniee.co.jp/entry/so_reuseport http://uwsgi-docs.readthedo
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
Netty.docs: Native transports
Note that you must specify the proper classifier for the dependency to ensure that the corresponding native libraries are included. Because the native transport is compatible with the NIO transport, you can just do the following search-and-replace: NioEventLoopGroup → EpollEventLoopGroup NioEventLoop → EpollEventLoop NioServerSocketChannel → EpollServerSocketChannel NioSocketChannel → EpollSocketC
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
Netty.news: Netty 4.0.17.Final released