Linux – ich habe keinen RAM mehr

Da ich in den letzten Jahren immer wieder Diskussionen darum hatte, daß Linux den „gesamten“ RAM auffrisst, habe ich mir gedacht, da ich mein Wissen eh ins Blog schreiben wollte, wäre jetzt ein guter Zeitpunkt den Sachverhalt nochmal eindeutig in einem Artikel zu veröffentlichen.

Worum geht es ?

Ich mach das Problem am sinnvollsten an einem Bild deutlich:

Das ist einer meiner Linux Server, der laut top unschwer behauptet 12.414 GB RAM von 32 GB RAM zu verwenden.
Da nur ein paar kleinere Java-Applikationen und ein DB-Server auf der Büchse laufen, sieht das natürlich erstmal imposant aus.

Wow, die eine JAVA-App zieht 12GB virtuell – das ist übrigens mein BitBucket (6GB) mit ElasticSearch (6GB) – MySql zieht auch schon 3GB RAM.

Aber halt, ist das wirklich so ?

Schauen wir uns doch einfach mal den Prozess 10676 an, der angeblich 6706,7MB verbrät.
– Sorry, daß werden jetzt knappe 1000 Zeilen 🙂 –

Also laut pmap verbraucht dieser Java-Prozess tatsächlich nur ca. 1,6 GB RAM und keine 6,8GB.

Was zeigt denn also top da bei VIRT an ?
Das ist schlicht alles, was die Applikation gerade im Zugriff hat, also Files und RAM.
Wie man am pmap sehr schön sehen kann, hat die eine JVM tatsächlich irgendwo knappe 6 GB insgesamt im Zugriff, also Logfiles, Klassen und halt auch nebenbei noch RAM (1,5GB).

Warum sagt mir mein Top, daß ich 12GB von 32GB RAM gerade verbrauche ?

Hier kommt Linux ins Spiel. Schauen wir uns einfach einmal an, was da in dem Bildchen unter „cached Mem“ steht, kommen wir der Sache auf die Spur

Laut top haben wir also 7,5GB an „cached Mem“.

Machen wir mal die Gegenkontrolle mit free

Und wie man bei free sehr schön sehen kann, haben wir in der Zeile „-/+ buffers/cache“ unter „free“ auf einmal 26GB RAM stehen.
Meine laufenden Applikationen ziehen also tatsächlich nur irgendwas um 6GB RAM, inklusive OS.

Aber was ist das denn nun mit dem „cached Mem“ ?

Linux nimmt sich die Freiheit für schnellere Zugriffe auf Files diese schlicht im RAM zu cachen.
Damit also das Linux auf meinem Server den Zugriff auf die physikalischen Festplatten so gering wie möglich halten kann, cached es halt die Dateien, die oft im Zugriff sind, schlicht im RAM.

Und wenn meine Apps jetzt mehr tatsächlichen RAM brauchen ?

Die Frage ist recht simpel zu beantworten: in dem Moment, wo der tatsächliche RAM-Bedarf seitens der installierten Applikationen höher wird, wird der cached-Memory automatisch vom OS wieder freigegeben an die Applikationen.
Wenn man nun recht langsame Festplatten in seinem System hat, könnte daß ein Moment sein, wo man auf einmal Leistungseinbrüche auf dem System feststellen kann.

 

Fazit

Wenn ihr meint, daß Euer Speicher vom Linux „aufgefressen wird“ schaut einfach mit free nach, was in der Zeile „-/+ buffers/cache“ unter „free“ steht, dann wisst Ihr, was Ihr noch an Reserven habt. 🙂

 

 

Debian und Initscripte

Unter Debian gibt es für init Scripte eigentlich eine recht gute Vorlage, die man unter /etc/init.d/skeleton findet.

OK, war ein Scherz 🙂
Die Vorlage ist mehr als rudimentär und nicht wirklich nutzbar.

Da ich auch kleinere Webservices/Server geschrieben habe, die irgendwo laufen, hab ich mir mal ein simples init-Script geschrieben, daß ich nun überall unter Debian/Ubuntu nutze.

Simpel deswegen, weil ich nur ein paar Zeilen anpassen muß, damit ich das für jedes Projekt verwenden kann.

Das Script baut auf dem LSBInit-Framework auf.

Hier einfach ein Beispiel für meinen GPRS-Server, Scriptname gprsserver, der ein laufendes mysql benötigt:

Sieht zwar kompliziert aus, ist es aber nicht wirklich.
Alles was man einstellen muß, hört mit dem „END OF CONFIG-SECTION“ auf.

Das fertig angepasste Script, gefolgt von einem chmod 755, kopiert man dann einfach nach /etc/init.d/gprrserver

Anschließend teilt man dem System noch über ein

mit, das es bitte in /etc/rcX.d die entsprechenden Links setzen möge.

Was tun bei DoS/DDoS-Angriffen ?

Ich beobachte nebenbei gerne die neuesten Entwicklungen im Bereich DDoS (DistributedDenialofService).

NEIN, nicht weil ich es selbst nutzen möchte, sondern schlicht um Kunden besser schützen zu können.

In den letzten Tagen hatte schon Akamai die Segel gestrichen, als ein illustrer Traffic von 620GBit/s das Blog von Brian Krebs lahmlegte (übrigens eine mehr als imposante Zugriffsrate für ein Blog 🙂 ).
Heute lese ich nun auf Heise, daß der französische Hoster OVH von einem DDoS mit 1,1TB/s minimal überrascht wurde.

Das sind mal UpStream-Raten 🙂

Und nu ?

Da nun nicht jeder Webseitenbetreiber von einem DDoS in diesen Außmaßen getroffen wird, empfiehlt es sich zum Beispiel beim Apache httpd etwas wie mod_evasive einzusetzen.
Es wird ganz sicher nicht dem Anfangs genannten Traffic von 620GB/1,1TB standhalten – da ist der Speicher schneller voll, als man Papp sagen kann – aber es hilft doch gegen Script-Kids und wirklich einfach gestrickte DoS/DDoS-Versuche.

Zusätzlich könnte man natürlich auch noch eine Strategie wählen die ich in diesem Beitrag beschrieben hatte und diese Methode auf Port 80 ausdehnen.

 

Toll 🙁

Ich werde mal am Wochenende versuchen einen etwas detaillierten Beitrag zu mod_evasive zu schreiben 🙂

Welche Gegenmaßnahmen man sonst noch treffen kann, darf ich, nach gründlicher rechtlicher Recherche, hier leider nicht posten 🙁

Jenkins Slave-Nutzung

Sofern man sich beim Jenkins für die Skalierung mittels Build-Slaves entschieden hat, läuft man zwangsläufig in eines der Jenkins Grundprobleme:
Man hat zwar nun mehere Build-Slaves, die Jobs werden aber nach wie vor nach dem Jenkins Prinzip auf dem entsprechenden Node gestartet.

Was meine ich nun mit Jenkins-Prinzip ?
Jenkins startet grundsätzlich den auszuführenden Job IMMER dort, wo er zuletzt ausgeführt wurde.

Wenn also alle meine Jobs bisher auf dem Master ausgeführt wurden, werden sie auch weiterhin dort ausgeführt, was dann den Aufbau von Build-Slaves ad Absurdum führt 🙁

Die Lösung

Es gibt ein sehr zu empfehlendes Plugin für Jenkins: Scoring Load Balancer

Das Plugin überschreibt das Standardverhalten vom Jenkins und entscheidet anhand von Konfigurationen, wie die Last auf die Knoten verteilt werden soll.

Es gibt bei diesem Plugin diverse Möglichkeiten die Last gewichtet zu verteilen, allerdings ist meine präferierte Einstellung bei diesem Plugin das „Scoring by Node Loads“.

Hier wird im Endeffekt für jeden Build-Knoten zunächst ein Wert „Scale for Scores“ definiert.
Jeder „Freie Build-Executor“ erhält nun noch einen inkrementellen Wert und jeder „Belegte Build-Executor“ einen dekrementellen Wert.

Um zu verdeutlichen, wie das Ganze nun funktioniert, nehmen wir einfach mal folgende Jenkins-Knoten-Konfiguration an:

Knoten Anzahl Build-Prozessoren Knoten Score
Master 30 300 (30*(1*10))
Slave 1 30 300 (30*(1*10))

Wird jetzt auf dem Master ein Job ausgeführt, sinkt der Knoten Score auf 290, da ja ein Build-Prozessor belegt ist.
Wird nun während des laufenden Builds auf dem Master ein weiterer Build angestoßen, sucht das Plugin nun nach dem Knoten, der den höchsten verfügbaren Knoten-Score hat. In diesem Fall wäre das dann der theoretische Knoten Slave 1.

Das Plugin bietet des Weiteren diverse Kombinationsmöglichkeiten von Gewichtigungsvarianten, allerdings bin ich bisher mit dieser einfachen Konfiguration am besten gefahren. 🙂

Ein Lockfile im Shell-Script

Gute Vorschläge und Ideen um Lock-Files in einem Shell-Script zu verwenden, gibt es wie Sand am Meer.

Es gehen – mittlerweile seit Jahren – tiefgreifenden Diskussionen einher, welche Variante nun die Sicherste ist und welche Scripts Race-Conditions haben.

Meine persönliche Variante, die sicherlich nicht im Millisekunden-Bereich stabil ist, ist die folgende:

Über die erste Zeile hole ich mir einen Lockfilenamen in /tmp der den Namen des Scripts+“.lock“ hat.

Das kill -0 prüft schlicht, ob der Prozess der das „Lock“ hat, auch tatsächlich noch läuft.

Trap sichert noch ab, daß, außer bei einem kill -9, das Lockfile auch gelöscht wird 🙂

Jenkins

Da ich in der Vergangenheit Jenkins bei vielen Kunden aufgebaut und/oder erweitert habe, zudem Plugin-Maintainer bin, werde ich jetzt hier auf dem Blog in Zukuft einfach mal eine Serie mit Tips- und Tricks zu Jenkins veröffentlichen 🙂

Die Artikel werden etwas chaotisch veröffentlicht, je nachdem wieviel Zeit ich habe, aber zum Schluß wird es für diverse Bereiche nochmals eine Zusammenfassung nach Themengebieten geben.

Bei Anregungen/Wünschen: einfach hier einen Kommentar hinterlassen 🙂

px3