タグ

Programmingとmemcachedに関するHeavyFeatherのブックマーク (3)

  • mixiがはまったmemcached(or libevent?)の問題を調べる人たち

    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とし

    mixiがはまったmemcached(or libevent?)の問題を調べる人たち
  • 「キー・バリュー型データストア」開発者が大集合した夜

    「発表者が自分よりも若い人ばかりだ」。外見が20代にしか見えない東京工業大学の首藤一幸准教授(1973年生)の驚くさまが、少し面白かった。2009年2月20日の夜、多くのWeb企業が注目する「キー・バリュー型データストア」を開発する若手技術者が、東京・六木のグリー社に一堂に会した。 キー・バリュー型データストア(またはキー・バリュー型データベース)は、大量のユーザーとデータを抱え、データベースのパフォーマンス問題とコスト高に頭を悩ませるWeb企業が注目する技術である。記者は同日に開催された「Key-Value Store 勉強会」に参加させてもらった。午後7時から11時まで、キー・バリュー型データストアを開発・研究する若手技術者が立て続けに登場し、1人15分の持ち時間で成果を発表し、議論を重ねるという集まりだ。 呼びかけ人であるプリファードインフラストラクチャー(PFI)最高技術責任者

    「キー・バリュー型データストア」開発者が大集合した夜
  • 第2回 memcachedのメモリストレージを理解する | gihyo.jp

    株式会社ミクシィ 研究開発グループの前坂です。前回の記事でmemcachedは分散に長けた高速なキャッシュサーバであることが紹介されました。今回はmemcachedの内部構造がどう実装されているのか、そしてメモリがどう管理されているのかをご紹介します。また、memcachedの内部構造の事情による弱点も紹介します。 メモリを整理して再利用するSlab Allocationメカニズム 昨今のmemcachedはデフォルトでSlab Allocatorというメカニズムを使ってメモリの確保・管理を行っています。このメカニズムが登場する以前のメモリ確保の戦略は、単純にすべてのレコードに対してmallocとfreeを行うといったものでした。しがしながら、このアプローチではメモリにフラグメンテーション(断片化)を発生させてしまい、OSのメモリマネージャに負荷をかけ、最悪の場合だとmemcachedのプ

    第2回 memcachedのメモリストレージを理解する | gihyo.jp
  • 1