Brendan Gregg, uno de los desarrolladores de DTrace, que actualmente está desarrollando herramientas de análisis de rendimiento basadas en BPF en el kernel de Linux, resumió la experiencia obtenida al analizar los problemas de rendimiento que encontró Netflix al migrar el DBMS Cassandra de CentOS a Ubuntu. la nube de Amazon EC2 basada en Xen. Después de la migración, la carga de la CPU aumentó en un 30 % y los retrasos durante las operaciones de escritura aumentaron aproximadamente en la misma cantidad. Resulta que el rendimiento de las aplicaciones que solicitan intensivamente información horaria depende en gran medida de la fuente horaria exacta seleccionada en el sistema.
Al principio, el motivo de la disminución en el rendimiento no era obvio y el diagnóstico comenzó con el monitoreo del posible impacto de los procesos del sistema que consumen muchos recursos y se ejecutan constantemente o se inician periódicamente utilizando las utilidades top y execsnoop. Pero todo indicaba que el consumo de recursos había aumentado específicamente en el DBMS Cassandra, escrito en Java. La comparación de las métricas de creación de perfiles de dos procesos de Cassandra que se ejecutan en paralelo en CentOS y Ubuntu, procesando las mismas consultas, mostró que aproximadamente el 32% del tiempo total se dedicó a llamar a os::javaTimeMillis(), que se utiliza para obtener información sobre la hora actual. .
Después de esto, se llevó a cabo un experimento en el que se escribió una aplicación Java simple que llamaba al método System.currentTimeMillis() cien millones de veces en un bucle. La ejecución de la aplicación mostró que tardó 13 segundos en completarse en CentOS y unos 68 segundos en Ubuntu, es decir. 5 veces más lento. Se escribió un programa similar en C que llamó a la función gettimeofday() cien millones de veces, pero cuando se ejecutó, se obtuvieron resultados similares.
Dado que quedó claro que la fuente del problema era la función de devolver la hora actual, la atención se centró en los cambios en los indicadores al elegir diferentes fuentes de hora exacta en el sistema. A juzgar por el contenido de "/sys/devices/system/clocksource/clocksource0/current_clocksource", el temporizador "xen" se usó de forma predeterminada cuando se ejecuta Linux en el sistema invitado. Después de cambiar la fuente de tiempo a "tsc", el tiempo de ejecución de la aplicación de prueba en Ubuntu disminuyó de 68 a 3.3 segundos, es decir. se volvió 20 veces más rápido. Además, se realizó una prueba de rendimiento de la fuente de tiempo kvm-clock, que mostró un aumento en los retrasos del 20% en comparación con TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ tiempo java TimeBench real 1m8.300s usuario 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ tiempo java TimeBench real 0m3.370s usuario 0m3.353s sys 0m0.026s
Para obtener el tiempo al seleccionar una fuente TSC, se utiliza la instrucción del procesador RDTSC, cuya ejecución no requiere una llamada al sistema (la instrucción no requiere privilegios elevados y genera un valor del contador de tiempo integrado en la CPU). Por defecto, TSC no está activado porque antiguamente esta fuente no excluía la deriva gradual del tiempo, que en otros procesadores se ajusta mediante software para lograr lecturas más precisas. Según un ingeniero especializado en desarrollo de procesadores, los temores sobre los cambios de tiempo al utilizar TSC han sido falsos durante mucho tiempo y en los procesadores modernos esta fuente puede producir lecturas estables durante años.
El cambio de los servidores de producción de Netflix a una fuente TSC resultó en una reducción del 43 % en la latencia de escritura y logró resultados con Ubuntu que fueron 4 veces más rápidos que las configuraciones que ejecutaban CentOS con una fuente de tiempo "xen". Los resultados del estudio se transfirieron a Amazon, que recomendó oficialmente utilizar la fuente de tiempo TSC predeterminada en entornos AWS EC2 basados en el hipervisor Xen (kvm-clock sigue siendo recomendado en entornos basados en el hipervisor Nitro).
Fuente: opennet.ru