Limitez la mémoire et le processeur avec lxc-execute


9

Je voudrais isoler les processus utilisant lxc-execute. Est-il possible de définir la bande passante, le processeur et la limite de mémoire?

J'ai jeté un œil à l'homme de lxc.conf mais je ne l'ai pas trouvé exhaustif.

Réponses:


23

Tout d'abord, je voudrais que vous compreniez les Cgroups qui font partie de l'utilitaire LXC. lorsque vous avez un conteneur, vous voudrez évidemment vous assurer que les différents conteneurs que vous exécutez affament tout autre conteneur ou processus à l'intérieur. Dans cet esprit, le gentil gars du projet LXCalias Daniel Lezcano a intégré les groupes de contrôle avec la technologie de conteneur qu'il créait, c'est-à-dire LXC. Maintenant, si vous souhaitez affecter l'utilisation des ressources, vous devrez examiner la configuration de votre CGROUP. Les groupes de contrôle vous permettent d'allouer des ressources (telles que le temps processeur, la mémoire système, la bande passante réseau ou des combinaisons de ces ressources) entre des groupes de tâches (processus) définis par l'utilisateur exécutés sur un système. Vous pouvez surveiller les groupes de contrôle que vous configurez, refuser l'accès aux groupes de contrôle à certaines ressources et même reconfigurer dynamiquement vos groupes de contrôle sur un système en cours d'exécution. Le service cgconfig (configuration du groupe de contrôle) peut être configuré pour démarrer au démarrage et rétablir vos groupes de contrôle prédéfinis, les rendant ainsi persistants lors des redémarrages. Les groupes de contrôle peuvent avoir plusieurs hiérarchies car chaque hiérarchie est attachée à un ou plusieurs sous-systèmes (également appelés contrôleurs de ressources ou contrôleurs). Cela créera alors plusieurs arbres qui ne sont pas connectés. Il existe neuf sous-systèmes disponibles.

  1. blkio fixe des limites sur l'accès aux entrées / sorties sur les périphériques blocs
  2. planificateur cpu pour l'accès des tâches cgroup au CPU
  3. cpuacct génère des rapports pour l'utilisation du CPU et cgroup
  4. cpuset attribue des processeurs et de la mémoire à un groupe de contrôle
  5. les appareils gèrent l'accès aux appareils par tâches
  6. congélation suspendre / reprendre les tâches
  7. mémoire limite mémoire
  8. Les paquets réseau de balises net_cls permettent au contrôleur de trafic Linux d'identifier le trafic des tâches
  9. espace de noms ns

Nous pouvons lister les sous-systèmes que nous avons dans notre noyau par la commande:

lssubsys –am

lxc-cgroup récupère ou définit la valeur du groupe de contrôle associé au nom du conteneur. Gérez le groupe de contrôle associé à un conteneur. exemple d'utilisation:

lxc-cgroup -n foo cpuset.cpus "0,3" 

affectez les processeurs 0 et 3 au conteneur.

Maintenant, j'ai à mon avis répondu à votre question initiale. Mais permettez-moi d'ajouter un peu des paramètres qui pourraient vous être utiles pour configurer votre conteneur pour utiliser lxc. il existe une forme condensée de la documentation du contrôle des ressources par redhat

Paramètres modifiables BLKIO:

    blkio.reset_stats : any int to reset the statistics of BLKIO
    blkio.weight : 100 - 1000 (relative proportion of block I/O access)
    blkio.weight_device : major, minor , weight 100 - 1000 
    blkio.time : major, minor and time (device type and node numbers and length of access in milli seconds)
    blkio.throttle.read_bps_device : major, minor specifies the upper limit on the number of read operations a device can perform. The rate of the read operations is specified in bytes per second.
    blkio.throttle.read_iops_device :major, minor and operations_per_second specifies the upper limit on the number of read operations a device can  perform
    blkio.throttle.write_bps_device : major, minor and bytes_per_second (bytes per second)
    blkio.throttle.write_iops_device : major, minor and operations_per_second

Paramètres modifiables CFS:

    cpu.cfs_period_us : specifies a period of time in microseconds for how regularly a cgroup's access to CPU resources should be reallocated. If tasks in a cgroup should be able to access a single CPU for 0.2 seconds out of every 1 second, set cpu.cfs_quota_us to 200000 and cpu.cfs_period_us to 1000000.
    cpu.cfs_quota_us : total amount of time in microseconds that all tasks in a cgroup can run during one period. Once limit has reached, they are not allowed to run beyond that. 
    cpu.shares : contains an integer value that specifies the relative share of CPU time available to tasks in a cgroup.


    Note: For example, tasks in two cgroups that have cpu.shares set to 1 will receive equal CPU time, but tasks in a cgroup that has cpu.shares set to 2 receive twice the CPU time of tasks in a cgroup where cpu.shares is set to 1. Note that shares of CPU time are distributed per CPU. If one cgroup is limited to 25% of CPU and another cgroup is limited to 75% of CPU, on a multi-core system, both cgroups will use 100% of two different CPUs. 

Paramètres modifiables RT:

cpu.rt_period_us : time in microseconds for how regularly a cgroups access to CPU resources should be reallocated. 
cpu.rt_runtime_us : same as above.

CPUset:

cpuset subsystem assigns individual CPUs and memory nodes to cgroups.
Note: here some parameters are mandatory
Mandatory: 


cpuset.cpus : specifies the CPUs that tasks in this cgroup are permitted to access. This is a comma-separated list in ASCII format, with dashes (" -")                 to represent ranges. For example 0-2,16 represents CPUs 0, 1, 2, and 16. 
        cpuset.mems : specifies the memory nodes that tasks in this cgroup are permitted to access. same as above format


Optional: 
        cpuset.cpu_exclusive : contains a flag ( 0 or 1) that specifies whether cpusets other than this one and its parents and children can share the CPUs specified for this cpuset. By default ( 0), CPUs are not allocated exclusively to one cpuset. 
        cpuset.mem_exclusive : contains a flag ( 0 or 1) that specifies whether other cpusets can share the memory nodes specified for this cpuset. By default ( 0), memory nodes are not allocated exclusively to one cpuset. Reserving memory nodes for the exclusive use of a cpuset ( 1) is functionally the same as enabling a memory hardwall with the cpuset.mem_hardwall parameter.
        cpuset.mem_hardwall : contains a flag ( 0 or 1) that specifies whether kernel allocations of memory page and buffer data should be restricted to the memory nodes specified for this cpuset. By default ( 0), page and buffer data is shared across processes belonging to multiple users. With a hardwall enabled ( 1), each tasks' user allocation can be kept separate.
        cpuset.memory_pressure_enabled : contains a flag ( 0 or 1) that specifies whether the system should compute the memory pressure created by the processes in this cgroup
        cpuset.memory_spread_page : contains a flag ( 0 or 1) that specifies whether file system buffers should be spread evenly across the memory nodes allocated to this cpuset. By default ( 0), no attempt is made to spread memory pages for these buffers evenly, and buffers are placed on the same node on which the process that created them is running. 
        cpuset.memory_spread_slab : contains a flag ( 0 or 1) that specifies whether kernel slab caches for file input/output operations should be spread evenly across the cpuset. By default ( 0), no attempt is made to spread kernel slab caches evenly, and slab caches are placed on the same node on which the process that created them is running.
        cpuset.sched_load_balance : contains a flag ( 0 or 1) that specifies whether the kernel will balance loads across the CPUs in this cpuset. By default ( 1), the kernel balances loads by moving processes from overloaded CPUs to less heavily used CPUs.

Dispositifs:

The devices subsystem allows or denies access to devices by tasks in a cgroup. 
    devices.allow : specifies devices to which tasks in a cgroup have access. Each entry has four fields: type, major, minor, and access.
    type can be of following three values: 
        a - applies to all devices
        b - block devices
        c - character devices
    access is a sequence of one or more letters: 
        r read from device
        w write to device
        m create device files that do not yet exist

    devices.deny : similar syntax as above
    devices.list : reports devices for which access control has been set for tasks in this cgroup

Mémoire:

Le sous-système de mémoire génère des rapports automatiques sur les ressources de mémoire utilisées par les tâches dans un groupe de contrôle et définit les limites d'utilisation de la mémoire par ces tâches Paramètres de mémoire modifiables: memory.limit_in_bytes: définit la quantité maximale de mémoire utilisateur. peut utiliser des suffixes comme K pour kilo et M pour méga, etc. Cela ne limite que les groupes inférieurs de la hiérarchie. c'est-à-dire que le groupe de racine ne peut pas être limité memory.memsw.limit_in_bytes: définit la quantité maximale pour la somme de la mémoire et l'utilisation du swap. encore une fois, cela ne peut pas limiter le groupe racine.

    Note: memory.limit_in_bytes should always be set before memory.memsw.limit_in_bytes because only after limit, can swp limit be set
    memory.force_empty : when set to 0, empties memory of all pages used by tasks in this cgroup
    memory.swappiness : sets the tendency of the kernel to swap out process memory used by tasks in this cgroup instead of reclaiming pages from the page cache. he default value is 60. Values lower than 60 decrease the kernel's tendency to swap out process memory, values greater than 60 increase the kernel's tendency to swap out process memory, and values greater than 100 permit the kernel to swap out pages that are part of the address space of the processes in this cgroup. 


    Note: Swappiness can only be asssigned to leaf groups in the cgroups architecture. i.e if any cgroup has a child cgroup, we cannot set the swappiness for that
    memory.oom_control : contains a flag ( 0 or 1) that enables or disables the Out of Memory killer for a cgroup. If enabled ( 0), tasks that attempt to consume more memory than they are allowed are immediately killed by the OOM killer. 

net_cls:

Le sous-système net_cls marque les paquets réseau avec un identificateur de classe (classid) qui permet au contrôleur de trafic Linux (tc) d'identifier les paquets provenant d'un groupe de contrôle particulier. Le contrôleur de trafic peut être configuré pour attribuer différentes priorités aux paquets de différents groupes de contrôle.

net_cls.classid : 0XAAAABBBB AAAA = major number (hex)
                         BBBB = minor number (hex)
        net_cls.classid contains a single value that indicates a traffic control handle. The value of classid read from the net_cls.classid file is presented in the decimal format while the value to be written to the file is expected in the hexadecimal format. e.g. 0X100001 = 10:1

net_prio:

Le sous-système Network Priority (net_prio) fournit un moyen de définir dynamiquement la priorité du trafic réseau pour chaque interface réseau pour les applications au sein de divers groupes de contrôle. La priorité d'un réseau est un numéro attribué au trafic réseau et utilisé en interne par le système et les périphériques réseau. La priorité réseau est utilisée pour différencier les paquets envoyés, mis en file d'attente ou abandonnés. le contrôleur de trafic (tc) est chargé de définir la priorité des réseaux.

net_prio.ifpriomap : networkinterface , priority (/cgroup/net_prio/iscsi/net_prio.ifpriomap)
        Contents of the net_prio.ifpriomap file can be modified by echoing a string into the file using the above format, for example:

            ~]# echo "eth0 5" > /cgroup/net_prio/iscsi/net_prio.ifpriomap

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.