dstatの万能感がハンパない - （ひ）メモ
サーバーのリソースを見るにはグラフ化は重要ですが、推移ではなくリアルタイムな状況、例えば秒単位のスパイキーな負荷を見るには、サーバー上でvmstatやiostatなどの*statファミリーを叩く必要があります。 さて、vmstatはメモリの状況やブロック数単位のI/O状況は見られますが、バイト単位のI/O状況やネットワークの送信、受信バイト数を見ることはできません。 # vmstat 1 procs -----------memory---------- ---swap--- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 4724956 355452 726532 0 0 54 484 3 3 1 0 99 0 0 2 0 0 47
LinuxのLVS(IPVS)でMySQLをロードバランスするときはtimeoutに注意 - （ひ）メモ
構成 [appサーバ] -> [lvs] -> [MySQL]群 DRでMySQLのスレーブ群にロードバランス appサーバはDBコネクションのプーリング、永続化をしている 問題の現象 DBサーバ上ではmysqldへのコネクションが存在するのに、appサーバ上ではコネクションが存在しない。(netstat調べ) →無用なコネクションが残留するせいで、MySQLのmax_connectionsに達してしまう。 原因 MySQLの世界の無通信時のコネクションのタイムアウトはデフォルトで 28800秒 (8時間)。一方、IPVSの世界の無通信時のタイムアウトはESTABLISHEDなコネクションで900秒 (15分)。 # ipvsadm -Ln --timeout Timeout (tcp tcpfin udp): 900 120 300なので、DBコネクションの永続化等でコネクションを張りっ
これはもう手放せない！社内ツールベスト4 - （ひ）メモ
どれもオープンなサービスではあるんですが、社内限定でも使いたいなーというものたちです。 IRC プロトコルと実装がオープンなので、周辺のライブラリやツールが充実してるのがいいですね。 ぼくは、家のサーバに IRC proxy (bouncer) のTiarraを常駐させて、PCがあるときはLimeChatで、ないときはiPhoneのSafariでmobircを使っていつでも見られるようにしています。 コミュニケーションはもとより、いろんなボットを常駐させて通知プラットフォーム的にも使っています。これがまた便利なんです。 deployスクリプトから状況をポスト Continuous Integrationの自動テストの結果をポスト 「#NNN」に反応して、当該チケットのタイトルとURLをポスト 「これから#765やる」、「XXXの修正のチケットってどれだっけ？」「#973だにょ」とか コミッ
async, semi-sync混在のレプリケーション [要検証] - （ひ）メモ
以下、ウラトリしてないので[要検証]です。 これまたhbstudy#13で[twitter:@nippondanji]さんのセッションを聞いてて思いついたこと。 複数台スレーブがいると、マスタがダウンした場合にどのスレーブをマスタに昇格させるべきか調べるのがめんどいです。非同期レプリケーション故に。 5.5以降ならば、semi-synchronousなレプリケーションが使えるので、全スレーブでsemi-syncなレプリケーションすればこういった悩みも解消されそうなんですが、semi-sync故に台数が多くなると同期待ちで時間がかかるようになります。おそらく。→時間がかかるようにはならない。なぜなら、ackを待つのは、semi-syncなスレーブすべてからackが返るまで、ではなく、semi-syncなスレーブのうちどれかひとつからackが返るまで、なので。see: http://dev.m
![async, semi-sync混在のレプリケーション [要検証] - （ひ）メモ](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e2bad705b6c065ec968795ee4aa64912ac42a32/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhirose31%2F20100728%2F20100728202353.png)
実録MySQLのチューニング 春の陣 - （ひ）メモ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
奥様に耳より情報！ Go DaddyでSSL証明書を買う前に必見！！ - （ひ）メモ
2010-11-11追記 いつの間にか$49.99/yearになってたんですが、 http://www.godaddy.com/Compare/gdcompare_ssl.aspx?isc=sslqasia1 を踏んで購入すると$12.99になる模様。 Go Daddy は、SSLサーバ証明書が安いです。 1年間有効のもので、たったの$29.99です。 これでもやすーいなんですが、promo codeを入れるともっとお買い求めしやすくなります！ 新規に証明書を購入する場合は、 GoDaddy Coupons – April 2010 - Promo-Code.net の「promossl」のリンクを踏んで Go Daddy のサイトにとんで、そこでカートに証明書を入れます。 これだけで、$29.99の証明書がなんと$12.99 (56.7%オフ)になります！ 新規じゃなくて更新する場合は、
負荷をかけるツール - HTTP編 - (ひ)メモ
ApacheCon US 2007の、『Apache Performance Tuning / Part One: Scaling Up』, Sander Temme (PDF) より。 ab おなじみ、Apache付属のあいつ http_load http://www.acme.com/software/http_load/ flood http://httpd.apache.org/test/flood/ JMeter http://jakarta.apache.org/jmeter/ 最近のバージョンは使いやすくなったらしい あと、ほかには httperf http://www.hpl.hp.com/research/linux/httperf/ とか。
MySQLで、指定したときだけクエリキャッシュする - （ひ）メモ
今までMySQLのクエリキャッシュはは有効にしてたんですが、Webサービスだとキャッシュヒットするようなクエリはそんなに多くないし、どこかで見かけたんですが(失念…)クエリキャッシュをオフにしたら(逆に)パフォーマンスが上がっただか負荷が下がっただかというのも目にしたので、今度クエリキャッシュはオフにしようと思ってました。(どのみちヒット率悪いし) そんなとき、同僚に query_cache_type を教えてもらいました。(4.0からあるオプションなのに今まで知りませんでした。。。＞＜) http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_query_cache_type てっきりクエリキャッシュはオンかオフかしかできないと思い込んでたんですが、"DEMAND" を指定すると、「原則キャッシ
kumofsの死活監視はこんな感じでNagiosでやってます - （ひ）メモ
分散Key-Valueストア「kumofs」を公開しました！ - 古橋貞之の日記 ＼(＾o＾)／ kumofsは、弊社のフォトストレージサービス Ficia で現在大絶賛モリモリ稼働中なんですが、その死活監視は自家製の Nagios プラグインで行っています。 というわけで、kumofsをサービスで使いたい人の一助になればと思い、ぼくが実際に行っている kumofs の監視について紹介したいと思います。 サーバノードとマネージャノード サーバノードとマネージャノードの監視には、それぞれのノードに対してステータスを問い合わせるコマンドを発行して、その応答で死活を判断するスクリプトを書いて使っています。 kumofs公開記念ということでgithubにpushっておきました。 http://github.com/etolabo/nagios-check_kumofs 問い合わせの処理は、管理用コ
そろそろFiciaについてひとこと言っておくか - （ひ）メモ
えとらぼの『Ficia （フィシア）』、追加容量を大幅値下げ 〜315円（税込）で 100GB まで！ 動画も写真もさくっとアップ〜 えとらぼ、写真ストレージサービス「Ficia」の追加容量を値下げ:ニュース - CNET Japan ぼくも携わっているフォトストレージサービスFiciaの利用料金が大幅に値下げになりました！ これまで 2GBまで無料 2GB〜12GBまで315円/月 以後10GBごとに315円/月が加算 ↓ これから 2GBまで無料 2GB〜100GBまで315円/月 以後100GBごとに315円/月が加算 これまでの料金は、正直に言って高かったと思うのですが、今回の改訂でだいぶお手頃な価格(容量)になったのではないかと思います。 値下げに加え、機能的にも骨子のコンセプトの部分がだいぶ整ってきており、いい機会だと思うので、今まで我慢してきたFiciaに対する思いの丈をここ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
