タグ

ブックマーク / sfujiwara.hatenablog.com (17)

  • HAProxy で MySQL のヘルスチェックをちょっと便利にする - 酒日記 はてな支店

    MySQL で slave を複数台立てて参照分散するには、HAProxy を利用してロードバランスと切り離しを行うと手軽に使えて便利です。 option mysql-check という設定で、HAProxy 自身が mysqld に接続してヘルスチェックが可能です。 listen mysql-slave bind 127.0.0.1:3307 mode tcp option mysql-check user haproxy balance roundrobin server slave1 192.168.1.11 check server slave2 192.168.1.12 check server slave3 192.168.1.13 checkなのですが、この設定だと以下のように少々不便なことがあります。 mysqldに接続できるかどうかのみを死活の判断にしているので、レプリケ

    HAProxy で MySQL のヘルスチェックをちょっと便利にする - 酒日記 はてな支店
    ryster
    ryster 2014/04/24
  • 異常値検出プラグイン fluent-plugin-anomalydetect を使ってみたのでそろそろ閾値を決めたい - 酒日記 はてな支店

    異常値検知、素敵な響きですね!fluent-plugin-anomalydetect 作りました - PolyPeaceLight あらかじめ固定値でアラートの条件を決めておかなくても、通常と異なる数値変化を検出してアラートできたら大変嬉しい、ということでインストールして一週間ほど運用してみました。 fluent-agent-lite で送信されてくる nginx のアクセスログの数を対象 60秒間隔で集計 <match nginx.access.**> type copy <store> ... </store> <store> ... </store> <store> type anomalydetect tag nginx.anomaly.access_log tick 60 store_file /var/log/td-agent/anomalydetect.dat </store

    異常値検出プラグイン fluent-plugin-anomalydetect を使ってみたのでそろそろ閾値を決めたい - 酒日記 はてな支店
  • RSS対応NICなのに割り込み処理が複数コアに分散しない…のはirqbalanceが動いてなかったから - 酒日記 はてな支店

    タイトルがすべてでございます。 NICの割り込み処理が1コアに集中してしまい、ボトルネックになって性能が出ない場合があるという話は最近広く知られていると思います。 NICのハードウェアレベルで割り込みを分散してくれる RSS(Receive Side Scaling) という仕組みがあり、それを利用すれば特になにもしなくても複数コアに分散されるはず、と思っていたのですが、どうも特定のマシンでそうならない。 # cat /proc/interrupts CPU0 CPU1 CPU2 (省略) CPU11 64: 1256214 0 0 ... 0 IR-PCI-MSI-edge eth1-0 65: 225711 0 0 0 IR-PCI-MSI-edge eth1-1 66: 402906 0 0 0 IR-PCI-MSI-edge eth1-2 67: 723539 0 0 0 IR-P

    RSS対応NICなのに割り込み処理が複数コアに分散しない…のはirqbalanceが動いてなかったから - 酒日記 はてな支店
    ryster
    ryster 2013/01/02
  • Zabbix-1.8で運用中のzabbix-serverを分散監視に切り替える場合の注意 - 酒日記 はてな支店

    実運用に使用している Zabbix-1.8 を、とある事情で途中から分散監視設定に変更しようかと思い立って調査したところ、気を付けないと危なそうなのでメモ。(zabbix-2.0以降はみていません) 分散監視のドキュメントを参考に、 zabbix_server.confファイルに次の行を設定します: NodeID=1ステップ3 データベースデータの変換。 Zabbixサーバのバイナリを実行して、最初のノードが使用できるように一意なIDを変換します。 cd bin ./zabbix_server -n 1 -c /etc/zabbix/zabbix_server.conf Converting tables .................................................................. done. 15 分散監視 [Zabbix Docu

    Zabbix-1.8で運用中のzabbix-serverを分散監視に切り替える場合の注意 - 酒日記 はてな支店
  • #isucon2 で優勝してきました - 酒日記 はてな支店

    なんでもありのいい感じにスピードアップコンテスト ISUCON が 2 になって帰ってきたので、参加して優勝を勝ち取ってきました。 まとめ的なものはこちらから livedoor Techブログ : ISUCON チームメンバーのblogも併せてご覧ください。 おそらくはそれさえも平凡な日々: #isucon2 で連覇させてもらってきました Redis布教活動報告 ISUCON 編 - unknownplace.org 今回は前回の ISUCON 優勝メンバーのひとり @sugyan が転職して出題側に回ってしまったので、@typester を招聘してチーム編成。@songmu と共に3人でチーム「fujiwara組」として再参戦です。 以下、作業用IRCのログからふりかえりますと…… 11:39:29 <typester> とりあえずrecent_soldはキャッシュってのはまずやることか

    #isucon2 で優勝してきました - 酒日記 はてな支店
  • 手軽に使える forward http proxy : stone, Tinyproxy - 酒日記 はてな支店

    直接グローバルに繋がる経路をもたないホストから http アクセスしたいので http proxy を使いたい。Squidは定番ですが、もう少し手軽なのはなにかないかと思っていたところ twitter で教えていただきました。ありがとうございます。 reverseじゃなくてforwardなhttp proxyでsquid以外って手軽なの何かないか。Apacheをそれだけのために動かすのはちょっと…てかんじ 2012-10-23 17:57:44 via YoruFukurou @fujiwara stone とか? 2012-10-23 18:03:07 via web to @fujiwara @fujiwara うちはtinyproxyつかってますよ。 2012-10-23 19:01:47 via Echofon to @fujiwara Stone Simple Repeater

    ryster
    ryster 2012/10/23
  • zabbixでiptablesが有効になっているかどうかを検出する - 酒日記 はてな支店

    iptables、便利ですが必要のないホストで有効になっていると困りますね。特に conntrack が適切に設定されていない状態で有効になると、流量が多くなった時にテーブルが溢れてパケットが捨てられてしまいます。 厄介なことに、状態を確認しようと思って迂闊に iptables -L を実行しただけで kernel module が読み込まれてしまうので、うっかり知らないうちに有効になっているという事故例もありました。 ということで、zabbix で iptables が有効かどうかを検出して、望ましくない状態になっていたらアラートを上げたいと思います。 外部コマンドを実行するようなことは(設定が面倒なので)したくない。zabbix-agentのデフォルトで持っている項目で検知する方法を考えて、以下のようにしてみました。 "iptables is loaded" というアイテムを、vfs.

    zabbixでiptablesが有効になっているかどうかを検出する - 酒日記 はてな支店
  • ロードアベレージを監視して任意のコマンドを実行する(monitで) - 酒日記 はてな支店

    他に似たツールがあれば教えて欲しいです ロードアベレージを監視して任意のコマンドを実行するコマンド - blog.nomadscafe.jp いままで使ったことはなかったのですが、monit でできるはず、と思って実験。一般的には、負荷が上がったりプロセスが応答しなくなったら再起動、のような用途に使うツールです。 # /etc/monit/monitrc check system localhost start program = "/path/to/command" if loadavg (1min) > 2 then start[追記] exec を使うほうがよいとのご指摘をコメントでいただきました。 check system localhost if loadavg (1min) > 2 then exec "/path/to/command"これでロードアベレージの1分平均が2を超

    ロードアベレージを監視して任意のコマンドを実行する(monitで) - 酒日記 はてな支店
  • cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店

    (タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ!出力を /dev/null に捨てるなんてとんでもないよね!」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、

    ryster
    ryster 2012/06/13
  • KVM guest VM が突然 paused になった - 酒日記 はてな支店

    何も前触れもなく、KVM の guest VM が突然 paused (suspend した状態) になってしまって何事かなのか悩んでいたところ。 VM 置いてるファイルシステムがいっぱいになったときになりました。RT @fujiwara: 【緩募】KVMのguest VMが何もしてないのにいつの間にかpausedになってしまう現象に遭遇した経験 2012-01-14 01:52:48 via web まさしく、DISK image を置いていたパーティションが 100% になっていました。sparse で作成していたので、容量分のファイルは作成できていたのだけど、実際に確保するところで足りなくなった状態でした。 他のパーティションに mv して事なきを得ましたが、実際以上に容量確保できる sparse image を実運用するときは要注意ですね……

    ryster
    ryster 2012/01/14
  • クエリキャッシュを切ったほうがいイカ? ベンチマークしてみた - 酒日記 はてな支店

    カジュアル!(挨拶) このエントリは MySQL Casual Advent Calendar 2011 の18日目の記事です。 昔、専ら PostgreSQL を使っていた頃、MySQL のクエリキャッシュって簡単に性能上がるしみたいだし羨ましいなあ、と思っていました。そのため、1年ほど前から業務で MySQL を使うようになっても、クエリキャッシュは当然のごとく有効にしておりました。 ところが先日 DSAS開発者の部屋:クエリキャッシュは切ったほうがいいんじゃなイカ? というエントリを読みまして、クエリキャッシュはグローバルロックを獲得するとのこと。これはちょっと検証してみなければなるまい、ということでベンチマークをしてみました。 ベンチマーク結果 結果は別ページにまとめました benchmark script と my.cnf ざっくりと説明しますと、 平均 260 byte/行、1

    クエリキャッシュを切ったほうがいイカ? ベンチマークしてみた - 酒日記 はてな支店
    ryster
    ryster 2011/12/18
  • #isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店

    前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DBCPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、

    #isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
  • #isucon で優勝してきました - 酒日記 はてな支店

    なんでもありのWebアプリケーション高速化バトル、#isucon に会社の同僚 @Songmu @sugyan と3人で、fujiwara組として参戦してきました。結果、幸いにも優勝を勝ち取ることが出来ました。 こんなに楽しいイベントを企画、運営していただいた Livedoor の皆様、当にありがとうございます!! さて、ざっとチューニングした経過などを記録しておきます。 [追記] もっと詳しいレポートを @Songmu が上げているのでそちらもご覧ください おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました [さらに追記] #isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店 自分でももう少し詳しく振り返りエントリ書きました。 まず説明を聞いて、環境を作るところから。IPアドレスでは作業がしにくいし事故も起こりそうなので、host

    #isucon で優勝してきました - 酒日記 はてな支店
  • LVM にインストールした仮想マシンのディスクをあとから増やす方法 - 酒日記 はてな支店

    host 側に LVM でパーティションを切って、そこに KVM なりなんなりの仮想マシン (guest) をインストールした場合、あとから guest のディスクを増やすのにはこんなふうにすればいいかな、というメモ。 まず host 側で LVM パーティションを作成し、そこに guest をインストール。 # lvcreate --size 4G --name guestvm /dev/VolGroupVM # virt-install --connect qemu:///system --name guestvm --ram 512 --file /dev/VolGroupVM/test # (略guest のインストールでは LVM を使用せず、普通にパーティションを切る。3つ目のプライマリパーティションを / にマウントして、全部ひとまとめ。 /dev/vda1 => /boot

    LVM にインストールした仮想マシンのディスクをあとから増やす方法 - 酒日記 はてな支店
    ryster
    ryster 2011/06/21
  • Webアプリケーションのログについてあれこれ - 酒日記 はてな支店

    社内勉強会で話したスライドをおいておきます。(IE以外のブラウザ推奨) http://dl.dropbox.com/u/224433/kayac-01-log/index.html 初心者向けというか、かなりざっくりしたスピリチュアルな話でございます。 要約すると、 後で役に立つからログは出しておけ ログ捨てるな 捨てたら椅子投げるぶん殴る という感じですね。

    Webアプリケーションのログについてあれこれ - 酒日記 はてな支店
  • 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で参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
  • 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台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という

  • 1