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)
Nach der Umstellung (24.09.2005)
Datenquelle: heute ermittelt auf meinem VSERVER Basic; niedrigere Werte in rot, höhere Werte in grün
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:
Erhöht wurden:
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.
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 115Nach 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 0Im 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.
Die alten MAX Ressourcen sind ja quasi nun die BASIC Ressourcen. Korrigier aber bitte mal die Berechnung oben. 
