2010/09/07 KVS（キー・バリュー・ストア）に分類されるオープンソースのRedisの新バージョン、「Redis 2.0.0」が2010年9月5日にリリースされた。Redisはmemcachedと同様にキーと値のペアをメモリ上に保持するKVSの一種だが、3つの際立った特徴がある。1つはハッシュ以外のデータ構造もサポートしていることで、リスト型、集合型、順序付き集合型などのデータ構造が扱え、サーバ側でコレクションに対するpush/pop、コレクション同士のunion/intersection、数値のincr、decrなどの操作がアトミックに行える。バージョン2.0では複数の操作を1つにまとめてアトミックに操作するコマンドも増えている。 もう1つのRedisの特徴は、マスター・スレーブによるレプリケーション設定ができ、リード側のスケールアウトが容易にできること。 そして3つ目の特徴は、
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
こんにちは、システム本部技術部たんぽぽ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
こんにちは。システム本部技術部たんぽぽGの森本です 補足を追記しました (2010/08/20 15時) 先日のmixi大規模障害についての続報です 今回は小ネタはありません はじめに まず初めにtwitter/blogなどを通じて今回の問題の解析を行っていただいたみなさんに感謝の言葉を捧げたいと思います kzk_moverさん stanakaさん mala(bulkneets)さん llameradaさん (順不同) ありがとうございました 書き漏らした人ごめんなさい memcachedはすごい 今回の件でmemcachedに対して不安感を持たれた方もおられるとお聞きしました 説明不足だったせいで誤解を与えてしまい申し訳ありません きちんと設定および監視を行っていれば通常の使用にはまったく問題はありません 弊社にて -c 30万で起動したmemcachedに対して、先のテストスクリプトに
先週のmixiの大規模な障害は、memcachedに対する接続が非常に多いところから発生したようなので、CloudForecastでその接続数をモニタリングできるようにしてみました。 （mixiではたぶんおそらくmemcachedは専用のサーバとなっているので、通常のTCP Established数がそのんままコネクション数になるはず） グラフは以下のように出力されます 赤いラインが起動時に指定した -c の値。 ところで、このmemcachedの起動オプションを取得する方法は今までないものだと思っていたのですが、memcached 1.4以降なら「stats settings」というコマンドで取得できるようです。 % telnet localhost 11211 Trying ::1... Connected to localhost. Escape character is '^]'.
こんにちは。システム本部技術部たんぽぽGの森本です 先日のmixi大規模障害についてのブログです。 はじめにお断りしておきますが、弊社CTOがtwitterで公開した以上の情報はまだ得られておりません。 twitterでは書ききれなかった細部を補足してみたいと思います 現状判明しているのは以下の点です memcachedに大量の接続・切断を行うとmemcachedプロセスが突然終了することがある memcachedには異常時に終了するフローもあるが、同時に出力されるはずのエラーログは出ていなかった coreも出力されていなかった テスト環境にて追試を行ったところ、なんどか再現させることができましたが、確実に発生する条件は未だ不明です。 障害時の memcachedのバージョンは1.4.4, libeventのバージョンは1.3bです memcached の起動オプションは以下のとおり ./
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. */
Neal Sato @nealsato 二日とも複数台のmemcachedが連続して落ちました。コアは吐かずにストンと落ちるので、原因追及に時間がかかりましたが、memcachedへの接続数が異常に多いと落ちる事は再現できました。 #mixi 2010-08-12 02:33:00 Neal Sato @nealsato memcachedが大量の接続を受けると突然停止をするので、memcachedへの接続数を減らし安定運用中。外部からの過剰アクセスではなく、サーバ追加→クライアント数増加→停止。 2010-08-12 08:45:50 Masahiro Nagano / 長野雅広 @kazeburo ファイルディスクリプタが不足してmemcachedが落ちたとして、そのときには、3万強の接続となってるはず。3万強の接続となるにはアプリケーションサーバ側のmax clientが平均60とし
8月10日の17時20分頃から12日未明までの長時間にわたり、サービスが利用不能もしくは利用しにくい状況になっていた「mixi」。数度の断続的な復旧ののちに、本日12日午前1時50分頃には復旧が完了し、現時点で全面的に復旧しているようです。 その障害の経緯について株式会社ミクシィの広報からプレスリリース「『mixi』のアクセス障害のお詫び及び復旧に関するお知らせ」として発表されました。 原因はアクセスの急増ではなかった プレスリリースの中で、今回の障害の原因は以下のように説明されています。 『mixi』のデータベースへの負荷軽減のために導入しているデータキャッシュシステムが複数同時に異常終了したことに伴い、データベースへの負荷が急増したため『mixi』を閲覧しづらい状態となりました。 高負荷かつ特殊な状態でのみデータキャッシュシステムの異常終了が発生していたため、根本的な原因の究明に時間が
memcachedに依存するシステムやコードを書く人は大嫌いな訳だけど、スケーラビリティを向上させてレスポンス時間の高速化には必須なmemcachedですが、最近のプロトコル変更には疑問を感じてしまう。 1.4.0では、こちらに書いた通り、いつの間にかdeleteのtimeoutがサポートされなくなった。なので、 delete key timeout noreply というコマンドが無効になって困ることになった。それでも delete key timeout というコマンドは、timeoutにどんなも文字列が入っていてもエラーになることはなかった。timeoutは効かないけど。 ここから1.4.4ではさらに悪化。timeoutが0でないとエラーになるようになった。つまり delete key 0 noreply delete key 0 は有効なんだけど、 delete key 10 がエ
分散Key-Valueストア「kumofs」を公開しました！ - 古橋貞之の日記 ＼(＾o＾)／ kumofsは、弊社のフォトストレージサービス Ficia で現在大絶賛モリモリ稼働中なんですが、その死活監視は自家製の Nagios プラグインで行っています。 というわけで、kumofsをサービスで使いたい人の一助になればと思い、ぼくが実際に行っている kumofs の監視について紹介したいと思います。 サーバノードとマネージャノード サーバノードとマネージャノードの監視には、それぞれのノードに対してステータスを問い合わせるコマンドを発行して、その応答で死活を判断するスクリプトを書いて使っています。 kumofs公開記念ということでgithubにpushっておきました。 http://github.com/etolabo/nagios-check_kumofs 問い合わせの処理は、管理用コ
株式会社ミクシィの長野です。memcachedの連載も今回が最終回になります。前回までmemcachedに直接関連する話題を中心に書いてきましたが、今回はmixiでの事例や運用に関する話題、memcachedの互換アプリケーションについて紹介します。 mixiでの事例 mixiではサービスの初期の頃からmemcachedを利用していました。memcachedはサイトへのアクセスの増加が、データベースのスレーブを増やしていく方法では追いつかないほど急激にのびていく中で導入して行きました。加えてスケーラビリティを向上させていく手段として検証を行い、十分な速度と安定性があることが確認できたことも導入の理由になります。現在ではmemcachedはmixiのサービスを提供していく中で非常に重要なコンポーネントとなっています。 図1 現在のシステムコンポーネント サーバ構成と台数 mixiではデータベ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
stats の出力をもっと注意深く見る。 stats でぞろぞろ出てくる物の中に bytes の項目がある。 protocol.txt によると bytes 64u Current number of bytes used by this server to store items とあるので、これが実際いま保存されているキャッシュオブジェクトの総量ということになるのかな。 そして memcached プロセスが確保済みの（しかしそのうち何パーセントくらい使い切れているのかはわからない）メモリ総量は stats slabs で出てくる total_malloced の数字のように思える。 total_malloced Total amount of memory allocated to slab pages. とある。 つまり、第一段階として、 memcached プロセス全体でどのくら
ちょうどコンビニで買った湾岸ミッドナイト41巻に「チューニングとは楽器の調律が本来の意味だ」とか書いてあって、厳密に言うと今やってることはチューニングと呼べないんじゃないだろうかとか思ったけど他にいいタイトルも思いつかない。「Memcached のチューニング」といったら Memcached 本体のコードに手を入れることだよなあ。でもじゃあ今からやろうとしてるのは何だろうな。最適化？も違うかなぁ。 仕様書最強 http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt プロトコル仕様書の存在は前から知っていたけど、「プロトコルとか何か難しそうだし、そんな深いことを知りたいわけじゃないよ」と思って敬遠していた。けど昨日、これ以上検索しても（日本語では）新しい情報は見つけられなさそうだ、本家のメーリングリストのアーカ
memcached Night in Tokyo #1によれば、mixiはmemcachedサーバーを135台使っているらしい。多い！ 話に依れば一番最初に足りなくなるのはメモリの容量（3GBほど割り当てられている）で、ネットワークやCPUはボトルネックになっていないらしい。 ではメモリの代わりにHDDを使うのはどうか。HDDのランダムアクセス時の遅延がかなり大きいので、影響が出るほど遅くなりそう。 そこでSSDを使うのはどうか。ランダムリードで700Mbpsくらい出るらしいので、スループットに関してはCPUの方が先に限界に来ると思う。遅延はどれくらいか良く分からないが、アプリケーション側でget_multiを使っていれば隠蔽できないか。 バイト単価はDRAMよりはずっと安い。 実装としては以下： 32GBくらいのSSD 2GBくらいのメモリ（多ければ多いほどキャッシュに載りやすいので、平
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
ある程度でかいサービスでDailyCount的な事をやらなきゃいけなくなって、DBに突っ込むとログのお掃除や負荷が大変だからmemcachedでやりたいけど、落ちたらウザいしなー・・・って考えてたらrepcachedを思い出した。YAPC2008でもmixiのkazeburoさんが紹介してたみたい。まぁ寝坊して聞けなかったんだけど。。。 で、ちょっと色々やってみたメモ。まださほど検証してない。 Installとかはほとんど公式のとおりに。memcachedと共存させるためにバイナリ名かえてみた。 ./configure --enable-replication --program-transform-name=s/memcached/repcached/ make make installで、起動。console2つ開いて-vつけて情報表示させつつ。 repcached -v -m 64
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
