Redisセッションの遅さ

7

セッションのredisを有効にし、githubから最新の拡張機能とlibコードを取得しました。一部のリクエストには約30秒かかることに気づいています。

ここでnewrelicから3つのトランザクショントレースがあり、彼らは私にはほとんど同じに見える： http://imgur.com/JQUzheJ,0sCqUni,3L4PJAX

redisで次の設定を使用しています。

    <redis_session>
            <host>127.0.0.1</host>
            <port>6379</port>
            <password></password>
            <timeout>2.5</timeout>
            <persistent></persistent>
            <db>2</db>
            <compression_threshold>2048</compression_threshold>
            <compression_lib>lzf</compression_lib>
            <log_level>4</log_level>
             <!-- maximum number of processes that can wait for a lock on one session; for large production clusters, set this to at least 10% of the number of PHP processes -->
            <max_concurrency>12</max_concurrency>
            <!-- seconds to wait for a session lock in the frontend; not as critical as admin -->
            <break_after_frontend>5</break_after_frontend>
            <break_after_adminhtml>30</break_after_adminhtml>
            <!-- Bots get shorter session lifetimes. 0 to disable -->
            <bot_lifetime>7200</bot_lifetime>
    </redis_session>

現時点では、1つのフロントエンドサーバーのみがmagentoに使用されています。

ありがとう！

redis cm-redissession

— SCM
ソース

5

それは十数の異なるものになる可能性があり、その時点でサーバー全体の完全な概要がなければ、決定的な答えを出すことは不可能です。

かもしれない、

redis-server 100％CPUでのプロセス
- 永続化のためにインメモリデータをディスクにフラッシュするため
- 立ち退き中のキーの有効期限のため
- 重いプロセスが実行されているため
サーバー側のボトルネック
- VPS /クラウドの場合は、ハイパーバイザー上の別のゲストがリソースを消費してハングアップしている可能性があります（ヒント。信頼性と予測可能性が必要な場合はVPS /クラウドを使用しないでください）
- スワッピングなどによるOOM状態、またはバッファ/キャッシュからユーザースペースへのメモリの交換
- Redisプロセスが不足している高CPU負荷
- 使用可能なTCP状態がありません（テーブルがいっぱいです）
- 利用可能なソケットがありません
- 利用可能なファイル記述子がありません
多目的Redis
- キャッシュとセッションの両方に同じRedisインスタンス（データベースではない）を使用すると、このタイプの動作が発生します。キャッシュにもRedisを使用している場合は、initスクリプトを編集して、2つの異なるポート/ソケットで2つの個別のデーモンをインスタンス化します。

リストはどんどん続く可能性があります。必要なのは、サーバー全体の完全かつ適切な監視です。これにより、診断を行うために何が起こっているかを正確に確認できます。

これには、Muninを使用したすべてのアプリケーションのグラフ化、Atopデーモンを使用した履歴ロギング、単一のダッシュボードへのログデータのロギングと一元化が含まれます。

New Relicは優れたツールですが、問題を特定するのに役立ちますが、問題の原因を完全に可視化するための最良のツールとは限りません。

最も簡単な開始場所は、Redisがより多くのメモリを必要とするかどうかを確認することです。

redis-cli
> info

ピークメモリを定義した制限と比較します。

NB。あなたのホスティングプロバイダーはすぐにこの質問に答えられるはずです、私は間違いなく彼らの意見を求めることをお勧めします。

— ベン・レッサーニ-ソナッシ
ソース

4

バージョンに応じて（私は1.8ここで使用しています）、Cm_RedisSession_Model_Sessionはsleep()特定の条件で動作します。

行325

// Detect dead waiters
if ($tries == 1 /* TODO - $tries % 10 == 0 ? */) {
    $detectZombies = TRUE;
    // TODO: allow configuration of sleep period?
    usleep(1500000); // 1.5 seconds
}

364行目：

if ($tries >= $this->_breakAfter+self::FAIL_AFTER) {
    // ...
    if ($this->_logLevel >= 5) {
        // ...
        Mage::log(
            sprintf(
                "%s: Giving up on read lock for ID %s %s",
                $this->_getPid(),
                $sessionId,
                $additionalDetails
            ),
            Zend_Log::NOTICE, self::LOG_FILE
        );
    }
    break;
}
else {
    // TODO: configurable wait period?
    sleep(1);
}

Xdebugプロファイルを作成し、これが問題の原因かどうかを確認します。これらの行はどちらも、セッションのロックを取得することに関係しています。

sleep()20〜30回呼び出されるクライアントでこの問題が発生しました。DBセッションに切り替えました。または、最新のものでアップグレードCm_RedisSession_Model_Sessionしてみることもできます

— スティーブ・ロビンス
ソース