タグ

memcachedに関するmasudaKのブックマーク (18)

  • Memcachedの30days problemとはなんなのか - Qiita

    今北産業 Memcachedではexpiration timeに絶対指定と相対指定をすることができる expiration timeに30日を超える秒数を指定すると絶対指定(epoch)として扱われる つまりexpiration timeに30日を超える秒数を相対指定のつもりで指定した場合、絶対指定として処理されて大抵の場合は死に至る Memcachedのexpiration Memcachedのexpirationには無効値とするまでの相対的な時間を秒数で指定する方法が一般的だ。 だが、実はMemcachedはepochによる絶対指定によるexpirationもサポートしている。 https://github.com/memcached/memcached/wiki/Commands#standard-protocol ドキュメントを引用: An expiration time, in

    Memcachedの30days problemとはなんなのか - Qiita
    masudaK
    masudaK 2017/06/11
    怖い
  • Introducing mcrouter: A memcached protocol router for scaling memcached deployments

    Introducing mcrouter: A memcached protocol router for scaling memcached deployments Most web-based services begin as a collection of front-end application servers paired with databases used to manage data storage. As they grow, the databases are augmented with caches to store frequently-read pieces of data and improve site performance. Often, the ability to quickly access data moves from being an

    Introducing mcrouter: A memcached protocol router for scaling memcached deployments
  • Scaling Memcache at Facebook | USENIX

    by Michael Piatek Responsiveness is essential for web services. Speed drives user engagement, which drives revenue. To reduce response latency, modern web services are architected to serve as much as possible from in-memory caches. The structure is familiar: a database is split among servers with caches for scaling reads. Over time, caches tends to accumulate more responsibility in the storage sta

    Scaling Memcache at Facebook | USENIX
  • 第4回 memcachedを快適に利用するTips集 | gihyo.jp

    「memcachedの活用と運用 実践編」の連載も今回が最後となります。連載の第1回ではmemcachedの最新バージョンである1.4系で増えたオプションやよく利用されるオプションの紹介をしました。第2回目では安全にmemcachedを利用するために気を配るセキュリティや脆弱性について説明し、3回目では稼働監視やリソースモニタリングについて書かせて頂きました。 最終回では、これまで説明してこなかったmemcachedを快適に活用、運用するための小さめのTipsをいくつか紹介します。 指定したキーが含まれるサーバを探す 複数台のmemcachedのサーバを1つのグループとしてWebアプリケーションサーバなどのクライアントから利用している場合、特定のキーのデータがどのmemcachedサーバに保存されているのか知ることは容易ではありません。 memcachedのキャッシュオブジェクトの分散は、

    第4回 memcachedを快適に利用するTips集 | gihyo.jp
  • memcached(プロトコル)のデータレプリケーション - (ひ)メモ

    国内だけでなく国外(なぜか主に中国語)でもまだrepcachedについて言及してるのをちらほら見かけるのですが、repcachedはmemcached 1.2.8ベースですし(memcached 1.4.5に対応してる人もいるようですが)いまならKyoto Tycoon使えばいいんじゃないかと思うのです。 Kyoto Tycoonなら: memcachedプロトコルプラグインを使えば、Kyoto Tycoonがそのままmemcachedの代替になる(memcachedプロトコルを喋るクライアントコードはそのままでよい) Tokyo Tyrantと違ってexpireもOK memcachedの代替が目的なら、速いオンメモリDB(StashDBとか)でOK 非同期レプリケーションもできる ホットスタンバイ側のサーバリソースが無駄に思うなら、keyに応じてmodとかでリクエストするサーバを2台の

    memcached(プロトコル)のデータレプリケーション - (ひ)メモ
  • memcached の中身を確認するなら memcached-tool コマンド | バシャログ。

    蚊取り線香の焚きすぎで目がかい~~の。nakamura です。今年なんか蚊多くありません? 以前に CakePHP の特集 で取り上げたりもした memcached ですが、キャッシュの中身を簡単に確認できるツールないかな?と探していたところ memcached-tool というコマンドがある事を知ったので今回ご紹介しようと思います。 memcached-tool コマンドは memcached をインストールすると自動でくっついてくる、言ってみればめっちゃシンプルな memcached クライアントです。機能的には参照系のものしかなく、キャッシュの中身を書き換えたり削除したりというのはできないようです。 オプション オプションは display, stats, dump の 3 つしかありません。ちなみにオプションなしでコマンドを実行すると使い方が表示されます。こんな感じ↓ memcac

    memcached の中身を確認するなら memcached-tool コマンド | バシャログ。
  • memcached互換のNoSQLデータベース「Membase」がオープンソースで登場

    memcachedの開発者らが中心となって今年の3月に立ち上げた企業NorthScaleが、memcached互換のNoSQLデータベース「Membase」のオープンソースプロジェクト「membase.org」を6月23日に発表しました。 MembaseはWebアプリケーションのバックエンドに使われることを想定したキーバリュー型データストア。高速かつ高いスケーラビリティを目指したもの。 主な機能として、将来にわたってmemcachedとプロトコルの互換性を保証しつつ、ディスクへの永続性機能(データのディスクへの書き込み)、階層型データストア管理、データレプリケーション、稼働状態での設定変更とノード間のリバランシング機能なども備えると説明されています。 Membaseの特徴はmemcached互換とスケーラビリティ MembaseのWebサイトの情報を基に、特徴を紹介しましょう。 動的なノー

    memcached互換のNoSQLデータベース「Membase」がオープンソースで登場
  • memcached | feedforce Engineers' blog

    何? オブジェクトをメモリにキャッシュするデーモン。 動的ページを持つウェブアプリケーションの裏側で動くデータベースへの負荷を軽減させることを目的にデザインされている。 - 公式サイト memcached: a distributed memory object caching system 特徴 オブジェクトをメモリ上にキャッシュ 複数ホスト間でキャッシュ共有可能(リモートからキャッシュにアクセス可能) 各言語用のインタフェースライブラリがそろってます 実績豊富 よくある用途 セッションストア DBへのクエリ結果のキャッシュ アプリケーションレベルのオブジェクト共有(静的インスタンス) セッションストア 複数サーバ間のセッション情報共有 DBを使う方法と比べて負荷がかからなくてうれしい セッションストアとしての問題点 レプリケーションの仕組みがない。 ので、アプリケーションの性質によって

    memcached | feedforce Engineers' blog
  • 第2回 mixi、ニコニコ動画、Livedoorの各システム構成とmemcached | gihyo.jp

    WEB+DB PRESS Vol.47の特集2「mixi、ニコニコ動画、livedoor [⁠実例から学ぶ]memcachedベストプラクティス」で掲載した内容の元となった座談会の様子を動画でお送りします。 第2回は、mixi、ニコニコ動画、livedoorの各システム構成の概要と、それらシステム構成に対して、どのようにmemcachedが利用されているかを紹介していきます。 ニコニコ動画:https://www.nicovideo.jp/watch/sm4960083 座談会の模様 mixiのシステム構成についてやり取り。左から、前坂さん、長野さん、正野さん ニコニコ動画のシステム構成について説明する、福冨さん(一番右) スライドで触れていなかった部分を直接ホワイトボードに描いて説明する、池邉さん 第2回終了時のホワイトボード

    第2回 mixi、ニコニコ動画、Livedoorの各システム構成とmemcached | gihyo.jp
  • memcached Cacti Template

    Before you begin, you should ensure that you have a working cacti installation already polling and graphing devices and at least one working installation of memcached. The installation of cacti and memcached is outside the scope of this document. Python Client API Installation Download and copy the latest version of the Python client API to a writable directory on the same server that cacti is ins

  • 第3回 memcachedの監視とCloudForecastによるモニタリング | gihyo.jp

    安定したWebサービスを提供するためには欠かすことができないのが監視です。監視を行うことで障害をいち早く検知し、対応を行うことでダウンタイムを最小限にできます。また負荷の掛かり具合やサーバリソースの消費度合いを明らかにすることでいつ、どのタイミングでサーバやインフラを増強するか、またアプリケーションの改善を行うのかを判断できます。Webサービスの稼働やリソースの「見える化」を実現することで、個人の経験や勘、また根性だけに頼らない運用が可能となり、より的確なタイミングでのシステムの改善、増強を行えます。 稼働監視とリソースモニタリング Webサービスのシステムの監視には大きく分けて2種類の監視があります。1つ目は稼働監視、2つ目はリソースのモニタリングです。稼働監視では監視を行ったタイミングで対象システムに例外があれば、メールを送信するなどのアラートを発生させます。稼働監視に於ける例外とは、

    第3回 memcachedの監視とCloudForecastによるモニタリング | gihyo.jp
  • 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大規模障害について 解明編 - mixi engineer blog
  • mixi大規模障害について - mixi engineer blog

    こんにちは。システム技術部たんぽぽGの森です 先日のmixi大規模障害についてのブログです。 はじめにお断りしておきますが、弊社CTOがtwitterで公開した以上の情報はまだ得られておりません。 twitterでは書ききれなかった細部を補足してみたいと思います 現状判明しているのは以下の点です memcachedに大量の接続・切断を行うとmemcachedプロセスが突然終了することがある memcachedには異常時に終了するフローもあるが、同時に出力されるはずのエラーログは出ていなかった coreも出力されていなかった テスト環境にて追試を行ったところ、なんどか再現させることができましたが、確実に発生する条件は未だ不明です。 障害時の memcachedのバージョンは1.4.4, libeventのバージョンは1.3bです memcached の起動オプションは以下のとおり ./

    mixi大規模障害について - mixi engineer blog
  • 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. */

  • PHP: Memcached::set - Manual

    Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Enumerations Errors Exceptions Fibers Generators Attributes References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Predefined Attributes Context options and parameters Su

  • Ethna CacheManager 比較 - てつじんにっき

    Ethnaにはデータキャッシュ用のプラグインがあります。効率よく使うとパフォーマンスを劇的に改善してくれるアレです。 Ethna_Plugin_Cachemanager_Memcache Ethna_Plugin_Cachemanager_Localfile がありますが、今までずっとEthna_Plugin_Cachemanager_Localfileばっかり使っていたので、memcachedを使うとどんだけ早いんだろー?と以前からワクワクしてたので、Ethna_Plugin_Cachemanager_Memcacheを使ってみました。 ちなみに、set時でなくget時にライフタイム指定ができるあたりが結構気に入ってます。 memcachedを入れてみる 面倒だから今回はrpmで突っ込んでみる。 # wget http://dag.wieers.com/rpm/packages/libe

    Ethna CacheManager 比較 - てつじんにっき
  • 第1回 memcachedの基本 | gihyo.jp

    株式会社ミクシィ 開発部 システム運用グループの長野です。普段はミクシィのアプリケーション運用を担当しております。今回から数回にわたり、最近Webアプリケーションのスケーラビリティの分野で話題になっているmemcachedについて、弊社開発部 研究開発グループの前坂とともに、使い方や内部構造、運用について解説させて頂きます。 memcachedとは memcachedは、LiveJournalを運営していたDanga Interactive社で、Brad Fitzpatrick氏が中心となって開発されたソフトウェアです。現在ではmixiやはてな、Facebook、Vox、LiveJournalなど、さまざまなサービスでWebアプリケーションのスケーラビリティを向上させる重要な要素になっています。 多くのWebアプリケーションは、RDBMSにデータを格納し、アプリケーションサーバでそのデータ

    第1回 memcachedの基本 | gihyo.jp
  • mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築

    連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「

    mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
  • 1