Swapping obwohl noch RAM Frei

[reox]

Kann es sein das es dies Verhalten ein Kernelbug ist oder ob das irgendwoanders her kommt? Also folgendes passiert in letzter Zeit häufig an unserem Server:

Irgendein Cronjob (oder sonst was, mir scheint cronjob da fast immer zur gleichen zeit) kommt daher, der von der Platte lesen muss und ein bissi RAM braucht. Der RAM ist net mal zu 1/3 ausgelastet, trotzdem wird fast alles in den Swap geschrieben. Die Load geht dann in ungeahnte Höhen, also Load 100 ist da fast immer drin. Im Collectd sehe ich das vorher im RAM 4G Cached, 200M buffered und 2G used sind. Dann plötzlich ist swap-cached von 400 auf 900M und swap-used geht auf 1,4G von ehemals 400m. Im RAM ist dann nichts mehr cached oder buffered, used wird in gleichem maße in den swap geschrieben. Die Swapin phase dauert dann etwa 10min, dass heißt hier ist der server prinzipiell mal nicht erreichbar oder nur sehr schwer... Dann rennt halt der cron und dann beginnt das swapout. Das geht zwar mit vieel weniger load ist aber auch zach...

Wir verwenden OpenVZ und haben jetzt da schon die memory limits mega getweaked... Unsere Utlilization ist jetzt unter 1, genso wie das commitment level (Wir haben 8GB RAM und 8GB Swap) - es sollte sich also alles bei uns im RAM ausgehen ohne das er swappen muss, er sollte net mal dran denken zu swappen eigentlich!
Kernel ist 2.6.32-5-openvz-amd64

Was kann das sein? OpenVZ Mailinglist sagt nur das kann passieren wenn wir keinen PAE Kernel verwenden, aber wir haben ja eh x86_64. Anbei noch die graphen zum angucken... (leider bricht er irgendwann ab weil ein zu eifriger sysadmin aus unserem team den server gleich mal neugestartet hat obwohl ich ne mail geschrieben hab das er ihn laufen lassen soll -.-)

-> Graphen:

Als Temporären Workarround könnte ich alle cronjobs abdrehen... haben wir teilweise eh schon gemacht...

[rendegast]

Da wird wohl eine(mehrere) große Datei(en) eingelesen.
Eine Datei befindet sich entweder im swap oder im cache, nicht teilweise.
Daher diese sprungartigen Wechsel.

Versuche das mit 2 der tmpfs (per default jeweils bis 1/2 RAM anwachsend):

Code: Alles auswählen

$ mount | grep tmpfs
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
varrun on /var/run type tmpfs (rw,nosuid,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /tmp type tmpfs (rw,mode=1777)
tmpfs on /etc/network/run type tmpfs (rw,size=1%)

(Ein tmpfs resp. deren Dateien machen sich als cache bemerkbar,
daher kann es in diesem Fall dem cache äquivalent betrachtet werden.)
Beschreibe ein tmpfs mit dd (cache wird nicht ändern, der "wirkliche" Inhalt wird entsorgt),
der RAM-Verbrauch liegt dann bei nahezu 100%.
Wird das bei einem zweiten tmpfs wiederholt, so wird nur direkt ein Schreibvorgang in den swap einsetzen.

Werden danach die tmpfs-Testdateien gelöscht, wird auch der cache als leer angezeigt.

Wir haben 8GB RAM und 8GB Swap) - es sollte sich also alles bei uns im RAM ausgehen ohne das er swappen muss, er sollte net mal dran denken zu swappen eigentlich!

Wenn zBsp. ein Sicherungsvorgang oben erwägte große Dateien abarbeitet,
wäre das Szenario gut denkbar.

Code: Alles auswählen

$ echo $(( 8000 / (10*60)  ))
13

Würde auf ein langsames Schreiben/Lesen passen.
(mindestens halbierte Rate durch den swap)

Irgendein Cronjob (oder sonst was, mir scheint cronjob da fast immer zur gleichen zeit)

Die sollten einem Admin bekannt sein.
10min Zeitfenster, -> '[h]top', 'df -m', 'lsof', 'iotop' usw.?
(Einen Kernel entpacken und kompilieren verbraucht mit debug-Symbolen ~2GB.
Vielleicht macht sich einer der User einen Spaß damit, das auf Images im tmpfs
für mehrere Kernel gleichzeitig durchzuführen
weil das so schön schnell geht. Die hohe Load würde auch zu so etwas passen.)

[Gunman1982]

Ihr könntet auch versuchen die swappiness auf 0 zu setzen, sofern ich mich da nicht irre sollte der Swapper dann erst versuchen den Cache (wenn nicht benutzt) wieder zu verwenden bevor er anfängt da zeugs raus zu swappen.

[reox]

Also wenn ich dich richtig verstehe versucht irgendwas in ein tmpfs zu schreiben und braucht dafür eben ur viel Cache? Ergo müssten wir das abschalten und es sollte normal gehen? Was nur tun wenn das benötigt wird?

Die Cronjobs wissen wir eh welche rennen, Um 9 und 39 rennt der php garbage collector, das würde zeitlich passen! Es sollte aber eigentlich kein großes file lesen oder schreiben müssen! Es macht ja nur einen find auf den session ordner, das braucht zwar auch einiges an load nur ich gehe nicht davon aus das es das problem ist. Wir müssen nochmal in allen VZs nach crons suchen die da irgendwo rennen... das ist halt rel. schwer wenn da 20 container rennen...

@Gunman1982: Wir haben vm.swappiness derzeit = 1

[rendegast]

Um 9 und 39 rennt der php garbage collector, das würde zeitlich passen! Es sollte aber eigentlich kein großes file lesen oder schreiben müssen! Es macht ja nur einen find auf den session ordner, das braucht zwar auch einiges an load nur ich gehe nicht davon aus das es das problem ist.

Zum Vergleich: locate-Datenbank, zBsp. /var/lib/mlocate/mlocate.db, löschen und 'updatedb'.

Wir müssen nochmal in allen VZs nach crons suchen die da irgendwo rennen... das ist halt rel. schwer wenn da 20 container rennen...

Leg den gc auf 09:19? 08:15? 11:11?
EDIT Jedoch läuft der gc per default doch alle halbe Stunde? Sorry!
Vielleicht ein Angriff in der default-Laufzeit des Skriptes?

[reox]

locate hab ich gestern nacht runtergeschmissen

ja ich kanns probieren, es ist nur net jedes mal, zB sind 90% der gc aufrufe unproblematisch und die load geht nicht spürbar hoch...

[rendegast]

es ist nur net jedes mal, zB sind 90% der gc aufrufe unproblematisch und die load geht nicht spürbar hoch...

Vielleicht ein gelegentlicher, aber gezielter Angriff in der debian-default-Laufzeit 09:39 des Skriptes?
Sowas wie eine script-Angriff auf root-Login des ssh:22?

Vielleicht läuft das gc nicht nur in den session-dirs,
sondern durch Fehlkonfiguration über die gesamte Maschine und verhaspelt sich dabei?

locate hab ich gestern nacht runtergeschmissen

Code: Alles auswählen

# strings /var/lib/mlocate/mlocate.db | wc -l
977163


# time updatedb.mlocate 

real    1m54.511s
user    0m1.216s
sys     0m4.652s

(Bei Ersterstellung natürlich um einiges länger)

[reox]

ich werds schon wieder draufgeben aber es ist grad sehr zach wenn da nix geht und dauert die kiste steht... gestern nacht wo ich mir einfach mal 1h im htop angeschaut hab was da rennt, ist mir aufgefallen das der find job vom locate auch ein bissi load braucht und hab ihn mal gekillt... scheiss problem - kommt auf einmal und keiner weiß warum :/

ich hab grad kein ssh hier, werd mir das aber mal anschauen wie das konfiguriert ist, bzw was genau da abrennt

[rendegast]

das der find job vom locate

Wichtig dabei, locate durch mlocate ersetzen.
Das macht nicht ein einfaches 'find alles', sondern beschränkt sich auf geänderte Verzeichnisse.

[reox]

Sowas wie eine script-Angriff auf root-Login des ssh:22?

kann ich glaube ich auch ausschließen, wir tracen dass und da war nix. auf der netzwerkkarte gab es zu dem zeitpunkt auch keine besonderen vorkommnisse... Also es ist schon was internes