Redis Session Langsamkeit

Ich habe redis für die Sitzung aktiviert, habe die neueste Erweiterung und den neuesten lib-Code von github und stelle fest, dass einige Anfragen etwa 30 Sekunden dauern - und dies geschieht ziemlich häufig, und es ist immer redis schuld.

Hier sind 3 Transaktionsspuren von newrelic, die für mich ziemlich gleich aussehen: http://imgur.com/JQUzheJ,0sCqUni,3L4PJAX

Ich verwende die folgenden Einstellungen in 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>   

Derzeit wird nur ein Frontend-Server für Magento verwendet.

Vielen Dank!

Es könnte ein Dutzend verschiedener Dinge sein, und ohne einen vollständigen Überblick über Ihren gesamten Server zu diesem Zeitpunkt wird es nicht möglich sein, eine endgültige Antwort zu geben.

Es könnte sein,

• redis-server Prozess bei 100% CPU
  • Aufgrund eines Flushs von In-Memory-Daten auf die Festplatte für die Persistenz
  • Aufgrund des Schlüsselablaufs während einer Räumung
  • Aufgrund eines schweren Prozesses wird ausgeführt
• Serverseitiger Engpass
  • Wenn es sich um eine VPS / Cloud handelt, verbraucht möglicherweise ein anderer Gast auf dem Hypervisor Ressourcen und zwingt Ihre zum Hängen (Tipp. Verwenden Sie keine VPS / Cloud, wenn Sie Zuverlässigkeit und Vorhersehbarkeit wünschen).
  • OOM-Bedingung aufgrund von Austausch usw. oder Speicheraustausch von Puffern / Cache in den Benutzerbereich
  • Hohe CPU-Auslastung führt zum Redis-Prozess
  • Keine verfügbaren TCP-Zustände (dh Tabelle voll)
  • Keine Steckdosen verfügbar
  • Keine verfügbaren Dateideskriptoren
• Mehrzweck Redis
  • Die Verwendung derselben Redis-Instanz (nicht Datenbank) für Cache und Sitzungen führt zu dieser Art von Verhalten. Wenn Sie Redis auch für den Cache verwenden, bearbeiten Sie Ihr Init-Skript, um zwei separate Dämonen an zwei verschiedenen Ports / Sockets zu instanziieren.

Die Liste könnte weiter und weiter gehen. Was Sie brauchen, ist eine vollständige und ordnungsgemäße Überwachung Ihres gesamten Servers, damit Sie genau sehen können, was passiert, um eine Diagnose zu stellen.

Dazu gehören die grafische Darstellung jeder Anwendung mit Munin, die Protokollierung mit dem Atop-Daemon, die Protokollierung und die Zentralisierung von Protokolldaten in einem einzigen Dashboard.

New Relic ist ein nützliches Tool, das zwar zur Identifizierung von Problemen nützlich ist, aber nicht unbedingt das beste Tool, um die Ursache von Problemen vollständig sichtbar zu machen.

Am einfachsten ist es, zu überprüfen, ob Redis mehr Speicher benötigt.

redis-cli
> info

Vergleichen Sie den Spitzenspeicher mit dem von Ihnen definierten Grenzwert.

NB. Ihr Hosting-Anbieter sollte in der Lage sein, diese Frage sofort zu beantworten. Ich würde definitiv empfehlen, nach deren Eingabe zu fragen.

Abhängig von Ihrer Version (ich verwende 1.8hier) wird Cm_RedisSession_Model_Session unter sleep()bestimmten Bedingungen:

Zeile 325

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

Zeile 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);
}

Erstellen Sie ein Xdebug-Profil und prüfen Sie, ob hier die Dinge hängen bleiben. Beide Zeilen haben damit zu tun, die Sitzung zu sperren.

Ich hatte dieses Problem mit einem Kunden sleep(), der 20 bis 30 Mal angerufen wurde. Am Ende haben wir zu DB-Sitzungen gewechselt. Alternativ können Sie versuchen, ein Upgrade Cm_RedisSession_Model_Sessionmit der neuesten Version durchzuführen