Ajuste del rendimiento de Docker.

Puede utilizar la siguiente información relacionada con el ajuste de rendimiento para configurar sus entornos de HCL Commerce contenerizados y obtener un rendimiento óptimo.

En HCL Commerce Version 9.1, los servidores de aplicaciones (tienda, transacción, búsqueda) se ejecutan dentro de contenedores de Docker. A menudo, estos contenedores de Docker se gestionan mediante un sistema de organización de formularios de Docker, K8S, IBM Cloud Private, etc.

Con anterioridad, los servidores de aplicaciones de HCL Commerce se ejecutaban en entornos de caja física (servidores nativos) o virtuales, como LPAR, VMware y Xen. Docker ofrece otro nivel de virtualización, pero la tecnología de implementación de Docker difiere de la virtualización tradicional y, por lo tanto, afecta la manera en que se ajusta el rendimiento.

Las especificaciones siguientes se basan en los resultados de pruebas internas. El entorno de producción puede diferir de los entornos que se utilizan para llevar a cabo las pruebas internas. Supervise siempre los estados de su entorno de producción para establecer el ajuste del rendimiento.

Configuración de recursos del contenedor de Docker

Los contenedores de Docker incluyen los siguientes recursos informáticos generales:
  • CPU
  • Memoria
  • E/S de red
  • E/S de disco
Por lo general, no se limitan los E/S de red o E/S de disco para los contenedores de Docker de la aplicación Las limitaciones sólo afectan al CPU y al uso de la memoria de los contenedores de la aplicación. La limitación de recursos de memoria es más directa, ya que utiliza un parámetro de tamaño único. Por otra parte, la limitación de recursos del CPU es un poco más compleja. Por su parte, la limitación de recursos de CPU es un poco más compleja.

Comparación entre dos configuraciones diferentes para recursos de CPU

Docker ofrece varios métodos diferentes para controlar los recursos de CPU. Para obtener más información sobre cómo controlar los recursos de CPU, consulte Restricciones de tiempo de ejecución de Docker en Recursos.

CPUset/CPU-binding y CPU-quota son métodos de ajuste que se utilizan frecuentemente y son fáciles de comprender. Los hosts de Docker simultáneos que se basan en Linux poseen, por lo regular, varias CPU virtuales. CPUset enlaza los procesos del contenedor de Docker con CPU virtuales específicas. Por lo tanto, el límite superior del recurso de CPU que el contenedor de Docker puede utilizar está controlado por el número de CPU virtuales asignados. En entornos de Docker de producción, es posible que el contenedor de Docker no utilice el límite, ya que otros contenedores de Docker pueden competir con él en el mismo CPU virtual. De forma alternativa, CPU-quota es un método diferente de CPU que se basa en el tiempo. Este método controla el total del tiempo de CPU específico que el contenedor de Docker puede utilizar; sin embargo, el contenedor de Docker es capaz de utilizar libremente diferentes CPU virtuales. A primera vista, es posible que los dos enfoques parezcan iguales. Sin embargo, cuando se posee muchas CPU virtuales, los dos métodos pueden generar diferencias significativas de rendimiento. Cambiar procesos de Docker entre diferentes CPU virtuales también tiene consecuencias. Cuanto mayor sea el intervalo que hay entre el número de CPU-quota y el número total de CPU virtuales, mayor es la posibilidad de que un proceso de Docker tenga que moverse entre diferentes CPU virtuales.

La prueba interna realizó una comparación entre los dos enfoques para limitar los recursos del CPU. La prueba utilizó un servidor nativo con 24 CPU virtuales. Se llevaron a cabo tres casos de prueba con tres servidores de aplicaciones de HCL Commerce diferentes: Tienda, transacción y búsqueda. Cada prueba utilizó un contenedor de Docker para el nivel de aplicación de destino. El entorno también se configuró de manera que el único cuello de botella posible fuese el recurso de CPU del nivel de aplicación de destino. En otras palabras, salvo ese, se eliminaron todos los cuellos de botella potenciales.

La prueba interna descubrió el mismo patrón en los tres servidores:
  • En general, CPUset reveló un mejor rendimiento que el método CPUquota.
  • El número de CPU virtual óptimo es 6~8. Muy pocos (<=4) o demasiados (>=10) números de CPU virtuales pueden tener un impacto negativo en el rendimiento.

Valores recomendados para los recursos de CPU

En general, CPUset es un método seguro para limitar el número de recursos de CPU para los contenedores de Docker de HCL Commerce. Este enfoque se puede utilizar con docker-run o docker-compose para gestionar o ejecutar los contenedores. Lamentablemente, la modalidad CPUset restringe la capacidad que tiene de mover libremente los Dockers entre distintos hosts de Docker, lo que puede limitar el diseño del sistema de organización de Docker. Por lo tanto, la mayoría de los sistemas de Docker sólo son compatibles con el método CPUquota para controlar el uso de los recursos de CPU. Además, suele haber un número "predeterminado" de CPU para cada Docker de aplicación. Por ejemplo, el límite de recursos de CPU es 2 CPU virtuales para sistemas K8S/IBM Cloud Private. Esto no debería ser un problema si el host del Docker sólo tiene unas pocas CPU virtuales. Sin embargo, si el host del Docker tiene muchas CPU virtuales, considere la posibilidad de cambiar el límite de CPU a 6~8 para contenedores de aplicaciones.

Valores recomendados para los recursos de memoria

HCL Commerce : estos servidores de aplicaciones son todos programas Java. Con la inclusión de contenedores, se puede producir una confusión sobre del tamaño de almacenamiento dinámico de JVM y el tamaño de memoria para procesos de Docker. Los programas Java requieren de dps secciones de memoria: el almacenamiento dinámico de JVM y nativo, en específico la memoria que se utiliza para el programa de gestión de JVM en lugar del código de aplicación Java. La memoria física total necesaria para contenedores de Docker de HCL Commerce es la suma de las dos secciones.

Hoy en día, los servidores de aplicaciones de HCL Commerce necesitan el tamaño de su almacenamiento dinámico para JVM sea de 2 GB~4 GB. Para obtener más información, consulte Valores ajustables predeterminados de HCL Commerce.

El límite predeterminado de recursos de memoria para contenedores de aplicaciones en el sistema K8S/IBM Cloud Private es de 4 GB. Cuando el almacenamiento dinámico de la JVM de la aplicación de HCL Commerce se aproxima a los 4 GB, el tamaño de la memoria total es superior a 4 GB ya que se cuenta con más espacio para el almacenamiento dinámico nativo. Como resultado, la memoria se limita y el contenedor de aplicación finaliza.

En este caso, la solución correcta es añadir un almacenamiento intermedio adicional para la memoria intermedia nativa. En la mayoría de los casos, puede añadir un almacenamiento intermedio de 2 GB para el almacenamiento dinámico nativo. Si el tamaño máximo de almacenamiento dinámico de JVM es de 4 GB, debe establecer en 6 GB el límite de recursos para el contenedor de aplicación. Si el tamaño máximo de almacenamiento dinámico de JVM es superior a 4 GB, aumente el límite de la memoria de Docker según corresponda. Al igual que el ajuste de rendimiento, es necesario realizar pruebas de rendimiento para determinar estos valores.

Note: Todos los valores de CPU/memoria ya mencionados son específicos para los entornos de prueba de producción o de rendimiento. Cuando se trabaja con entornos de prueba de creación o funcionales, el sistema no suele utilizarse al máximo, por lo que el límite de la CPU/memoria puede configurarse con un valor menor; por ejemplo: 2 CPU virtuales/4GB de memoria.