技術を活かし、新しい価値を創造する DeNAのエンジニアは、想像を超えるDelightを届けるために何ができるかを考え、技術力と発想力で新しい価値を生み出しています。 多様な専門性を持ったエンジニアが切磋琢磨し、互いに刺激し合える環境や制度がさらなる成長へとつなげます。
要約 Server::Starterの0.17以下のバージョン(とStarlet)によって動かしているときに無限ループ等でいつまでも処理の終わらないリクエストが発生すると、アプリケーションプロセスの再起動のためのHUPシグナルをServer::Starterが正しく処理してくれないことがある。 この挙動によってアプリケーションプロセスが古いリビジョンで動かしてしまうなどの問題があって困っていたんだけど、気付いたら0.19でこの挙動が改善していた。 前提 perlでdaemontoolsを用いてアプリケーションプロセスを動かし、かつホットデプロイを実現しようと思ったときの有力な選択肢がServer::Starterによるstart_serverとStarletの組み合わせだと思う。start_serverとStarletは以下のような挙動を示す。 start_serverはHUPを受け取った
@takezawaさんから、PerlベースのWebアプリケーションサーバであるStarletで複数ポートをlistenできるようにするPRをいただいたのでマージしました。やったね! で、それに伴いprefork型TCPサーバのThundering Herd問題を再訪したので、その備忘録。なお、Thundering Herd問題については、prefork サーバーと thundering herd 問題 - naoyaのはてなダイアリーや、Starman と Starlet のベンチマークと Accept Serialization - Hateburo: kazeburo hatenablogあたりを参照のこと。 まず、こんなテストスクリプトを書いた: thundering-herd.pl こいつを書いてあるコメントのとおり実行してみることで、2種類のケースでThundering Herd
やりたいことの半分も出来てないけど、連休終わってしまうので出来たところまでDemo。Webサーバーのアクセスログをリアルタイムで監視して、リアルタイムで音にして聴いてみよう、しかも音楽的な感じで、という試みです。 https://github.com/aklaswad/statechno ビデオにキャプションつけるやりかた分からなかったので、何をやっているかわかりづらいかもしれませんが、以下のような流れのデモです。 起動するよ 音が出るよ アクセスが増えると盛り上がるよ エラーも拾うよ アタックされると多分こんな感じだよ upstreamが死ぬと多分こんな感じだよ 監視サーバーごと死ぬと多分こんな感じだよ Pdのパッチだよ アクセスが減ると寂しいよ 基本的にtechno_nekoさんと話してた流れで「perlで音楽で遊びたい」->「だがperlでオーディオそのものをいじるのはしんどい」->
NAME P9Y::ProcessTable - Portably access the process table SYNOPSIS use P9Y::ProcessTable; my @process_table = P9Y::ProcessTable->table; print $process_table[0]->pid."\n"; my @pids = P9Y::ProcessTable->list; my $perl_process = P9Y::ProcessTable->process; my $other_process = P9Y::ProcessTable->process($pids[0]); if ($other_process->has_threads) { print "# of Threads: ".$other_process->threads."\n";
Monoceros というPSGI/Plackサーバ書きました https://metacpan.org/release/Monoceros https://github.com/kazeburo/Monoceros StarmanやStarletのようなPreforkなアプリケーションサーバでは、コネクションの維持イコールプロセスの占有なので、HTTPのKeepAliveは無効にするのが一般的ですが、負荷の高いサービスではTIME_WAIT状態のソケットが溜まったり、SYN-ACKの再送問題などあり、KeepAliveを使いたいという欲求があったりなかったりします。 Monoceros はリクエストを処理するworkerの他に、イベントドリブンで動くコネクション管理プロセスを立てて、クライアントからの接続ソケットをunix domain socketを使いプロセス間でやりとりします。待機
具体的には Redis の subscriber なんですが、pub/sub の pub 側が publish し続けている状態で subscriber を再起動すると、落ちてから起動までの間に来たメッセージを取りこぼす可能性があります。 pub 側を一時停止すればいいのですが、fluent-plugin-redis_publish で fluentd から publish しているので、これを止めるのはあまりやりたくない。 複数の subscriber が同時起動して処理に問題が出ないように作られていることが前提ですが、新しい subscriber を起動したら古いのを殺すようにすればいいよね? → それ Server::Starter でできるよ、という流れ。 $ start_server -- perl -e '$SIG{TERM}=sub{ warn "[$$] SIGTERM";
Webアプリケーション開発時などに依存するバックグラウンドプロセスを管理するツールとして rubyで作られた foreman というツールがあります Procfileという名前のファイルに worker: ./bin/worker web: plackup web.psgi と書いて $ foreman start とやると指定したプロセスを起動してくれるらしいです。 cho45やtokuhiromからの提案もあったので、Procletをベースに同様の機能を持つprocletコマンドを作り、Procletに同梱してリリースしました。 https://metacpan.org/module/Proclet バージョン0.11で追加されました。 インストールは $ cpanm Proclet 使い方 実装されていない機能もあるけどだいたいforemanと一緒です Procfileを用意して p
perldoc Test::Config::System use Test::Config::System tests => 4; check_package('less', 'package less'); check_package('emacs21', 'emacs uninstalled', 1, 'rpm'); check_link('/etc/alternatives/www-browser', '/usr/bin/w3m'); check_file_contents('Test/Config/System.pm', qr/do {local \$\//); check_package dpkgかrpm packageがinstallされているか。defaultはdpkgをtest check_file_contents 指定したファイル内に指定したregexがマッチするかte
perl は system perl じゃなくて perlbrew で入れて、アプリで必要な CPAN モジュールは全てアプリのディレクトリ下の extlib というディレクトリにインストールする方式は個人的にはいい感じだよなぁと思いつつ、cron とか daemontools がいつもどうやるのが正解なのか分からず困ってた。 またセットアップする機会があったので色々考えた結果、こんな感じなら割とすっきりした感じになった。 env このファイルがキモで、アプリのディレクトリに移動しつつ、いい感じに perl とか PATH とか@INC を設定して、渡されたコマンドを実行してくれる。 # perl -v This is perl, v5.8.8 built for x86_64-linux-thread-multi # ./env perl -v This is perl 5, versi
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
App::MadEyeとはPerlでかかれた監視フレームワークである。 基本ドキュメントを見ても一切使い方がわからないであろう このモジュールをちょっと解説してみる。 ちなみにYAPC::Asia 2010の省サーバ運用の発表の際、 「監視とかどうしてますか?」 という質問があったが、私はこのApp::MadEyeを使っている。 使用理由としては、基本的に監視したいと思う項目が網羅されている事、 使ったことがあること、nagiosとかめんどくさそう(使ったこと無いだけです) ということ、そして最大の理由はそれがPerlで書かれていることであろう。 早速解説というか使い方 App::MadEyeを起動するスクリプトを用意する。 今回は指定のサーバにpingを打ってみる例である。 #! /usr/bin/perl use strict; use warnings; use App::MadEy
以前「StarmanやStarletでmod_statusっぽい情報を得る簡易版Plack::Middleware::ServerStatus」で書いていたPlack::Middleware::ServerStatus::LIteをCPANにリリースしました。 http://search.cpan.org/dist/Plack-Middleware-ServerStatus-LIte/ 前回と大きく実装が異なっている箇所があります。1つはプロセスの状態を保持するためにParallel::Scoreboardを使うようになり、$0(PROGRAM_NAME)の書き換えを行わないようになったこと。2つ目はロケタッチを開発しているhideokiさんからの指摘で、アプリケーションが例外を起こしたときにステータスが戻らないという問題への対応をTry::Tinyを使って行っていることが大きな変更点です
cho45 さんの Plack::Middleware::ServerStatus (Starman や Starlet で Apache の mod_status 相当の情報を得られるようにする - 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech) に続き、昨日 kazeburo さんが「StarmanやStarletでmod_statusっぽい情報を得る簡易版Plack::Middleware::ServerStatus - blog.nomadscafe.jp」というエントリを書かれていらっしゃいましたが、ウェブアプリケーションサーバに限らず、複数のワーカープロセスが動作するシステムにおいて、それらの状況をモニタリングするためのスコアボードがほしい、というケースはよくあることだと思います。 また、プロセス名を使う方法は、他の監視ツールとの相性が悪い、プロ
最近、弊社でもいくつかのサービスでStarmanが動き始めてます。リソース監視厨としてStarmanやStarletといったPreforkなPlackサーバにおいてもApacheのmod_status同様、使用されているプロセス数、アイドル中のプロセス数を当然知りたいわけです。CloudForecastでグラフにしたいわけです。 すでにcho45氏がその機能を実現しています。cho45++です。ただ、ステータス表示を行うMiddlewareの他にステータス情報の変更を行うためにStarmanやStarletの本体に手を入れており、若干使いにくいという印象を持っていました。そこでMiddlewareだけで、Middlewareのできる範囲でステータスを変更・表示するPlack::Middleware::ServerStatus::Liteを書いてみました。ソースコードはgithubにpush
http://frepan.64p.org/~tokuhirom/Proc-Guard-0.01/lib/Proc/Guard.pm テストなどで memcached やら ttserver やら gearmand やらを起動するにあたって、サーバープロセスを起動するとかいった場合に、サーバーの種類ごとにライブラリを書くのも馬鹿馬鹿しいので、起動する部分だけを抽象化してみたという話。主にテストでつかう用途を想定している。 たとえば、memcached の起動部分は以下のようにかくことができる。$proc が消滅した時点で、memcached のプロセスは消滅する(by DESTROY())。 use Test::TCP qw/empty_port wait_port/; use File::Which qw/which/; use Proc::Guard; my $port = empty
「クラウド」って言ってみたかった。今は反省していr 上のグラフは前回のエントリーを公開したときの、当blogを配信しているサーバのトラフィックグラフです。記事を公開した17時にぴょーんとトラフィックが伸びています。4時にも増えているけどこちらは謎。 実はこのグラフもCloudForecastを利用して取得しています。CloudForecastはサーバ等のリソース監視を行うツールもしくはフレームワークで、rrdtoolの薄いラッパーとして動作し、小規模から大規模なサーバ群を一括で管理できるように設計してあります。tokuhirom曰く、「perlが書けてrrdtoolがつかえるsysadminの人だったら使いやすいと思われる」というのがもっともしっくりくるような気がします。Perlとrrdtoolが使える運用者によるカスタマイズ前提なのがフレームワークと呼んでいる所以です。 CloudFor
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く