• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

VSERVER-Limits nach dem S4Y-Update: Fakten, Fakten, Fakten

Elegantly

Registered User
Ich habe mich nach einigen Diskussionen von anderen selbst daran gesetzt, etwaige Änderungen an den Werten gelistet in /proc/user_beancounters nach der kürzlichen S4Y-Umstellung (Erhöhung des Traffics und des Webspaces für VSERVER sowie einige - noch ausstehende - Änderungen und Features am Kundeninterface) zu dokumentieren und damit hoffentlich eine objektive Aussage dazu treffen zu können.

Die hier genannten Daten wurden ermittelt auf einem S4Y VSERVER Basic (meinem eigenen VSERVER).

Vor der Umstellung (14.04.2005)
Datenquelle: Langsamer vSERVER (user_beancounters und numiptent)

Code:
vsXXXXXX:~ # cat /proc/user_beancounters
Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
    XXXXXX: kmemsize        1519788    1588070    7056211    7761832      56912
            lockedpages           0          0        344        344          0
            privvmpages       12050      12165     194904     214394          0
            shmpages            144        144      19490      19490          0
            dummy                 0          0          0          0          0
            numproc              22         23        172        172          0
            physpages          4887       4890          0 2147483647          0
            vmguarpages           0          0      32484 2147483647          0
            oomguarpages       5455       5458      32484 2147483647          0
            numtcpsock            8          8        172        172          0
            numflock              2          3        275        302          0
            numpty                1          1         16         16          0
            numsiginfo            0          1       1024       1024          0
            tcpsndbuf          2220       4440    1647558    2352070          0
            tcprcvbuf             0       4268    1647558    2352070          0
            othersockbuf      11100      11528     823779    1528291          0
            dgramrcvbuf           0          0     823779     823779          0
            numothersock         11         12        172        172          0
            dcachesize       268157     272683    1538982    1585152          0
            numfile             595        606       2752       2752          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            10         10         64         64        115

Nach der Umstellung (24.09.2005)
Datenquelle: heute ermittelt auf meinem VSERVER Basic; niedrigere Werte in rot, höhere Werte in grün

Code:
vsXXXXXX:~ # cat /proc/user_beancounters
Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
    XXXXXX: kmemsize        2077507    3895536    4652588    [COLOR="Red"]5117846[/COLOR]          0
            lockedpages           0          8        344        344          0
            privvmpages       26556      36494     109542     [COLOR="Red"]120496[/COLOR]          0
            shmpages            138        202      32000      [COLOR="Lime"]32000[/COLOR]          0
            dummy                 0          0          0          0          0
            numproc              29         62         96         [COLOR="Red"]96[/COLOR]          0
            physpages         10844      17557          0 2147483647          0
            vmguarpages           0          0      18257 2147483647          0
            oomguarpages      16494      20333      18257 2147483647          0
            numtcpsock            9         25        132        [COLOR="Red"]132[/COLOR]          0
            numflock              3          8        224        [COLOR="Red"]246[/COLOR]          0
            numpty                1          3         16         16          0
            numsiginfo            0          7        512        [COLOR="Red"]512[/COLOR]          0
            tcpsndbuf          4440     287332    1416560    [COLOR="Lime"]2768240[/COLOR]          0
            tcprcvbuf             0     174988    1416560    [COLOR="Lime"]2768240[/COLOR]          0
            othersockbuf      11100     164544     562911     [COLOR="Red"]987951[/COLOR]          0
            dgramrcvbuf           0      12804     562911     [COLOR="Red"]562911[/COLOR]          0
            numothersock         21         45        132        [COLOR="Red"]132[/COLOR]          0
            dcachesize       294995     369644    1002127    [COLOR="Red"]1032191[/COLOR]          0
            numfile             678        992       2240       [COLOR="Red"]2240[/COLOR]          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            24         24         64         64          0

Im Klartext: was bedeuten diese Änderungen?
Eine Erläuterung der Werte findet ihr in der OpenVZ Dokumentation (PDF) (Dank an mbroemme für den Link)

Beschränkt wurden:
  • kmemsize (-34%): The size of unswappable kernel memory allocated for the internal kernel structures for the processes of a particular VPS.
  • privvmpages (-44%): The size of private (or potentially private) memory allocated by an application. The memory that is always shared among different applications is not included in this resource parameter.
  • numproc (-44%): The maximal number of processes and threads the VPS may create.
  • numtcpsock (-23%): The number of TCP sockets (PF_INET family, SOCK_STREAM type). This parameter limits the number of TCP connections and, thus, the number of clients the server application can handle in parallel.
  • numflock (-19%): The number of file locks created by all VPS processes.
  • numsiginfo (-50%): The number of siginfo structures (essentially, this parameter limits the size of the signal delivery queue).
  • othersockbuf (-35%): The total size of UNIX-domain socket buffers, UDP, and other datagram protocol send buffers
  • dgramrcvbuf (-32%): The total size of receive buffers of UDP and other datagram protocols.
  • numothersock (-23%): The number of sockets other than TCP ones. Local (UNIX-domain) sockets are used for communications inside the system. UDP sockets are used, for example, for Domain Name Service (DNS) queries. UDP and other sockets may also be used in some very specialized applications (SNMP agents and others).
  • dcachesize (-35%): The total size of dentry and inode structures locked in the memory.
  • numfile (-19%): The number of files opened by all VPS processes.

Erhöht wurden:
  • shmpages (+64%): The total size of shared memory (including IPC, shared anonymous mappings and tmpfs objects) allocated by the processes of a particular VPS, in pages.
  • tcpsndbuf (+18%): The total size of send buffers for TCP sockets, i.e. the amount of kernel memory allocated for the data sent from an application to a TCP socket, but not acknowledged by the remote side yet.
  • tcprcvbuf (+18%): The total size of receive buffers for TCP sockets, i.e. the amount of kernel memory allocated for the data received from the remote side, but not read by the local application yet.


Fazit

HINWEIS: Bei allen o.g. Daten und Werten muss man bedenken, dass VSERVER - wie der Name sagt - virtuelle Server sind, bei denen man sich einen physikalischen VSERVER mit anderen Kunden teilt. Eine Limitierung von Performance-Werten muss sich also nicht zwangsläufig negativ auf die Performance des eigenen VSERVERs auswirken (denn mglw. erreicht man selbst diese Limits nie oder nur selten); im Gegenteil kann die Performance des eigenen VSERVERS sogar steigen, da andere VSERVER-Kunden auf dem gleichen physikalischen Server nicht mehr soviele der gemeinsam genutzten Ressourcen verbrauchen können wie vorher.

Was können wir aus den Werten gewinnen?

Erstens: Es wurden doch eine große Anzahl von Limits nach unten gesetzt, d.h. also die potenzielle Leistungsfähigkeit eines einzelnen VSERVERs beschränkt - sogar recht deutlich.

Zweitens: Die Summe aller (relativen) Änderungen mit Einbezug der gleichgebliebenen Werte, die ich salopp als aggregierter "Gesamt-Änderungswert" bezeichne, liegt bei: -11% (~ durchschnittliche Änderung)

ABER: Nicht alle Werte wirken sich zu gleichen Teilen auf die Gesamtperformance eines VSERVERs aus, von daher ist der Gesamt-Änderungswert mit Vorsicht zu genießen: manche Einstellungen wirken sich nur minimal an einem VSERVER aus (wie z.B. numsiginfo), manche haben einen signifikanten Einfluss (wie z.B. kmemsize). Zusätzlich hängt die subjektiv empfundene Performance auch vom individuellen Einsatzgebiet des VSERVERs ab (z.B. hat ein als Web-Server betriebener VSERVER andere Anforderungen als ein Game- oder IRC-Server, so dass sich auch die o.g. Limits anders auswirken).

Wie bereits im Hinweis genannt: Die Änderungen können sich für den eigenen VSERVER nicht nur negativ auswirken; eine sinnvolle Anpassung der Werte mit Hinblick auf die Gesamt-Performance eines physikalischen Servers für dessen N gehostete VSERVER-Kunden kann sich auch positiv auswirken.

P.S.: Im übrigen kann ich damit auch brummfondel's Limit-Wert von über 7.000.000 für kmemsize vor der S4Y-Umstellung bestätigen - im Gegensatz zu anderslautenden Aussagen.
 
@Elegantly

Danke für die objektive Darstellung. Ich kann die Werte bestätigen, da ich auch Aufzeichnungen von vor dem Update habe.


Und nun ein paar Überlegungen meinerseits zum Thema VPS:

Ich finde es traurig, dass von Seiten des Betreibers die alten Werte einfach als falsch dargestellt werden, obwohl es mehrere Aufzeichnungen dieser Werte gibt.

Für mich ist die Rechnung einfach. Plattenplatz ist billig, also gebe ich ein paar GB zu und packe dafür mehr VPS auf einen Host. So werden die User die bittere Pille schon schlucken.

Edit: Dies war wohl ein Missverständnis aufgrund einer Fehlkonfiguration. Die Beanwerte wurden mittlerweile korrigiert.
 
Last edited by a moderator:
Hi,

@Elegantly: Ich habs korrigiert, allerdings vergleichst du oben ein ALTEN vSERVER MAX mit einem vSERVER BASIC. Nichts destotrotz waren die Files nicht korrekt. :) Die alten MAX Ressourcen sind ja quasi nun die BASIC Ressourcen. Korrigier aber bitte mal die Berechnung oben. :) Ich hab das gerade in der Datenbank ueberall korrekt hinterlegt. Damit ist auch das komische Postfix Problem bei SuSE Linux 9.3 behoben. Hier muss ich mich mal entschuldigen, der Fehler lag bei uns. Aber niemand ist perfekt und hauptsache ist, es ist korrigiert. :p

Und wie schon von Elegantly gesagt, die Werte spiegeln dynamisch Ressourcen wieder und sind teilweise stark voneinander abhaengig, was dazu fuehren kann, dass wenn man einen Wert um den selben Faktor verringert wie man einen anderen erhoeht, durchaus mehr an Ressourcen hat, aber ich geb zu das obige Config File spiegelte das so nicht wieder. :) Ist aber korrigiert.
 
Eddi said:
@Elegantly
Für mich ist die Rechnung einfach. Plattenplatz ist billig, also gebe ich ein paar GB zu und packe dafür mehr VPS auf einen Host. So werden die User die bittere Pille schon schlucken.

Die Rechnung musst du mir mal erklaeren. Ich gebe jedem Kunden mehr Platz und packe mehr Kunden auf einen Host, der zu jedem Zeitpunkt physikalisch den selben Platz hat. :)

Wenn ich 100 Kunden mehr Platz auf einem Rechner mit angenommen 500 GB gebe, dann muss ich (da ich ja nicht in jedem Rechner neue Platten einbauen kann und alle Raids neubaue) auch ein paar Kunden darunterziehen, sonst wirds etwas eng mit dem Platz. :) Und das haben wir auch getan, allein ausdem Grund hast du schon mehr Performance, weil einfach weniger Kunden sich die gleichen vorhandenen Ressourcen teilen und das nur da Bestandskunden mehr Plattenplatz bekommen. :)
 
@mbroemme

Ich bin bei meiner Betrachtung davon ausgegangen, dass aufgrund der verringerten Beanwerte mehr VPS Einheiten auf dem Host plaziert werden sollten. Da die verringerten Werte sich mittlerweile als Fehlkonfiguration herausgestellt haben, habe ich wohl falsche Annahmen getroffen. Ich war irretiert, da die alten Beanwerte, obwohl mehrere User auf die verringerten Werte hingewiesen haben, erst einmal als falsch hingestellt wurden.

Das hat sich ja nun glücklicherweise geklärt. Ich habe mein oberes Posting entsprechend korrigiert.
 
Hi Maik!

mbroemme said:
@Elegantly: Ich habs korrigiert, allerdings vergleichst du oben ein ALTEN vSERVER MAX mit einem vSERVER BASIC.
Ahm, das stimmt so nicht.

Beide o.g. Auszüge von /proc/user_beancounters (vorher - nachher) sind von meinem eigenen VSERVER Basic, aufgenommen an den genannten Daten. Von daher sollten auch die Berechnungen korrekt sein.

mbroemme said:
Ich hab das gerade in der Datenbank ueberall korrekt hinterlegt. Damit ist auch das komische Postfix Problem bei SuSE Linux 9.3 behoben. Hier muss ich mich mal entschuldigen, der Fehler lag bei uns. Aber niemand ist perfekt und hauptsache ist, es ist korrigiert. :p
Kein Problem, Entschuldigung angenommen. Auch euch darf das mal passieren. :)


-- Myc (nicht zu verwechseln mit Maik)
 
mbroemme said:
Wenn ich 100 Kunden mehr Platz auf einem Rechner mit angenommen 500 GB gebe, dann muss ich (da ich ja nicht in jedem Rechner neue Platten einbauen kann und alle Raids neubaue) auch ein paar Kunden darunterziehen, sonst wirds etwas eng mit dem Platz. :) Und das haben wir auch getan, allein ausdem Grund hast du schon mehr Performance, weil einfach weniger Kunden sich die gleichen vorhandenen Ressourcen teilen und das nur da Bestandskunden mehr Plattenplatz bekommen. :)

mh.. das äre doch aber nur dann richtig , wenn ich nicht mit NAS Arbeiten würde...udn den Speicherplatz auf dem NAS vergebe.. somit ist es doch egal ob auf einer Maschiene jetzt 10 VPS liegen oder 500.. muss doch nur die externe speichereinheit erhöhen bzw. den ein oder anderen kunden auf ein anderen NAS legen oder?

Zumindest würde ich es so machen um mich unabhänig zu machen was die Speichererweiterung an den Servern selber betrifft.. ;)

Hatte ich gerade so als gedanken und wollte das mal sagen :)
 
Nach Maik's Änderung (24.09.2005)
Datenquelle: heute um 20:24h ermittelt auf meinem VSERVER Basic; niedrigere Werte in rot, höhere Werte in grün (im Vergleich zu den Daten vom April 2005)

Code:
vsXXXXXX:~ # cat /proc/user_beancounters
Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
    XXXXXX: kmemsize        3667460    4824134    7056211    7761832          0
            lockedpages           0          8        344        344          0
            privvmpages       39497      66685     109542     [COLOR="Red"]120496[/COLOR]          0
            shmpages           3201       3329      32000      [COLOR="Lime"]32000[/COLOR]          0
            dummy                 0          0          0          0          0
            numproc              55         74         96         [COLOR="Red"]96[/COLOR]          0
            physpages         20441      40438          0 2147483647          0
            vmguarpages           0          0      18257 2147483647          0
            oomguarpages      20441      40438      18257 2147483647          0
            numtcpsock           14         18        172        172          0
            numflock              8         11        224        [COLOR="Red"]246[/COLOR]          0
            numpty                3          4         16         16          0
            numsiginfo            0         10        512        [COLOR="Red"]512[/COLOR]          0
            tcpsndbuf         13320     128760    1416560    [COLOR="Lime"]2768240[/COLOR]          0
            tcprcvbuf             0     174988    1416560    [COLOR="Lime"]2768240[/COLOR]          0
            othersockbuf     153180     291084     562911     [COLOR="Red"]987951[/COLOR]          0
            dgramrcvbuf           0       4268     562911     [COLOR="Red"]562911[/COLOR]          0
            numothersock        121        132        172        172          0
            dcachesize       455936     492149    1002127    [COLOR="Red"]1032191[/COLOR]          0
            numfile            1408       1660       2240       [COLOR="Red"]2240[/COLOR]          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            24         34         64         64          0

Im Klartext: was bedeuten diese Änderungen?
Eine Erläuterung der Werte findet ihr in der OpenVZ Dokumentation (PDF) (Dank an mbroemme für den Link)

Beschränkt wurden:
  • privvmpages (-44%): The size of private (or potentially private) memory allocated by an application. The memory that is always shared among different applications is not included in this resource parameter.
  • numproc (-44%): The maximal number of processes and threads the VPS may create.
  • numflock (-19%): The number of file locks created by all VPS processes.
  • numsiginfo (-50%): The number of siginfo structures (essentially, this parameter limits the size of the signal delivery queue).
  • othersockbuf (-35%): The total size of UNIX-domain socket buffers, UDP, and other datagram protocol send buffers
  • dgramrcvbuf (-32%): The total size of receive buffers of UDP and other datagram protocols.
  • dcachesize (-35%): The total size of dentry and inode structures locked in the memory.
  • numfile (-19%): The number of files opened by all VPS processes.

Erhöht wurden:
  • shmpages (+64%): The total size of shared memory (including IPC, shared anonymous mappings and tmpfs objects) allocated by the processes of a particular VPS, in pages.
  • tcpsndbuf (+18%): The total size of send buffers for TCP sockets, i.e. the amount of kernel memory allocated for the data sent from an application to a TCP socket, but not acknowledged by the remote side yet.
  • tcprcvbuf (+18%): The total size of receive buffers for TCP sockets, i.e. the amount of kernel memory allocated for the data received from the remote side, but not read by the local application yet.

Was hat S4Y wieder auf die alten (höheren Werte) gesetzt?

  • kmemsize
  • numtcpsock
  • numothersock
 
Last edited by a moderator:
Hi,

@Elegantly: Und nochmal. Ich hab nochmal die Werte umgestellt und verbessert. Man sieht die Ueberschreitungen ja schoen in einer Statistik. :)
 
Ich habe mommentan, das Problem, das ich keinen Speicher mehr habe.

Siehe Anhang
 

Attachments

  • speicher.jpg
    speicher.jpg
    32.8 KB · Views: 337
mbroemme said:
Hi,

@Elegantly: Und nochmal. Ich hab nochmal die Werte umgestellt und verbessert. Man sieht die Ueberschreitungen ja schoen in einer Statistik. :)

Hi Maik, du machst das wohl absichtlich - so peu à peu. Aber ich gebe nicht auf. :D
Aber danke für den Hinweis. Ich habe übrigens vor dem Aufruf von cat /proc/user_beancounters gewettet, dass numproc erhöht wurde. Und siehe da... ;)

Nach Maik's Änderung (25.09.2005) - absolute Änderungen
Datenquelle: heute um 07:14h ermittelt auf meinem VSERVER Basic; niedrigere Werte in rot, höhere Werte in grün (im Vergleich zu den Daten vom April 2005)

Code:
vsXXXXXX:~ # cat /proc/user_beancounters
Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
    XXXXXX: kmemsize        2592873    4824134    7056211    7761832          0
            lockedpages           0          8        344        344          0
            privvmpages       45005      66685     109542     [COLOR="Red"]120496[/COLOR]          0
            shmpages            641       3329      19567      [COLOR="Lime"]19567[/COLOR]          0
            dummy                 0          0          0          0          0
            numproc              38         74        128        [COLOR="Red"]128[/COLOR]          0
            physpages          8545      40438          0 2147483647          0
            vmguarpages           0          0      18257 2147483647          0
            oomguarpages      22535      40438      21300 2147483647          0
            numtcpsock           11         28        172        172          0
            numflock              8         18        224        [COLOR="Red"]246[/COLOR]          0
            numpty                1          4         16         16          0
            numsiginfo            0         10        512        [COLOR="Red"]512[/COLOR]          0
            tcpsndbuf         17760     157620    1416560    [COLOR="Lime"]2768240[/COLOR]          0
            tcprcvbuf             0     174988    1416560    [COLOR="Lime"]2768240[/COLOR]          0
            othersockbuf     148740     302184     655717    [COLOR="Red"]1153621[/COLOR]          0
            dgramrcvbuf           0      72556     655717     [COLOR="Red"]655717[/COLOR]          0
            numothersock        103        150        172        172          0
            dcachesize       417917     504565    1002127    [COLOR="Red"]1032191[/COLOR]          0
            numfile             976       1660       2240       [COLOR="Red"]2240[/COLOR]          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            24         34         64         64          0

Im Klartext: was bedeuten diese Änderungen?
Eine Erläuterung der Werte findet ihr in der OpenVZ Dokumentation (PDF) (Dank an mbroemme für den Link)

Beschränkt wurden:
  • privvmpages (-44%): The size of private (or potentially private) memory allocated by an application. The memory that is always shared among different applications is not included in this resource parameter.
  • numproc (-26%): The maximal number of processes and threads the VPS may create.
  • numflock (-19%): The number of file locks created by all VPS processes.
  • numsiginfo (-50%): The number of siginfo structures (essentially, this parameter limits the size of the signal delivery queue).
  • othersockbuf (-25%): The total size of UNIX-domain socket buffers, UDP, and other datagram protocol send buffers
  • dgramrcvbuf (-20%): The total size of receive buffers of UDP and other datagram protocols.
  • dcachesize (-35%): The total size of dentry and inode structures locked in the memory.
  • numfile (-19%): The number of files opened by all VPS processes.

Erhöht wurden:
  • shmpages (+0%): The total size of shared memory (including IPC, shared anonymous mappings and tmpfs objects) allocated by the processes of a particular VPS, in pages.
  • tcpsndbuf (+18%): The total size of send buffers for TCP sockets, i.e. the amount of kernel memory allocated for the data sent from an application to a TCP socket, but not acknowledged by the remote side yet.
  • tcprcvbuf (+18%): The total size of receive buffers for TCP sockets, i.e. the amount of kernel memory allocated for the data received from the remote side, but not read by the local application yet.

Was hat S4Y im Verleich zum letzten Stand vom 24.09.2005 wieder geändert? - relative Änderungen

  • shmpages: wurde wieder heruntergesetzt auf etwa den Ursprungswert vom April 2005, jedoch etwas höher als damals
  • numproc: wurde im Vergleich zum letzten Stand wieder erhöht, aber immer noch weniger als im April
  • othersockbuf: wurde im Vergleich zum letzten Stand wieder erhöht, aber immer noch weniger als im April
  • dgramrcvbuf: wurde im Vergleich zum letzten Stand wieder erhöht, aber immer noch weniger als im April

Die wohl wichtigste Änderung ist die Erhöhung von numproc; dessen Limit ist zwar nicht mehr so hoch wie im April, jedoch besser als in der letzten Änderungsiteration.

Sieht in meinen Augen insgesamt doch recht vernünftig aus.
 
Schade habe ich diesen Beitrag erst jetzt gefunden. Habe mich sehr gewundert wieso meine Programme auf meinem Vserver Basic nach dem Upgrade immer wieder gecrashed sind .... Nun weiss ich, das vom Betreiber der Wert von privvmpages massiv heruntergschraubt wurde (-44%).

Leider hatte ich mir diese Werte vor dem Upgrade nicht herausgeschrieben, sonst hätte ich bestimmt reklamiert. Meine Programme sind nach dem Upgrade offenbar immer wieder gegen das reduzierte privvmpages Limit gelaufen und dann gecrashed. In meiner Not habe ich gestern einen Upgrade auf Vserver Medium ausführen lassen, und siehe da alles läuft wieder einwandfrei. So kann man natürlich auch Geschäfte machen ....

Hier noch meine aktuellen UBC Werte meines Vserver Medium:

Code:
Version: 2.5                                                                   
       uid  resource           held    maxheld    barrier      limit    failcnt
    249039: kmemsize        2661408    3163135    9384760   10323236          0
            lockedpages           0          0        430        430          0
            privvmpages      117197     130158     219084     240992    2472494
            shmpages           1294       2606      23020      23020          0
            dummy                 0          0          0          0          0
            numproc              41         59        144        144          0
            physpages         75974     111805          0 2147483647          0
            vmguarpages           0          0      27385 2147483647          0
            oomguarpages     102399     113624      27385 2147483647          0
            numtcpsock           50         82        244        244          0
            numflock              1          7        336        369          0
            numpty                2          3         24         24          0
            numsiginfo            0         23        768        768          0
            tcpsndbuf         88800     397808    1884024    3681759          0
            tcprcvbuf             0     460944    1884024    3681759          0
            othersockbuf       8880      42868     844366    1481926          0
            dgramrcvbuf           0     115092     844366     844366          0
            numothersock          7         24        244        244          0
            dcachesize       174417     215045    1503190    1548286          0
            numfile             475        619       3360       3360          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            13         26         64         64          0

Man beachte den failcnt Zähler von privvmpages :eek:
Ich denke davon sind bestimmt auch andere Kunden betroffen, hoffentlich lesen Sie zuerst diesen Thread ....
Finde ich gelinde gesagt schon nicht ganz fair vom Betreiber :mad:

Von einem bekannten weiss ich übrigens, das bei Hosteurope beim VPS Linux M, das Limit von privvmpages auf ~365000 steht ! Ich weiss das dieser eine Parameter nicht das Mass aller Dinge ist, in meinem speziellen Fall aber schon.
 
Das gibts doch gar nicht.... Plötzlich kriege ich :

#ps ax
-bash: fork: Cannot allocate memory

Keine Ahnung wieso, lief alles einwandfrei seit über einem Monat. Naja mal ein Reboot über das Webinterface gemacht. Ok komme wieder auf meinen Vserver Medium. Mal gucken was denn da los ist:

Das sind die aktuellen Werte von meinem Vserver Medium
Code:
cat /proc/user_beancounters 
Version: 2.5                                                                   
       uid  resource           held    maxheld    barrier      limit    failcnt
    249039: kmemsize        2241329    5193895    9384760   10323236          0
            lockedpages           0          0        430        430          0
            privvmpages      106606     212751     118296     130131   16348284
            shmpages            654       4190      23020      23020          0
            dummy                 0          0          0          0          0
            numproc              39         78        144        144          0
            physpages         92280     164516          0 2147483647          0
            vmguarpages           0          0      27385 2147483647          0
            oomguarpages      92373     183204      27385 2147483647          0
            numtcpsock           14         86        244        244          0
            numflock              2         10        336        369          0
            numpty                1          6         24         24          0
            numsiginfo            0         23        768        768          0
            tcpsndbuf          6660     397808    1884024    3681759          0
            tcprcvbuf             0     753560    1884024    3681759          0
            othersockbuf       6660     156428     844366    1481926          0
            dgramrcvbuf           0     170720     844366     844366          0
            numothersock          6         26        244        244          0
            dcachesize       155670     293051    1503190    1548286          0
            numfile             471        863       3360       3360          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            10         26         64         64          0

Hoppla !! Wer hat denn da an den UBC von privvmpages rumgeschraubt :mad: !!! Vor ein paar Stunden hat das noch ganz anderst ausgesehen (siehe mein Beitrag vom 29.9).
Gleich ein Ticket eröffnet, jetzt bin ich mal gespannt auf die Ausrede ...

Greez
gafrol
 
Last edited by a moderator:
Hallo zusammen,

wollte Euch die Antwort vom Support nicht vorenthalten :

Code:
Sehr geehrter Kunde,

das aktuelle Virtuozzo passt die Resourcenlimits der vSERVER an um eine fairere
Aufteilung der insgesamt zur Verfügung stehenden Resourcen auf die einzelnen
vSERVER zu erreichen. Dabei wird ein kurzzeitig höherer Verbrauch anders
berücksichtigt als eine dauerhafte Belegung.



Mit freundlichen Grüßen

Und was soll das jetzt bedeuten ? Ich bezahle zwar ein Medium, aber wenn es ihnen Lustig ist, dann schrauben sie die Leistung einfach auf ein Basic runter ? Also wenn das tatsächlich ihre letzte Antwort ist, dann sind sie mich als Kunden los.

Cheers
gafrol
 
Last edited by a moderator:
Hmm, seit zwei Tagen keine Antwort , obwohl ich in der Zwischenzeit nochmals nachgehakt habe...

Was soll man von einem solchen Kundenservice halten ? Hat jemand ähnliche Erfahrungen gemacht ?

rgds
gafrol
 
Hallo,

ich fürchte dabei bleibt es, wenn Du fest zugesicherte Rechenzeit wünschst ist ein vSERVER wohl leider nicht das richtige Produkt für dich.

-Torsten
 
Hallo, da bin ich anderer Meinung. Ich bezahle für einen Vserver Medium. Das Produkt zeichnet sich durch gewisse Merkmale aus, und wird dadurch definierbar. Wenn ich ein Auto kaufe, hat das auch gewisse Merkmale wofür ich bezahle. Wenn ich nicht das erhalte wofür ich bezahlt habe, dann reklamiere ich.

Dies ist nun mit meinem Vserver der Fall. Ich kriege nicht die Leistung wofür ich bezahlt habe, in meinem Fall wurde aus mir unerklärlichen Gründen ein für mich wichtiger Parameter verändert, der zudem nichts mit der eigentlichen Rechenleistung zu tun hat, sondern mit dem zugeteilten Speicher.

Der UBC Wert von privvmpages eines Vserver Medium beträgt 240992 (limit), wie an verschiedenen Stellen hier im Forum nachzulesen ist, unter anderem hier:

Das hat übrigens ein Kollege von Ihnen geschrieben ...

Cheers
gafrol
 
Also nu frage auch ich mich was da grade abgeht.
Ich lasse auf meinem vServer seid 2 Jahren erfolgreich einen kleinen selbstprogrammierten Java Chatserver laufen. Der hat IMMER ohne probleme funktioniert. Hatte immer genug speicher usw.
Bis gestern.
Ich weiss nicht woran es genau liegt, ich bin kein Linux Guru. Aber seid gestern beendet sich der Java Prozess irgendwie ständig automatisch. Und da habe ich mir mal die Beancounter angeguckt und frage mich ob es an folgendem liegt:

resource held maxheld barrier limit failcnt
privvmpages 63324 112608 87632 96396 787413

?
Irre ich mich oder steht mir da wirklich nicht gerade viel zur Verfügung?
Wenn Ihr auch die anderen Werte braucht kann ich sie gern noch reinschreiben. Aber mich hat eben genau DIESE Zeile gewundert. Es kann doch nicht sein das ein vServer mittlerweile nicht mehr genug Ressourcen für einen einfachen kleinen Java Server bietet der bisher IMMER funktionierte?
 
Die Beschränkung der privvmpages stellt wirklich ein großes Problem dar, vielleicht sollte man von Seiten von S4Y noch einmal nachdenken das Limit zu erhöhen.
Um Php zu kompilieren musste ich die Datenbank und den Webserver stoppen. :(
Nicht wirklich der Weisheit letzter Schluss.
 
Back
Top