memcachedプロトコルでメッセージキューが実現できるという話を前回したが、今回はその具体的な使用方法を解説してみる。 サーバを起動する まずはサーバを起動しないと始まらない。典型的には以下のコマンドで立ち上げるとよい。 $ ktserver -th 1 -ls \ -plsv /usr/local/libexec/ktplugservmemc.so \ -plex 'port=11211#tout=30#thnum=16#opts=fq#qtout=10' \ 'casket.kct#ktopts=p' 「-th 1」でメインサーバのスレッド数を1にしている。最新版からはデフォルトで16スレッドを立てるのだが、アプリ側からはメインのサーバにはアクセスしないだろうから、1個あればよい。「-ls」はログレベルをSYSTEMに設定。「-plsv ...」では、memachedプラガブルサー
前回の記事にて、Kyoto Tycoonでメッセージキューを実現する方法について述べた。今回は、それを実運用にて使いやすくするための諸機能について説明する。みんな大好きなmemcachedプロトコルでメッセージキューを実現してみよう。 ジョブキューとメッセージキュー どうでもいい話ではあるが、ジョブキューおよびメッセージキューという用語はよく混同して使ってしまう。俺定義では、ジョブキューは「ジョブ管理機能」という目的をたまたまキュー構造に基づいて実装しているものであり、メッセージキューはキュー構造に基づく非同期メッセージング機構であって用途は特に限定しない。つまりメッセージキューをジョブキューを実装するのに使うこともあるが、それ以外の用途にもメッセージキューは使われる。またジョブキューをメッセージキューに基づかないで同期的に実装することもできる。 きっと偉い学者さんがどこかでちゃんとした定
クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基本は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシ
Kyoto Tycoonやmemcachedにてnoreplyオプションを使ってパフォーマンスを上げる話。 noreplyの功罪 DBに対する更新操作はその成否を真偽値などとして呼出側に返すのが通常であるが、それを省略することでパフォーマンスを上げることができる。memcachedではnoreplyオプションとして知られている。KTの最新版からは、memcachedプラグインと独自バイナリプロトコルでもnoreplyオプションをサポートすることにした。 noreplyを有効にするとなぜ高速化するのか。クライアントはクエリをsendしただけで、recvをせずに次の処理に移れるからだ。sendシステムコールに渡したデータはカーネルが非同期に処理するので、カーネルとアプリケーションは並列に処理を進めることができる。recvをした場合にはその時点で両者の待ち合わせが発生してしまうのだが、それをしな
こんにちは、システム本部技術部たんぽぽ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に対して、先のテストスクリプトに
運営元のロゴ Copyright © 2007-2026 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
こんにちは。システム本部技術部たんぽぽ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』を閲覧しづらい状態となりました。 高負荷かつ特殊な状態でのみデータキャッシュシステムの異常終了が発生していたため、根本的な原因の究明に時間が
Membaseを入れてみたので、実際にどれくらいの速度が出るのか試してみました。 memcached vs TokyoCabinet vs TokyoTyrant vs Redis - blog.katsuma.tv この記事のパクリですね。これにMembaseを加えてみた感じです。 クライアントによって速度が変わるのが嫌だったので、すべてPythonのmemcachedクライアントを使って、1万回setを行いその時間を計測してみました。 Membase 1.18884205818 memcached 0.683738946915 TokyoTyrant 0.788640022278 Redis 0.642278909683 思ったよりMembaseが遅い…。って言うかRedis速い。 まとめ 使おう！Redis！APIも豊富だし、レプリケーションとかも簡単らしいよ！ ちなみに今回計測に使
前回の投稿(Key Value Storeについて)に引き続き、今回はKVS関連としてmemcachedプロトコルの詳細を説明したいと思います。
Twitterを利用していると、ときどきクジラの絵の画面が表示されることがあります。これはTwitterの処理能力がパンクして一時的に利用不可になったときに表示されるお馴染みの画面。 2月9日にTwitter Engineeringブログにポストされたエントリ「The Anatomy of a Whale」（クジラの解剖学）では、Twitterのエンジニアたちがこのクジラの内部に分け入ってどのようにTwitterサーバの処理能力を向上させたのか、という話が詳しく語られています。 彼らが行ったのは、まず詳細なデータを取得して原因がどの辺にあるのかを推測すること。そこから多数の無駄な処理を発見し、ソースコードの修正による性能の向上に成功します。 元記事は非常に長いエントリになっていますが、問題の調査から解決に至るアプローチについて多くのエンジニアの方の参考になりそうな内容が含まれていますし、T
Webスケールのデータを扱うためにさまざまなデータベースが登場してきている、ということを昨日のエントリ「データベースは目的別に使い分けるべし」で紹介しました。 特にリレーショナルモデルをベースとしない、非SQL系（NoSQL）と呼ばれるさまざまな種類のデータベースが登場してきています。非SQL系のデータベースは以前からオブジェクトデータベースやドキュメントデータベース、階層型データベースなどが存在していましたが、最近注目されているのがキーバリュー型データストアと呼ばれるデータベース。 ブログ「High Scalability」にポストされたエントリ「A Yes for a NoSQL Taxonomy」では、これら非SQL系のデータベースを詳細に9分類し、それぞれの分類に属するデータベースをリストアップしています（基になったのは「NoSQL is a Horseless Carriage」
数日前にmemcached-1.4のリリース候補が出ましたので、今日はその最新版と、それを使ったメモリ節約の運用法を紹介します。厳密にいうと、ご紹介させていただくmemcachedのメモリ節約機能は1.3のbetaから存在し、過去にこちらで取り上げました。 memcached-1.4.0-rc1 1.4 RCは基本的に1.3.* betaで発見・報告されたバグの修正やコードベースの改修が主な内容です。詳しいリリースノートはこちらになります。 http://code.google.com/p/memcached/wiki/ReleaseNotes140rc1 ダウンロードはこちらです。 http://code.google.com/p/memcached/downloads/list 新しいバージョンのmemcachedはバイナリプロトコルの導入以外に地味に生まれ変わっています。例えばコード
最近のWebシステム開発ではキャッシュを使うケースが増えつつある。各種Webアプリケーション向けフレームワークでもキャッシュをデフォルトでサポートしているものも多く、その筆頭に挙げられるのがmemcachedだ。 top風にmemcachedのステータスが確認できる memcachedは軽量で、あると便利だと思える機能が殆ど実装されていない。ステータスを監視するような機能もないが、そこは独自に開発されたmemcache-topを使えば解決する。 今回紹介するオープンソース・ソフトウェアはmemcache-top、memcachedのステータスを表示するコマンドラインスクリプトだ。 memcache-topはPerlで作られたスクリプトで、既に立ち上がっているmemcachedサーバを一覧し、そのステータスを表示してくれる。デフォルトで3秒ごとにリフレッシュされるようになっており、topコマ
groongaにおいて、データベースを扱うためのAPI群について概説します。 groongaは、RDBMSでいうところのテーブル・カラムを扱うAPIを提供します。 テーブルは、内部的にハッシュテーブルもしくはパトリシアトライが基となっています。 それぞれの要素について、どのような操作が行えるかを説明します。 grn_hash grn_hashとは、以下の操作を行えるAPI群です。 任意のkeyを指定したデータ保存 任意のkeyを指定したデータ取得 任意のkeyを指定したデータ削除 カーソルを用いた、全てのkey/valueの取得・設定・削除 内部の実装は、ハッシュテーブルです。 メモリ上に作成することも、ファイルとして作成することもできます。 いわゆる*DBMと同等のことができます。 Tokyo CabinetでいうところのTCHDBですね。 grn_pat grn_patとは、以下の操作
株式会社ミクシィ 開発部 システム運用グループの長野です。普段はミクシィのアプリケーション運用を担当しております。今回から数回にわたり、最近Webアプリケーションのスケーラビリティの分野で話題になっているmemcachedについて、弊社開発部 研究開発グループの前坂とともに、使い方や内部構造、運用について解説させて頂きます。 memcachedとは memcachedは、LiveJournalを運営していたDanga Interactive社で、Brad Fitzpatrick氏が中心となって開発されたソフトウェアです。現在ではmixiやはてな、Facebook、Vox、LiveJournalなど、さまざまなサービスでWebアプリケーションのスケーラビリティを向上させる重要な要素になっています。 多くのWebアプリケーションは、RDBMSにデータを格納し、アプリケーションサーバでそのデータ
DSのスターフォックスというゲームにはまりまくりのmikioです。最近社内外で「俺ストレージサーバ」を作るのが流行っているようなので私も参戦してみました。今回はDBMのネットワーク層をほぼスクラッチで作った話をします。 Tokyo Tyrant Tokyo Tyrant（以下TT）はTokyo Cabinet（以下TC）をラップしてネットワーク越しに操作できるようにするツールです。キャビネット（内閣）を傀儡にするタイラント（僭主）ということで名付けました。ダウンロードはこちら。 TCは高性能なDBMで、マルチスレッドモデルで高い並列性を実現していますが、逆にマルチプロセスモデルだとファイルロックがかかるので並列性が低くなってしまいます。つまり、書き込みモードでデータベースにアクセスしているプロセスがいると、その間は他のプロセスがデータベースに接続しようとするとブロックされることになります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
