RootForum Community

Edit: Sorry, dass ihr soviel lesen müsst, ist leider etwas mehr geworden, danke an alle, die sich die Mühe machen !

Hi, erstmal ne ganz kurze Vorgeschichte.

Ich habe einen Half-Life Server bei mir laufen. Bis auf einem Online Update ist alles noch Original-Zustand, Suse 7.2 256 MB Ram, 1200er Celeron. Das Problem, was ich habe, ist, dass der HL Server so ab 10 Player extrem anfängt zu laggen.

Es läuft NUR Apache, mysql, ssh, ftp, alles andere is aus. (Allerdings liegt http mäßig nix aufm Server, außer die paar Iam html Files.)

Nun bin ich seit 3 Tagen auf Fehlersuche. An 1&1 und deren Anbindung kanns eigentlich nicht liegen, bei ping IP sind die Werte gut, wie immer. Am CPU kanns auch nicht liegen, der hlds hat sogut wie NIE mehr als 40 % Auslastung, meistens sogar unter 30 %. Bleibt eigentlich nur noch der Ram. Und dort gibt es sogar Fakten, die dafür sprechen.

DENN, immer so bei 10 Playern ist unter Free Mem 0, und er fängt an zu swappen. Das Linux BasisSystem verbraucht so ca 30 MB. Nochmal 30 Apache, mysql, und co. Sind wir bei 60 MB.

Unter Cashed Memory habe ich 140 MB !!!! => 200 MB. Leer verbraucht der hlds 50 MB, sind also noch ca 5 MB Free Mem da. Ab 10 Player brauch er so 60/70 MB, fängt also an zu swappen, der Ping mag das ganz und gar nicht. *ggg*

So, meine Fragen, die sich daraus ergeben:

1. Bisher habe ich immer gedacht, dass das "cashed Mem" für andere Prozesse "freigegeben" wird, und erst wenn dann immer noch nicht genug Mem zur Verfügung steht, geswapped wird. Ist scheinbar aber nicht so ?!?!

2. Was genau ist überhaupt das cashed Memory ?! Windoof brauch ja schon sau viel "BasisMemory", so ca 100 MB inkl cashed Files, aber das Linux 140 MB cashed + 30 MB System = 170 MB erstmal nur für sich selber brauch, ist echt der Hammer ?!?!

3. Wie kann man bewirken, dass das cashed Memory für andere Anwendungen freigegeben wird ?! Geht dies überhaupt ?

4. Wie kann ich das cashed Memory "verkleinern" ??? Ist scheinbar nur bei Suse so viel, Gentoo zB benötigt gerade Mal 40 MB, im Vergleich, Suse 140 !!
Ich hatte schon unter Windows, K6-2 300, 256 MB nen 24 Mann Server laufen ( LAN ), der ohne Probleme seinen Dienst gemacht hat !

Ich denke mal, das ganze gehört nicht ins GameServer Forum, da das Problem auch mit jedem anderen "Prozess" auftreten könnte.

was mich ebenfalls "brennend" interessieren würde, wie sieht es bei Debian mit dem cashed Mem aus, wieviel ist es da ???

mein alter Debian:

Gruß

Olfi ;)

hmm, 70 MB, zwar auch fast doppelt soviel, wie bei Gentoo, aber immer keine 140 MB wie bei Suse.

Trotzdem muss es doch irgendeine Einstellung geben, was alles "gecashed" wird...

ich hab mich gerade mal ein paar Stunden "durch Google gesucht".

Allerdings habe ich nie eine Antwort auf das Problem gefunden, oder ich bin zu dumm, auf irgendeinen versteckten Link zu klicken...

http://www.uwsg.iu.edu/hypermail/linux/ ... /0326.html

Hier mal eine "Paradebeispiel"...

Ã?brigens, cached Memory ist scheinbar einfach nur zwischengespeicherte Files, die irgendwann mal gebraucht wurden, oder Verzeichnislisten/strukturen usw. Man muss doch irgendwie einstellen können, wieviel Memory ich zum "Cachen" freigeben will.

Klar kannst du das einstellen : hack mal ein bisschen in der "Virtual Machine"-Sektion der Kernel-Sourcen rum, und pass das ganze deinen Vorstellungen an ...
Nein, mal ernsthaft : such dich mal durch die Doku deines Kernels. Unter Umständen lässt sich da was über /proc machen, bin gerade zu faul zum suchen ...

ich habe nun eine Möglichkeit gefunden, den cached Mem zu leeren, shutdown -r now *ggg* Soll nochmal jemand sagen, Reboot bei Linux bringt nix *ggg*

Hab nun 70 MB cached, da hat hlds auf jeden Fall genug Ram frei, mal sehn, wie lange der cached unter 100 MB bleibt, und ob der Server nun immer noch laggt...

Nachdem ich den ganzen Cache durch den Reboot gesäubert habe, läuft hlds einwandfrei, es liegt also definitiv am Ram !

Wie kann ich denn blos verhindern, dass mir als der Cache wieder vollgehaun wird, sollte das jemand wissen, wäre ich ihm sehr sehr sehr dankbar...

In Google hab ich was gelesen von "mmap", hört sich aber ziemlich kompliziert an, und würde gerne wissen, ob das schon mal jemand "verstellt" hat...

Da stand auch was, dass man mmap einfach verbieten könnte, ich hab aber von dem allen nicht unbedingt viel verstanden *ggg*

Hi, das Problem ist gelöst, für alle, die es interessiert:

Es ist tatsächlich so, dass hlds aus irgendeinem Grund den cached Ram nicht anfasst, OBWOHL der Kernel eigentlich den Ram für den Prozess freigeben würde => hlds swappt => lags.

Ich habe nun folgendes C Programm bekommen, dass einfach große Mengen Memory anfordert, was reinschreibt, und wieder freigibt.

=> cached memory wird fast komplett geleert
=> alle unnötigen bzw lange nicht mehr benutzten "Memory-Teile" von anderen Prozessen werden in die Swap ausgelagert, nur die aller nötigsten bleiben im Ram
=> alle Prozesse, die sich irgendwo Ram reserviert haben, diesen aber nicht unbedingt brauchen, müssen diesen wenns irgendwie geht an das Script abgeben, da das Script aber gleich wieder alles freigibt, kann man so seinen Speicher aufräumen.

Das Ergebnis bei mir ist verblüffend !

Vor dem Script hatte ich 240 MB Ram used, davon 140 MB cached Memory, 15 MB frei, 2 MB swapped,

Nach dem Script hatte ich 70 MB used, davon 20 cached, 30 MB swappt, und 180 MB free !

Falls jemand Interesse am Sourcecode hat:
Ihr müsst das ganze natürlich vorher durch einen C Compiler laufen lassen, und ein Binary erzeugen...

Und für alle, die jetzt meinen, damit ihren Rechner schneller machen zu müssen:

Wenn ich kase richtig verstanden habe, ist das ein Problem, das ausschließlich mit dem oben genannten Gameserver auftritt! Wer den nicht einsetzt, braucht das auch nicht...


Grüßle

Olfi ;)

jop, es ist keine empfehlenswerte Methode seinen Speicher zu "leeren", da man nicht nur den cached Mem sondern auch alle anderen Prozesse erstmal in Mitleidenschaft zieht und ihnen den Ram abknipst.

Aber da sich hlds einfach von dem ganzen Cached Ram nix nehmen will, und lieber swappt, bekomme ich durch das Script meinen cached Ram wieder frei, und hlds kann ihn benutzen.

Allgemein ist das Script eher nicht empfehlenswert, da die Speicherverwaltung des Kernels inzwischen ausgereift genug ist...

Hiho,

das C-Programm scheint das Problem (für die Probs mit hlds) zu lösen, jedoch sollte man den allokierten Speicherblock vor dem return noch mittels free(m) freigeben. Theoretisch sollte das beim Beenden des Prozesses automatisch geschehen, aber sicher ist sicher, sonst hat man hinterher immer noch irgendwelche Zombiefragmente im Speicher rumliegen:

int main (void)
{
int mb=200;
char* m=malloc(1024*1024*mb);
memset(m,42,mb*1024*1024);
free(m);
return 0;
}

PS: Hätte nicht gedacht, dass die jungs von Valve den server in Bezug auf Speicherallokierung so ulkig programmiert haben.

ich habe den, von dem ich das Programm bekommen habe, auch gefragt, wo denn der Mem wieder freigegeben wird, der hat ebenfalls gemeint, dass geschieht von alleine, dafür wäre kein Befehl mehr nötig.

Und auch ich kann inzwischen bestätigen, dass das Programm das RAM-Problem von hlds 100 % gelöst hat. Warum hlds nicht an das cached Mem geht, zumindest bei Suse 7.2 ?! wird uns wohl nur Valve beantworten können.

Mal sehn, ob ich deine Version nochmal durch C jage, obwohls bei mir auch ohne free alles geklappt hat.

Mit Powertweak kann man Eingriffe auf den VM des Kernels vornehmen.
Im Suse Packet des Enterprise Servers 8.0 ist es auch implementiert. Da zumindestens ist es ausführlich dokumentiert:

http://powertweak.sourceforge.net

Die neuste Version gibt leider beim Kompilieren Fehlermeldungen raus; Habe die Ã?ltere-RPM für SUSE installiert.


Zu oben:
Leider bekomme ich beim Kompilieren folgenden Fehler:
p15110742:~ # gcc free.c
free.c: In function `main':
free.c:4: warning: initialization makes pointer from integer without a cast

Woran liegt es? Ist schon einige Tage vergangen als ich mit C programmiert habe....

Folgenden Quelltext habe ich genommen:

#include <stdio.h>
int main (void)
{
int mb=200;
char* m=malloc(1024*1024*mb);
memset(m,42,mb*1024*1024);
free(m);
return 0;
}

das ist normal, dieser Fehler kam bei mir auch, und ist nicht weiter bedenklich...

Einfach nun die angelegte a.out ausführen...

Edit: Also nicht, dass ihr jetzt denkt, ich hab eben mal schnell den Fehler für unbedenklich erklärt, sondern der, der mir das Programm geschrieben hat, hat gemeint, dass würde öfters passieren und wäre bedeutungslos...

Muss ich dieses script nun nur einmal ausführen und gut ist oder muss ich das dann per cron z.b. jede stunde machen lassen, damit es etwas bewirkt ?

nein, auf keinen Fall jede Stunde ausführn !

Am besten du installierst dir Debian auf den Server, dann brauchst du das ganze gar nicht mehr, der Fehler tritt nur bei Suse auf.

Warum nicht jede Stunde oder alle 5min ausführen ?

Wenn ich es ausführe hab ich ca. 200MB Ram frei.

Nach 15min sinds nur noch ca. 100 . Tendenz fallend.

Was ist so schlimm, wenn ich es regelmäßig alle 15min z.b. ausführen lasse?

Dass du allen Programmen ständig den RAM abschneidest, und zwar auch dem hlds. Führ das Script max so alle 3-4 Tage aus, öfter zieht das die Leistung nur extrem runter.

Normalerweise braucht man so ein Programm überhaupt nicht, nur scheint sich Suse 7.2 und hlds irgendwie nicht zu mögen. Der Kernel ist inzwischen so ausgereift, dass der die Speicherverwaltung komplett und perfekt übernimmt. So ein Program ist da eigentlich kontraproduktiv. Das es in diesem Fall hilft, ist die absolute Ausnahme. (da wie schon mehrmals geschrieben sich hlds den cached Mem nicht nimmt, sondern swappt)

Wie gesagt, seitdem ich auf Debian umgestiegen bin, brauche und benutze ich das Programm gar nicht mehr, und jeder, der es nicht unbedingt braucht, der lässt von dem Ding besser die Finger.

Also ehrlich gesagt besteht das gleiche Problem mit dem UT2k3 server
Da kann man so bis 6 Player ganz ok spielen, dann gehts richtig los mit lag bis es dann bei 12 playern echt kacke is.
rcapache stop und alles is ok
rcapache start und es lagt wieder wie sau
Scheiße :)
Lösung: rcapache in rclag unbenennen :)
Tut mir Leid, aber ich sehe es nicht ein, dass der sich da gleich beim Start erstmal so 100 MB abknipst. Lol. Das ganze htdocs Verzeichnis ist keine 100 Mb groß, lol. nene. Der kann auch gut die wichtigsten Seiten in 10 Mb halten!! Aber wie kriegt man ihn dazu? Hmm. Vielleicht wäre mit einem Update auf SuSE 8.1 alles gebacken? Ich krieg noch die Krise. Der Webserver sollte schon weiterlaufen beim zoggn :)

der Webserver verbraucht nicht viel RAM !

Bei mir 6*7 MB, allerdings sind von den 6*7 MB 6*5MB Shared, dh, der Apache braucht:

6*2 + 1*5 = <20 MB

Du musst halt in der httpd.conf die min Server auf 1 oder 2 stellen, damit möglichst wenig Prozesse laufen, und mit dem max Server Limit etwas "spielen", um dort einen guten Wert zu finden.

Aber du musst wie gesagt beim RAM Verbrauch das Shared wieder abziehen, bzw nur 1 Mal berechnen, und dann ist das gar nicht mehr soo viel. Nicht umsonst spendiert 1und1, aber auch alle anderen Provider, dem "Billig-Angebot" nur 256 MB Ram.

hab mich informiert, und alle sagen daß es ganz normal ist, Linux Speicherverwahltung verwendet immer den ganzen Speicher.

So ähnlich sieht's aus, raven ...

@distanzcheck :
Dies ist der Thread, den du lesen solltest ...

raven wrote:hab mich informiert, und alle sagen daß es ganz normal ist, Linux Speicherverwahltung verwendet immer den ganzen Speicher.

Ja, das ist richtig. Der komplette Speicher wird, wenn nicht benötigt, als Cache benutzt, dieser Cache wird immer weiter gefüllt, bis der RAM alle ist. Wenn aber jetzt irgendein Programm RAM brauch, aber alles in der Cache steckt, dann wird der Cache einfach geleert, und zwar um soviel, wie der Prozess braucht. Deshalb ist es eigentlich so, dass wenn der cached MEM > 30-40 MB ist, dann sind auf jeden Fall aktive Prozesse noch nicht am swappen.

Das ganze trifft aber nicht richtig bei hlds und Suse 7.2 zu. Dort ist es definitiv so, dass hlds swappt, obwohl 150 MB cached MEM "leer" wären. Das Problem betrifft aber NUR Suse 7.2 und hlds, wirklich NUR diese Kombination. Bei Debian und hlds als Kombination funktioniert alles einwandfrei, deshalb läuft mein CS Server nun auch schon seit längerer Zeit auf Debian *ggg*

free -m gibt Auskunft über euern Ramverbrauch/Ramaufteiling.

Das die SWAP File trotzdem manchmal so bis 20-30 MB groß ist, ist ganz normal, und hat nix damit zu tun, dass der Ram komplett verbraucht ist. Es werden einfach total unwichtige und kaum benutzte Sachen ausgelagert, obwohl noch Ram frei ist.