Parallel::Fork::BossWorkerAsyncがいい感じ
先日 id:hirose31 と
- 並列処理はParallel::ForkManagerとかParallel::Preforkが定番だけど、もうちょっと効率よくやりたいこともある
- P::ForkManagerはタスクごとにforkするので負荷の分散は綺麗にできるが、タスクの数だけforkが発生して効率がよくない
- P::Preforkだとfork回数は並列度分だけだが、タスク開始前にタスクの分配を完了させないといけない
- Cでmultithreadならmaster-workerモデルでmasterにqueue持ってmutexでロックするような練習問題とかある
- けどPerlでmultithreadやりたくないし、実現するとすればsocket経由でタスクを渡していく感じにしないといけないか
- 誰かCPANに上げてるんじゃないかなー
- なければ作るかー
的な話をしていました。
で、metacpanを漁っていたところ、それっぽいのを見付けました。Parallel::Fork::BossWorkerAsync。
計算モデル
このモジュールは事前に1個のbossとk個のworkerプロセスをforkし、masterが都度タスクを生成して登録していきます。
workerはただただwork_handlerで与えられたsubを実行していき、計算結果をreturnします。
workerの計算結果が帰ってくるとmasterではresult_handlerで与えられたsubが呼び出されます。(たとえば結果を集めるオブジェクトに登録する)
最後にshutdownを呼び出すとbossと全workerが終了します。
プロセスツリーとしてはこうなります。
└─perl,18371 bwa.pl # アプリケーション
└─perl,18372 bwa.pl # boss
├─perl,18373 bwa.pl # worker
├─perl,18374 bwa.pl # worker
├─perl,18375 bwa.pl # worker
├─perl,18376 bwa.pl # worker
└─perl,18377 bwa.pl # workerbossプロセスは各workerとアプリケーションとタスク/結果のやりとりをするためにひたすらselect(2)を呼んでいるプロセスです。
workerプロセスはbossからタスクを受け取って処理したらbossに結果を返します。
アプリケーションプロセスはbossとだけ直接通信し、タスクを投げて結果を受け取ります。
利用例
大したものではないですが、podに書かれていないようなモデルでの利用例。
workerは単に1秒sleepし、自分のjob idを返します。
masterは返されたjob idを配列に追加していって最後にdumpします。
それだけ。
この例ではk=5としていて、最初に5プロセスが生まれた後はプロセスの交代は起こっていません。
タスク供給はちょっと不定期な感じにするために、17個ずつ供給し、終了次第次の17個を供給してます。
53 / 17 = 3あまり2
17個のタスクを5並列でやると4秒かかるので、
4 * 3 + 1 = 13秒で実行が完了します。
#!/usr/bin/env perl use strict; use warnings; use Parallel::Fork::BossWorkerAsync; use Data::Dumper qw(Dumper); use Time::HiRes qw(gettimeofday); my @Finished_Jobs = (); my $PARALLELISM = 5; # sleep time my $NUM_WORKS = 53; my $WORKS_AT = 17; # この時点でworkerがｆｏｒｋされた my $bw = Parallel::Fork::BossWorkerAsync->new( work_handler => \&work, result_handler => \&rhandler, worker_count => $PARALLELISM, ); my $thrown_work = 0; while($thrown_work < $NUM_WORKS) { my @tasks; for my $i ($thrown_work .. $thrown_work + $WORKS_AT - 1) { push @tasks, { id => $i, sleep => 1 }; $thrown_work++; if ($thrown_work >= $NUM_WORKS) { last; } } # タスク集合はここでディスパッチされる $bw->add_work(@tasks); # 実行完了待ちタスク数が得られる。この関数はblockしない while($bw->pending) { # "return"されたオブジェクトをそのまま受け取る。以下のように単に呼び出すとblocking my $ref = $bw->get_result; # P::F::BossWorkerAsyncのレイヤでエラーがハンドルされた場合は ERROR というkeyにメッセージが入ってくる(タイムアウトを指定した場合など) if ($ref->{ERROR}) { print STDERR "ERR: ". $ref->{ERROR}; } else { print $ref->{job} . "\n"; } } } # workerプロセスを終了させる $bw->shut_down; print Dumper \@Finished_Jobs; # worker側で各タスクに対してcallbackされる sub work { my ($job) = @_; my $id = $job->{id}; my $t0 = gettimeofday; print "$t0 start $id\n"; sleep $job->{sleep}; my $te = gettimeofday; print "$te end $id\n"; return { job => $id }; } # master側でタスク終了時にcallbackされる sub rhandler { my ($result) = @_; my $job = $result->{job}; push @Finished_Jobs, $job; return $result; }
内部的にData::Dumperを使ったシリアライズをしているらしく、データの区切りに決め打ちのバイト列を指定する必要があります。そこはStorable::nfreeze/thawした方がいいんじゃないかな？と思ったりはします。
P::ForkManagerやP::Preforkに比べると記述は増えますが、用途によっては便利なのでは？
Server::Starterに対応するとはどういうことか
StarletやStarmanと組み合わせてよく使われているServer::Starterですが、普段気にしないような部分を読む機会があったのでメモ。
Server::Starterは --port (TCP) や --path (Unix Domain Socket) を渡すとこれでlisten(2)して起動するworkerに引き渡してくれる。
これはfork(2)とexec(2)によってファイルディスクリプタを引き継ぐことにより実現されているが、ファイルディスクリプタそのものをどのように引き渡しているのか、という問題。
exec(2)により実行バイナリは差し換わってしまうので、プログラム中の変数により引き継ぐことはできない。
Server::Starterではこれを環境変数SERVER_STARTER_PORTにより実現している。
おおよそ以下のような感じ。
FD = integer EQ = '=' SEMICOLON = ';' SERVER_STARTER_PORT = PORT_DESCRIPTION ( SEMICOLON SERVER_STARTER_PORT ) PORT_DESCRIPTION = PORT_NAME EQ FD PORT_NAME = character+
PORT_NAMEはソケットの種類によって違って、TCPであればポート番号(8080)とかホスト名:ポート番号(localhost:8080)、Unix Domain Socketであればそのパス(/path/to/app.sock)となる。
PODにも書いてあるServer::Starter::server_portsはこの環境変数をほどいてPerlのハッシュにして返してくれる小さなサブルーチンとして実装されているので、workerがPerlであればこれを使えばよい。
workerは環境変数から受け取ったファイルディスクリプタの番号をfdopen(3)して（あるいはそれすらもせずに)そのソケットを利用することができる。
ところで別にworkerがPerlであることは要請されていない。
続きを読むYAPC::Asia 2013 Staff Report
去年の YAPC::Asia 2012にStaff参加してきた - Limitの日記 に引き続き、今年も YAPC::Asia 2013 のStaffとして参加してきました。
今年も「ブログを書くまでがYAPC::Asia」ということで、書きます。
今年は僭越ながら多目的教室2という部屋のリーダーを仰せつかり、メンバーをまとめる役割となってしまいました。
この部屋で何か問題があったら私のせいです。
Staff Kickoff
Staffは7月頃に1度集まり、kickoffという名の飲み会をやっていました。
ここでは主に顔合わせ。去年と同じく名刺交換などです。
前夜祭
実は前夜祭の前にコアスタッフと呼ばれる一部メンバーが9割方の準備を済ませてくれています（ほんとうにありがとう！）
前夜祭の日に集まったスタッフは残り1割の準備をやります。
ひたすら来場者に渡すノベルティの準備作業をしたり、椅子スポンサーの準備をしたり、会場の展示物の準備をしたり、、、
例年の前夜祭では受付の開始前にはノベルティは準備が終わるのですが、今年は分量が多く、受付開始しても準備が終わらない状態。
前夜祭の受付がバタバタしていたのはそのせいです。
それでもスタッフがいい感じに連携してTシャツを渡すことができていたので、かなりスムーズな受付になっていたと思います。
その裏では別メンバーがノベルティ詰め作業を続行していました。
受付が一段落した後もTシャツをサイズ別にトートバッグに入れ、整頓する作業が続けられました。
NOCチームはずっとNW敷設作業をしていました。
個人スポンサー/企業スポンサーの提灯のセッティングもこのあたりで。
企業スポンサーの提灯が階段上の手すりをわたるようにセットされていましたが、あれもその場のスタッフのアイデアです。
作業は施錠の21:00まで続きました。
1日目
本番初日、8:30集合、9:00開錠ということで、朝から慌ただしい感じでした。
多目的教室はこの日初めて入れるようになったので、そこから椅子スポンサーの準備、ビデオカメラ設置、電源準備、バックパネル準備などを行い、最初のセッションに備えます。
各部屋ごとに担当者のLINEグループをつくり、メンバーはそこでその部屋固有のやりとりをできるように準備。
スタッフも抜けたい時間があったり、他の会場の準備を手伝う予定ができたりするので、セッションごとに担当を割り付けます。
そのあとは各セッションでタイムキーピング、録画がされているかを確認、幕間に流すCM、発表者への説明などを行っていました。
懇親会の間には翌日に備えた細々とした準備をしたり、投票システムのチェックをしたり（実は告知前にシステムのバグを発見していました/もちろんリリース前に修正済）。
懇親会は後半だけいたのですが、ご飯おいしかったですね。
この日は懇親会の後比較的早めに作業が終わり、平和に終わりました。
2日目
この日は基本的に1日目と同じです。
LTが行われる間に大量の撤収作業が行われ、とにかく早く全てを片付ける、ということに追われていました。
ということでやはり発表はほとんど見ていません。動画に期待。
大きな物の運び出しは運送業者の方がやってくる時間が決まっているので、期限があるものからとにかく片付ける。
なかなか物は減らず、メインホールで発表が行われている間も含めて数時間にわたる撤収作業が行われていました。
Staff として。
YAPC::Asia Staff としては2年目、YAPC::Asia の参加者としては3年目でした。
去年も一緒にStaffとして仕事をした方とは相変わらず、今年からの方とも仲良くなれて、人間関係が広がったんじゃないかなと思います。
Hacker の技術をお披露目する場を作る手伝いができるって、楽しい。
実は通しで見られたセッションは2つくらいだったりしますが、その辺は後日公開の動画で補完しておきます。
今後の YAPC::Asia は？
クロージングでは今まで YAPC::Asia を主体となって運営してきて下さった牧さん、櫛井さんの引退が発表されました。
スタッフもこのとき初めて聞かされたことでした。世代交代の時期ということなのだと思います。
来年も YAPC::Asia を誰かが開催できるかどうか、わかりません。今回1000人規模でしたが、牧さん櫛井さんが抜けた結果、この規模で開催はできないかもしれません。
それでも、縮小しても開催できれば、また大きくするチャンスがあるのだと思います。
もし開催されれば、そのときはまた運営として携わってみたいです。
クロージングでのスタッフ紹介のときにぱちり。
参加したみなさんへ
ブログを書くまでがYAPC::Asiaです。みなさん書きましょう。
書いたらYAPC::Asia 2013 感想エントリまとめ（募集中） | YAPC::Asia Tokyo 2013へ。
アンケートもメールが届いていると思うのでお願いします！
ときどきTech系イベントには参加しているので、もしどこかで見掛けたら声かけてください。
では！
MacBook Air 11インチ用ケース
4年くらい前に800円くらいで買ったケースがだいぶボロボロになってしまったので、いっそのこと、ということで新しいのを買うことに。
近所の電器店で眺めて、収まりのよさそうなやつを選択。
いい感じ。
だが、結果的にはAmazonで買った方が安かったじゃないか。。。
MacのDockが暴走した
最近メインで使っているのはMacbook Air (Lion) なのだけど、数日前から妙に動きが重くなり、ファンもうるさくなったのでちょっと調べてみた。
まずhtopで長めてみると Dock がCPU 100%食っていた。原因はまずこれだ。
減少としては17秒くらいに1回DockがSIGABRTを受けて死んで、また起動してCPU 100%に貼り付く。を繰り返す状態だった。
検索したところ、VMware関係が原因だとかいうのが目立つが、どうやら違うらしく、最終的に以下の記事に行きついた。
https://discussions.apple.com/thread/3684623?start=0&tstart=0
まずは ~/Library/Preferences をまるっとbackupしておく。
で、とりあえず ~/Library/Preferences を消してみる。
そうすると次にDockの再起動時には直るので、ここが原因らしいと確認できた。
あとはbackupを戻して再起動して再現させ、設定ファイルを消しては再起動後に直るかどうかを順番に試していくだけ。
今回は最終的に
rm ~/Preferences/ByHost/com.apple.dock.AE697267-4B85-5FC7-BF96-EBE7847EF12B.plist
により落ち着くことが確認でき、復旧完了。
あー大変だった。
YAPC::Asia 2012にStaff参加してきた
日本で最も大きなPerlの会議、YAPC::Asia 2012に参加してきました。
去年は学生チケットで参加させていただいたのですが、今年はボランティアスタッフとして。
ということで、スタッフをやりながら印象に残った発表などを書いていきます。
前夜祭の日は参加できませんでしたが、2日目と3日目はフルで参加しました。
Kickoff Meeting
これはYAPC::Asia 2012の数ヶ月前に開催された、スタッフの顔合わせです。
ボランティアスタッフ募集に応募した人が一度集まり、名刺交換したり親睦を深めたり。
ここで多くの人がFacebook経由でゆるーく繋がり、連絡が取りやすくなりました。
LINE
「当日は LINE で連絡とりあいましょう」という通知がきました。
みんなスマホ持ってるし、IRC よりカジュアルに連絡が取れました。通知もくるし。
それまではスタッフ用 IRC で込み入ったやりとりをしていましたが、当日はこっちの方が楽だったのでよかったと思います。
結果論ではありますが、今年のネットワークではIRCのポートが遮断されていたので、むしろHTTPだけのLINEが好都合でしたね。LINE++
スタッフみんなが入るグループトークと別に部屋ごとにもグループトークをつくり、スタッフ同士の緊密なやりとりがそこでされていました。
発表中にでも離れたスタッフに空調の調整、マイク調整など、連携をとることができました。
スタッフみんなが#yapcasia をウォッチできていたわけではなかったのですが、見ていた人から「〜の部屋寒いって」などの情報が伝えられ、調整していました。
1日目
YAPC::Asia 2012 スタッフの朝は早い。
8時に現地に集合です。9時には受付を開始し、10時くらいには各部屋の机や椅子の配置、音響チェック、電源の確保、録画録音の準備、椅子ポンサー広告貼り、プロジェクタ投影テストなどを済ませておく必要があります。
特に録画録音はミスすると後日の映像公開に支障が出てしまうので、ミスのないようにどうするか、その場でプロトコルを決めました。結果的に非常にうまくいきました。
発表者の方には発表に関する連絡(持ち時間、ベル鳴らす時間)をします。1日目の中教室(Room 1)は日本語を話せない発表者の方が多かったので、全てはスタッフの英語力にかかっていました。話せてよかった。
Impressive Presentation
1日目で自分にとって最も印象的だった発表は Tim Bunce の Profiling memory usage of Perl applications です。
LLのメモリ消費は通常ランタイム実行系に任せてしまい、多くの場合プログラマは気にしなくていいのですが、いざメモリ消費が深刻な問題となったとき、それを突き止めるのが困難であるという面もあります。
この発表ではそれを分析するための基礎知識としてPerlにおけるメモリ消費がどのように行われているかという解説に始まり、あるPerlプロセスがどこでどれだけのメモリを消費しているかを可視化するツールの実演も行われました。資料によると9/30中に公開されるようです。
質疑ではLarryからの突っ込み回答などもあり、盛況なセッションでした。
実は他の発表、眠気に勝てずちゃんと見られていません。あとで録画を見ます…
懇親会
懇親会は大盛況でしたね。去年と比べても人が多かったように思いました。
同僚やスタッフ、その他知り合いとゆっくり話すことができました。
食事は豪華でしたね。来年もできるのかな…？
2日目
Impressive Presentations
午後の id:TAKESAKO による発表『Perlで始める！初めての機械学習の学習』が非常に面白かったです。
機械学習のバイブルともいえるビショップ本を読んでいた話、それを読むための基礎数学をまとめた話、そしてKinectを使ったデモなど、明瞭なプレゼンが人気を博していました。
特別教室で行われた @nontan___ の『Perlでひとつサービスをつくってわかったこと』も印象に残りました。
本当にプログラミングの経験が一切ない人が、3ヶ月間で1つWebサービスを作ってみたとき、何に躓くのか、紹介してくれました。
個人的には12年くらい前、自力でプログラミングを覚えたときの自分を見ているようで、懐しい気分になりました。似た気分になった人もいるのではないでしょうか。
発表後、つい話しかけてしまいました。
Closing
Closing session は我らYAPC::Asia スタッフを取り纏めてくださっていた id:lestrrat です。
過去にない規模のイベントになり、そこでスタッフとして参加できてよかったです。
この最後にスタッフ紹介という感じで壇上に上がったのですが、ほぼ満席になったメインホールは壮観でした。
片付け
イベントが終わり、参加者がだいたい帰ったところでスタッフは片付けです。
忘れ物の集計、発送しておく必要のある荷物をまとめるなどして、借りていた会場のセッティングを元に戻して完了です。
今年は人数も多く、非常に速く作業ができたようです。
50個くらいある椅子を「片付けるの手伝ってくださーい」といった数分後には完全に片付いていました。
数の力ってすごい。
Githubの証明書問題をまっとうに解決する
github SSL certificate problem - A Life Less Ordinary と同じ問題に遭遇してしまったので、まっとうな解決策を探ってみたところ、無事に解決できたのだが、どうやら同じようなことをしているページが見つからなかったので書いておく。
error: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing https://github.com/......
- 問題はGithubのHTTPSで使われているSSL証明書を発行しているところ(CA)が変わったが、たまたまそのgitコマンドは Root CA のセットが古く、新しいCAの証明書が入っていなかったこと。
- したがって、根本的な解決策としては新しい Root CA のセットを用意して、gitがそれを参照するようにしてあげればいい。
まず、そういう Root CA のセットをとってくる。
curl http://curl.haxx.se/ca/cacert.pem -o ca-bundle.crt
あとはgitが参照する Root CA セットのファイル名をどこに置くかということになる。
git-config(1) によると、どうやら http.sslCAInfo でいいらしい。
ということで、たとえば
git config --global http.sslCAInfo /home/limit/ssl/ca-bundle.crt
みたいなことをするか、適当に書くなどして、~/.gitconfig は以下のようになる。
[http]
sslCAInfo = /home/limit/ssl/ca-bundle.crt
と、ここまで書いておいて、実際やってるページをみつけた。 Github のプライベートリポジトリからcloneするときにSSLエラーがでた場合の対応策 - Goodpic
