LVSの高負荷対策 その2 ~障害の再現とその原因~ : DSAS開発者の部屋
こんにちは。インフラ担当の岡村です。 「LVSの高負荷対策 その1 ~障害発生~」の記事で、大量のSYNパケットを受信した際にロードバランサの再起動が発生したことと、その緊急の対策についてご紹介しました。 今回は、再現確認を行い判明した再起動の原因と、LVSに備わっている高負荷対策の機能についてご紹介します。 検証 前回ご紹介した通り、障害発生時のログからメモリ周りが怪しそうでした。 そこで、ロードバランサにSYNパケットを送り、メモリの使用量の推移を観察しながら、再起動が発生するかどうかを確認しました。 検証環境の構成は次のようになります。 検証環境の構成 パケット送信用サーバを複数台、ロードバランサを1台、Webサーバを1台使用し検証を行いました。 ロードバランサの検証を行う上で、本番環境と同様にロードバランスの処理をさせたかったため、LVSに振り分け先のWebサーバのIPアドレスを複
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コネクションの永続化等でコネクションを張りっ
お名前.com プライマリ・セカンダリ共に障害発生？: 駄文と書評
何故か他のニュースソースに全く掲載されていないのだが、お名前.comで障害が発生しているようだ。 【DNS設定/転送Plus】名前解決不具合の発生と復旧お名前.comをご利用いただきまして、誠にありがとうございます。 現在、一部サービスに障害が発生しております。ご利用のお客様には 大変ご不便をおかけ致しますが、復旧まで今しばらくお待ちください ますようお願い申し上げます。 発生日時 ： 2009年11月27日(金) 17時30分頃 対象 ： DNS設定/転送Plus 影響/詳細 ： DNS設定/転送Plusの名前解決ができない 緊急の場合は、外部のDNSサービス（"無料DNS","Free DNS" などで検索） などをご利用いただきますようお願い申しあげます。 手順：1.外部DNSサービスにてレコード設定 2.ドメインNaviにてネームサーバー変更 ネームサーバー変更方法 http:
お名前.comのDNSサーバが長時間逝ってしまった件
復旧したばかりだが良くまとまっているレスがあったのでコピペ 5 ：名無しさん＠お腹いっぱい。：2009/11/28(土) 07:40:58 0 【今回の不具合の私的なまとめ】 サービス不能期間 2009/11/27(金) 17:30 ～ 2009/11/28/(土) 06:30 お名前.comが無償提供するDNSサーバ（ *.dnsv.jp ）によって設定されたドメイン、 約200,000件以上のドメインが一斉にアクセス不能になった 原因は特定アジアからのDDoSではないかとの説があるが、 2日前に微妙な不具合を出しているため、お名前.com側に全く問題がないとは言えない 今回のような障害が発生した場合、通常はネームサーバを追加したり別なとこに切り替えるのだが DNSの仕組みをよく理解していないのか、前スレでは障害の切り分けに迷った書き込みが散見された その他細かいところ ・お名前.com
Real Beat » Blog Archive » [MySQL] MyISAMとInnoDB
Keep drinking, Keep listening to music, Go fuck yourself 今運用している某システム、MyISAMのある難癖によって非常に辛い目に遭っております。それはもちろんテーブルロック。これはもうMyISAMを選択した時点でどうしても避けては通れない道。そこんところ仕組みをちゃんと理解してないと、MyISAMのほうが速いって言うから選んだのに、なんだよ全然遅いじゃん！っていうか使い物にならないよウワァァァァンみたいなことになりがち。今のシステムでどうやってMyISAMかInnoDBかを分けたのかというと、単純に更新頻度だった。頻繁に更新されるテーブルはInnoDB、そうじゃなければMyISAM。参照が殆どならInnoDBを選択するメリットは何もないと思っていた。が、実は全然そうじゃなかった。 MyISAMが辛いのは、INSERT文実行時にテーブル
redis導入後にトラブル発生、そのレポート
こんにちわ、ミツバチワークス stoneです。 今回は、redisシリーズ第３弾、実際にredisをサービスの投入してみて、うまく行かなかった事例についてご紹介します。 redisの使用用途 今回、いくつかあるセッションデータのうち２つをMySQLからredisへ移行させました。 これらのセッションデータ、MySQL上では、セッションIDの他に複数のカラムから構成されているのですが、redis上では、この複数のカラムをserialize()して、 key(string) => value(string) という形で格納するようにしました。 ちゃんとソースコードで確認はしていないのですが、memcachedでも、TTLが設定できますが、TTLを過ぎたデータを監視してクリアしていないですよね。 また、memcached内部のslabの構成次第では、TTLまでデータが保持されずに、データがクリア
foursquareの11時間にも及ぶサービスダウンの原因を詳細に調査してみた。<a href="http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/doryokujin/20101014/1287000278" class="bookmark-count"><img src="http://b.hatena.ne.jp/entry/image/http://d.hatena.ne.jp/doryokujin/20101014/1287000278" tit
こんにちは、@doryokujinです。前回に引き続き、MongoDBに関するエントリーです。今回は10月4日にMongoDBが原因で起きた、foursquareのサービスダウンに関して、その原因や復旧に至る経緯を詳細に調査しました。TechCrunchJapanの記事、Foursquare：「対策を講じたはずなのですが、また6時間もダウンしてしまいました」にも紹介されていたのでご存知の方も多いと思います。MongoDBが原因で引き起こったとするならば、企業で実際に運用している僕にとっては放っておけない問題になります。実は5月にも長いサービスダウンがあったのですが、それはAmazonEC2の停電によるものでした。 本日のアジェンダです： foursquareにおけるMongoDB サービスダウン時の状況 本当にMongoDB自体の問題だったのだろうか サービスダウンの引き金となった出来事
FoursquareとAmazonEC2
カテゴリー DX (2) 一般 (59) 研究会 (6) 働き方 (4) 技術 (353) Edge AI (2) Edge Computing (13) Erlang (1) FIWARE (2) Fog Computing (10) Infiniband (31) Internet of Things (32) Key Value Store (17) Linux (3) Linux KVM (10) Machine Learning (6) RealTime Web (14) SRE (3) Webサービス (42) インフラ (8) コンテナ (4) ストレージ (93) データセンター (7) データベース (47) データ流通 (6) テレプレゼンス (2) ネットワーク (215) 仮想化 (111) 災害コミュニケーション (26) 空間情報 (30) 量子コンピューティン
ApacheのディスクキャッシュはMime-Typeを見てくれない｜ITプロフェッショナル部（システム開発のアイロベックス｜東京都新宿区の業務システム開発会社）
以前、開発にかかわったシステムでDBからバイナリデータを取得し、 画像として表示するというプログラムに関わりました。 DBへのアクセス負荷を抑えるために、Apacheのディスクキャッシュ機能を 使用しました。 その時にハマッタことについて説明したいと思います。 まず、DBから取得するバイナリデータは画像がそのまま格納されているので 特に何も処理せず、取得したデータをPHPで画面へ出力します。 >> 以下ソース $data = 画像データ; header("Content-type: image/jpeg"); echo $data; << ここまでソース 簡単に書くとこのような処理になります。このプログラムがimage_output.phpという名前とすると 画面上のHTMLタグは以下のように記述していました。 <img src="https://hoge.com/image_output
Skype Translator Preview – A New Chapter in Communication – - Skype Blogs
We are thrilled to take you on a trip around our new version of Skype messaging. Brace yourself for a complete revamp that promises to redefine your messaging experience. From a modernized Context Menu to a sleek UI redesign, file sharing innovations to a media heaven - we've got it all covered. Read more
mixi大規模障害について 解明編 - mixi engineer blog
こんにちは、システム本部技術部たんぽぽGの森本です。 先日のmixi大規模障害の原因となったmemcachedの不具合の詳細な解明ができました。 再来週まで発表を見合わせようと思ったのですが、早くお伝えしたほうがいいと思いましたので公開発表致します。 memcachedとlibevent memcachedはlibeventというライブラリを使用してクライアントからの要求(接続、コマンド送信)を処理しています。 libeventを使用するにはevent_baseという構造体を用います。 main threadはmain_baseを使用します。 static struct event_base *main_base; ... int main (int argc, char **argv) { ... main_base = event_init(); ... /* enter the ev
mixi大規模障害について その2 - mixi engineer blog
こんにちは。システム本部技術部たんぽぽGの森本です 補足を追記しました (2010/08/20 15時) 先日のmixi大規模障害についての続報です 今回は小ネタはありません はじめに まず初めにtwitter/blogなどを通じて今回の問題の解析を行っていただいたみなさんに感謝の言葉を捧げたいと思います kzk_moverさん stanakaさん mala(bulkneets)さん llameradaさん (順不同) ありがとうございました 書き漏らした人ごめんなさい memcachedはすごい 今回の件でmemcachedに対して不安感を持たれた方もおられるとお聞きしました 説明不足だったせいで誤解を与えてしまい申し訳ありません きちんと設定および監視を行っていれば通常の使用にはまったく問題はありません 弊社にて -c 30万で起動したmemcachedに対して、先のテストスクリプトに
mixiがはまったmemcached(or libevent?)の問題を調べる人たち
Neal Sato @nealsato 二日とも複数台のmemcachedが連続して落ちました。コアは吐かずにストンと落ちるので、原因追及に時間がかかりましたが、memcachedへの接続数が異常に多いと落ちる事は再現できました。 #mixi Neal Sato @nealsato memcachedが大量の接続を受けると突然停止をするので、memcachedへの接続数を減らし安定運用中。外部からの過剰アクセスではなく、サーバ追加→クライアント数増加→停止。 Masahiro Nagano / 長野雅広 @kazeburo ファイルディスクリプタが不足してmemcachedが落ちたとして、そのときには、3万強の接続となってるはず。3万強の接続となるにはアプリケーションサーバ側のmax clientが平均60として500台以上必要。そんなに増えたん？
libevent-1.3b, libmemcached-1.4.4 で固まる? - moratorium
libevent-1.3b, libmemcached-1.4.4 で固まる? 2010-08-13 (Fri) 0:56 Uncategorized mixiの件について、nealさんから情報を貰ったので数時間調査してみた。というのも、うちの製品でもlibevent(evhttp)をリクエスト処理に使っているので、これにバグが有ると非常に困る。 Nealさんのつぶやき ひとまず、libevent-1.3b, libmemcached-1.4.4をビルドする。memcachedは、-cで同時接続数を制限できる。で、この同時接続数というのは、実はファイルディスクリプタの数を制限する事で達成されている。memcached.cの以下の部分。 /* * If needed, increase rlimits to allow as many connections * as needed. */
パイプ経由のログ出力はCPUを浪費する
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Apache HTTP Serverでログをパイプ経由でプログラムに出力すると、リクエストを処理するたびにログを処理するプログラムへのコンテキストスイッチが起こります。そのためアクセスが増えたときにCPUをかなり浪費します。UltraSPARC T1は32個のコンテキストを保持できて、1クロックでコンテキストスイッチできるので問題ないと思っていました。しかし、CPUの使用率が100%に達して、さらに負荷が掛かる状況になると違いました。 ftp.jaist.ac.jpにはパイプ経由のログ出力が3つあります。エラーログとアクセスログのrotatelogsへの出力と、以前
Linux ブートディスクの交換と環境移行
とある日曜日，久しぶりにコンソールを見てみると，エラーがドカドカと 表示されています．戦慄を覚えつつ /var/log/messages を確認してみると… terminator kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC } … kernel: hda: dma_intr: error=0x40 { UncorrectableError },LBAsect=232389, high=0, low=232389, sector=103848 上記のようなディスク関係のエーラーが大量に出ています．それも出所は hda と なっていますので，ブートディスクです． このエラーは IDE ケーブルの不良によって発生する場合もありますが，当初は 問題なく動いていたことから考えても，ディスクに不良セクタが出来はじめている と考
nemuiDoc: あるext3復旧レポート
#0 (編集)#1 最初に注意 (編集)#2 発端 (編集)#3 前提/現時点で分かっていること (編集)#4 復旧作業 (編集)#5 辛うじて復旧は出来た (編集)#6 まとめ (編集) ReverseLinks: IndexPage (737d) Invalid argument while checking ext3 journal と言うエラーで fsck がかからないファイルシステムをどうやって復旧したか。そのレポート。 結果だけ知りたい人は一番最後のまとめだけどうぞ。 最初に注意 この方法は余り良くないかもしれない（と言うか多分良くない）。 こういう方法もあるのだという参考程度に。 発端 RedHat が起動できなくなったので見てくれと言われる いってみると確かに起動できない、grub で kernel を探そうにもディレクトリエントリが読めない。（何かの範囲外にある？とか言う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
しゃおの雑記帳 - dip.jpにおける間違ったグルー設定
http://collectivemeta.com/er845
「SYNパケットが再度送られてくる」（1） Master of IP Network － ＠IT