directorio
Un .docker Gestión de Recursos general
Optimización de los recursos .CPU
III. Optimizar los recursos de memoria
III. Optimizar el disco E / S de lectura y escritura
Un .docker Gestión de Recursos general
- Desde el anfitrión puede poner una pluralidad de recipientes, de forma predeterminada, no hay límite en el espejo contenedor recursos de hardware acoplables
- Cuando el contenedor de carga es demasiado alta se ocupará de los recursos de acogida tanto como sea posible, así que a veces tenemos que utilizar recursos para establecer un límite superior para el envase
- Uso systemctl-cgtop visión dinámica del uso de varios recursos (asignación de recursos de acuerdo con la situación del contenedor ventana acoplable)
[root@cloud ~]# systemd-cgtop
Path Tasks %CPU Memory Input/s Output/s
/ 55 4.5 2.7G - -
/system.slice - 3.6 468.6M - -
/system.slice/aegis.service 3 3.3 109.5M - -
/user.slice 3 0.9 11.0M - -
/system.slice/containerd.service 1 0.2 83.0M - -
/system.slice/aliyun.service 1 0.0 2.4M - -
/system.slice/tuned.service 1 0.0 13.0M - -
/system.slice/rsyslog.service 1 0.0 2.9M - -
/system.slice/atd.service 1 - - - -
/system.slice/auditd.service 1 - 1.3M - -
/system.slice/chronyd.service 1 - 532.0K - -
/system.slice/crond.service 1 - 716.0K - -
/system.slice/dbus.service 1 - 36.0K - -
/system.slice/docker.service 1 - 228.5M - -
/system.slice/lvm2-lvmetad.service 1 - - - -
/system.slice/network.service 1 - 1.9M - -
/system.slice/polkit.service 1 - 7.9M - -
- Docker recursos para el control, respectivamente, por la memoria, CPU, disco de lectura y escritura, etc., que se describe en detalle más adelante
Optimización de los recursos .CPU
- Por defecto, cada contenedor se puede utilizar todos los recursos de la CPU en el host, pero el sistema de planificación de recursos utilizados por la mayoría de SFC (Completamente programador de reparto justo)
- CFS justo programación de cada proceso de trabajo
- Proceso se divide en dos tipos de IO CPU-intensivo e intensivo
- El núcleo del sistema procesará sistema de monitoreo en tiempo real, cuando un proceso recursos de la CPU durante demasiado tiempo, el núcleo ajustar la prioridad del proceso de
- Éstos son algunos de los parámetros de los recursos de la CPU ventana acoplable límite de mando
| nombre del parámetro | explicación |
| --cpu-acciones | recursos de la CPU proporciona un conjunto de contenedores, el contenedor utilizado en los recursos de CPU escala de grupo, la carga de recursos golpeado cpu ocupada recipiente (relación de compresión de acuerdo con la asignación), Estar en funcionamiento cuando está en reposo, los recursos de CPU se asignarán a otros recipientes |
| --cpus = valor |
Especifica el número de núcleo de la CPU |
| --cpuset CPUs | contenedor especificado sólo se puede ejecutar en el núcleo de la CPU (CPU de unión); número de la base usando 0,1,2,3 |
| --cpu de cuotas | El límite superior del porcentaje especificado de cpu |
-
Ver CPU detalles del sistema Linux
##查看详细信息
[root@cloud ~]# cat /proc/cpuinfo
##查看CPU的核数
[root@cloud ~]# cat /proc/cpuinfo | grep "processor"
processor : 0
processor : 1
[root@cloud ~]#
-
Para las restricciones de uso de la CPU
## --name 指定容器的名字
## --cpu-quota 200000 指定该容器对于cpu的使用率上限是20%
[root@cloud ~]# docker run --name c0 --cpu-quota 200000 nginx:latest
[root@cloud ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2a0222c54f1a nginx:latest "nginx -g 'daemon of…" About an hour ago Up 1 second 80/tcp c0
[root@cloud ~]#
-
Para la asignación proporcional de cpu
##-i表示输入，-t表示绑定终端，-d表示开启守护进程
[root@cloud ~]# docker run -itd --name c1 --cpu-shares 512 httpd
cfa4b5f14f75ef2f30d884d11341582396401c767675a11b43e029a40a1ea207
[root@cloud ~]# docker run -itd --name c2 --cpu-shares 1024 httpd
118e74d7fa84f5d1fcac7e6ed028e185fde6d2c6edceab89a10ab609d7bd9052
[root@cloud ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
118e74d7fa84 httpd "httpd-foreground" 9 seconds ago Up 8 seconds 80/tcp c2
cfa4b5f14f75 httpd "httpd-foreground" 20 seconds ago Up 18 seconds 80/tcp c1
2a0222c54f1a nginx:latest "nginx -g 'daemon of…" 2 hours ago Exited (0) 2 minutes ago c0
[root@cloud ~]#
- Para la CPU limitar el número de armas nucleares
[root@cloud ~]# cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
[root@cloud ~]# docker run -itd --name c3 --cpuset-cpus 0,1 httpd
271eaa8de989f1decf23ddada071db801348e607c6a4ed3b6ee2ad0671482d4a
[root@cloud ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
271eaa8de989 httpd "httpd-foreground" 5 seconds ago Up 4 seconds 80/tcp c3
118e74d7fa84 httpd "httpd-foreground" 3 minutes ago Up 3 minutes 80/tcp c2
cfa4b5f14f75 httpd "httpd-foreground" 3 minutes ago Up 3 minutes 80/tcp c1
2a0222c54f1a nginx:latest "nginx -g 'daemon of…" 2 hours ago Exited (0) 6 minutes ago c0
[root@cloud ~]#
III. Optimizar los recursos de memoria
- Por defecto, el recipiente acoplable hay límite de memoria, es decir, el contenedor se puede utilizar toda la memoria proporcionada por el anfitrión.
- Si el recipiente no restringe la memoria, causará algún peligro. Por ejemplo, un envase de consumo de memoria para ejecutar el software malicioso, o código tiene pérdidas de memoria, es probable que la memoria principal de plomo se agota, lo que resulta en el servicio no está disponible.
- Para el caso anterior, la ventana acoplable daemon acoplable establece OOM (de memoria) valor, a fin de disminuir mató a la memoria de baja prioridad. Además, se puede proporcionar el límite superior de la memoria para cada recipiente, una vez excedido este límite, el contenedor será matado, sin consumir la memoria del anfitrión
- A pesar de que, a pesar de que puede limitar el límite de memoria para proteger al huésped, sino que también podría perjudicar al servicio de contenedores. Si la memoria es demasiado pequeña para establecer el límite superior del servicio, conducirá el servicio aún funciona bien cuando lo mataron OOM. Si es muy grande, porque algoritmo planificador de memoria emaciación. enfoque razonable incluyen:
1. La memoria para la solicitud de hacer pruebas de esfuerzo, para entender la memoria cuando se utiliza en las necesidades normales de trabajo, a continuación, utilizar para entrar en el entorno de construcción
2. El contenedor de uso de la memoria límite superior
3. medida de lo posible para garantizar recursos suficientes para anfitrión, una vez encontrado mediante el control de la falta de recursos, es para la expansión o la migración del recipiente
4. Si suficientes recursos de memoria, reducir al mínimo el uso de intercambio, el canje causaría una memoria complejidad computacional del planificador muy antipático
- En los parámetros de arranque estibador, y las limitaciones de memoria comprenden asociado (parámetro se refiere en general al tamaño de la memoria, las unidades de memoria, respectivamente, b (bytes), k (KB), M (mb), G (GB)), los parámetros son como sigue :
| parámetros | explicación |
| -m o --memory | El tamaño máximo de memoria del recipiente se puede utilizar, para el 4m mínimo |
| --memory-swap | tamaño del recipiente se puede utilizar para intercambio |
| --memory-swappiness | Por defecto, el anfitrión puede utilizar la página contenedores anónima (página anónima) intercambiar, que se puede configurar un valor entre 0-100, representantes Permitir que el intercambio fuera de proporción |
| --memory-reserva | Configuración de un uso de la memoria límite blando, si se encuentra la memoria del host ventana acoplable insuficiente, OOM realizará la operación. Este valor debe ser menor que el valor establecido -m |
| --kernel memoria | kernel tamaño de la memoria del recipiente se puede utilizar, para el 4m mínimo |
| --oom-kill-disable | El tiempo se acaba contenedor matanza OOM. Sólo -m conjunto, se puede poner esta opción es falso, de lo contrario el contenedor se quede sin memoria anfitrión, y haciendo que la aplicación host se mató |
- Los ejemplos son como sigue
[root@cloud ~]# free -m
total used free shared buff/cache available
Mem: 3789 223 664 0 2900 3282
Swap: 0 0 0
[root@cloud ~]# docker run -itd --name c4 -m 512m httpd:latest
a1834d69cb55e6809211d381d6ca7c2acfe52cbc11be37293f48c2bfb52e2d0a
[root@cloud ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1834d69cb55 httpd:latest "httpd-foreground" 5 seconds ago Up 4 seconds 80/tcp c4
271eaa8de989 httpd "httpd-foreground" 28 minutes ago Exited (0) 27 minutes ago c3
118e74d7fa84 httpd "httpd-foreground" 32 minutes ago Exited (0) 27 minutes ago c2
cfa4b5f14f75 httpd "httpd-foreground" 32 minutes ago Exited (0) 27 minutes ago c1
2a0222c54f1a nginx:latest "nginx -g 'daemon of…" 2 hours ago Exited (0) 34 minutes ago c0
[root@cloud ~]#
- Observe recurso recipiente Docke uso
[root@cloud ~]# docker stats
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
a1834d69cb55 c4 0.00% 14.1MiB / 512MiB 2.75% 0B / 0B 0B / 0B 82
III. Optimizar el disco E / S de lectura y escritura
- IO recursos, el sistema operativo es también un recurso muy importante, a menudo contienen leer y escribir en el disco duro, el intercambio de datos de red, etc.
- El método de control de escritura recipiente duro:
1. Establecer el disco duro para leer y escribir el peso del contenedor recursos
2. límite bps (cantidad de datos) y de IOPS (veces)
bps: bytes por segundo, el número de bytes que se leen por segundo (, es decir, leen y las tasas de escritura)
iops: el número de io por segundo, IO por segundo
- conjunto de peso
Al utilizar carrera ventana acoplable a partir parámetros de suministro de contenedores --blkio peso int priority nos puede ayudar en el disco contenedor de control leer y escribir (bloque IO) de
- Restricciones bps y iops
1 .-- dispositivo-read-bps (restricciones lectura de un dispositivo bps)
2 .-- dispositivo de lectura-escritura-bps (bps escribiendo un dispositivo de restricción)
3 .-- dispositivo-read-iops (restricciones lectura de un dispositivo iops)
4 .-- dispositivo de escritura IOPS (IOPS un dispositivo de escritura límite)
- Ejemplos
