Redis

Siehe auch

Das in C geschriebene Redis (REmote DIctionary Server) ist single-threaded, arbeitet also immer nur auf einem einzigen CPU-Kern. Der einfachste Weg, den Gesamtdurchsatz von Redis zu erhöhen, ist das Hinzufügen von Read-only Replika-Shards oder Slave-Redis Servern.

„Redis Server“ oder „Shard“ ist das nichts anderes als ein Redis-Prozess, der auf einem Knoten läuft. Mehrere Redis-Prozesse können auf derselben Maschine auf verschiedenen Ports laufen.

Redis unterstützt die Replikation von Daten von einem Redis-Shard zu einem anderen Shard. Ein Leader-Shard repliziert kontinuierlich an einen oder mehrere Follower (Leader-Follower-Methode). Um den Durchsatz zu erhöhen, muss die Applikation die Verbindung von einem Replika-Prozess hin zu Replika-Shards wechseln.

Für RHEL und kompatible finden sich aktuelle Versionen im Remi-Repo.

Redis 4 führte das Modulsystem sowie den „Memory Doctor“ ein.

Begriffe:

  • AOF: Append Only File (Persistenz). AOF ist eigentlich eine Persistenztechnik, bei der eine RDB-Datei einmal erstellt wird und weitere Daten nach und nach an sie angehängt werden.

  • RDB: Redis Database (Persistenz). Die RDB-Datei ist ein Dump aller Benutzerdaten, die in einem internen, komprimierten Serialisierungsformat zu einem bestimmten Zeitpunkt gespeichert sind und für die Point-in-Time-Wiederherstellung (Wiederherstellung ab einem bestimmten Zeitpunkt) verwendet werden.

Links:

Installation und Konfiguration

Kernel-Settings optimieren und „Transparent Huge Pages“ deaktivieren:

mkdir /etc/tuned/kernel_settings

cat > /etc/tuned/kernel_settings/tuned.conf << 'EOF'
[main]
summary = kernel settings

[sysctl]
vm.overcommit_memory = 1
net.core.somaxconn = 1024

[vm]
transparent_hugepages = madvise
EOF

tuned-adm profile virtual-guest kernel_settings

# Redis 5 (default in RHEL 8)
dnf -y install redis

# Redis 6 (available per module stream)
dnf -y module enable redis:6
dnf -y module install redis

systemctl enable --now redis.service

redis-cli

Beispiele:

redis-cli
redis-cli -h hostname -p port
redis-cli -s /var/run/redis/redis.sock

127.0.0.1:6379> ping

127.0.0.1:6379> set mykey "myvalue"
127.0.0.1:6379> get mykey

127.0.0.1:6379> info
127.0.0.1:6379> info commandstats
127.0.0.1:6379> info keyspace
127.0.0.1:6379> info server

127.0.0.1:6379> exit

Alle Keys auslesen:

redis-cli keys '*'

Redis bei der Arbeit zuschauen:

redis-cli monitor

Redis benchmarken:

redis-benchmark -t set -n 1000000 -r 100000000 -l

Redis Memory-Zustand anschauen:

redis-cli memory doctor

Redis-Datenbank leeren:

redis-cli flushdb

Redis räumt den Cache nicht auf

VM mit 1 GB RAM und Redis 3. Mehrere Prozesse schreiben laufend und parallel neue Keys inkl. TTL in Redis, zudem wird Redis zusätzlich gebenchmarked. Redis ist also unter Vollast. Die Keys werden in dem Zeitraum von keiner Applikation gelesen. save ist nach Standard aktiviert. VM läuft voll, Redis „evicted“ die Keys aber nicht - redis-cli info | grep evicted bleibt immer auf 0. Auch ein nachträgliches Lesen der Keys hilft nicht. Woran liegt das? An der Schreiblast?

Nein. Schuld ist maxmemory 0: Die Einstellung sorgt dafür, dass die Maschine bis an die Schmerzgrenze vollgeschrieben wird, also inklusive Swap-Space. Erst wenn der Kernel kein Byte mehr freischaufeln kann, würde Redis mit der Key-Eviction beginnen. Das passiert aber nie: Ist save konfiguriert, wird Redis schon vorher wegen Can't save in background: fork: Cannot allocate memory keine neuen Schreibvorgänge mehr annehmen. Ist save abgeschaltet, wird Redis vom OOM gekillt.

Die Lösung besteht also darin, maxmemory immer auf einen Wert zu begrenzen, z.B. auf 90% des physischen Hauptspeichers:

maxmemory 900M

Diese Einstellungen haben dagegen keinen Einfluss auf den Start der Key-Eviction:

maxmemory-policy allkeys-lru
maxmemory-samples 5
hz 10
save ...

Built on 2025-10-27