タグ

memcachedに関するnobodyplaceのブックマーク (7)

  • memcachedのセキュリティの話

    平素よりさくらインターネットに格別のご愛顧を賜り、誠にありがとうございます。 このたび、適切なアクセス制限を設定していないmemcachedがリフレクションDDoS攻撃 発信の踏み台として悪用されている事例がJPCERTコーディネーションセンターより報告 されました。 ▼「memcachedのアクセス制御に関する注意喚起」(JPCERTコーディネーションセンター) https://www.jpcert.or.jp/at/2018/at180009.html アクセス制限をせずにmemcachedを運用した場合、DDoS攻撃のほか、キャッシュデータ を第三者に参照され、情報漏洩が発生する可能性もございます。 お客さまにおかれましては、memcachedに適切なアクセス制限が設定されているかを今 一度ご確認いただき、不正に利用されないよう対策をお願いいたします。 【重要】memcachedのア

    memcachedのセキュリティの話
  • KyotoCabinet + KyotoTycoonをインストールしてPECL::Memcachedで接続

    調べてみたらPEAR::Cache_Liteが思った以上に頼りないことが解ったのでキャッシュ機構の入れ替えを検討。 【メモ】PEAR::Cache_Liteの生存期間について誤解してたこと(追記あり) | mutter いろいろ考えたのだけど、個人プロジェクトなんだし好奇心優先って事でKyotoCabinetとそれを扱うKyotoTycoonを入れて、PECL::Memcachedを利用して接続してみることにしました。PHP側については、OpenPEARの方に「Net_KyotoTycoon」と言うライブラリもアップされているのですが、まぁ今は良いかなと言うことで。 Net_KyotoTycoon \ パッケージ \ Openpear KyotoTycoon の PHP 版を作った – Heavens hell と言うわけで、以下インストール。 KyotoCabinetのインストール #

    KyotoCabinet + KyotoTycoonをインストールしてPECL::Memcachedで接続
  • memcachedのaccept_new_connsがスレッドセーフじゃない件がmemcached-1.4.6で修正されたにょ - mixi engineer blog

    こんにちは、たんぽぽGの森です memcached-1.4.6がリリースされました。 mixi大規模障害の原因となった不具合が解消されているとのことなので検証してみました。 動作確認 過去のバージョンで不具合が発生することと新しいバージョン(1.4.6)で不具合が発生しないことを確認するために 負荷テストを行いました。 memcachedの設定は memcached -U 0 -u nobody -p 11222 -t 4 -m 16000 -C -c 1000 -v としました。 -l オプションを指定していないので eth0, lo の二つのネットワークI/Fに対してlistenを行う設定です。 クライアント側のスクリプトは前回と同様にmalaさん作のテストスクリプトを用いました。 ./memcachedos.pl localhost 11222 5 memcached-1.4.4の

    memcachedのaccept_new_connsがスレッドセーフじゃない件がmemcached-1.4.6で修正されたにょ - mixi engineer blog
  • 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大規模障害について その2 - mixi engineer blog

    こんにちは。システム技術部たんぽぽGの森です 補足を追記しました (2010/08/20 15時) 先日のmixi大規模障害についての続報です 今回は小ネタはありません はじめに まず初めにtwitter/blogなどを通じて今回の問題の解析を行っていただいたみなさんに感謝の言葉を捧げたいと思います kzk_moverさん stanakaさん mala(bulkneets)さん llameradaさん (順不同) ありがとうございました 書き漏らした人ごめんなさい memcachedはすごい 今回の件でmemcachedに対して不安感を持たれた方もおられるとお聞きしました 説明不足だったせいで誤解を与えてしまい申し訳ありません きちんと設定および監視を行っていれば通常の使用にはまったく問題はありません 弊社にて -c 30万で起動したmemcachedに対して、先のテストスクリプトに

    mixi大規模障害について その2 - 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
  • mixiがはまったmemcached(or libevent?)の問題を調べる人たち

    Neal Sato @nealsato 二日とも複数台のmemcachedが連続して落ちました。コアは吐かずにストンと落ちるので、原因追及に時間がかかりましたが、memcachedへの接続数が異常に多いと落ちる事は再現できました。 #mixi Neal Sato @nealsato memcachedが大量の接続を受けると突然停止をするので、memcachedへの接続数を減らし安定運用中。外部からの過剰アクセスではなく、サーバ追加→クライアント数増加→停止。 Masahiro Nagano / 長野雅広 @kazeburo ファイルディスクリプタが不足してmemcachedが落ちたとして、そのときには、3万強の接続となってるはず。3万強の接続となるにはアプリケーションサーバ側のmax clientが平均60として500台以上必要。そんなに増えたん?

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