Neu SWAP Speicher beim Webhoster läuft plötzlich laufend über

[Buinger]

Wir benutzen noch den JTL- Shop 4 und der ist all die Jahre gut gelaufen. Seit kurzen läuft plötzlich der SWAP-Speicher bei unserem Webhoster laufend über und im Webshop selber gibt es REDIS Fehlermeldungen, so dass man keine Produkte mehr in den Warenkorb legen kann.

Am System und in unserer Büroumgebung selber wurde nichts verändert (außer vielleicht, dass wir auf die WaWi 1.7 geupdatet haben).

Woran könnten diese Probleme liegen?

Vielen Dank.

 

[css-umsetzung]

Dann hat er vermutlich Redis falsch konfiguriert.

 

[mh1]

Seit kurzen läuft plötzlich der SWAP-Speicher bei unserem Webhoster laufend über und im Webshop selber gibt es REDIS Fehlermeldungen, ...

Weißt du denn mit Sicherheit, dass der Swap Speicher das Problem verursacht? Woher?
Du schreibst ja auch von Redis Fehlermeldungen.

Hat den vielleicht der Webhoster euren Shop auf ein neues System mit jetzt weniger RAM umgezogen? Weil Redis könnte ja abhängig von der Konfiguration in den Swap schreiben, weil er keinen freien RAM mehr findet. Wie auch immer würde ich auf jeden Fall erstmal den Redis Fehlermeldungen auf den Grund gehen. Vermutlich hat da mein Vorredner bereits das richtige geschrieben, nämlich das Redis falsch konfiguriert wurde.

 

[css-umsetzung]

So wird es bestimmt auch sein,
Redis kann so konfiguriert werden, das man zum einen die max. Menge angibt und zum anderem, was passieren soll wenn die Menge erreicht wurde.

Das was du schreibst liest sich so, als ob da ein Fehler in der Behandlung des erreichen des Max. Wertes gemacht wurde

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#
# volatile-lru -> Evict using approximated LRU among the keys with an expire set.
# allkeys-lru -> Evict any key using approximated LRU.
# volatile-lfu -> Evict using approximated LFU among the keys with an expire set.
# allkeys-lfu -> Evict any key using approximated LFU.
# volatile-random -> Remove a random key among the ones with an expire set.
# allkeys-random -> Remove a random key, any key.
# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
# noeviction -> Don't evict anything, just return an error on write operations.
#
# LRU means Least Recently Used
# LFU means Least Frequently Used
#
# Both LRU, LFU and volatile-ttl are implemented using approximated
# randomized algorithms.
#
# Note: with any of the above policies, Redis will return an error on write
#       operations, when there are no suitable keys for eviction.
#
#       At the date of writing these commands are: set setnx setex append
#       incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
#       sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
#       zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
#       getset mset msetnx exec sort
#

Eventuell steht es auf "noeviction" aber von außen, ohne eine genaue Fehlermeldung zu sehen ist das eher raten als wissen.

 

[Buinger]

Wir haben Plesk als Benutzeroberfläche für den Webserver, laut Dokumentation ist Redis von dort gar nicht konfigurierbar.

Wie das immer so ist, wenn was jahrelang funktioniert hat und dann plötzlich nicht mehr stellt sich halt immer die Frage was ist jetzt anders.

@mh1 - in den Serverinformationen im Plesk ist die Serverauslastung bei 99,71%. Die RAM Auslastung ist weniger als 50%, ein Umzug hat nicht statt gefunden.

 

[css-umsetzung]

Redis wird auf cem Server konfiguriert.
Ob Redis im Shop genutzt wird lässt sich in den cache Einstellungen des Shops leicht erkennen, einfach mal das dropdown Feld auswählen und schauen ob redis wirklich auswählbar ist.

Mit all deinen Informationen hier ist keine Hilfe möglich, dass ist einfach zu wenig.

 

[Buinger]

Redis wird auf cem Server konfiguriert.
Ob Redis im Shop genutzt wird lässt sich in den cache Einstellungen des Shops leicht erkennen, einfach mal das dropdown Feld auswählen und schauen ob redis wirklich auswählbar ist.

Mit all deinen Informationen hier ist keine Hilfe möglich, dass ist einfach zu wenig.

Welche Infos brauchst Du noch? Ich habe mal einen Screenshot angehängt wie es im Backend vom Shop aussieht (auf dem Bild ist der Cache im Moment deaktiviert, das war zu Testzwecken, alle anderen Einstellungen sind unverändert).

Serverseitig haben wir keinerlei Zugriff auf Redis. Unser Webhoster hatte in einer Email folgendes dazu geschrieben (fett markiert, das war einer der Redis Fehlermeldungen, als der Shop plötzlich anfing Fehlermeldungen auszuspucken). Kunden konnten dann z.B. keine Artikel mehr in den Warenkorb legen.


außer der einen Änderung vor einer Woche von mir bzgl. "Received invalid response: Redis exception: MISCONF Redis is configured to save RDB snapshots" wurden von uns keine Anpassung am Redis gemacht. Das Redis soweit eigentlich den Standardeinstellungen.

Auf "noeviction" stand es und ich hatte das bereits vor einer Woche abgeändert.

Vorher
[root@vs-96 ~]# redis-cli info | egrep --color "(role|used_memory_peak|maxmemory|evicted_keys|uptime_in_days|maxmemory-policy)"
uptime_in_days:0
used_memory_peak:8009119424
used_memory_peak_human:7.46G
used_memory_peak_perc:16.63%
maxmemory:8000000000
maxmemory_human:7.45G
maxmemory_policy:noeviction
evicted_keys:0
role:master

Nacher
[root@vs-96 ~]# redis-cli info | egrep --color "(role|used_memory_peak|maxmemory|evicted_keys|uptime_in_days|maxmemory-policy)"
uptime_in_days:0
used_memory_peak:1434945280
used_memory_peak_human:1.34G
used_memory_peak_perc:100.00%
maxmemory:8000000000
maxmemory_human:7.45G
maxmemory_policy:allkeys-lru
evicted_keys:0
role:master

 

[css-umsetzung]

Welche Infos brauchst Du noch? Ich habe mal einen Screenshot angehängt wie es im Backend vom Shop aussieht (auf dem Bild ist der Cache im Moment deaktiviert, das war zu Testzwecken, alle anderen Einstellungen sind unverändert).

Ich sehe kein Bild?

das Problem ist, das dir eigentlich nur der Serverbetreiber sagen kann was mit dem Server los ist, wenn du da selbst keinen Zugriff drauf hast, wundert mich aber auch weil du ja schreibst das du selbst die Redis Config geändert hast?
Ich hätte eher volatile-ttl genommen.

Wenn der Cache derzeit deaktiviert ist, dann ist der Shop von sich aus schon extrem langsam, das sollte zuerst wieder aktiviert werden.
Und dann solltest du da mal jemanden draufschauen lassen der weiß wie er so ein Problem angeht wenn der Server Hoster dir nicht sagen kann was da so eine Last verursacht.

Wir wissen nicht:

1. Um welche Menge an Artikel es geht
2. wie gut der Server überhaupt ist
3. was du für Plugins am laufen hast
4. wie die Besucherzahlen sind oder ob du gerade ein Bad Bot Problem hast (auch dann kann der cache ganz schnell eine Krise bekommen)
5. wie die Datenbank aussieht
6. usw.

Das sind nur einige Punkte, die sich in einem Forum nicht klären lassen und wo einer direkt draufschauen muss um das System nach und nach auseinanderzunehmen.
Der erste Ansprechpartner wäre aber der Server Hoster da der genau schauen kann was da Ressourcen frisst.

Ich bin ganz ehrlich, ich würde meine Zeit jetzt nicht damit verbringen, hier im Forum auf einen Hilfreichen Beitrag zu hoffen sondern direkt aktiv werden und dem Server Hoster auf die Füße treten bzw. den JTL Support oder einen SP beauftragen zu schauen was da nicht passt.



Ich hab deinen Shop gerade aufgerufen, nur die Umschaltung von http: auf https hat gefühlt schon fast eine Minute gedauert.

 

[Buinger]

Ich sehe kein Bild?

das Problem ist, das dir eigentlich nur der Serverbetreiber sagen kann was mit dem Server los ist, wenn du da selbst keinen Zugriff drauf hast, wundert mich aber auch weil du ja schreibst das du selbst die Redis Config geändert hast?
Ich hätte eher volatile-ttl genommen.

Wenn der Cache derzeit deaktiviert ist, dann ist der Shop von sich aus schon extrem langsam, das sollte zuerst wieder aktiviert werden.
Und dann solltest du da mal jemanden draufschauen lassen der weiß wie er so ein Problem angeht wenn der Server Hoster dir nicht sagen kann was da so eine Last verursacht.

Wir wissen nicht:

1. Um welche Menge an Artikel es geht
2. wie gut der Server überhaupt ist
3. was du für Plugins am laufen hast
4. wie die Besucherzahlen sind oder ob du gerade ein Bad Bot Problem hast (auch dann kann der cache ganz schnell eine Krise bekommen)
5. wie die Datenbank aussieht
6. usw.

Das sind nur einige Punkte, die sich in einem Forum nicht klären lassen und wo einer direkt draufschauen muss um das System nach und nach auseinanderzunehmen.
Der erste Ansprechpartner wäre aber der Server Hoster da der genau schauen kann was da Ressourcen frisst.

Ich bin ganz ehrlich, ich würde meine Zeit jetzt nicht damit verbringen, hier im Forum auf einen Hilfreichen Beitrag zu hoffen sondern direkt aktiv werden und dem Server Hoster auf die Füße treten bzw. den JTL Support oder einen SP beauftragen zu schauen was da nicht passt.



Ich hab deinen Shop gerade aufgerufen, nur die Umschaltung von http: auf https hat gefühlt schon fast eine Minute gedauert.

Hier ist der Screenshot und auch mal die Info wie der Server aussieht. Swap is nun bei 100%. Cache ist wieder an.

Momentan Kunden: 47, Gäste: 665, Insgesamt: 712. Wir haben ca. 20.000 Artikel. Plugins siehe Screenshot. Was die Datenbank angeht, was möchtest Du da wissen?

Und ja, wir hatten es direkt unserem Webhoster gemeldet, daher stammte ja auch die Antwort aus dem vorherigen Post, aber ich habe so das Gefühl, dass die auch nicht wissen was da plötzlich los ist.

 

[css-umsetzung]

1130 Tage Betriebszeit ist ja recht sportlich
8GB RAM für einen Webserver auch, das war Anno Leipzig mal ausreichend.
In Verbindung mit Redis sollte vm.swappiness eigentlich auf 0 stehen, was bedeutet das die Auslagerungsdatei nur verwendet wird wenn es nicht mehr anders geht.
Der Cache ist laut Screenshot noch immer deaktiviert, so wirst du in Sachen Performance keinen Blumentopf gewinnen.

Also nochmals, das bringt dir so nichts und vergeudet nur unnötige Zeit die du nicht hast, da die Verkäufe durch die langen Wartezeiten vermutlich rückgängig sind.
Das muss jemand direkt im Shop und auf dem Server anschauen.

Was mich wundert, wenn du diese Ansicht da hast, dann hast du doch nicht nur ein Webhosting sondern ein Serverhosting oder wie, dann kommst du selbst auch in die Shell vom Server?

 

[mh1]

Ich schließe mich dem Ratschlag von @css-umsetzung an: Das Problem muss direkt am Server bearbeitet werden (z.B. auch um in Echtzeit zu sehen was/wie Last verursacht).

Aber auch...

...
Nacher
[root@vs-96 ~]# redis-cli info | egrep --color "(role|used_memory_peak|maxmemory|evicted_keys|uptime_in_days|maxmemory-policy)"
uptime_in_days:0
used_memory_peak:1434945280
used_memory_peak_human:1.34G
used_memory_peak_perc:100.00%
maxmemory:8000000000
maxmemory_human:7.45G
maxmemory_policy:allkeys-lru
evicted_keys:0
role:master

ein Server mit rund 8 GB RAM??? - und dann gibst du Redis rund 8GB RAM.... mmmh - das zwingt den Server ja in den Swap

 

[Buinger]

Ich schließe mich dem Ratschlag von @css-umsetzung an: Das Problem muss direkt am Server bearbeitet werden (z.B. auch um in Echtzeit zu sehen was/wie Last verursacht).

Aber auch...

ein Server mit rund 8 GB RAM??? - und dann gibst du Redis rund 8GB RAM.... mmmh - das zwingt den Server ja in den Swap

Ich habe das noch mal alles an unseren Webhoster weiter gegeben, allen vielen Dank.

Der Speicher ist übrigens nie hoch ausgelastet (siehe Screenshot), das sollte doch dann nicht der Grund sein?!

Die meiste Zeit gestern war die Speicherauslastung unter 50%.

 

[mh1]

Ich habe das noch mal alles an unseren Webhoster weiter gegeben, allen vielen Dank.

Der Speicher ist übrigens nie hoch ausgelastet (siehe Screenshot), das sollte doch dann nicht der Grund sein?!

Ich weiß nicht genau, welche Werte Plesk hier anzeigt. Ich bin mit solchen Panels nicht vertraut.

Aber mal angenommen es ist so, wie der Screenshot sagt, dass 2.4 GB verfügbar sind, dann wäre es spannend zu untesuchen, warum CentOS es für eine gute Idee hält, den Swap zu 100% auszulasten.
Aber das ist wie gesagt nur direkt auf dem System ersichtlich.

Und bei einer Prüfung des Systems nicht vorschnell auf einen Schuldigenn festlegen (also nicht zwingend den Fehler in der Redis Konfiguration suchen - es kann ja auch der PHP-Prozess heißlaufen, oder Apache ist falsch konfiguriert, oder Maria oder oder...)

 

[css-umsetzung]

Aber mal angenommen es ist so, wie der Screenshot sagt, dass 2.4 GB verfügbar sind, dann wäre es spannend zu untesuchen, warum CentOS es für eine gute Idee hält, den Swap zu 100% auszulasten.
Aber das ist wie gesagt nur direkt auf dem System ersichtlich.

Dafür kann die Einstellung vm.swappiness verantwortlich sein, je höher der Wert umso eher wird die Auslagerungsdatei in Anspruch genommen.
Das wäre also zuerst zu prüfen.