Gestión de recursos de CPU de GaussDB(DWS)

Descripción de la gestión de recursos de CPU

En diferentes escenarios de servicio, los recursos del sistema (CPU, memoria, E/S y recursos de almacenamiento) de la base de datos se asignan correctamente a las consultas para garantizar el rendimiento de las consultas y la estabilidad del servicio.

GaussDB(DWS) proporciona la función de gestión de recursos. Puede poner recursos en diferentes grupos de recursos, que están aislados entre sí. A continuación, puede asociar usuarios de base de datos a estos grupos de recursos. Cuando un usuario inicia una consulta de SQL, la consulta se transferirá al grupo de recursos asociado con el usuario. Puede especificar el número de consultas que se pueden ejecutar simultáneamente en un grupo de recursos, el límite superior de memoria utilizado para una sola consulta y los recursos de memoria y CPU que puede utilizar un grupo de recursos. De esta manera, puede limitar y aislar los recursos ocupados por diferentes cargas de trabajo.

GaussDB(DWS) utiliza cgroups para gestionar y controlar recursos de CPU, involucrando los subsistemas de CPU, de cpuacct y de cpuset. El recurso compartido de CPU se implementa basándose en el subsistema de CPU cpu.shares. Las ventajas de compartir la CPU son las siguientes: El control de la CPU no se activa cuando la CPU del SO no está completamente ocupada. El límite de CPU se implementa basándose en cpuset, que es un subsistema de CPU usado para monitorear el uso de recursos de CPU.

Al agregar un grupo de recursos en la consola de gestión de GaussDB(DWS), debe elegir entre Share y Limit.

Compartir CPU

CPU Share: Porcentaje de tiempo de CPU que pueden utilizar los usuarios asociados al grupo de recursos actual para ejecutar trabajos.

La acción tiene dos significados:

• Compartir: La CPU es compartida por todos los Cgroups. Los recursos de CPU inactivos pueden ser utilizados por otros Cgroups.
• Cuota: Cuando la CPU está completamente cargada durante las horas pico, los Cgroups prefieren los recursos de CPU en función de sus cuotas.

El uso compartido de CPU se implementa basado en cpu.shares y solo tiene efecto cuando la CPU está completamente cargada. Cuando la CPU está inactiva, no hay garantía de que un Cgroup se adelantará a los recursos de CPU apropiados a su cuota. Todavía puede haber contención de recursos cuando la CPU está inactiva. Las tareas en un Cgroup pueden usar recursos de CPU sin restricciones. Aunque el uso promedio de CPU puede no ser alto, la contención de recursos de CPU todavía puede ocurrir en un momento específico.

Por ejemplo, 10 trabajos se están ejecutando en 10 CPU, y un trabajo se está ejecutando en cada CPU. En este caso, cualquier solicitud de trabajo para recursos de CPU se responderá instantáneamente, y no hay ninguna contención. Si se ejecutan 20 trabajos en 10 CPU, es posible que el uso de CPU aún no sea alto porque los trabajos no siempre ocupan la CPU y pueden esperar recursos de E/S y de red. Los recursos de CPU parecen estar inactivos. Sin embargo, si 2 o más trabajos solicitan una CPU al mismo tiempo, se produce una contención de recursos de CPU, lo que afecta al rendimiento del trabajo.

Límite de CPU

CPU Limit: especifica el porcentaje del número máximo de núcleos de CPU que puede utilizar un usuario de base de datos en el grupo de recursos.

El límite de CPU se implementa basado en cpuset.cpu. Puede establecer una cuota adecuada para implementar el aislamiento absoluto de los recursos de CPU entre Cgroups. De esta manera, las tareas de los diferentes Cgroups no se afectarán entre sí. Sin embargo, el aislamiento absoluto de la CPU hará que los recursos inactivos de la CPU en un Cgroup sean desperdiciados. Por lo tanto, el límite no puede ser demasiado grande. Un límite mayor puede no traer un mejor rendimiento.

Por ejemplo, en un caso, 10 trabajos se ejecutan en 10 CPU y el uso promedio de CPU es de aproximadamente el 5%. En otro caso, 10 trabajos se ejecutan en 5 CPUs y el uso promedio de CPU es de aproximadamente el 10%. De acuerdo con el análisis anterior, aunque el uso de CPU es bajo cuando se ejecutan 10 trabajos en cinco CPU. Sin embargo, todavía existe contención de recursos de CPU. Por lo tanto, el rendimiento de ejecutar 10 trabajos en 10 CPU es mejor que el de ejecutar 10 trabajos en 5 CPUs. Pero más CPU no siempre es mejor. Si diez trabajos se ejecutan en 20 CPUs, en cualquier momento, al menos 10 CPUs están inactivas. Por lo tanto, teóricamente, ejecutar 10 trabajos en 20 CPUs no tiene mejor rendimiento que ejecutar 10 CPUs. Para un Cgroup con una concurrencia de N, si el número de CPU asignadas es menor que N, el rendimiento del trabajo es mejor con más CPU. Sin embargo, si el número de CPU asignadas es mayor que N, el rendimiento del trabajo no se mejorará con más CPU.

Escenarios de aplicación de la gestión de recursos de CPU

El límite de CPU y la cuota de CPU tienen sus propias ventajas y desventajas. El uso compartido de la CPU puede utilizar completamente los recursos de la CPU. Sin embargo, los recursos de diferentes Cgroups no están completamente aislados, lo que puede afectar al rendimiento de la consulta. El límite de CPU puede implementar el aislamiento absoluto de los recursos de CPU. Sin embargo, los recursos de CPU inactivos se desperdiciarán. En comparación con el límite de CPU, el uso compartido de CPU tiene un mayor uso de CPU y un rendimiento general de trabajo. En comparación con el uso compartido de CPU, el límite de CPU tiene un aislamiento completo de la CPU, lo que puede satisfacer mejor los requisitos de los usuarios sensibles al rendimiento.

Si se produce contención de CPU cuando se ejecutan varios tipos de trabajos en el sistema de base de datos, puede seleccionar diferentes modos de control de recursos de CPU en función de diferentes escenarios.

• Escenario 1: Utilice completamente los recursos de la CPU. Concéntrese en el rendimiento general de la CPU en lugar del rendimiento de un solo tipo de trabajos.

  Sugerencia: No se recomienda aislar CPUs entre usuarios. No importa qué tipo de control de CPU se implemente, el uso general de CPU se ve afectado.

• Escenario 2: Se permite un cierto grado de contención de recursos de CPU y pérdida de rendimiento. Cuando la CPU está inactiva, los recursos de la CPU se utilizan completamente. Cuando la CPU está completamente cargada, cada tipo de servicio necesita usar la CPU proporcionalmente.

  Sugerencia: Puede utilizar el uso compartido de CPU para mejorar el uso general de la CPU mientras implementa el aislamiento y el control de la CPU cuando las CPU están completamente cargadas.

• Escenario 3: Algunos trabajos son sensibles al rendimiento y se permite el desperdicio de recursos de CPU.

  Sugerencia: Puede usar el límite de CPU para implementar el aislamiento absoluto de CPU entre diferentes tipos de trabajos.