kmemsize und "Cannot allocate memory"

H

hoko

New Member
Hallo,

seit vielen Jahren habe ich einen "Premium X3" vServer bei server4you.
Bisher gab es auch nichts zu klagen und alles funktionierte wie es sollte.

Leider habe ich seit mehreren Wochen das Problem, dass der Server mehrfach am Tag faktisch tot ist, da er keinen Speicher mehr allokieren und somit keine Prozesse mehr erzeugen kann. Damit sind dann keine Dienste wie Mail, HTTP usw. mehr erreichbar. ja meisstens kann man sich auch nicht mehr per SSH anmelden und mir bleibt nur ein Reboot über die Adminkonsole.

Ich habe ein Ticket eröffnet, allerdings wird das nur mit wenig Interesse von server4you bearbeitet, hier eine der zahlreichen vorgefertigten Standardantworten:

Hallo Herr Koch,

die Ressourcen werden vom Hostsystem limitiert.

Wie weit Sie den Server auslasten dürfen und wie der aktuelle Status Ihres vServers ist, können Sie unter Linux der Datei /proc/user_beancounters entnehmen.

Mit dem Befehl "cat /proc/user_beancounters" in einem SSH-Client (bspw PuTTy) werden Ihnen diese Informationen angezeigt.

Die letzte Spalte ist für Sie interessant, da hier gezählt wird, wie oft es zu einer Ressourcen-Überschreitung kam. Ressourcen-Überschreitungen führen in der Regel dazu, dass Dienste nur langsam reagieren oder gar ausfallen.
Standardtools (z.B.: "ps", "free" oder "top") können aufgrund der Virtualisierung in Bezug auf Auslastung/Arbeitsspeicher falsche Werte liefern.

Nähere Informationen zu den Ressourcen-Limitierungen finden Sie unter http://wiki.openvz.org/UBC .

Die Werte sind fest an die Produkte gebunden. Um die Ressourcen-Beschränkungen zu erhöhen, müsste ein grösseres Produkt gebucht werden. Gegebenenfalls ist sogar der Wechsel auf einen dedizierten Root-Server zu empfehlen (https://www.server4you.de/root-server/). Einige Programme (wie z.B. Java) kommen mit nicht-virtualisierten Systemen deutlich besser zurecht.
Die entstandenen Probleme müssen jedoch nicht auf Ressourcen-Limitierungen zurückzuführen sein. Einzelne Programme könnten auch an eine eigene Grenze gelangt sein. Der Apache-Webserver hat beispielsweise solche Einschränkungen, dass maximal X Anfragen parallel verarbeitet werden. Alle weiteren Anfragen werden in eine Warteschleife gestellt. Diese Einschränkungen gibt es zum Schutz vor einer Systemüberlastung bei fast jeder Software. Hinweise auf diese Probleme werden konfigurationsabhängig protokolliert.

Bitte zögern Sie nicht, uns erneut zu kontaktieren, wenn Sie weitere Fragen oder Probleme haben. Wir helfen Ihnen gerne weiter.

Mit freundlichen Grüßen / Best regards
MOD: Namen des Support Mitarbeiters entfernt
- Customer Service -
--
SERVER4YOU
BSB Service GmbH
Daimlerstraße 9-11
50354 Hürth
Deutschland
[Telefax] 02233 - 612 5150
www.server4you.de

HRB 42945 / Amtsgericht Köln, USt-ID DE22 08 01 20 5
Geschäftsführer: Jochen Berger, Thomas Strohe
--
Obwohl Sie unsere Antworten auf Ihre Tickets auch per E-Mail erhalten, ist es nicht möglich, auf diese direkt per E-Mail zu reagieren. Die Antworten werden über eine noreply-Adresse versendet und E-Mails an diese Adresse ungelesen gelöscht. Daher ist es erforderlich, dass Sie sich zunächst in Ihrem Panel anmelden, um weitere Nachrichten zu Ihrem Ticket zu senden.
Click to expand...


Die Ausgabe von bean zeigt:
Code: 
vs137005:~ # ./bean 
#####################################################################################################################
BEANS FOR UID 137005
resource                     held              maxheld              barrier                limit              failcnt
kmemsize                  5.38 mb             26.21 mb             26.08 mb             28.69 mb          32326816441
lockedpages                     0             32.00 kb             10.43 mb             10.43 mb                    0
privvmpages             182.26 mb           2023.04 mb           2048.00 mb           2112.00 mb                    0
shmpages                  3.05 mb             31.97 mb            150.71 mb            150.71 mb                    0
numproc                        41                  210                  666                  666                    0
physpages                78.70 mb            692.16 mb                    036028797018963968.00 mb                    0
vmguarpages                     0                    0           1024.00 mb36028797018963968.00 mb                    0
oomguarpages             78.70 mb            692.16 mb           1024.00 mb36028797018963968.00 mb                    0
numtcpsock                     17                  187                 1800                 1800                    0
numflock                        8                   23                 1000                 1100                    0
numpty                          1                    3                   66                   66                    0
numsiginfo                      0                   59                 1024                 1024                    0
tcpsndbuf               307.96 kb              8.18 mb              9.14 mb             13.04 mb                    0
tcprcvbuf               385.48 kb              2.89 mb              9.14 mb             13.04 mb                    0
othersockbuf             38.65 kb              1.95 mb              3.05 mb              5.65 mb                    0
dgramrcvbuf               2.55 kb            299.23 kb              3.05 mb              3.05 mb                    0
numothersock                   26                  127                 1800                 1800                    0
dcachesize                1.37 mb              2.15 mb              5.68 mb              5.85 mb                    0
numfile                      1969                 6165                10656                10656                    0
numiptent                      10                   10                  192                  192                    0

das mein Problem bei kmemsize liegt. Allerdings auch, dass ich noch sehr weit von der kritischen Limit entfernt bin. Auch ein Monitoring zeigt nie einen Wert größer 16MB an.

Jetzt zu meinen Fragen:
* Ist es möglich, dass server4you den zugrundeliegenden Host so stark überbucht hat, dass von allen vHosts der kmem Speicher nicht mehr in das 1. GB passen?
* Habt ihr eine Idee, was ich tun kann, damit mein Server wieder stabil läuft und nicht mehrfach am Tag ausfällt?
* Ist server4you für sein Desinteresse bekannt oder hatte ich bisher einfach nur Pech mti den Bearbeitern?

Ich bin für jeden Hinweis dankbar.

Mit freundlichen Grüßen

Holger Koch
 
Last edited by a moderator:
Schon mal daran gedacht, dass dein Monitoring nicht mehr viel erfasst, wenn er an das Limit stößt und du deshalb da nie entsprechende Werte bekommst?
Die UserBeanCounters haben ein eigenes Monitoring, was du netterweise auch schon selbst hier mitgeteilt hast. Dein Maxheld (das maximale Wert den deine VE erreicht hat) liegt zwischen Barrier und Limit (Soft und Hardlimit). Damit hast du die dir zur Verfügung stehenden Ressourcen voll ausgenutzt.

Für die Administration deiner Anwendungen bist du selbst verantwortlich. Wenn es längere Zeit funktioniert hat und nun plötzlich nicht mehr, können folgende Dinge eingetreten sein:

  • Deine Konfiguration hat sich geändert und braucht nun mehr Ressourcen
  • Die Nutzung der Dienste durch User und Bots hat sich geändert und braucht nun mehr Ressourcen
  • Die Anwendungen wurden gegen andere oder aktualisiertere ausgetauscht und brauchen nun mehr Ressourcen
 
Hallo Firewire2002,

vielen Dank für deine Antwort. Ich gebe dir vollkommen Recht, dass in dem Moment wenn es interessant wird das Monitoring versagt. Es ist aber eine atypische Verteilung, wenn der Server über viele Stunden hinweg nur 8-10 MB kmem belegt und dann auf einmal dreimal soviel. Das entspricht ca. 300 Prozessen mehr. Wo sollen die herkommen? Der Apache ist stark limitiert und kann max. 30 Prozesse aufmachen. Ähnlich sieht es bei qmail aus. Wo also kommen die vielen Prozesse her?
Stutzig macht mich auch, dass mit max. 26.21 mb nur wenig mehr wie 26.08 mb (Barriere) verbraucht wurde (Wann das allerdings war...vielleicht ist das schon hunderte Tage her...) und die Barriere soll kurzzeitig überschritten werden kann und sich das Limit noch unglaublich weit entfernt befindet.

Ich vermute das Problem in einer anderen Ecke. 32- Bit Betriebsysteme sind darauf angewiessen. dass sich der Kmem im ersten GB des Speichers befindet. Und das von allen vHost. Wenn jetzt Server4you den Server hoffnungslos überbucht, dann kann es dazu kommen, dass gar nicht mehr genügend Speicher zur Verfügung steht. Leider lässt sich das ohne die Mitarbeit von Server4you nicht klären und die haben trotz mehrfacher Nachfrage überhaupt kein Interesse daran.

Holger
 
Ich darf dir versichern, dass die Hostsysteme alle 64bit Kernel nutzen. Völlig unabhängig davon, ob du ein 32bit oder 64bit Template installierst.
Somit ist die Limitierung auf das erste Gigabyte hinfällig.
 
kmemsize

Hallo,

ich habe leider bei s4y mit ähnlichen Problemen zu kämpfen. Der Parameter kmemsize ist wie alle anderen UBC Parameter bei keinem Hoster Vertragsbestandteil, damit kann er jederzeit einseitig geändert werden. Vielleicht ist eine solche einseitige Reduzierung ja die Ursache der plötzlichen Probleme bei HoKo.
Nach den sehr ärgerlichen Instabilitäten bei s4y, die wir leider auch nicht durch irgendwelche Optimierungen in den Griff kriegen, haben wir uns mal hier umgeschaut:
http://faq.hosteurope.de/index.php?cpid=13281
Schon das kleinste Produkt hat hier einen ca. 3-fachen kmemsize-Wert gegenüber dem Setup von HoKo im Posting. Wir haben unsere Daten jetzt seit ein paar Tagen im Probebetrieb unter vergleichbarer Last auf einem Server dieses Anbieters (kleinstes System) und siehe da, die Probleme scheinen verflogen zu sein. Wenn die Problemlösung mit dem Support nicht in den Griff zu bekommen ist bleibt da wohl nur der Wechsel ...
Ciao,
Pitty
 
Hallo Pitty,

vielen Dank für deinen Hinweis.
Es scheint also wirklich so zu sein, dass Server4you im Vergleich zu anderen Hostern die Limits extrem eng setzt.
Was ich nicht verstehe, ich habe bei weitem nicht das kleinste Paket (Premium) genommen, wie sieht es dann erst bei den kleineren aus?

Ich habe ja immer noch die Hoffnung, dass Server4you Probleme hat und sich die irgendwann lösen und der Spuk genau so schnell verschwindet, wie er gekommen ist.

Holger
 
You get what you pay for *hust* und nein, ich meine das wirklich nicht Böse. Es ist einfach so, dass die Größe des Anbieters praktisch gar nichts aussagt. Server4you ist sehr günstig und wenn die Hardware den eigenen Ansprüchen genügt: why not? Irgendwoher muss ein Preisvorteil ja kommen.

Ich habe bei Webtropia und De-Punkt sehr gute Erfahrungen mit vServern gemacht, dort könnt ihr ja auch mal reinschauen.
Netcups hat jetzt auch KVM basierte vServer, dort teste ich gerade den Kleinsten, kann aber noch nicht viel dazu sagen.
 
Ich darf mal die Diskussion Back-to-Topic führen:
Das Problem ist nicht der Host oder der Hoster, sondern der Container. Das geht aus den UBC eindeutig hervor.
Die "Ressourcen Verschwendung" findet im vServer statt. Es wäre also zu untersuchen wie es dazu kommt und was den Speicher dermaßen auslastet.
Aufgrund der vorgelegten Daten gehe ich davon aus, dass hoko mit ps, top u.ä. umgehen kann um weitere Daten zu liefern.


Der obigen Liste von Firewire2002 der möglichen Ursachen hätte ich einen unschönen Punkt hinzuzufügen:
* Ein Einbruch hat statt gefunden und es laufen unbekannte Programme im Hintergrund oder über den Apache.

PS: Nicht falsch verstehen, dies ist nur eine weitere Möglichkeit. Keine Vermutung oder Faktum!

huschi.
 
Huschi lag mit seiner Vermutung absolut richtig. Es gab einen Einbruch und partiell sehr hohe Last.
Unter http://www.flexthinker.com/2012/09/ hat ein anderer Betroffener seine Erfahrungen dokumentiert.
Das größte Problem war, das immer wenn ich mir den Server angeschaut hatte, überhaupt keine Last oder auffällige Prozesse vorhanden waren...

Aber Dank der Unterstützung eines kompetenten Server4you Mitarbeiters hat sich das jetzt auch geklärt und kann gelöst werden.

Vielen Dank an alle Beteiligten

H. Koch
 
You must log in or register to reply here.
Back
Top