Seite wählen

NETWAYS Blog

Redis Eviction Policies

After install Redis you don’t have any settings configured to control memory consumption. In Production this brings OOM to the arena which leads into a broken applications.

First thingy what users do is to configure MaxMemory config setting (like me of course ;-)). In combination with a noeviction policy (which is also the default) the documentation says:

[…] return errors when the memory limit was reached and the client is trying to execute commands that could result in more memory to be used (most write commands, but DEL and a few more exceptions).

The bad news is, you’ll have a broken application again. Most web apps just use Redis as an uncontrolled cache data sink and left over to you how to handle it. For 99.9% of the use-cases you just need to configure a cache policy, or in Redis-speech, an Eviction Policy, which means:

maxmemory 128mb
maxmemory-policy allkeys-lru
maxmemory-samples 10

1. You allow roughly 128MB of memory for Redis
2. Redis tries to remove the less recently used (LRU) keys first
3. Because LRU is not a exact LRU algo, you use 10 samples to help the algorithm to find the items

Try to explain by counters:

Icinga Redis Plugin Output:

Above is a icinga redis check plugin output. Which shows a roundabout memory use of 108% – which is more than the configured 128M 100% base.

Grafana Graph (Telegraf Redis Input Plugin)

Here is the config change made on the 02/04 down to 128M MaxMemory and the LRU Eviction Policy. The memory footprint stays the same. The change is more granular if you zoom in:

If the allkeys-lru does not work for you, give the documentation a try. There is a lot you can do to keep your applications up and running and make Redis a fluently easy dependency.

Marius Hein
Marius Hein
Head of IT Service Management

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.

Graphite vs. IOPS – experience exchange

Last year, Blerim told us how to benchmark a Graphite and now we want to share some experience on how to handle the emerging IOPS with its pro and contra. It is important to know that Graphite can store its metrics in 3 different ways (CACHE_WRITE_STRATEGY). Each one of them influences another system resource like CPU, RAM or IO. Let us start with an overview about each option and its function.

max

The cache will keep almost all the metrics in memory and only writes the one with the most datapoints. Sounds nice and helps a lot to reduce the general and random io. But this option should never be used without the WHISPER_AUTOFLUSH flag, because most of your metrics are only available in memory. Otherwise you have a high risk of losing your metrics in cases of unclean shutdown or system breaks.
The disadvantage here is that you need a strong CPU, because the cache must sort all the metrics. The required CPU usage increases with the amount of cached metrics and it is important to keep an eye on enough free capacity. Otherwise it will slow down the processing time for new metrics and dramatically reduce the rendering performance of the graphite-web app.

naive

This is the counterpart to the max option and writes the metrics randomly to the disk. It can be used if you need to save CPU power or have fast storage like solid state disk, but be aware that it generates a large amount of IOPS !

sorted

With this option the cache will sort all metrics according to the number of datapoints and write the list to the disk. It works similar to max, but writes all metrics, so the cache will not get to big. This helps to keep the CPU usage low while getting the benefit of caching the metrics in RAM.
All the mentioned options can be controlled with the MAX_UPDATES_PER_SECOND, but each one will be affected in its own way.

Summary

At the end, we made use of the sorted option and spread the workload to multiple cache instances. With this we reduced the amount of different metrics each cache has to process (consistent-hashing relay) and find the best solution in the mix of MAX_UPDATES_PER_SECOND per instance to the related IOPS and CPU/RAM usage. It may sound really low, but currently we are running 15 updates per second for each instance and could increase the in-memory-cache with a low CPU impact. So we have enough resources for fast rendering within graphite-web.
I hope this post can help you in understanding how the cache works and generates the IOPS and system requirements.

NETWAYS Web Services: Web Accelerator

NETWAYS Web AcceleratorBeim Onlinehandel zählt jede Sekunde (eigentlich sogar jede Hundertstelsekunde) – die Ladezeiten wirken sich 1:1 auf Ihren Umsatz aus. Daher sind moderne Cachingtechnologien für den Umsatzerfolg unabdingbar, allerdings hat nicht jeder Shopbetreiber kompletten Zugriff auf seine Infrastruktur oder möchte sich nicht mit den technischen Details auseinander setzen. Hier haben wir eine passende Lösung in unseren NETWAYS Web Services:
Der NWS Web Accelerator bietet einen schnellen Cache für die statischen Inhalte Ihrer Website, um die Ladezeit zu beschleunigen. NWS WebAccelerator reduziert die Ladezeit Ihrer Website um ein Vielfaches. Eine schnellere Ladezeit ermöglicht es Ihnen, Ihre -Absprungraten zu reduzieren und führt damit zu einer besseren Conversion Rate.

Das Setup ist in wenigen Minuten erledigt – alles, was man braucht, ist ein gültiges SSL-Zertifikat für Ihre Webseite und einen Redirect Ihrer Webseite. Darüber hinaus kann man eine eigene Wartungsseite hinterlegen, wenn z.B. Wartungsarbeiten an Ihrem Backend durchgeführt werden.
Wichtiger Hinweis: Alle Angebote bei den NETWAYS Web Services können Sie 30 Tage kostenfrei testen!

Martin Krodel
Martin Krodel
Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Graphite mit Icingadaten füttern

Sgraphite_ping4-rtaeit Icinga 2 wird Graphite über ein eigenes Feature, also direkt, unterstützt. Muss man bei Icinga 1 noch den Umweg über zusätzliche Tools, wie z.B. Graphios gehen, fällt das nun weg. Standardmäßig erwartet Icinga 2 den Carbon Cache Daemon auf dem selben System (localhost) an Port 2003, also über das Plaintext Protokoll. Davon abweichende Einstellungen können in der Konfigurationsdatei „/etc/icinga2/features-available/graphite.conf“ vorgenommen werden.
Zunächst zieht der Carbon Cache Daemon die Datei „storage-schemas.conf“ zur Speicherung bzw. Aggregation der Metriken heran, die Icinga 2 Dokumentation gibt hier für den Graphite Carbon Cache Writer bereits ein allgemein gültiges Schema vor:

[icinga_internals]
pattern = ^icinga\..*\.(max_check_attempts|reachable|current_attempt|execution_time|latency|state|state_type)
retentions = 5m:7d
[icinga_default]
pattern = ^icinga\.
retentions = 1m:2d,5m:10d,30m:90d,360m:4y

Damit die Verdichtung der Daten korrekt funktioniert, ist es wichtig das die angegebenen Werte mit den wirklichen Host- bzw. Servicecheckintervallen (check_interval) überstimmen. In diesem Beispiel müsste also das Intervall für Host- und Servicechecks auf eine Minute gesetzt sein. Gibt es Abweichungen davon, müssen hier entsprechend Einträge hinzugefügt bzw. abgeändert werden.
Ob die Einstellungen passen, lässt sich nach den ersten Prüfungen mit den mitgelieferten Whisper Scripts anhand der abgelegten Metriken relativ leicht überprüfen. Zuerst kontrollieren wir mit whisper-info ob die angegeben Werte korrekt übernommen wurden:

# whisper-info rta.wsp
maxRetention: 126144000
xFilesFactor: 0.5
aggregationMethod: average
fileSize: 191104
Archive 0
retention: 172800
secondsPerPoint: 60
points: 2880
size: 34560
offset: 64
Archive 1
retention: 864000
secondsPerPoint: 300
points: 2880
size: 34560
offset: 34624
Archive 2
retention: 7776000
secondsPerPoint: 1800
points: 4320
size: 51840
offset: 69184
Archive 3
retention: 126144000
secondsPerPoint: 21600
points: 5840
size: 70080
offset: 121024

Die angegebene retention im Archive 0 von 172800 Sekunden stimmt mit dem angegebenen Speicherintervall überein (2*24*60*60 für 2 Tage) und auch die secondsPerPoint wurden mit 60 (also 1m) richtig übernommen. Eine stichpunktartige Kontrolle der retention von Archive 2 für 90 Tage (also 90*24*60*60) zeigt, das auch hier die Werte stimmen.
So weit gut so gut, allerdings sollte man um wirklich sicher zu gehen auch noch einen Blick auf die gespeicherten Datenpunkte werfen. Das geschieht mit whisper-fetch, der Parameter pretty zeigt dabei menschenlesbare Zeitstempel an:

# whisper-fetch --pretty rta.wsp
...
Tue Jul 21 09:05:00 2015	0.000083
Tue Jul 21 09:06:00 2015	0.000072
Tue Jul 21 09:07:00 2015	0.000137
Tue Jul 21 09:08:00 2015	0.000093
Tue Jul 21 09:09:00 2015	0.000102

Wenn die Einstellungen korrekt sind, sollten hier wie im gezeigten Beispiel nach Möglichkeit keine leeren Datenpunkte (Eintrag: None) vorkommen, andernfalls muss hier nochmal nachgefasst werden.

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Graphing mit Graphite: NETWAYS Webinar

Graphite ist eine Open Source Graphing Lösung, welche sich aufgrund der Flexibilität und Skalierbarkeit auf Augenhöhe mit vergleichbaren Enterprise Lösungen befindet.
Morgen, den 06. November 2013 um 14:00 Uhr, werden wir diese in unserem Webinar vorstellen.
Hier werden wir unter anderem auf das Webinterface, die Handhabung sowie die Architektur eingehen. Die Registrierung erfolgt wie immer über unser Webinar-Center.
Anschließend findet sich in unserem Webinar-Archiv sowie auf unserem YouTube-Channel das Webinar-Video sowie die Präsentationsfolien.
Übrigens: Bereits nächste Woche, am 13. November um 14:00 Uhr, findet unser erstes Webinar zu Icinga 2 statt. Also jetzt jetzt noch schnell registrieren!
Wir freuen uns auf eine rege Teilnahme!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".