openVZ - max user processes

Firebird

Firebird

0
Hallo,

In einem openVZ VE habe ich das Problem das bei größerer Auslastung diverse Dienste nicht mehr forken bzw keinen Speicher allozieren können. Ich denke, dass das Prozesslimit überschritten wird - jedenfalls wäre noch genug RAM da.
ulimit -u ist 100, nach setzen auf 200 und Neustart des entsprechenden Dienstes (meistens Postfix) funktioniert das ganze wieder.

Mein Problem nun: Ich kann ulimit -u nicht permanent setzen im Container. Die Änderungen sind nach einem Logout verloren. nproc in der limits.conf wird auch fleißig ignoriert.
So wie ich das sehe, gibt es aber keinen Einstellung in openVZ selber (oder ich bin blind).

Weiß jemand wie ich das anders ändern kann?


Host: Gentoo
Guest: Ubuntu 10.04 (Lucid)
 
Zuletzt bearbeitet:
Welche Limits du mit Tools wie ulimit setzt, ist OpenVZ ziemlich egal. Die Frage ist eher welche Werte in der /proc/user_beancounters des VE stehen bzw. welche in der VE-Konfiguration gesetzt sind. Woran machst du fest, dass du in die nproc-Limits läufst? Die wären in einem VE zu vergleichen mit den numproc-Einstellungen. Wie sehen die failcnt-Werte in der user_beancounters aus?
 
Danke für die Antwort.

failcnt ist eben in Ordnung obwohl das Problem inzwischen wieder aufgetreten ist:
Code: 
Version: 2.5                                                                                                                                   
       uid  resource                     held              maxheld              barrier                limit              failcnt              
        9:  kmemsize                 25204494             46833687            143727000            147901640                    0              
            lockedpages                     0                    7                  256                  256                    0              
            privvmpages                262296               437068               734003               786432                    0              
            shmpages                    23677                64637               100000               100000                    0              
            dummy                           0                    0                    0                    0                    0              
            numproc                       115                  177                 1000                 1000                    0              
            physpages                  187938               287053                    0  9223372036854775807                    0
            vmguarpages                     0                    0                33792  9223372036854775807                    0
            oomguarpages               187938               287053                26112  9223372036854775807                    0
            numtcpsock                     55                  148                  360                  360                    0
            numflock                       17                   30                  188                  206                    0
            numpty                          2                    4                   16                   16                    0
            numsiginfo                      0                   17                  256                  256                    0
            tcpsndbuf                 1815808              3764736             27203200             37033600                    0
            tcprcvbuf                  338432              1587200              2720320              3703360                    0
            othersockbuf               239104               635648              2126080              3097152                    0
            dgramrcvbuf                     0                94976               262144               262144                    0
            numothersock                  170                  270                  500                  500                    0
            dcachesize                 791690              1068265              3409920              3624960                    0
            numfile                      2640                 3937                 9312                 9312                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      13                   13                  128                  128                    0

Ich hab Ewigkeiten gerätselt an was es liegen könnte, bis ich einmal auf gut Glück den ulimit Wert auf 200 erhöht habe. Das hat geholfen (und tut es immer noch). Wobei ich aber nach Erhöhung immer noch den Dienst Neustarten muss (Neustart ohne vorheriges ulimit "behebt" das Problem nicht).

Nochmal zu den Fehlermeldungen:
Code: 
postfix/pipe[19331]: warning: fork: Resource temporarily unavailable
(manchmal auch andere Dienste)
 
Also fork-Fehler ohne failcnt-Erhöhungen hatte ich zumeist, wenn die kmemsize zu klein war, wenn die zugeteilten CPU-Ressourcen zu knapp waren, was man dann durch Erhöhen der Werte für cpuunits und cpulimits beseitigen konnte, oder wenn die Host-Maschine an ihre Limits kam und sich die VEs gegenseitig Ressourcen "geklaut" haben. Wie sieht denn die Speicher- und CPU-Auslastung der Host-Maschine aus? Kann es sein, dass dort evtl. Hardware-Grenzen erreicht werden. Hat jedes VE eine eigene CPU zur Verfügung, oder werden diese zwischen den VEs geteilt?
 
Wie kann es sein, dass die kmemsize zu klein ist, man aber keinen failcnt sieht? Ich werd das mal testen und schauen ob das was bringt..

Prinzipiell laufen noch 2 andere Container darauf, aber die sind momentan quasi 0 ausgelastet. Einzig #3 hat etwas zu, hat aber noch genug Spielraum auf dem Quadcore... Host ist nicht ausgelastet.
cpulimit gibt es keines, und die cpuunits werden glaub ich nur benötigt um die Resourcen gerecht zwischen den VEs aufzuteilen wenn es zu Engpässen kommt. Da die andere VEs nichts arbeiten kann das, das eigentlich auch nicht betreffen.

CPUs werden geshared - wie kann man einer VE eine CPU zuweisen? Meinst du eine Aufteilung mit cpulimit?
 
Ja, ich meine schon die cpulimits und -units. Beachte aber, dass cpulimit nur greift, wenn du keinen allzu aktuellen Kernel verwendest. Ausserdem kannst du festlegen wieviele CPUs ein VE maximal zur Verfügung hat (vzctl set $CTID --cpus N --save). Die Frage ob ein einzelnes VE noch genug Spielraum auf einem Quadcore lässt, stellt sich aber auch nur theoretisch. Es kann durchaus schon kritisch sein, wenn sie auf allen 4 Kernen gleichzeitig etwas tut und dabei einen höheren cpuunit-Wert hat als die anderen VEs. Die müssen dann nämlich warten und man läft ggf. schon in ein Problem mit der Ressourcen-Zuteilung, wenn der Kernel diese in einem bestimmten Zeitraum erwartet.
 
So, nun ists wieder aufgetreten. Es wurden gerade einige Dienste restarted (durch ein Script):
Code: 
pure-ftpd:
Unable to start a standalone server - fork: Resource temporarily unavailable
postfix/pipe[13960]: warning: fork: Resource temporarily unavailable

Zu dem Zeitpunkt war kmemsize schon erhöht, und die --cpus gesetzt, so dass sich niemand darum streiten hätte dürfen. (Funktioniert --cpus überhaupt bei einem kernel > 2.6.18? Ich find da nichts in der Doku).

Würden sich die VEs Ressourcen klauen, müssten die Dienste aber spätestens nach einem Neustart wieder funktionieren wenn genug sonst nichts mehr ausgelastet ist. Dem ist aber nicht zwangsläufig so, oft genug funktioniert das auch dann nicht..

Kernel ist btw linux-2.6.27-openvz-kuindzhi.1-r1, eventuell sollte ich mal einen .18er testen.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben