beancounters oomguarpages > vmguarpages

amandel

Registered User
Hallo,

ich hab inzwischen versucht einiges an Informationen über die beancounters, die über uns vServer Nutzer wachen heraus zu bekommen. Es scheint mir dennoch einiges an Magie dahinter versteckt zu sein (ich kapier es wohl nicht).

Ich würde gerne einen tomcat auf meinem vServer laufen lassen. Das geht auch, mit sehr eingeschränktem heap space. Leider wir der tomcat dennoch regelmäßig gekillt und der failed counter bei oomguarpages geht um eins nach oben. (Und meine Laune geht entsprechend nach unten).

Nun zieht die oomguarpages barrier -- soweit ich das gelesen hab -- nur wenn sich das Host System in Überlast befindet. Ärgerlich, wenn das mehrmals am Tag passiert :-(

Nun aber meine eigentliche Frage. Der Grenzwert bei oomguarpages ist garnicht so nieder (98304) und eigentlich ist da noch reichlich Luft (normalerweise steht der held Wert bei laufendem Tomcat auf 30019). Der vmguarpages barrier Wert (der IMHO unter Normallast zählt) steht jedoch auf 27385 was mir als wesentlich zu klein erscheint (bei "im Prospekt" garantierten 384MB).

Wär klasse wenn ihr mir mit Tipps helfen könntet.

Andreas.
 
Keine Tipps?

Kann mir wirklich keiner einen Tipp geben? Oder zumindest bestätigen, dass die Konfiguration so ungültig ist, dann kann ich S4Y mal bitten das zu überprüfen? (was ich schon gemacht hab, aber ich hätte es gerne von euch bestätigt)
 
Ich führe weiter Selbstgespräche.... Aber eventuell hat ja doch jemand ähnliche Probleme oder gar Tipps.

Ok, inzwischen habe ich die Bestätigung, dass der vmguarpages immer größer gleich dem oomguarpages sein sollte. Und dass da wohl ein Konfigurationsfehler vorliegt. Leider scheint SERVER4YOU für eine Änderung hier etwas länger zu brauchen, bzw. hat sich dazu noch nicht einmal geäußert.

Auch die eigentlichen Werte sollten bei versprochenen 384MB/768MB RAM auf
Code:
privmpages 196608 (ist 131448 ~ 513MB)
vmguarpages 98304 (ist 27385 ~ 107MB)
oomguarpages 98304 (ist 98304 ~ 384MB aha!?)
stehen.

Nunja. Eigentlich ist mir das alles nicht so wichtig. Es war nur eben so, dass der Server sehr instabil läuft und ich die Ursache gesucht habe. (Dabei war auch ein Upgrade vom vServer Basic auf den vServer Medium). Inzwischen hab ich wohl auch den Auslöser des Dilemmas gefunden: Dem Host geht regelmäßig der swap Speicher aus. Der host hat wohl 6GB RAM und 8GB swap. Wobei der freie swap Speicher mehrmals täglich (manchmal im Minutenabstand) auf 0 runter fällt :-(.

Schade nur, dass S4Y so lange braucht um das zu beheben bzw. stellung dazu zu nehmen. (nein bisher hat sich NIX geändert)

Ach ja... Im Ticket steht jetzt ich soll etwas Geduld haben (nunja das ist jetzt mehr als ein Monat offen und die eigentlichen Probleme hab ich ja schon länger) und mich an eine andere Email Adresse wenden, falls ich mich beschweren will. Irgendwie suspekt das Ganze!?


Habt ihr mir eventuell noch Tipps wie ich das eventuell beschleunigen kann?
 
Wow, cool, danke! Ich glaub ich hab meine Probleme bisher in's falsche Ticket system getippt ;-)

Das Problem mit dem swap bleibt aber (gerade ist es wieder ganz schlimm) bestehen, oder?
 
amandel said:
Wow, cool, danke! Ich glaub ich hab meine Probleme bisher in's falsche Ticket system getippt ;-)

Das Problem mit dem swap bleibt aber (gerade ist es wieder ganz schlimm) bestehen, oder?

Das ist normal. SWAP wird immer bei der Prozessanzahl genutzt, der Kernel entscheidet halt von alleine, was er auslagern sollte und was nicht.
 
Das das RAM immer nahezu voll ausgelastet wird ist klar. Das wird bei Bedarf für buffers oder cache verwendet. Und klar, was nicht akut gebraucht wird, wird vom RAM in den swap Speicher ausgelagert.

Aber wenn kein swap Speicher mehr da ist müsste der Kernel ja caches und dann buffers abbauen, was zumindest unnötig ist, da ja offensichtlich genug zum Auslagern gefunden wurde (bzw. aus anderen Gründen ausgelagert werden soll). Was der 2.4er Kernel oder Virtuozzo in der Situation wirklich macht weiß ich nicht. Es ist jedenfalls eine Engpasssituation und ich vermute nicht, dass zuerst cache und buffers auf 0 gefahren werden bevor der Kernel um sich ballert. (mit einem 2.6er könnte ich das mal testen...)


Code:
www:~# free -m
             total       used       free     shared    buffers     cached
Mem:          6051       5985         65          0       1599       1318
-/+ buffers/cache:       3067       2984
Swap:         8032       8021         10

Also gut ist das nicht Und die 10MB gehen wie gesagt auch gerne mal auf 0 runter.

Jetzt gerade:
Code:
www:~# free -m
             total       used       free     shared    buffers     cached
Mem:          6051       5977         73          0       1582       1285
-/+ buffers/cache:       3108       2942
Swap:         8032       8032          0
 
Hi,

Tipp:
root Server nehem.
Du versuchst eine VM in einer virtuallisierten Umgebung zu starten. Lass es, und da davor gewarnt wird (www.vserver.de -> FAQ), solltes du eingentlich wissen, dass du keinen Support erhalten wirst, es ist eine heiden Handarbeit, und du verstehst nicht genug davon es selber zu machen. Und du würdest kaum 3-400 Euro bezahlen wollen, um das mal richtig einstellen zu lassen, wozu auch, ist ja unrentabel ohne Ende. (bevor du den 3-400 Euro widersprichst, überleg dir, wie viel Zeit du schon verbrannt hast und dass Facharbeiter-Stunden 100-200 Eu kosten, es sind ja keine Hilfarbeiter)

Gruß MeMeD
 
Last edited by a moderator:
Hallo memed,

irgendwie kann ich Deinen Tipp nicht richtig verstehen.

Die Java VM lief in den letzten Monaten recht zuverlässig, nachdem der Host aufgrund des Updates neu gebootet wurde und der swap des Host Systems nicht mehr auf 0 runter gegangen ist. Ich kann nicht nachvollziehen wie Du darauf kommst, dass ich vom konfigurieren einer java vm zu wenig verstehen würde.

Das war keineswegs ein Problem mit meiner Konfiguration!

BTW: Die "Warnung" im FAQ kann ich nicht finden, nur den Hinweis: "Aus lizenzrechtlichen Gründen ... können Sie sich Java selbst installieren." (https://www.server4you.de/de/v_faq/index.html#17)

Gruß, Andreas.
 
Last edited by a moderator:
Thread ist schon älter aber egal,

bei garantierten 250 MB RAM sollte man in etwa die Werte von Parameter C haben.

Link

Hab mir ein rootDS 250 MB RAM geholt. Dessen Beancounters Werte liegen weit unter den Tabellenwerten :mad:
 
Back
Top