なんかかきたい

プログラミングなどの個人的なメモやサークル「ゆきいろパラソル」の情報を載せてます

C90夏コミありがとうございました＆サークル活動の休止について

同人活動 技術系 PHP

C90でゆきいろパラソルのブースに来てくださったみなさま、ありがとうございました。

今回も無事「ひだまりPHPシリーズ」の新刊を出すことができました。

あと、10部ほどコピー本も用意してみました。Kinko'sさんで初めて作ってみたのですが、無事刷れてよかったです。超大変でした！中身はもちろん、今回初めて表紙絵描きました！(前日まで間に合うよ！すごいね)

ImageMagickで作った(!)巨大PDFをUSBに入れて持っていくだけで Kinko's お兄さんがいい感じにプリンタ設定してくれました。すごいね。

そんなこんなで三度目となるサークル参加となったC90も楽しい３日間でした。

今後のサークル活動についてですが、ゆきいろパラソルとしての活動は一旦おやすみとします。

ひだまりPHPシリーズが一通り書けたというのと、今後の広がりがあまり想像できなくなったというのが理由です。すみません。

ほかに書くことが見つかるまで、こちらのブログは引き続き更新していきますのでお付き合いいただければ幸いです。

MySQL 5.6の InnoDB バッファープールのプリロード機能が優秀で頭悪いクエリを投げなくても良くなった

mysql 運用 技術系

再起動を高速化するための InnoDB バッファープールのプリロード

特に大きなバッファプールを扱う場合にMySQLを再起動すると、起動直後はメモリにDBのデータが乗っていないので大きなディスクIOが必要になるようなイカれたクエリを投げるとめちゃくちゃ遅いという現象が起きます。

MySQL5.5以前はユーザリクエストを振る前にイカれたクエリを実行しておくことでバッファプールに乗せるという手法がそれなりに有効でした。

ただ、イカれたクエリを投げる方法ではバッファプールが再起動前と同じ状態になるわけではないので遅いクエリはどうしても出てしまうし、再起動前に近い状態になるにはそれなりに長い時間が必要でした。

InnoDB バッファプールのプリロード機能は、バッファプールの復元に必要な情報をファイルから復元することでバッファプールを再起動前の状態に復元できる機能です。

バッファプール復元のための情報は終了時か任意のタイミングでファイルに書き出せます。バッファプールの中身をすべて書き出すわけではないので、それほどディスクを圧迫することはありませんし、IO負荷も少なめです。

ファイルにはテーブルスペースIDとページのIDが書き出されます。

シャットダウン時にバッファプールを書き出すには SET GLOBAL innodb_buffer_pool_dump_at_shutdown=ON; を実行しておきます。 すぐに書き出すには SET GLOBAL innodb_buffer_pool_dump_now=ON; とするだけです。

デフォルトではデータディレクトリに ib_buffer_pool という名前で保存されます。 データディレクトリに ib_buffer_pool がある状態で SET GLOBAL innodb_buffer_pool_load_now=ON; を実行すると、バッファプールの復元が始まります。

ib_buffer_pool はテーブルスペースIDとページIDを記録しているだけなので、他のサーバで生成したものを使うこともできます。

(innodb_buffer_pool_sizeが違っていても動作します。メモリから溢れるだけかな・・・いや嘘ですわかりません適当なこと書きました)

mikeda.hatenablog.com

(できそうな気はしてたので検索したらやってる方がいました。)

これが便利で 本運用しているデータベースサーバで ib_buffer_pool を書き出し -> 再起動済みのデータベースサーバにコピー -> バッファプールのロード と実行すれば、 本運用しているサーバと同じようなバッファプールの状態が復元でき、いきなりイカれたクエリが飛んできてもそれなりに高速に処理できるようになっています。

ウォームアップのためにイカれたクエリを投げなくてもよくなって平和になりました。 メモリやSSDも数年前と比べ安価で高速になり大規模データベースを扱いやすくなっていますね。大きなバッファプールを扱わないといけない機会が辛いめでたい。

Vagrant 1.7からinsecure_private_keyが置き換えられる仕様になっていることに今更ながら気づいた

運用 vagrant

ごく日常的にvagrantを使っている分には気にならないと思いますが、vagrant 1.7から vagrant ssh する際に仕様される秘密鍵は vagrant up の際に置き換えられる仕様になっています。 (1.6以前はInsecure Private Keyと呼ばれる共有の秘密鍵を使っていた)

Insecure Private Keyを使ってvagrantで立てたVMにSSHをする方法を取っているとvagrantのバージョンをあげたときに突然エラーになって「おや？」ってなります。 vagrant upしてvagrant sshすると問題なくsshできるので原因に気づきづらい。

ssh -i ~/.vagrant.d/insecure_private_key vagrant_vm_ip # sshできない
vagrant ssh # sshできる

置き換える秘密鍵は .vagrant/machines/default/virtualbox/private_key に置かれるので、 こちらを指定するように変更するか、Vagrantfileにconfig.ssh.insert_key = falseの記述を追加すれば以前の動作と同じになります。

普段使いでは問題ないですが、自動テストなどで使っているとはまりますね。というかはまりました。

C90入稿完了したので、夏コミ本出ます。お品書きはまた後日出します。よろしくお願いします。

コミックマーケット90情報です

イベント 同人活動 運用 PHP

夏コミの時期が来ましたよ！！！

今回は3日目(日曜日)西f26aのスペースをいただきました。

シンフォニーちゃんが活躍する「ひだまりPHP」シリーズの新刊と既刊の「ひだまりPHP vol.2」を用意する予定です！

あと余裕があればWebサーバの運用周りで何か書ければいいなーと考えてますので、3日目西f26aの「ゆきいろパラソル」をよろしくお願いします！

Fluentdを使ってKibanaにデータを入れてるけど一部のログを落としていたのでリプレイしたい

fluentd kibana elasticsearch Linux 技術系 運用

Fluentdを使ってKibanaにデータを入れてるけど一部のログを落としていたのでリプレイしたいってときに、 取りこぼした時間分のログを置いて、Fluentdに読み込ませて送ればいいじゃんっていう気持ちになるけど、 ログの量が多いとクライアントが高速にログを読みすぎてFluentdのバッファーが溢れてしまう。

Fluentdの用途的におかしいので仕方ないのだけどなんとかしたいので、 通常時と同じようにログに追記していくようにする。 そのときに trottle(1) を使い、ストリームの速度を制限する。

cat foobar_log | throttle -l /tmp/throttle.ctl -M 1 > /tmp/foobar_log_replay.log

これで書き込み速度を1MByte/sに制限できる。 -l は制御用の名前付きパイプを作るオプション。 速度が早すぎたり遅すぎたりした際に調整するのに便利。

throttle -t /tmp/throttle.ctl -B 1

このようにすると、転送は1Byte/sになる。速すぎたときに使う。

流すログの量が多い場合は、バッファーのディレクトリを監視しながら 自動でlimitを調整できると便利かもしれない。

<source>
  type tail
  path /tmp/foobar_log_replay.log
  tag kibana4.foobar
  format json
  time_key time
  read_from_head true
</source>

<source>
  type tail
  path /var/fluentd/foobar/*.log
  pos_file /var/fluentd/foobar_log.pos
  tag kibana4.foobar
  format json
  time_key time
</source>

かしこ

任意のバージョンのImageMagickをビルドできるコマンドを作ってるよって話

ImageMagick Linux Ruby 技術系 運用

少し前からImageMagickの最新バージョンをビルドして使いたいなーというモチベで好きな時に好きなバージョンのImageMagickをソースからビルドできるスクリプトを作っていたので紹介します。

続きを読む