redis導入後にトラブル発生、そのレポート
こんにちわ、ミツバチワークス stoneです。 今回は、redisシリーズ第３弾、実際にredisをサービスの投入してみて、うまく行かなかった事例についてご紹介します。 redisの使用用途 今回、いくつかあるセッションデータのうち２つをMySQLからredisへ移行させました。 これらのセッションデータ、MySQL上では、セッションIDの他に複数のカラムから構成されているのですが、redis上では、この複数のカラムをserialize()して、 key(string) => value(string) という形で格納するようにしました。 ちゃんとソースコードで確認はしていないのですが、memcachedでも、TTLが設定できますが、TTLを過ぎたデータを監視してクリアしていないですよね。 また、memcached内部のslabの構成次第では、TTLまでデータが保持されずに、データがクリア
Redisを使う時は見積の二倍の容量必要だよね、という話 - Qiita
[15487] 04 Aug 21:02:37.523 * 1 changes in 900 seconds. Saving... [15487] 04 Aug 21:02:37.523 # Can't save in background: fork: Cannot allocate memory redis-cli infoしても、使用してるメモリは全体の半分ちょっとだったし、空きは十分にある… 答えは Redis Administration http://redis.io/topics/admin に書いてありました。 原因と解決策 redisのバックアップが走る際、おそらく現状使用している量と同じだけのallocateを要求しているために、redis自体はメモリ使用が50%強だとしても、バックアッププロセスが落ちてしまう模様。 解決は簡単で、Redis Administratio
巨大なデータを扱う場合のRedisの運用戦略 - Qiita
はじめに Read/Writeともに高速で，様々なデータの持ち方が可能なことでキャッシュDBとして人気のあるRedisですが，何も考えずに実運用システムで使用しているとデータが肥大化してしまい非常に扱いにくくなることがあります． 今回は，データの肥大化とともに顕在化する問題と，データの肥大化に対する戦略についてまとめたいと思います． データの肥大化時に顕在化する問題 何のキーが入っているか分からなくなる Redisはオンメモリ型のKVSであるため，データがある程度増えてくるとサーバのメモリ容量を圧迫し始めます． このような状態で，プロダクション環境に対して keys * などをやってしまうと，一時的にメモリ使用量が跳ね上がり，メモリ使用量を抑えるためにRedisがキーを削除したり，OOM KILLERにRedis Serverごと殺されてしまう可能性があるため，そういったコマンドはうてなく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
