Since friday, I have a VPS server with Debian.

I had to upgrade my VPS from Lenny to Squeeze (from stable to testing).

Upgrading went right, but I got that Fatal message in the title, when starting up CenterIM and Elinks.

Googling it was a pain in the ass, but I’ve found something.

That’s why I want to write this tutorial.

After upgrading, you’ll likely do this:

INSERT TERMINAL APP HERE

Fatal: no entropy gathering module detected

Aborted

Now don’t panic.

Do the followings:

cd /dev

ls

YOUR DEV’S (LOOK AT URANDOM AND RANDOM).

You’ll see either “urandom” and/or “random”.

Delete them:

rm -f urandom

rm -f random

Now we have to remake both of them and chmod it.

/sbin/MAKEDEV urandom

/sbin/MAKEDEV random

chmod 777 /dev/urandom

chmod 777 /dev/random

Now try the same app again, and it works!

via[Tutorial] Linux: “Fatal: no entropy gathering module detected”.

Using IPV6 On OpenVZ Containers

Posted on June 1, 2009, 12:01 am, by Michael, under How To.

Many of you have probably used OpenVZ and got very angry at the fact that out the box, the ipv6 support is there, but difficult, hidden and badly documented. Well one of the most common compliants is that getting ipv6 working on the host is easy, but getting it to work inside the containers is a different story.

For this how to, i’ll be assuming you have already configured your ipv6 tunnel on the OpenVZ host, and that you have a suitable prefix assigned, e.g. a /64.

Firstly, you have to run a few commands and depending on your installation, these may or may not already be set.

# echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp

# sysctl -w net.ipv6.conf.all.forwarding=1

These basically enable ipv6 to travel to and from containers without problems. Note, after a reboot these will need to be set again, however they can be set permanently also. This configuration will work for all containers.

Finally, to add an address to a specific container run the following (replacing with the number of your container) and replacing eth0 with the appropriate device.

# vzctl set <CTNUM> –ipadd 2001:630:c2:YYYY::XXXX –save

# ip -6 neigh add proxy 2001:630:c2:YYYY::XXXX dev eth0

The first line add’s the address inside the container (note: do not try to add an address manually inside the container… it won’t work). The second line basically makes the host os aware of this address (not always needed, but no harm done).

After this you should be able to communicate to and from the host to anywhere using the ipv6 address you just assigned! Good Luck!

viaUsing IPV6 On OpenVZ Containers | captaingeek.net.

error writing /proc/self/oom_adj: Operation not permitted

05.05.10 | G33keries, Tips

Si vous rencontrez cette erreur dans vos logs (auth.log) à l’intérieur d’un Container OpenVZ

1 auth.log: leela sshd[17009]: error writing /proc/self/oom_adj: Operation not permitted

Voici comment vous « débarasser » de cette erreur

Je l’ai rencontré sur la configuration suivante :

1 root@Leela:~# dpkg -l | grep openssh-server

2 ii openssh-server 1:5.1p1-5 secure shell server, an rshd replacement

1 root@Leela:~# cat /etc/issue.net

2 Debian GNU/Linux 5.0 (Lenny)

Il s’agit d’un bug, qui a été corrigé à partir de la version 1:5.4p1-1 par la communauté

En effet, il a été ajouté l’option SSHD_OOM_ADJUST, dans /etc/default/ssh

Cette option, lorsqu’on lui donne la valeur -17, permet de dire à oom de ne pas killer les processus SSH

Ce qui effectivement est bien utile

Sauf que dans le cas d’un Container OpenVZ, cela pose problème

Il vous reste donc 2 possibilités :

1. Modifier /etc/default/ssh ainsi :

1 root@Leela:~# cat /etc/default/ssh

2 # Default settings for openssh-server. This file is sourced by /bin/sh from

3 # /etc/init.d/ssh.

4

5 # Options to pass to sshd

6 SSHD_OPTS=

7

8 # OOM-killer adjustment for sshd (see

9 # linux/Documentation/filesystems/proc.txt; lower values reduce likelihood

10 # of being killed, while -17 means the OOM-killer will ignore sshd; set to

11 # the empty string to skip adjustment)

12 SSHD_OOM_ADJUST=

En laissant le paramètre vide, il n’y a plus de message d’erreur dans auth.log

2. Upgrader la version de openssh-server afin d’être >= 1:5.4p1-1

(J’ai choisi l’option 1)

That’all folks !

viaLord’s Lair » error writing /proc/self/oom_adj: Operation not permitted.

Sous openvz l’on a besoin par moment de monter un dossier de l’hote sur les vps pour par exemple un dossier de sauvegarde ou de template pour des applications .

Dans mon cas avec des ve debian voici la syntaxe que j’ai utilisé,
creation d’un fichier /etc/vz/conf/vps.mount 


#!/bin/bash
source /etc/vz/vz.conf
source ${VE_CONFFILE}
mount --bind -n /data ${VE_ROOT}/data

celui ci monte le dossier /data de l’hote dans
le dossier /data de chaque ve . Attention à ce
que le dossier existe sur les VEs

debian s’occupe du démontage

Régler l’heure d’un environnement virtuel OpenVZTuto servant à régler l’heure d’une machine virtuelle OpenVZ.

Source: http://forum.openvz.org/index.php?t=msg&goto=6694&

Admettons que l’environnement virtuel ait l’ID 101.

On stoppe le VE:?

vzctl stop 101On lui donne la possibilité de régler l’heure:

vzctl set 101 –capability sys_time:on –saveOn le démarre:

vzctl start 101On entre dedans pour finaliser l’opération:

vzctl enter 101On définit par exe

viaJean-Christophe VASSORT » OpenVZ.

OpenVZ est une technique de virtualisation noyau, qui permet de partager le noyau entre plusieurs systèmes. Il est équivalent à Vserver.

Voici quelques commande d’exploitation utiles :

vzctl set 107 –diskspace 6G:7G –save #définir les quotas disques à 6Go soft et 7Go hard

vzctl set 106 –save –tcprcvbuf 17203200 #augmenter le quotas de reception tcp

cat /proc/user_beancounters #Visiualiser l’état de chaque limitations par serveurs

vzdump –suspend –mailto adresseEmail 105 #sauvegarde un vz

Openvz contrôle les ressources systèmes grâce à UBC ( User Beancounter ), les valeurs définies pour chaques VZ sont visibles dans /proc/user_beancounters. Virtuozzo, la version commerciale d’openvz propose quand à lui une alternative qui s’apelle slm (on ne va pas en parler ici).

Limitations mémoire :

Il n’y a pas de notion de swap pour le container, la swap se trouve sur le host on choisit la quantité de ram qui va apparaitre sur le container.

Par exemple un host avec 2 Go de ram et 2 Go de swap qui aurait 4 container avec 1Go de RAM(vmguarpages*4Ko). Si chaque container utilise sa RAM, alors ils vont faire swapper le RAM pourtant du point de vue du container on ne swappera pas, on aura juste des perfs de merde.

Dans le cas où on allouerait plus que la mémoire allouable sur notre host alors les containers vont se faire killer des process (c’est la qu’intervient le parametre oomguarpages).

Détaillons les paramètres :

* kmemsize : représente en la valeur en octet utilisé par le kernel pour garder des informations sur les process, cette mémoire ne peut pas être swappée.

* privvmpages : représente la valeur de la mémoire alloué cela peut représenter les allocation en mémoire vive et les allocation qui se trouve en swap. Attention c’est une mémoire alloué (malloc en C) elle n’est pas forcément utilisé. L’unité est en nombre de pages, une page fait 4KB ( donc 4096 octets ). La valeur barrier représente la limite que l’ont veut poser alors que la valeur limit n’est pas définie et doit être positionnée à la valeur maximale (9223372036854775807 pour un système 64 bits).

* physpages : représente la mémoire réellement utilisée (généralement inférieur), généralement les valeurs ici correspondent à la moitié des valeurs de privvmpages. On ne peut pas poser de limites sur ce paramètre c’est juste un indicateur. A priori la mémoire swappé n’en fait pas partie.

* vmguarpages : permet de définir les valeurs garanties sur lesquelles notre vz va pouvoir compter, concretement cela se traduit par la taille de la mémoire allouable même si le host est à cours de mémoire.

* oomguarpages : définit un seuil d’utilisation mémoire à partir duquel les process vont pouvoir se faire tuer par OOMKILLER, si cette valeur n’est pas dépassée le container ne se fera pas killer sauvagement de process. En fait pour qu’un container se fasse killer des process il faut que la somme oomguarpages (valeur actuelle) + sockets buffer + kmemsize soit supérieur à la valeur limite de vmguarpages. Si les kills sauvage font peur la solution est de mettre cette valeur au dessus de privvmpages pour être tranquille.

* swappages : certaines applications doivent obligatoirement voir quelle quantité de swap est disponible, limit permet de définir combien de swap est visible depuis le container, la valeur held permet de voir quelle quantité de swap est effectivement utilisé par el container.

La mémoire visible dans le container est par défaut la valeur de vmguarpages, mais on peut définir explicitement la valeur visible avec l’option MEMINFO. Par exemple dans la configuration suivante on utilisera plutot la veleur de privvmpages :

MEMINFO= »privvmpages:1″

Limitations cpu

Il y a deux paramètres principaux pour la limitation cpu :

* cpuunits permet de définir un poid dans la distribution cpu offerte au container, plus le poid est important plus il aura de la patate lorsque le cpu sera déjà consommé par d’autres container. Si le cpu est libre de toute utilisation meme un container avec un poid faible pourra l’utiliser à 100%.

* cpulimit permet de brider l’utilisation d’un container à un certain pourcentage de la puissance cpu, attention pour calculer le pourcentage de la puissance totale il faut penser à le multiplier par le nombre total de cpu. Par exemple sur un système avec 16 coeurs, il faut fixer la limite à 1600% pour pouvoir tout utiliser (16*100%).

* Définir une utilisation cpu de 15% pour un host avec 8 coeurs:

cpulimit=15*8

* Définir un temps cpu avec cpuunit par vz, les valeurs agissent comme un poid, chaque vz aura un pourcentage du temps cpu qui correspond au ratio entre son poid et le poid total définit sur tous les vz.

Pour connaitre la répartition actuelle des poids :

vzcpucheck -v

Comment calculer le nombre de page à paramétrer

Toutes les parametres qui se terminent par pages, utilisent comme unités les pages. Une page représente pour les système 32 bits et amd64 une taille de 4ko, cette valeur varie pour des architectures particulière comme intel IA64 (attention rien à voir avec les processeurs intel 64 bits récents qui utilisent une architecture amd64).

Un raccourcis mathématique pratique permet de faire la correspondance entre le nombre de pages et le nombre de Mo.

Valeur en Mo = Nombre de page / 256

Nombre de page = 256 * Valeur en Mo

Par exemple pour définir une mémoire garantie à 2048Mo pour le container 101, on peut s’y prendre de la manière suivante :

vzctl set 101 –vmguarpages $((2048*256)) –save

Le futur d’openvz

OpenVZ et Vserver seront bientot obsolètes et bientot remplacés par LXC, lorsque ce dernier aura suffisament de maturité.

viaSysadmin Wiki : openvz.

Open with your favorite editor (eg: nano, vim) /etc/sysctl.conf and edit as following :

  • net.ipv4.conf.all.rp_filter=1
  • net.ipv4.icmp_echo_ignore_broadcasts=1
  • net.ipv4.conf.default.forwarding=1
  • net.ipv4.conf.default.proxy_arp = 0
  • net.ipv4.ip_forward=1 kernel.sysrq = 1
  • net.ipv4.conf.default.send_redirects = 1
  • net.ipv4.conf.all.send_redirects = 0
  • net.ipv4.conf.eth0.proxy_arp=1

After you’ve edited /etc/sysctl.conf file run: sysctl -p Step 4. Open /etc/vz/vz.conf and set as following: NOTE: This is important! If you don’t do this, networking will not work in the virtual machines!

NEIGHBOUR_DEVS=all

Le noyau linux OpenVZ permet de se cloisonner en VE (Virtual Environment). Pour chaque VE créé, il attribue une certaine quantité de ressources système comme par exemple un nombre de processus maximum ou bien une certaine quantité de mémoire. Ces ressources sont appelées, en jargon « OpenVZique » les « bean counters », soit les « compteurs de haricots »…si quelqu’un connait l’origine de ce terme, je suis preneur. Il sont consultables dans le fichier /proc/user_beancounters autant sur le HN pour le détail de tous les VE que sur chaque VE pour ses valeurs propres.

Pour la dernière version d’OpenVZ disponible au moment de l’écriture de cet article, il y a une vingtaine de paramètres disponibles. Avant de créer un VE, il est donc important de bien comprendre le rôle de chacun de ses paramètres car, la plupart du temps, les problèmes liés à l’exécution d’un programme dans un VE est lié à une mauvaise quantification de ceux-ci.

Informations générales sur tous les paramètres

Valeurs des paramètres

Chaque paramètre contient 6 valeurs, certains sont modifiables, d’autres en lecture seule.

En voici le détail :

* resource : c’est le nom du paramètre.

* held : c’est la valeur en cours pour le paramètre, elle varie donc dans le temps. Cette valeur peut utilisée pour monitorer un VE.

* maxheld : c’est la valeur maximum que le paramètre a atteint depuis le démarrage du VE. Cette valeur ne peut être remise à zéro qu’en redémarrant le VE.

* barrier et limit : ces deux valeurs ont une utilité dépendante du paramètre associé. Elles peuvent parfois être considérées comme une limite soft et hard, ou bien comme une valeur limite indépassable, ou bien ne pas du tout être prises en compte.

* failcnt : c’est un compteur qui s’incrémente chaque fois que les barrier ou limit sont dépassées. Il est également dépendant du paramètre.

Unités des paramètres

Les paramètres peuvent avoir trois unités de mesure :

* En unité : cette unité est utilisée par tous les paramètres dont le nom commence par « num ». Comme par exemple « nomproc » qui correspond au nombre de processus.

* En page de mémoire (memory page) : cette unitée est utilisée par tous les paramètres dont le nom fini par « page ». Comme par exemple « vmguarpages » qui permet de contrôler la quantité de mémoire allouée aux applications lancées dans le VE. Une page de mémoire fait 4ko sur les architectures x86 et x86_64.

* En octets : cette unité est utilisée par tous les autres paramètres. Comme par exemple « tcpsndbuf » qui représente la taille du tampon utilisé pour l’envoi de données sur une connexion TCP.

Les types de paramètres

Chaque paramètre peut être d’un type parmi les suivants :

* limiting : le paramètre pose une limite sur les ressources système qu’un VE peut utiliser. Si cette limite est dépassée, le processus qui provoquera ce dépassement sera tué. A noter quand même que si le paramètre a une barrière (barrier) et une limite (limit), une fois la barrière atteinte, le processus ne sera tué que s’il n’est pas vital pour le VE. Par contre la limite est réellement une frontière à ne pas dépasser quelque soit le processus.

* guarantee : le paramètre défini une quantité de ressources garantie. C’est à dire que, peut importe les ressources systèmes du HN et utilisées par les autres VE, cette quantité sera utilisée pour ce VE quitte à prendre des ressources chez les autres.

* accounting : ce paramètre est en lecture seule et c’est juste un compteur pour une valeur particulière. Il peut donc être utilisé pour monitorer le VE.

Tableau récapitulatif des paramètres

Voilà un tableau récapitulatif de tous les paramètres, leur type, leurs valeurs possibles et leur unité.

Name Type Account Barrier Limit Units

Primary parameters

numproc limiting Yes No Yes pieces

numtcpsock limiting Yes No Yes pieces

numothersock limiting Yes No Yes pieces

vmguarpages guarantee No guarantee No pages

Secondary parameters

kmemsize limiting Yes Yes Yes bytes

tcpsndbuf limiting Yes Yes Yes bytes

tcprcvbuf limiting Yes Yes Yes bytes

othersockbuf limiting Yes Yes Yes bytes

dgramrcvbuf limiting Yes Yes Yes bytes

oomguarpages guarantee Yes guarantee No pages

privvmpages limiting Yes Yes Yes pages

Auxiliary parameters

lockedpages limiting Yes Yes Yes pages

shmpages limiting Yes No Yes pages

physpages accounting Yes No No pages

numfile limiting Yes No Yes pieces

numflock limiting Yes Yes Yes pieces

numpty limiting Yes No Yes pieces

numsiginfo limiting Yes No Yes pieces

dcachesize limiting Yes Yes Yes bytes

numiptent limiting Yes No Yes pieces

Détails des paramètres

Paramètres primaires

numproc

Le paramètre numroc représente le nombre de processus en cours dans le VE. Il est de type « limiting », c’est à dire que sa valeur « limit » impose un nombre maximum de processus exécutables dans le VE.

Beaucoup d’application du type apache ou courier-imap exécutent un processus pour chaque connexion ouverte ainsi qu’un certain nombre de processus « dormants ». Il faut donc prévoir cette limite avec parcimonie car si elle est dépassée, les nouveaux processus sont tués dés leur création…ce qui peut avoir des effets de bords graves.

A noter également qu’à partir de 16000 processus simultanés (même dormants), un système sous linux commence à voir ses performances se réduire significativement. Au delà de 32000 processus simultanés, il y a de grandes chances que le système plante.

numtcpsock

Ce paramètre permet de limiter le nom de connexion TCP simultanées dans un VE. Etant donné le réseau est géré de façon interne par chaque VE (que ce soit en mode VENET ou VETH), le paramètre numtcpsock n’a aucune influence sur le réseau du HN. Le nombre de connexions TCP doit être limité car chaque socket ouvert nécessite une certaine quantité de mémoire et la mémoire est une ressource limitée.

Une limite trop basse peut avoir comme effet le refus de nouvelles connexions sur un service. Par exemple un serveur apache hébergeant un site très visité peut facilement avoir plusieurs centaines de connexions concurrentes, la limite de numtcpsock devra donc être modifiée en conséquence.

numothersock

Ce paramètre agit exactement de la même façon que numtcpsock mais pour tous les autres types de sockets (UDP, local, etc.). Il influe donc sur les serveurs DNS qui utilisent des sockets UDP, ou bien sur les bases de données MySQL qui utilisent des sockets locaux.

vmguarpages

Ce paramètre permet de définir la quantité de mémoire garantie pour le VE. Il est lié au paramètre privvmpages (voir plus loin).

En clair, cela veut dire que :

* Si la quantité de mémoire utilisée par le VE est inférieure à la barrière de vmguarpage, alors un nouveau processus pourra s’exécuter sans problèmes.

* Si la quantité de mémoire utilisée par le VE est comprise entre la barrière de vmguarpage et la barrière de privvmpages, un nouveau processus pourra s’exécuter sans problème s’il reste de la mémoire disponible sur le HN.

* L’exécution de nouveau processus sera ensuite dépendant du paramètre privvmpages (voir plus loin).

Ce paramètre est donc le principal paramètre influant sur la mémoire d’un VE. Une valeur trop faible empêche directement l’exécution d’un VE et/ou des programmes s’exécutant à l’intérieur de celui-ci. Et une valeur trop importante diminuera la quantité de mémoire disponible pour le HN, ce qui peut conduire à un plantage du système. Dans tous les cas, la valeur de vmguarpages ne peut excéder la quantité de ressource système disponible sur le HN (RAM+SWAP).

Etant donné que vmguardpages n’a pas de limite, celle-ci doit être positionnée à la valeur maximum (MAX_ULONG), soit 2147483647 (232-1) pour une architecture 32 bits et 9223372036854775807 (264-1) pour une architecture 64 bits.

L’unité de vmguarpages est variable selon l’architecture matérielle. Pour du matériel x86 ou x86_64, c’est 4ko.

Paramètres secondaires

kmemsize

Ce paramètre est la quantité de mémoire « unswappable » disponible pour un VE en octets. C’est à dire la somme de la quantité de mémoire utilisée par le noyau pour gérer chaque processus sans compter les tampons réseau (voir plus loin).

Ce paramètre est donc lié au paramètre numproc. Chaque processus utilise une certaine quantité de mémoire noyau, au minimum 24ko, en moyenne autour de 50ko mais elle peut être bien supérieure.

Si la quantité de mémoire noyau utilisée pour les processus du VE est supérieure à la valeur barrière, alors seuls les processus prioritaires pourront utiliser cette mémoire. Si elle dépasse la valeur limite, alors les nouveaux processus ne pourront pas s’exécuter et cela risquera de provoquer un plantage du VE. Les valeurs limite et barrière sont limitées par les ressources disponibles sur le HN.

tcpsndbuf, tcprcvbuf et othersockbuf

Ces deux valeurs déterminent la taille de la mémoire tampon utilisée pour, respectivement, envoyer et recevoir des données sur le réseau via le protocole TCP.

Elles dépendent directement du paramètre numtcpsock pour tcpsndbuf et tcprcvbuf et de numothersock pour othersockbuf. Elles doivent donc être suffisamment importantes pour que chaque socket ait assez de mémoire tampon disponible. Pour valider ce point, il suffit de respecter cette simple règle :

tcpsndbuflim – tcpsndbufbar >= 2.5ko × numtcpsock

(idem pour tcprcvbuf et othersockbuf)

Si elle n’est pas respectée, les connexions entrantes, sortantes ou via socket local peuvent devenir instables.

dgramrcvbuf

Ce paramètre est la taille du tampon utilisée pour la réception de datagrammes UDP. Si la valeur courante (account) dépasse la valeur limite alors les datagrammes seront refusés à la réception.

Mais comme UDP est un protocole non connecté les applications l’utilisant sont conçues pour gérer les pertes de données en réception. C’est pourquoi la limite de dgramrcvbuf n’a pas forcément besoin d’être élevée. Toutefois une valeur trop faible entraînerait trop de pertes de données et ainsi provoquerait une dégradation de service. Et une valeur trop élevée n’a pas de plus-value et serait de la mémoire inutilisée.

oomguarpages

Ce paramètre est lié à vmguardpages. C’est la quantité de mémoire garantie dans le cas où le noyau linux entre en mode oom (Out Of Memory).

C’est à dire que si la somme des quantités de mémoire et swap utilisées par tous les VE plus la somme des kmemsize plus la somme des buffers est supérieure à la quantité de mémoire (RAM+SWAP) disponible sur le HN, alors le noyau linux entre en mode oom et commence à tuer les processus dans les VE. Les VE dont la valeur de oomguardpage dépasse le plus la valeur barrière verront leurs processus tués en priorité.

Si la valeur barrière de ce paramètre est inférieure à la valeur limite de privvmpages (voir plus loin), les chances que des processus soient tués dans ce VE sont réduites. Si elle est définie à la moitié de cette limite, les chances deviennent nulles.

La valeur courante (account) de ce paramètre est la quantité de mémoire (RAM+SWAP) utilisée par les processus du VE. Elle est donc utile pour monitorer le VE.

privvmpages

Ce paramètre permet de contrôler la quantité de mémoire allouée par VE pour les processus. Cette quantité n’est toutefois pas garantie et dépend des ressources systèmes disponibles sur le HN. La quantité de mémoire garantie est définie par vmguardpages (voir plus haut). La somme des valeurs courantes (account) de privvmpages pour toutes les VE peut donc dépasser la quantité de mémoire (RAM+SWAP) disponible sur le HN. De plus la quantité de mémoire réellement utilisée par un VE est comptée par oomguardpages (voir plus haut).

Si la quantité de mémoire utilisée par le VE dépasse la valeur barrière de privvmpages, alors seule les allocations de mémoire prioritaires seront autorisées par le noyau (celles pour les processus déjà en cours d’exécution). Si cette quantité dépasse la valeur limite alors plus aucune allocation de mémoire ne sera autorisée et cela pourra provoquer une instabilité du VE.

Paramètres auxiliaires

lockedpages

Ce paramètre défini la quantité de mémoire bloquée, c’est à dire qui n’est pas autorisée à être mise sur la SWAP. Son fonctionnement est similaire à privvmpages au niveau des valeurs limite et barrière (voir plus haut).

La plupart des applications type serveur web, ftp, ou mail n’utilisent pas ce type de mémoire.

shmpages

Ce paramètre permet de définir la quantité de mémoire partagée (SHared Memory), c’est à dire la mémoire utilisable par plusieurs processus simultanément. C’est une méthode parfois utilisée pour faire communiquer deux processus entre eux. Son fonctionnement est également similaire à privvmpages (voir plus haut).

physpages

Ce paramètre est en lecture seule, c’est à dire que seule la valeur courante (account) évolue dans le temps et que les autres valeurs (limit et barrier) ne sont pas modifiables.

Il permet de quantifier la mémoire utilisée uniquement par les processus dans un VE. Elle est donc utile pour monitorer un VE.

numfile

Ce paramètre permet de contrôler le nombre de fichiers ouverts simultanément. Il a été développé uniquement pour les développeurs. Réduire la valeur limite de ce paramètre peut influer sur la stabilité d’un VE.

numflock

Ce paramètre contrôle le nombre de « lock » sur les fichiers. Un nombre trop élevé de « lock » peut baisser les performances d’un VE, la valeur limite doit donc être positionnée raisonnablement en fonction des besoins réels des applications.

numpty

C’est le nombre maximum de shell ouverts sur un VE. Le nombre de shell ouverts n’affecte pas les performances ou la stabilité d’un VE, toutefois le nombre maximum autorisé pour la valeur limite par le noyau OpenVZ est de 256.

numsiginfo

Ce paramètre permet de limiter le nombre de signaux de type SIGINFO simultanés sur un VE.

Une valeur limite trop élevée peut réduire les performances d’un VE et/ou du HN.

dcachesize

C’est la taille de la mémoire tampon pour les opérations sur disque dur. Si elle est supérieure à la valeur limite, la stabilité ou la sécurité d’un VE ne sera pas réduite, toutefois la performance des opérations sur disque sera réduite pour le VE uniquement.

numiptent

Ce paramètre permet de limiter le nombre d’entrées possibles pour iptables (netfilter). Si la limite est dépassée il y aura des erreurs dans le traitement de paquets par netfilter.

Une valeur trop importante provoquera un ralentissement du système, il est conseillé de limiter ce paramètre à une valeur maximale d’environ 250 entrées.

Exemple de fichier /proc/user_beancounters

Un fichier /proc/user_beancounters est donc disponible sur chaque VE. Il y en a également un sur le HN, il permet de lister celui de chaque VE ainsi que la somme des valeurs account pour chaque paramètre.

VE# cat /proc/user_beancounters

22: kmemsize 1124493 3977600 14372700 14790164 0

lockedpages 0 0 256 256 0

privvmpages 12703 39415 65536 69632 0

shmpages 0 1936 21504 21504 0

dummy 0 0 0 0 0

numproc 9 25 240 240 0

physpages 2151 17745 0 9223372036854775807 0

vmguarpages 0 0 33792 9223372036854775807 0

oomguarpages 2151 17745 26112 9223372036854775807 0

numtcpsock 2 12 360 360 0

numflock 1 5 188 206 0

numpty 0 3 16 16 0

numsiginfo 0 3 256 256 0

tcpsndbuf 34880 1343936 1720320 2703360 0

tcprcvbuf 32768 1125248 1720320 2703360 0

othersockbuf 2312 40080 1126080 2097152 0

dgramrcvbuf 0 2576 262144 262144 0

numothersock 16 38 360 360 0

dcachesize 102351 210219 3409920 3624960 0

numfile 215 649 9312 9312 0

dummy 0 0 0 0 0

dummy 0 0 0 0 0

dummy 0 0 0 0 0

numiptent 24 25 128 128 0

viaKafe-in.net Blog/OpenVZ : Les ressources système dans un VE.

OpenVZ resource limits can be a little tricky, even after reading through the documentation on the OpenVZ website. With this post, I hope to explain the /proc/user_beancounters file as well as provide an illustration of memory guarantees/limits in an example 256mb container.

Before attempting to understand OpenVZ’s memory limits, let’s recap Linux’s memory setup. This background information is important to firmly grasp OpenVZ’s behavior. You can safely skip this section if you already understand Linux’s memory overcommit accounting.

Linux Overcommit Accounting

Memory in Linux refers to the combined RAM + swap values. Memory is allocated from this pool using one of the *alloc() functions. If malloc() is used to allocate memory, the pages are not zeroed out. malloc() is unique in one regard: the kernel can malloc() more memory than what is available in RAM + swap. This behavior of allocating more than the total available memory is called overcommitting memory.

Seems like a recipe for disaster, huh? Imagine… processes are humming along allocating memory and BAM! some process wants to use the n’th + 1 byte of memory and an out of memory (OOM) condition provokes the kernel to start killing processes.

Why does the kernel allow memory to be overcommitted? Because most applications do not actually consume all of the malloc()’d memory. If an app doesn’t use a memory location, it does not really need to subtract from your total available memory.

Consider a typical Apache process. A full 20-30% of an Apache processes malloc()’d memory may not be consumed. With memory overcommit, this slice of memory can be used by other applications. Java applications also allocate much more than they use, as do many scientific applications.

At the system-wide level, these “malloc’d(), but not consumed” slices of memory begin to add up. By overcommitting memory, these slices don’t take up physical memory locations — resulting in more efficient use of memory resources.

OpenVZ and memory overcommit

OpenVZ also has the ability to overcommit memory. When creating an OpenVZ container, we specify the vmguarpages and oomguarpages resource guarantees. vmguarpages represents the maximum guaranteed amount of malloc()’d memory a container may have, while oomguarpages represents the maximum consumed memory. These are called guarantees because (If your server has enough RAM + swap) container processes will never be killed due to OOM if they are within these limits.

What if your container exceeds the vmguarpages or oomguarpages value? This is where a new limit comes in: privvmpages. privvmpages represents the absolute upper limit on container memory. When you run free or `cat /proc/meminfo` in a container, you see this privvmpages value take form as “Total memory”.

The memory gap between privvmpages and the two resource guarantees (vmguarpages and oomguarpages) is not safe to use in an ongoing basis if the sum of all container privvmpages exceeds RAM + swap of the hardware node. This is because if the hardware node runs out of memory, it begins looking for containers using more than their guaranteed memory. The kernel kills a process from the container who’s physpages exceeds oomguarpages the most.

I’ve created a diagram that hopefully illustrates the relationship between these three key memory limits/guarantees. Also included in the diagram is kmemsize, which is used for non-swappable kernel memory–not very important as long as it scales with privvmpages.

OpenVZ memory constraints

viamaxgarrick.com » Understanding OpenVZ resource limits.