Debain Buster kommt voraussichtlich am 6.7.2019

  • Meine Debian Systeme swappen seit dem Update auf Version 10 wie verrückt. Bei nichtmal ganz 2 von 8GB Auslastung hat mein einer Server eben 700MB geswappt, und das bei Swappiness 5. Bei meinem NAS ähnlich. Nur mein kleiner Server mit Swappiness 60 swappt nicht (da ungefähr 0,3 von 2GB belegt). Sehr komisch.


    Hat das auch jemand von euch beobachtet?

    Gestern auch von 9.9 auf 10 upgedated.

    Hat in der Nacht auch plötzlich angefangen zu swappen (swappiness ist auf 1).

    Hab heute früh mal den swap "geleert". Bisher Ruhe. Mal sehen ob es so bleibt.

  • Gestern auch von 9.9 auf 10 upgedated.

    Hat in der Nacht auch plötzlich angefangen zu swappen (swappiness ist auf 1).

    Hab heute früh mal den swap "geleert". Bisher Ruhe. Mal sehen ob es so bleibt.

    Das ist unnormal. Nach dem Buster Update am Sonntag ging meine RAM Nutzung erstmal ordentlich runter, und dann etwas später fing er mit diesem übelsten Swappen an... man sieht auch, dass ich heute mal ein swappoff -a && swapon -a gemacht habe, aber wie man sieht ohne viel Erfolg.

    swap_mem.png

  • bei Debian Buster gibt es kein OpenJDK 8 mehr.

    Haben bei einigen Projekten Elasticsearch im Einsatz, welches wir aktuell nicht Updaten können.


    gibt aber 2 Alternativen ohne Lizenz Probleme

    Code
    1. https://aws.amazon.com/de/corretto/
    2. https://adoptopenjdk.net/

    OpenJDK 8 hat Support bis "October 2020"
    Amazon Corretto 8 bis "June 2023"

    Wenn ich das richtig sehe, gibt es aber openjdk-11. Ist das nicht kompatibel?

  • Das ist unnormal. Nach dem Buster Update am Sonntag ging meine RAM Nutzung erstmal ordentlich runter, und dann etwas später fing er mit diesem übelsten Swappen an... man sieht auch, dass ich heute mal ein swappoff -a && swapon -a gemacht habe, aber wie man sieht ohne viel Erfolg.

    swap_mem.png

    Langsam gipfelt das hier in Realsatire. Weil mir das ganze auf den Keks ging, habe ich die swappiness auf meinem NAS auf 0 gesetzt und danach nochmal swapoff -a && swapon -a gemacht. Der Swap war an dieser Stelle auch leer, habe ich überprüft.

    Eine paar gzip Kompressionen später und nach noch ein paar anderen Sachen, kam ich dann an folgender Situation raus:

    swap_realsatire.png


    Sorry, aber das widerspricht in meinen Augen jeglicher Logik... das kann doch nur ein Bug sein. :/

  • Was liegt denn nun im Swap? So ist das nur ein Rätselraten ohne Chance.


    Von allem ein bisschen, würde ich sagen.... :/

    swap.py

  • Es ist okay, wenn ein System 190MB swappt obwohl es nicht swappen darf und noch mehr als genug RAM zur Verfügung steht. Gesundheit? ?(


    Ähm wie bitte?


    Du postet einen Screenshot wo knapp 100MB RAM frei sind. Wieso ist das mehr als genug?

    Woran machst du fest, dass das System nicht mehr swappen darf?


    bitte einmal lesen: -https://news.ycombinator.com/item?id=7940847

    - https://www.kernel.org/doc/Documentation/sysctl/vm.txt -> swappiness


    Und bitte einmal einen Graphen über Swap In/Out posten.


    Dein System lagert unbenutzt Teil-Bereiche von Prozessen aus um mehr Filesystem-Cache zu haben. Da swappt nichts kontinuierlich, der Graph wird konstant bei 0MB/s hängen.

  • Moment mal. Ja, es sind nur etwas über 100MB frei, aber zur Verfügung steht doch wesentlich mehr.

    Aber es kann doch nicht sein, dass laufende Programme auslagern, um Platz für den Cache zu machen. Oder doch?

    Systeme sollten meines Wissens nur im absoluten Notfall swappen, zumal sich da ja dann auch die SSD und die allgemeine Performance bedankt...


    Und um den Zeitpunkt vom Eintritt des swappens zu setzen, konfiguriert man die swappiness. Und hier steht geschrieben, dass bei einer swappiness von 0 das Swappen deaktiviert ist. Logisch, denn es ist ja der prozentuale Wert des verfügbaren RAMs. Und 0 würde dann heißen, geh bis ans Limit.

    Selbst wenn man die Swappiness am freien RAM und nicht am verfügbaren RAM ansetzen würde, dann würde es zwar erklären, warum er swappt, aber dann wäre das ganze in meinen Augen sinnentstellt, denn es wird i.d.R. ja immer soviel in den RAM Cache gepackt, wie möglich. Und dann würde er ja immer swappen.


    Swap I/O habe ich leider nicht in meinem Monitoring drin, aber das überarbeite ich allgemein gerade.

    Es ist schon richtig, dass die Prozessteile primär ungenutzt sind und ich schätze mal, dass der besagte I/O auch nicht groß ist. Aber Fakt ist, dass das bisher unter Stretch so nicht passiert ist, und wenn man dann so einen Prozessteil benötigt, dann wird die Sache halt auch schnell mal ganz schön träge...


    Ich kann deinen Denkansatz verstehen, aber warum trat dieses verhalten dann unter Stretch nicht auf? Immerhin waren manche Prozesse da genauso ungenutzt, daran hat sich nichts geändert...