FirehoseのHTTP配信機能でMackerelにメトリックを投稿する - 酒日記 はてな支店
先日、Amazon Kinesis Data Firehose が任意の HTTP エンドポイントに対しての配信機能をサポートしました。 aws.amazon.com 従来の S3 / Redshift / Elasticsearch Service などのマネージドなリソースに対してデータを配信する機能に加えて、自分で作った HTTP(s) のエンドポイントに対しても Firehose からデータを投げ込んでくれる機能です。 Amazon Kinesis Data Firehose now supports data delivery to Datadog 既に Datadog や New Relic へもマネージドでデータを配信できていて、それらに送りたいデータはとりあえず Firehose に流しておけば、実際の送信やバッファリングやリトライは Firehose が面倒を見てくれると
Provisioning Frameworks Casual Talks vol.1 で「新卒研修でserverspecとChefを使った話」を発表しました - 酒日記 はてな支店
主催の @studio3104 さん、登壇された方々、参加者の皆さんありがとうございました。 Provisioning Frameworks Casual Talks vol.1 にて、カヤックの今年の新卒研修でserverspecとChefを使った話、をしてきました。 スライドはこちら このblogには書いていなかったので、2013年のカヤック技術部新卒研修について、参考資料のリンクも張っておきます。 2013年の新卒研修と社内ISUCONやりました - (1) 研修編 | tech.kayac.com - KAYAC engineers' blog 2013年の新卒研修と社内ISUCONやりました - (2) ISUCON死闘編 | tech.kayac.com - KAYAC engineers' blog kayac / newbie-training - github Chefの
MongoDBをNUMAなマシンで使うときの注意 - 酒日記 はてな支店
デュアルCPUで計12コア24スレッド、メモリ48GBというマシンで MongoDB-2.0.8 をしばらく稼働させたところ、突然 CPU の system time が1コア分暴走したようになる、という現象が起きました。 最初は原因がよく分からず、とりあえず mongod のプロセスを kill して起動し直したら復旧したのですが、またしばらくすると同じ現象に。 mongoのメモリ使用量と Load Average をプロットしてみると、どうもある程度 (約24GB?) のメモリを使ったところで暴走が起きているような……とログを見直してみると、起動時に WARNING がでていました。 Sun Jan 20 00:10:01 [initandlisten] MongoDB starting : pid=12669 port=27017 dbpath=/var/lib/mongo 64-b
Redisでログの書き込みがblockを引き起こす - 酒日記 はてな支店
「RedisかわいいよRedis」(by typester)……というほど自分は Redis 期でもないのですが、最近 Redis を使ったサービスの面倒を見ていて時々レスポンスが悪化する現象に出会ったので調べました。 前提 使用しているのは Redis 2.4.16 です。 redis.conf に "save [t] [n]" を定義すると、最後に save をしてから [t]秒間に [n]個以上の key が更新された場合に background で save (=bgsave) が実行されます。 save 60 10000これだと、60秒間に 10,000 keys です。 bgsave では redisは自分自身のプロセスを fork() し、子プロセス側は自分のメモリに乗っている内容をファイルにすべて書き出します。 この仕組みによって、1プロセス 1スレッドで動作している re
RedisをKeepalivedでフェイルオーバーする構成案 - 酒日記 はてな支店
master slave 構成を取っている Redis で、master が落ちた場合に slave を昇格させてフェイルオーバーしたいという要件がありまして、Keepalived と組み合わせて構成してみました。Redis の運用経験がないのでご意見などいただければありがたいです。 Scientific Linux 6.2 keepalived-1.2.2-3 redis-2.4.10 前提 Redis のレプリケーションではマルチマスター構成を取ることができない Redis の slave は起動時に master に接続し、全データを取得してコピーを取る その後は順次 master で更新されたデータをコピーする redis-cli で slaveof コマンドを実行することで、動的に master, slave を切り替えることが可能 このような作りになっているため、2ホスト間で
chef-solo + capistrano で複数ホストを管理する - 酒日記 はてな支店
chef-server は仕組みが大げさでインストールも大変だし、10〜20台ぐらいなら chef-solo と capistrano を組み合わせればいいよね？（同案多数） Capistranoとchef-soloを組み合わせて使う | ひげろぐ capistrano + chef-soloで構成管理する - delirious thoughts 実はこれまでもずっと、適当に書き殴った shell script で rsync && chef-solo 実行というのをやっていたのですが、複数の json をいい感じにマージして適用したかったので、capistrano で書き直してみました。 fujiwara/chef-solo-with-capistrano · GitHub 方針 cookbook などのファイルの同期は rsync で 共通で使用する json とホストごとにそれを上
#fluentd で maillog を読み込んで MongoDB に投入 - 酒日記 はてな支店
MTA が吐く maillog は普段あまり見ないのだけど、トラブルがあったときには大変重要。これも Mongo に入れれば、問い合わせがあったアドレスで検索してログを管理画面で見るとかできて便利！ということでやってみた。 # fluentd.conf <source> type tail path /var/log/maillog tag maillog format /^(?<date>[^ ]+) (?<host>[^ ]+) (?<process>[^:]+): (?<message>((?<key>[^ :]+)[ :])? ?((to|from)=<(?<address>[^>]+)>)?.*)$/ </source>正規表現がなかなかですが、これで maillog を parse して以下のような生ログから 2012-03-26T19:49:56+09:00 worker00
[nginx] nginx で upstream を active backup 構成 - 酒日記 はてな支店
nginx で振り分けるのに、いままで自分の作った構成だと backend はすべて active でロードバランスしてたけど、都合により active-backup 構成にしたくて調べたら簡単だった。一応メモ。 HttpUpstreamModule - Nginx Community backup - (0.6.7 or later) only uses this server if the non-backup servers are all down or busy upstream server の定義に backup を付けておくと、それ以外のが全て落ちたときだけ振り分けられる。 upstream backend { server 127.0.0.1:5000; server 127.0.0.1:5001 backup; }
![[nginx] nginx で upstream を active backup 構成 - 酒日記 はてな支店](https://cdn-ak-scissors.b.st-hatena.com/image/square/42c097f3027b4dc8146002d2087dd51d1d697b24/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729889028%2F8454420450078126225%2F1419604156)
Parallel::Benchmark というモジュールを書きました - 酒日記 はてな支店
プロセスを並列に立ち上げて負荷を掛けるようなベンチマークを実行することって、よくありますよね。(例 : クエリキャッシュを切ったほうがいイカ？ ベンチマークしてみた - 酒日記 はてな支店) Perl で Parallel::ForkManager を使うとそういう処理も簡単に書けて便利なのですが、何度も同じようなコードを書くうちに、これもうちょっと抽象化したら使いやすいかも、と思って Parallel::Benchmark というモジュールを書いてみました。 リポジトリはこちらです。 https://github.com/fujiwara/p5-Parallel-Benchmark たとえばフィボナッチ数 fib(10) を求めるベンチマーク。 use Parallel::Benchmark; sub fib { my $n = shift; return $n if $n == 0 o
クエリキャッシュを切ったほうがいイカ？ ベンチマークしてみた - 酒日記 はてな支店
カジュアル！(挨拶) このエントリは MySQL Casual Advent Calendar 2011 の18日目の記事です。 昔、専ら PostgreSQL を使っていた頃、MySQL のクエリキャッシュって簡単に性能上がるしみたいだし羨ましいなあ、と思っていました。そのため、1年ほど前から業務で MySQL を使うようになっても、クエリキャッシュは当然のごとく有効にしておりました。 ところが先日 DSAS開発者の部屋:クエリキャッシュは切ったほうがいいんじゃなイカ？ というエントリを読みまして、クエリキャッシュはグローバルロックを獲得するとのこと。これはちょっと検証してみなければなるまい、ということでベンチマークをしてみました。 ベンチマーク結果 結果は別ページにまとめました benchmark script と my.cnf ざっくりと説明しますと、 平均 260 byte/行、1
HAProxy で graceful restart する方法 - 酒日記 はてな支店
haproxy には起動後に設定ファイルを読み込み直したりする機能がないので、バランス先を追加するなどの変更が無停止ではできない、と思い込んでいたのだけど実は違った、というお話。 実際、同一プロセスで読み込み直すことはできないのだけども、以下のような手法で graceful に再起動することができる。man はちゃんと読みましょう。 # haproxy -f /path/to/haproxy.conf -sf [既に動いているhaproxyのpid]として -sf オプションに pid を渡して起動すると…… haproxy[2] : 起動 haproxy[2] : 既に動いている haproxy[1] に SIGTTOU を送信 haproxy[1] : SIGTTOU を受けると Listen をやめる 新規接続は受け付けない 既に確立している接続はそのまま維持 haproxy[2]
mysql コマンドの履歴を残したくない場合は MYSQL_HISTFILE=/dev/null - 酒日記 はてな支店
タイトルで内容を全部書いてしまった。 SQL を直接 mysql コマンドから発行する場合、デフォルトでは履歴が $HOME/.mysql_history に残ります。次回起動した場合にも履歴をさかのぼれるわけですが、たとえば「本番データベースに繋いで更新、削除系の操作を実行する」ような場合。これは履歴に残ったものを間違って再実行してしまうと、大変な悲劇を引き起こす可能性があります。 とうことで、(緊張しながら本番で) 削除 SQL を実行した場合、手作業で .mysql_history をエディタで編集して消したりしていましたが、ここでよいツッコミが @n0ts さんから。 直に削除系SQL叩いたらじっとり手に汗が 2011-09-01 15:34:46 via YoruFukurou ヒストリ誤爆しないように.mysql_historyからも消す 2011-09-01 15:36:22
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
SIGNALを考慮してないTheSchwartz Job workerをなるべく安全に停止する - 酒日記 はてな支店
TheSchwartz の worker はシグナルに対してデフォルトでは何もしないので、再起動させようと SIGHUP を送信したりすると job 処理の途中で割り込まれて死ぬ可能性があります。 自前でトラップして安全に再起動する方法は過去に TheSchwartz の worker を安全に停止する で書きました。3年前の記事ですが。 今回は、シグナルへの対処がなされていない古いスクリプトを修正したものの、既に動いている worker を安全に止めないと入れ替えられないのでどうするか、というお話。 安全な停止法を twitter で緩募したところ、以下のようなアドバイスを頂きました。しかし別の queue DB 使うのは確実そうだけどちょっと面倒ですよね…… 緩募: signal trapしてないTheSchwartzのjob workerを安全に止める方法 2011-04-25 11
mod_pagespeed をちょっとだけ試してみた - 酒日記 はてな支店
Google の Page Speed の Apache module 版 mod_pagespeed をインストールして、ちょっとだけ動きを見てみた。 インストールは Ubuntu に deb パッケージで。 $ wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb # sudo dpkg -i mod-pagespeed-beta_current_amd64.debconfig はデフォルトで入るものそのまま。 <IfModule pagespeed_module> SetOutputFilter MOD_PAGESPEED_OUTPUT_FILTER ModPagespeed on ModPagespeedUrlPrefix "http://localhost/mod_p
IPC::Open2 が Catalyst のテストサーバで動かない件の対処 - 酒日記 はてな支店
IPC::Open2 (Open3) が Catalyst のテストサーバでまともに動かない。ハンドルを操作しようとすると Broken pipe のエラーが起きる。 package MyApp::Controller::Foo; sub foo :Private { my ( $self, $c ) = @_; open2( my $out, my $in, "/path/to/command" ); print $in "input" or die $!; # <-- Broken pipe 検索して Re: [Catalyst] Catalyst and IPC::Open2 を見つけた。それによると STDOUT and STDERR probably aren't what it expects. Try doing the same save+restore trick I u
mod_concat で複数ファイルを連結して配信する - 酒日記 はてな支店
先日リリースした某サービスの HTML を見ていたら、外部 js ファイルの読み込みに が十数行ずらずらと並んでいるのを発見。 これ、確か Apache module でまとめて配信してくれるのがあったよなあ……とブクマを掘り起こして、mod_concat を見つけたので試してみた。 ソースコードのコメントに * The Idea was initially thought of by David Davis in Vox, and reimplemented in perlbal. とあるように、もともとは Perlbal が持っている機能を Apache module にしたもの。 svn からチェックアウトして apxs でコンパイル & インストール。 $ svn checkout http://modconcat.googlecode.com/svn/trunk/ modconc
TheSchwartz を PostgreSQL / SQLite で使うと worker プロセスが太る(のは解決済) - 酒日記 はてな支店
MySQLだと問題ないみたい。あと、job の引数に何を渡すかで変わってくるらしい…… [2010-2-16 追記] 追記時点での DBD::Pg と DBD::SQLite の最新版 (DBD::Pg-2.16.1, DBD::SQLite-1.29) では、以下に記述されているメモリリークは解消されています。記事自体は記録の意味も兼ねているので消さずに残しますが、ご注意ください。 ちなみに SQLite 用のスキーマは TheSchwartz 自身に同梱されていて t/schema-sqlite.sql に、PostgreSQL 用のはリポジトリの trunk にあります。doc/schema-postgres.sql 検証用のスクリプトは最後に載せますが、単に client が job を突っ込んで、worker が job を取り出して $job->completed() するだけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
