memcached-1.4.7-rc1でmixiの大規模障害の原因となったmemcachedの不具合が全て解消されました - blog.nomadscafe.jp
こちらとこちらのエントリーの続き memcached 1.4.6でmixiの障害の原因となったaccept_new_connsがスレッドセーフじゃない件は修正されているはずだったのですが、検証したところ別のスレッド競合による不具合が発生し、Bugは全て解消されてはいませんでした。 この件についてmixiたんぽぽGの森本さんと調査していたところ、memcachedのcommiterにtwitter上で補足され、つたない英語で報告をあげていたら1.4.7-rc1で修正されたのでその報告。 memcached 1.4.6での不具合再現方法 まず、1.4.6で不具合を再現させる方法について。mixiのエンジニアブログと同じように、memcachedは次のオプションで起動し、 $ ./memcached -U 0 -u nobody -p 11222 -t 4 -m 16000 -C -c 1000
memcached を使ったアプリケーションの設計について - blog.nomadscafe.jp
クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基本は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシ
第6回 パフォーマンスはどうなの？ | gihyo.jp
この表では言及していませんが、Consistent Hashingやshardingによって分散させやすいというのはすべてのNoSQLデータベースが備えている特徴でしたね。 検証用サーバの準備 では実際のパフォーマンスを比較してみましょう。比較のため、10,000件のデータの書込み/読込みを行います。実行にあたり各種サーバを起動します。 リスト1 検証用サーバの起動コマンド # memcached memcached -u nobody -d # TokyoTyrant sudo ttserver -pid /var/ttserver/pid -dmn /var/ttserver/bench.tch # MongoDB mongod --dbpath ~/tmp/mongodb & # HBase sudo /etc/init.d/hadoop-0.20-namenode start su
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
複数サーバでセッションを共有する冴えたやりかた
