Contención de Spinlock durante la asignación de memoria de espacio de trabajo
Aquí es donde comienza a divertirse. Ya he descrito que el trabajo de clasificación y hash en la memoria del espacio de trabajo consume CPU pero no se refleja en los números de búsqueda de bpool.
La contención de Spinlock es otra capa para esta diversión particular. Cuando se roba memoria del grupo de búferes y se asigna para su uso contra una concesión de memoria de consulta, el acceso a la memoria se serializa con un spinlock. De forma predeterminada, esto tiene lugar con un recurso particionado en el nivel de nodo NUMA. Por lo tanto, cada consulta en el mismo nodo NUMA que usa la memoria del espacio de trabajo puede experimentar potencialmente una contención de spinlock al robar memoria contra concesiones. Muy importante tener en cuenta: esto no es un riesgo de contención "una vez por consulta", como lo sería si el punto de contención estuviera en el momento de la concesión real. Más bien, es cuando se roba la memoria contra la concesión, por lo que una consulta con una concesión de memoria muy grande tendrá muchas oportunidades para la contención de spinlock si utiliza la mayor parte de su concesión.
La marca de seguimiento 8048 hace un gran trabajo aliviando esta disputa al dividir aún más el recurso en el nivel central.
Microsoft dice "considere la marca de seguimiento 8048 si 8 o más núcleos por socket". Pero ... no es realmente cuántos núcleos por socket (siempre que sean múltiples), sino cuántas oportunidades de contención en el trabajo que se realiza en un solo nodo NUMA.
En los procesadores AMD pegados (12 núcleos por zócalo, 2 nodos NUMA por zócalo) había 6 núcleos por nodo NUMA. Vi un sistema con 4 de esas CPU (por lo tanto, ocho nodos NUMA, 6 núcleos cada uno) que estaba atascado en un convoy de spinlock hasta que se habilitó el indicador de rastreo 8048.
He visto que esta contención de spinlock reduce el rendimiento en máquinas virtuales tan pequeñas como 4 vCPU. El indicador de seguimiento 8048 hizo lo que se suponía que debía hacer cuando estaba habilitado en esos sistemas.
Teniendo en cuenta que todavía hay algunas CPU de 4 núcleos optimizadas en frecuencia, con la carga de trabajo correcta, también se beneficiarían de la marca de seguimiento 8048.
Las esperas de CMEMTHREAD acompañan el tipo de contención de spinlock que traza la bandera 8048 alivia. Pero una advertencia: las esperas de CMEMTHREAD son un síntoma corroborante, no la causa principal de este problema en particular. He visto sistemas con un alto "inicio de espera" de CMEMTHREAD donde el indicador de traza 8048 y / o 9024 se retrasaron en la implementación porque el tiempo de espera acumulado de CMEMTHREAD era bastante bajo. Con los spinlocks, el tiempo de espera acumulado suele ser algo incorrecto a la vista. Por el contrario, desea ver el tiempo perdido de la CPU, representado principalmente por los propios giros, en segundo lugar por las esperas asociadas que representan cambios de contexto potencialmente innecesarios.