Admin Linux - Gerenciamento de recursos com crgoups
cgroups ou grupos de controle são um recurso do kernel do Linux que permite a um administrador alocar ou limitar os recursos do sistema para serviços e também grupos.
Para listar os grupos de controle ativos em execução, podemos usar o seguinte comando ps -
[root@localhost]# ps xawf -eo pid,user,cgroup,args
8362 root - \_ [kworker/1:2]
1 root - /usr/lib/systemd/systemd --switched-
root --system -- deserialize 21
507 root 7:cpuacct,cpu:/system.slice /usr/lib/systemd/systemd-journald
527 root 7:cpuacct,cpu:/system.slice /usr/sbin/lvmetad -f
540 root 7:cpuacct,cpu:/system.slice /usr/lib/systemd/systemd-udevd
715 root 7:cpuacct,cpu:/system.slice /sbin/auditd -n
731 root 7:cpuacct,cpu:/system.slice \_ /sbin/audispd
734 root 7:cpuacct,cpu:/system.slice \_ /usr/sbin/sedispatch
737 polkitd 7:cpuacct,cpu:/system.slice /usr/lib/polkit-1/polkitd --no-debug
738 rtkit 6:memory:/system.slice/rtki /usr/libexec/rtkit-daemon
740 dbus 7:cpuacct,cpu:/system.slice /bin/dbus-daemon --system --
address=systemd: --nofork --nopidfile --systemd-activation
O gerenciamento de recursos, a partir do CentOS 6.X, foi redefinido com a implementação init do systemd . Ao pensar em Gerenciamento de Recursos para serviços, o principal foco são os cgroups .cgroupsavançaram com o systemd em funcionalidade e simplicidade.
O objetivo dos cgroups no gerenciamento de recursos é - nenhum serviço pode derrubar o sistema como um todo. Ou nenhum processo de serviço único (talvez um script PHP mal escrito) prejudicará a funcionalidade do servidor por consumir muitos recursos.
cgroups permitem controle de recursos de unidades para os seguintes recursos -
CPU - Limite as tarefas intensivas da CPU que não são críticas como outras tarefas menos intensivas
Memory - Limite a quantidade de memória que um serviço pode consumir
Disks - Limitar i / o do disco
** Tempo de CPU: **
Tarefas que precisam de menos prioridade de CPU podem ter fatias de CPU configuradas de maneira personalizada.
Vamos dar uma olhada nos dois serviços a seguir, por exemplo.
Polite CPU Service 1
[root@localhost]# systemctl cat polite.service
# /etc/systemd/system/polite.service
[Unit]
Description = Polite service limits CPU Slice and Memory
After=remote-fs.target nss-lookup.target
[Service]
MemoryLimit = 1M
ExecStart = /usr/bin/sha1sum /dev/zero
ExecStop = /bin/kill -WINCH ${MAINPID}
WantedBy=multi-user.target
# /etc/systemd/system/polite.service.d/50-CPUShares.conf
[Service]
CPUShares = 1024
[root@localhost]#
Evil CPU Service 2
[root@localhost]# systemctl cat evil.service
# /etc/systemd/system/evil.service
[Unit]
Description = I Eat You CPU
After=remote-fs.target nss-lookup.target
[Service]
ExecStart = /usr/bin/md5sum /dev/zero
ExecStop = /bin/kill -WINCH ${MAINPID}
WantedBy=multi-user.target
# /etc/systemd/system/evil.service.d/50-CPUShares.conf
[Service]
CPUShares = 1024
[root@localhost]#
Vamos definir o Serviço Polite usando uma prioridade de CPU menor -
systemctl set-property polite.service CPUShares = 20
/system.slice/polite.service
1 70.5 124.0K - -
/system.slice/evil.service
1 99.5 304.0K - -
Como podemos ver, durante um período normal de tempo ocioso do sistema, ambos os processos invasores ainda usam ciclos de CPU. No entanto, aquele configurado para ter menos fatias de tempo está usando menos tempo de CPU. Com isso em mente, podemos ver como o uso de um intervalo de tempo menor permitiria que tarefas essenciais acessassem melhor os recursos do sistema.
Para definir serviços para cada recurso, o método set-property define os seguintes parâmetros -
systemctl set-property name parameter=value
Fatias de CPU | CPUShares |
Limite de Memória | MemoryLimit |
Limite de memória suave | MemorySoftLimit |
Peso IO do bloco | BlockIOWeight |
Limite de dispositivo de bloqueio (especificado em / volume / caminho)) | BlockIODeviceWeight |
Leia IO | BlockIOReadBandwidth |
Gravação de disco IO | BlockIOReadBandwidth |
Na maioria das vezes, os serviços serão limitados pelo uso da CPU , limites de memória e E / S de leitura / gravação .
Após alterar cada um, é necessário recarregar o systemd e reiniciar o serviço -
systemctl set-property foo.service CPUShares = 250
systemctl daemon-reload
systemctl restart foo.service
Configurar CGroups no CentOS Linux
Para fazer cgroups personalizados no CentOS Linux, precisamos primeiro instalar os serviços e configurá-los.
Step 1 - Instale o libcgroup (se ainda não estiver instalado).
[root@localhost]# yum install libcgroup
Package libcgroup-0.41-11.el7.x86_64 already installed and latest version
Nothing to do
[root@localhost]#
Como podemos ver, por padrão o CentOS 7 tem o libcgroup instalado com o instalador de tudo . Usar um instalador mínimo exigirá que instalemos os utilitários libcgroup junto com todas as dependências.
Step 2 - Inicie e ative o serviço cgconfig.
[root@localhost]# systemctl enable cgconfig
Created symlink from /etc/systemd/system/sysinit.target.wants/cgconfig.service
to /usr/lib/systemd/system/cgconfig.service.
[root@localhost]# systemctl start cgconfig
[root@localhost]# systemctl status cgconfig
● cgconfig.service - Control Group configuration service
Loaded: loaded (/usr/lib/systemd/system/cgconfig.service; enabled; vendor
preset: disabled)
Active: active (exited) since Mon 2017-01-23 02:51:42 EST; 1min 21s ago
Main PID: 4692 (code=exited, status = 0/SUCCESS)
Memory: 0B
CGroup: /system.slice/cgconfig.service
Jan 23 02:51:42 localhost.localdomain systemd[1]: Starting Control Group
configuration service...
Jan 23 02:51:42 localhost.localdomain systemd[1]: Started Control Group
configuration service.
[root@localhost]#