Beste EC2-Einrichtung für Redis-Server

Question

Wir implementieren eine große Webanwendung, die nur Redis als Datenspeicher verwendet. Ich stelle fest, dass der Benchmark unseres Redis-Masters ungefähr 8000 Transaktionen pro Sekunde auf EC2 ist, weit weniger als die angegebenen Benchmarks auf dedizierter Hardware.

Ich verstehe, dass es eine Leistungseinbuße für das Ausführen von Redis auf einer virtuellen Maschine wie EC2 gibt, aber ich würde gerne einige Hinweise von Leuten, die Redis in Produktionsumgebungen auf EC2 installiert haben, auf welche EC2-Einrichtung Sie am effektivsten gefunden haben mehr aus Redis.

Danke.

Answer 1

EC2 ist wahrscheinlich nicht die beste Umgebung, um Redis auf virtualisierter Hardware laufen zu lassen, aber es ist eine populäre Umgebung, und es gibt eine Reihe von Punkten, um Redis auf dieser Plattform zu nutzen.

Ich bin einer der Autoren von http://redis.io/topics/benchmarks und http://redis.io/topics/latency, die die meisten der Themen abdecken, die ich unten präsentiere. Dies ist nur eine Zusammenfassung der wichtigsten Punkte.

Virtualisierung Maut

Es ist zu EC2 nicht spezifisch, sondern Redis ist deutlich langsamer als auf einer VM (in Laufzeit von maximal unterstützten Durchsatz) ausgeführt wird. Dies liegt daran, dass Redis für die grundlegenden Operationen keinen großen Overhead zu den epoll/read/write Systemaufrufen hinzufügt, die zur Verarbeitung von Clientverbindungen erforderlich sind (wie memcached oder andere effiziente Schlüssel-/Wertespeicher). Systemaufrufe sind in der Regel auf einer VM teurer und sie stellen einen wesentlichen Teil der Redis-Aktivität dar (insbesondere in Benchmarks). Unter diesen Bedingungen ist eine 50% ige Abnahme des maximalen Durchsatzes im Vergleich zu blankem Metall nicht ungewöhnlich.

Natürlich hängt es auch von der Qualität des Hypervisors ab. Für EC2 wird Xen verwendet.

Benchmarking in gutem Zustand

Benchmarking kann auf einer Plattform wie EC2 schwierig, vor allem sein. Ein oft vergessener Punkt ist die Sicherstellung einer korrekten Konfiguration sowohl für den Benchmark-Client als auch für den Server. Führen Sie zum Beispiel den redis-Benchmark nicht auf einer von der CPU ausgehungerten Mikroinstanz aus (die wahrscheinlich von Amazon gedrosselt wird), während Sie auf Ihren Redis-Server zielen. Beide Maschinen sind gleichermaßen wichtig, um einen guten maximalen Durchsatz zu erzielen.

Eigentlich Redis Leistung zu bewerten, müssen Sie:

• Lauf redis-Benchmark lokal (auf demselben Computer als der Server), vorausgesetzt, Sie sind mehr als ein vCPU Kern haben.

• Lauf redis-Benchmark der Ferne (aus einer anderen VM), auf einer Maschine, deren QoS-Konfiguration entspricht der Servermaschine

So können Sie die Leistung der Maschinen und das Netzwerk bewerten und vergleichen.

Auf EC2 haben Sie die besten Ergebnisse mit M3-Instanzen der zweiten Generation (oder mit High-Memory- oder Cluster-Compute-Instanzen), sodass Sie von HVM (Hardware-Virtualisierung) profitieren können, anstatt sich auf langsamere Paravirtualisierung zu verlassen.

Die Gabel Ausgabe

Dies ist EC2 nicht spezifisch, sondern auf Xen: einen großen Prozess Forking kann wirklich auf Xen langsam sein (es sieht besser aus mit kvm). Für Redis ist dies ein großes Problem, wenn Sie Persistenz verwenden möchten: Beide Persistenzoptionen (RDB oder AOF) erfordern den Hauptthread zum Verzweigen und Starten von Hintergrundsicherungs- oder Neuschreibprozessen.

In einigen Fällen kann die Gabel-Latenz die Redis-Ereignisschleife für einige Sekunden einfrieren. Je mehr Speicher von der Redis-Instanz verwaltet wird, desto mehr Latenzzeit.

Vergewissern Sie sich auf EC2, dass eine HVM-fähige Instanz (M3, hoher Speicher, Cluster) verwendet wird. Dadurch wird das Problem gemildert.

Wenn Sie große Speicheranforderungen haben und Ihre Anwendung dies tolerieren kann, sollten Sie mehrere kleinere Redis-Instanzen auf demselben Computer ausführen und Ihre Daten sharden. Es kann die Latenz aufgrund von Fork-Operationen auf ein akzeptables Niveau verringern.

Persistenz Konfiguration

Dies ist ein wichtiger Punkt gute Leistung von Redis (beide auf VM und Bare-Metal) zu erhalten. Also nehmen Sie sich die Zeit sorgfältig lesen http://redis.io/topics/persistence

Wenn Sie RDB verwenden, im Auge behalten wird der Speicher Copy-on-Write-Mechanismus Duplizieren Seiten beginnen, sobald der Hintergrundprozess speichern wurde aus gegabelt ist. Sie müssen also sicherstellen, dass genug Speicher für Redis selbst vorhanden ist, sowie ein gewisser Spielraum, um mit der COW fertig zu werden. Die Menge an zusätzlichem Arbeitsspeicher hängt von Ihrer Arbeitslast ab. Je mehr Sie in der Instanz schreiben, desto mehr zusätzlichen Speicher benötigen Sie.

Bitte beachten Sie, dass das Schreiben einer Datei auch etwas Speicher beanspruchen kann (wegen des Dateisystemcaches). Daher müssen Sie während einer Redis-Hintergrundspeicherung Redis-Speicher, COW-Overhead und Größe der Speicherabbilddatei berücksichtigen.

Der Computer, auf dem der Redis-Server ausgeführt wird, darf niemals vertauschen. Wenn dies der Fall ist, wird das Ergebnis katastrophal sein. Im Gegensatz zu einigen anderen Geschäften ist Redis nicht virtuell speicherfreundlich.

Mit Linux, stellen Sie sicher sinnvolle Systemparameter: vm.overcommit_memory = 1 und vm.swappiness = 0 (oder ein sehr niedriger Wert sowieso). Verwenden Sie keine alten Kernel-Versionen: Sie sind ziemlich schlecht darin, eine geringe Swappiness zu erzwingen (was zu einem Swapping führt, wenn eine große Datei geschrieben wird).

Wenn Sie AOF verwenden, überprüfen Sie die fsync-Optionen. Es ist ein Kompromiss zwischen roher Leistung und Haltbarkeit der Schreibvorgänge. Sie müssen eine Auswahl treffen und eine Strategie definieren.

Sie müssen sich auch mit den EC2-Speicheroptionen vertraut machen. Auf einigen VMs haben Sie die Wahl zwischen ephemeren Speicher und EBS. Bei einigen anderen haben Sie nur EBS.

Ephemere Speicherung ist in der Regel schneller, und Sie werden wahrscheinlich weniger Probleme als mit EBS haben, aber Sie können Ihre Daten im Falle eines Festplattenfehlers oder Neustarts des Hosts usw. leicht verlieren ... Sie können sich RDB-Snapshots vorstellen ephemere Speicherung und anschließendes Kopieren der resultierenden Dateien in EBS-Verzeichnisse als Kompromiss zwischen Leistung und Robustheit.

EBS ist Remotespeicher: Es kann die Standardnetzwerkbandbreite verbrauchen, die der VM zugewiesen ist, und den maximalen Durchsatz von Redis beeinflussen. Wenn Sie beabsichtigen, EBS zu verwenden, sollten Sie die Option "EBS-optimiert" auswählen, um eine QoS zwischen den standardmäßigen Netzwerk- und Speicherverbindungen einzurichten.

Schließlich ist ein sehr häufiges Setup für leistungsintensive Instanzen mit EC2, die Persistenz auf dem Master zu deaktivieren und nur auf einer Slave-Instanz zu aktivieren. Es ist wahrscheinlich weniger sicher für die Daten, aber es kann viele mögliche Latenzprobleme auf dem Master verhindern.