IIJ Technical WEEK 2011 Day1
-
- いいね！1
doumae
@donz80
10万ファイル10万mapタスクで実験すると、200ノードまでリニアに高速化されることが確認された。問題が大きければ多ノードが有効に活用できる。 #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 15:53:24
doumae
@donz80
Q.Map Reduceロジックの指定は可能か？A.自分で書いたプログラムを投入できる。 #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 15:56:19
doumae
@donz80
Q.分散数が3であって4でないのは？ A.GoogleもHadoopも3だったので……。2だと少なきがするし4だと多い気がする。 #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 15:57:05
doumae
@donz80
Q.dplat外部公開(サービス化)の予定は？ A.今のところは予定はありません #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 15:57:34
Manabu Kondo
@mnb0327
何故だろう? RT @donz80: Q.dplat外部公開(サービス化)の予定は？ A.今のところは予定はありません #iij_tw2011 http://t.co/J1ErNkTp
2011-11-09 16:00:14
doumae
@donz80
つぎは、IIJ-IIの山本から「マルチコア時代のサーバプログラミングとHaskell」です。今話題のHaskell! #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:06:29
doumae
@donz80
最近のCPUは高速化ではなく、マルチコア化・省電力化に進んでいる。本当にそのマルチコアを活用できていますか？ということで「マルチコア時代に使える技術を再検討してみよう」というお題で発表します #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:08:12
doumae
@donz80
同時接続の処理技術:都度プロセスを生成するのが最も基本。処理速度が求められないケースでは今でも使われている。単純、プロセスが別れているのでセキュア。fork・コンテキストスイッチが遅いので多数のリクエストには不適 #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:11:39
doumae
@donz80
プロセスをスレッドに変更、接続ごとにスレッド生成。プロセス生成に関する問題は回避できるが、利用実績は？ #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:12:32
doumae
@donz80
プロセスプール(prefoork)あらかじめプロセスをforkしておいたものを接続ごとに利用する。単純・セキュア・forkの遅さを回避。しかし、プロセスが足りなくなることも。コンテキストスイッチは相変わらず遅い #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:14:29
doumae
@donz80
スレッドプール あらかじめ生成しておいたスレッドに接続を割り当てる(ディスパッチ)。リソース消費が抑えられる。しかし、スレッド不足の可能性や、ディスパッチがボトルネックになる可能性も。 #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:16:30
doumae
@donz80
プロセス/スレッドの種類４つ: カーネルコンテキストスイッチ[プロセス・(ネイティブ)スレッド] ユーザプログラムによるコンテキストスイッチ[軽量プロセス・軽量(ユーザ)スレッド] #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:18:57
doumae
@donz80
Erlang→軽量プロセス、Haskell→軽量(ユーザ)スレッド / この発表での軽量の定義…10万超生成しても問題ないレベルのもの #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:19:46
doumae
@donz80
イベント駆動:I/O多重を使ってハンドラを駆動する 今のnode.jsとか。リソース消費が少ないが見通しが悪い。1プロセスしかないのでブロックすると全部とまる。 #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:21:56
Hiroshi Nakamura
@nahi
Node.jsはつい先日（この資料の作成後）リリースされたv0.6で、マルチプロセス化されました（言い方はともかく、ここで説明されている意味でのマルチプロセス化はされました） #iij_tw2011
2011-11-09 16:22:35
doumae
@donz80
うう、なんか講義ノートを取っている気持ちになってきた。このセッションは投稿が追いつかないと思うので、あとで発表資料をご覧になることを強くお勧めします。 資料は夜公開予定、右記URL参照 #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:23:06
doumae
@donz80
発表資料訂正: P14 非同期I/Oのところに縦の矢印がありますが、この矢印はないものと思ってください(間違えて書いたそうです) #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:25:35
SHIMPEI OGAWA (小川晋平)
@IIJ_Shimpei
IIJ Tech Week行きたいけど行けない...悲しい @donz80の資料を後でみます。#iij_tw2011 http://t.co/7ny714Ea
2011-11-09 16:26:23
doumae
@donz80
マルチプロセス+イベント駆動: 複数プロセスを立ち上げたイベント駆動。リソース消費そこそこで性能が出る。欠点はブロック厳禁、コードの見通しは悪い。 #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:28:10
doumae
@donz80
マルチプロセス+イベント駆動 or マルチスレッド+イベント駆動が最近のお勧め。では、「マルチ」っていくつぐらい？ #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:28:49
doumae
@donz80
コンテキストスイッチは重い。コンテキストスイッチさせないために、コア数と同じだけプロセスを作るのがベスト。さらにシステムコールを減らすのが重要。 #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:30:23
doumae
@donz80
kaz(発表者)が開発に参加しているHaskellのHTTPエンジンWarpではこの辺りに非常に気を遣っている。システムコールをできるだけ使わないように。lseek()を使わない、stat()の結果をキャッシュとか #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:32:29
doumae
@donz80
イベント駆動をどのようにプログラマに見せるか。(プログラマにどう使わせるか) コールバックはイベント駆動をそのまま見せている。AnyEventとかnode.jsとか。コードがぶつ切りになるので見通し悪い。 #iij_tw2011 http://t.co/cI9YMP0j
2011-11-09 16:34:12