マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
Togetter - 「GHC 7.0.x―7.2.1 現在のスレッド実装について」
GHC (Haskell) のスレッド実装について議論する時の参考になるよう、GHC 7.2.1 までのスレッド実装についてのやり取りやメモ的なつぶやきをまとめておきます。
mixi大規模障害について 解明編 - mixi engineer blog
こんにちは、システム本部技術部たんぽぽGの森本です。 先日のmixi大規模障害の原因となったmemcachedの不具合の詳細な解明ができました。 再来週まで発表を見合わせようと思ったのですが、早くお伝えしたほうがいいと思いましたので公開発表致します。 memcachedとlibevent memcachedはlibeventというライブラリを使用してクライアントからの要求(接続、コマンド送信)を処理しています。 libeventを使用するにはevent_baseという構造体を用います。 main threadはmain_baseを使用します。 static struct event_base *main_base; ... int main (int argc, char **argv) { ... main_base = event_init(); ... /* enter the ev
mixi大規模障害について その2 - mixi engineer blog
こんにちは。システム本部技術部たんぽぽGの森本です 補足を追記しました (2010/08/20 15時) 先日のmixi大規模障害についての続報です 今回は小ネタはありません はじめに まず初めにtwitter/blogなどを通じて今回の問題の解析を行っていただいたみなさんに感謝の言葉を捧げたいと思います kzk_moverさん stanakaさん mala(bulkneets)さん llameradaさん (順不同) ありがとうございました 書き漏らした人ごめんなさい memcachedはすごい 今回の件でmemcachedに対して不安感を持たれた方もおられるとお聞きしました 説明不足だったせいで誤解を与えてしまい申し訳ありません きちんと設定および監視を行っていれば通常の使用にはまったく問題はありません 弊社にて -c 30万で起動したmemcachedに対して、先のテストスクリプトに
index / OCaml4MultiCore
This project aims at allowing Objective Caml to take advantage of multicore architectures, notably those now commonly used in laptops and desktop PC. 2010 spring-summer (current work, in progress) : (ocaml-3.12-svn) “from scratch”, making the runtime library fully reentrant, first without threads preoccupation early 2010 : (ocaml-3.11.1) adaptation to work on x84-32 and x84-64, with Linux and Mac
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
ivarの必要性 - ocaml-nagoya
OCamlではCMLスタイルのスレッド間通信が可能です。 Eventモジュールには基本的なイベント型やその同期関数が揃っています。 ところが、ivarやmvarといった共有変数が無い為に苦しい状況になっています。 例えばとても単純に、整数を渡して計算結果を（今回は倍にして）返してくれるスレッドを作ってみましょう。 すぐに思いつくのは、次のようなコードです。 let start_server () = let in_ch, out_ch = new_channel (), new_channel () in let rec loop () = let x = sync (receive in_ch) in loop (sync (send out_ch (x * 2))) in ignore (Thread.create loop ()); in_ch, out_ch let calc (i
HaskellのスレッドシステムとSTMについて その1 — ありえるえりあ
概要 HaskellのスレッドシステムとSTMについて調べたので、ここにまとめます。 Haskellのスレッドシステムは、予想よりも複雑でした。 Haskellの世界で閉じた処理ならば、比較的簡単なのですが、 FFI(Foreign Function Interface: 外部のCの関数を呼び出す仕組み)を使うと、 とたんに複雑になってしまいます。 一度に書くと、量が多いため、数回に分けて書こうと思っています。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ccell
Simon Peyton-Jones - Microsoft Research