Rendimiento de Linux

 (brendangregg.com)
3 puntos por GN⁺ 2023-10-15 | 1 comentarios | Compartir por WhatsApp
  • La página Linux Performance de Brendan Gregg es un hub de enlaces que reúne en un solo lugar recursos de observabilidad, análisis, benchmarking y tuning necesarios para empezar a investigar el rendimiento de Linux
  • El flujo de herramientas clave pasa por perf, eBPF, bcc, bpftrace y Flame Graphs, con acceso directo desde ejemplos de comandos hasta herramientas de tracing y visualización
  • La documentación se amplía con el artículo de análisis de rendimiento de Netflix de 2015, tuning de EC2, Linux load averages, frame pointers, ejemplos de gdb y dos libros sobre rendimiento
  • La lista de charlas ofrece rutas de aprendizaje según el contexto, como una introducción de 40 minutos, un tutorial de herramientas de 90 minutos, análisis de rendimiento de contenedores y una checklist para SRE
  • En cada mapa de herramientas hay que verificar qué tan actualizado está mirando el año en la esquina inferior derecha de la imagen; el diagrama integrado no es tan completo como los demás diagramas individuales

Hub de recursos de rendimiento y mapas de herramientas

  • Esta página es un hub de enlaces que reúne recursos de Linux performance creados por Brendan Gregg
  • La imagen del mapa de herramientas de la derecha fue creada con una tipografía grande para adaptarse a decks de diapositivas, y tiene un formato que también permite imprimirla y pegarla en la pared de una oficina
  • Los mapas de herramientas dividen el trabajo de rendimiento en Linux en las siguientes áreas
  • Para saber qué tan actualizada está cada imagen, hay que revisar el año en la esquina inferior derecha
  • También se ofrece por separado un diagrama de alta resolución que combina observabilidad, tuning estático de rendimiento y perf-tools/bcc
    • png
    • svg
    • Este diagrama integrado no es tan completo como los demás diagramas individuales

Principales herramientas con acceso directo

  • perf: perf one-liners, ejemplos y material de visualización
  • eBPF tools: herramientas de tracing BPF/bcc y ejemplos
  • perf-tools: conjunto de herramientas perf basadas en Ftrace
  • bcc: conjunto de herramientas de rendimiento BPF/bcc
  • bpftrace: conjunto de herramientas de rendimiento BPF/bpftrace
  • Flame Graphs: cómo usar Flame Graphs con perf y otros profilers

Documentación y materiales de aprendizaje

Lecturas avanzadas sobre eBPF, ftrace y perf

Charlas recomendadas según la situación

  • Linux Systems Performance, USENIX LISA 2019

    • Resume en 40 minutos el rendimiento de sistemas Linux desde 6 aspectos: observabilidad, metodología, benchmarking, profiling, tracing y tuning
    • video, youtube, slides, PDF

  • Linux Performance 2018, PerconaLive 2018

    • Resume los cambios y funciones recientes de Linux performance en 2018 en una keynote de 20 minutos
    • youtube, slideshare, PDF

  • Linux Performance Tools, Velocity 2015

    • Tutorial de 90 minutos que cubre observabilidad de rendimiento, benchmarking, tuning, tuning estático de rendimiento, herramientas y metodologías de tracing, y demos en vivo
    • youtube playlist, slideshare, PDF

  • How Netflix Tunes EC2 Instances for Performance, AWS re:Invent 2017

    • Se centra en el tuning más que en la observabilidad del rendimiento, y cubre el contexto de Netflix, los tipos y funciones de instancias AWS EC2, los Linux kernel tunables y la observabilidad
    • youtube, slideshare

  • Container Performance Analysis, DockerCon 2017

    • Cubre cómo encontrar dónde está el cuello de botella entre el host y el contenedor, perfilar apps en contenedores y profundizar hasta el kernel
    • youtube, slideshare

  • Broken Linux Performance Tools, SCaLE14x 2016

    • Cubre problemas frecuentes en herramientas de sistemas Linux, métricas, estadísticas, visualizaciones, overhead de medición y benchmarks, junto con consejos de “What You Can Do”
    • youtube, slideshare, PDF

  • Using Linux perf at Netflix, Kernel Recipes 2017

    • Se centra en el profiling de CPU y en cómo funcionan los Flame Graphs, e incluye problemas de stack traces y symbols al perfilar Java, Node.js, VMs y contenedores con las propiedades de perf_events
    • youtube, slideshare

  • Give me 15 minutes and I'll change your view of Linux tracing, LISA 2016

  • Performance analysis superpowers with Linux eBPF, O’Reilly Velocity 2017

    • Cubre cómo usar enhanced BPF, es decir eBPF, agregado en la serie Linux 4.x, para análisis de rendimiento, observabilidad y depuración
    • El frontend es bcc, un proyecto open source que ofrece interfaces y herramientas BPF
    • youtube, slideshare, PDF

  • Linux Performance Analysis: New Tools and Old Secrets, LISA 2014

    • Cubre las herramientas ftrace y perf_events, además de perf-tools, que usa principalmente ftrace
    • ftrace se presenta como un tracer integrado en el kernel Linux durante muchos años, pero casi no descubierto
    • youtube, slideshare, PDF

  • Performance Checklists for SREs, SREcon 2016

    • Incluye en la parte final una checklist para responder a incidentes de rendimiento en Linux, y también puede ser útil para análisis urgentes de rendimiento en Linux
    • youtube, usenix, slideshare, PDF

Recursos externos recomendados

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-10-15
Opiniones de Hacker News

  • Estoy usando tuned en un VPS Debian/Ubuntu donde corro apps en tiempo real, y funciona bastante bien
    Es más simple que cambiar directamente los parámetros del kernel, es decir, la configuración de sysctl o los tunables del kernel
    https://access.redhat.com/documentation/en-us/red_hat_enterp...
    sudo apt install tuned

    • También usamos Tuned para cargas de trabajo SAP y nos gusta mucho

  • No sabía que Brendan Gregg ahora estaba en Intel
    https://en.wikipedia.org/wiki/Brendan_Gregg
    También es el protagonista del video viral Shouting in the Data Center
    https://www.youtube.com/watch?v=tDacjrSCeq4
    Es un verdadero genio

  • Vale la pena señalar que casi todo lo que trata el artículo original no tiene que ver con la latencia, sino con el rendimiento/ancho de banda de red, disco, otras E/S y CPU
    Para mucha gente, rendimiento significa throughput, así que se entiende. Pero también hay casos en los que la latencia es mucho más importante que el throughput, y para ajustar la latencia en Linux se necesita otro conjunto de herramientas

    • Es una observación bastante válida. Reducir la latencia también es mucho más difícil que aumentar el throughput[1], así que muchas veces es importante prestarle atención a la latencia
      Otro eje que la gente puede optimizar es el rendimiento por watt, pero no me voy a extender sobre eso aquí
      A veces optimizar el throughput también optimiza la latencia. Por ejemplo, si puedes meter más procesos en una misma máquina, se reduce la distancia promedio entre los procesos y sus interlocutores, y también baja la latencia promedio
      Algo muy obvio al optimizar la latencia es aumentar el throughput lo suficiente para que no se convierta en cuello de botella
      Si se optimiza la latencia de forma agresiva, siento que no hay tanto tuning de Linux en sí. Podría estar equivocado, pero en general parece centrarse en fijar cores, ejecución tickless, networking en espacio de usuario y ajustes del lado del hardware como tamaño de página, SMT, configuración de ahorro de energía y elección de hardware
      [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
    • Parece más correcto llamarlo throughput que bandwidth. El significado es parecido, pero el contraste entre throughput y latencia se discute desde hace mucho tiempo
      A veces se pueden mejorar ambos, pero normalmente hay un trade-off
    • Me gustaría saber qué herramientas o recursos recomiendan para el tuning de latencia
    • Si el objetivo es reducir la latencia para lograr características de tiempo real en el sistema, es poco probable que una distribución Linux estándar llegue a ser satisfactoria por más perillas que se toquen

  • Esperar también es una buena estrategia
    Desde Linux 6.5, el scheduler entiende que, cuando un “core” SMT está ocupado, colocar algo en otro “core” no necesariamente es lo mejor. En la práctica, se parece más a un solo core con un costo de cambio de contexto muy bajo
    Gracias a esto, las tareas muy paralelas se volvieron perceptiblemente más ágiles, y también se nota en los gráficos de uso de CPU
    Los resultados pueden variar por temas de coherencia de caché y NUMA

    • En kernels anteriores, con solo desactivar SMT se puede obtener una sensación de mayor agilidad, además de bloquear algunos ataques de canal lateral y mejorar la eficiencia energética

  • Artículos relacionados:
    Linux Performance - https://news.ycombinator.com/item?id=13498485 - enero de 2017, 64 comentarios
    Linux Performance - https://news.ycombinator.com/item?id=8205057 - agosto de 2014, 22 comentarios

  • Si alguien quiere cambiar algún parámetro tunable pero no puede explicar por qué ese cambio produciría el efecto deseado, ni por qué está configurado con ese valor en primer lugar, no le dejaría cambiarlo en producción
    Se podría llamar “el parámetro tunable de Chesterton”

    • Aunque pueda explicar una razón hipotética, ¿no bastaría con hacer benchmarks fuera de producción?

  • Pensando en el trabajo de Brendan con eBPF, tomo este material como una forma de monitorear y evaluar más fácilmente distintas situaciones de rendimiento
    En los ajustes y el tuning hay trade-offs, y normalmente cuando se optimiza una cosa, otra se ve perjudicada
    Como extra, btop me resultó muy útil como visor TUI todo en uno de rendimiento y carga del sistema, en reemplazo de glances. Me pregunto cuánto lo están aprovechando los desarrolladores y si hay motivación para crear mejores herramientas TUI de monitoreo
    Cuando entro a un servidor, lo primero que hago es abrir tmux y asignar una ventana a btop

  • Para mí, el “tuning” de rendimiento en Linux equivale a desactivar las mitigaciones de Spectre/Meltdown
    En este caso, los nodos de cómputo corren dentro de una VPC sin acceso a Internet, así que el riesgo parece bastante bajo

    • Depende de qué CPU uses. En Zen 4, desactivar las mitigaciones no estaba soportado y causaba bugs o crasheos
      Parece que ese crash específico ya fue corregido, pero aun así no lo recomiendo. Las CPU modernas de AMD e Intel están diseñadas para ejecutarse al menos con las mitigaciones básicas activadas

  • Lo dejé en favoritos. Creo que pronto me va a servir para algo en lo que estoy trabajando.
    Todavía no leí todas las diapositivas, pero me da curiosidad si alguien ha visto mejoras de rendimiento significativas con opciones de compilación del kernel.
    Antes, cuando usaba Gentoo y ajustaba flags de compilación, solía modificar el Makefile del kernel para usar -O3 y aplicar un parche de -march=native. Viéndolo en retrospectiva, según los benchmarks de Phoronix parece ser más bien perjudicial para varias cargas de trabajo, así que me pregunto si alguien ha visto casos opuestos.

  • Es un buen sitio. Como tiende a resumir el rendimiento de Linux, ya sea para tuning o monitoreo, hace que uno respire hondo.
    Este tema es profundo, y también hay muchísimos tipos de herramientas de observación. Como mínimo hay que conocer a fondo uptime, dmesg e iostat. Estas herramientas dan una mirada general a varios aspectos del sistema, como carga, memoria y CPU, y ofrecen las primeras pistas para diagnosticar el estado. Es la página 1 de 100 de mi checklist de “a ver, echemos un vistazo”.
    En metodología de análisis de rendimiento, se recomiendan benchmarks cuidadosos para evaluar de forma integral el comportamiento del sistema y las características de la carga de trabajo. Hay que comparar escenarios antes y después de los cambios, hacer primero cambios pequeños y luego combinar gradualmente aquellos que parezcan aportar beneficios. El laboratorio y el entorno de producción nunca se comportan exactamente igual.
    A partir de aquí se pone complicado. El perfilado de CPU con herramientas como perf y visualizaciones como flame graphs permiten analizar de forma dirigida la actividad de la CPU y, si se suma el seguimiento de eventos de hardware, también se puede optimizar la eficiencia de cómputo. Hay que saber algo más que “es problema de la app, antes del último release del equipo de desarrollo estaba bien”.
    Como administrador, al hablar con desarrolladores se vuelven necesarias herramientas de Linux como ftrace y BPF. Permiten rastrear en detalle la ejecución de funciones del kernel y llamadas al sistema, por lo que son importantes para resolver problemas y optimizar rendimiento. A la inversa, si eres desarrollador, quizá tengas que verificar la intuición del administrador. Como dice el dicho: confía, pero verifica.
    Si es tu propio código, tienes que conocer BPF. BPF no solo permite trazado eficiente dentro del kernel, sino que también impulsa el desarrollo de herramientas avanzadas y personalizadas de perfilado mediante bcc y bpftrace, y permite mirar más a fondo el rendimiento del sistema.
    Por último, esto sí que es difícil. El tuning consiste en ajustar numerosos componentes del sistema y parámetros del kernel, desde CPU y memoria hasta la configuración de red, para optimizar el rendimiento y la confiabilidad en diversas cargas de trabajo. O bien puedes echarle la culpa a la red.
    En la práctica, se necesita una buena actitud hacia la gestión de cambios. Perseguir cambios en el código o en parámetros del kernel puede abrumar a cualquiera, y cuando se trabaja contra el reloj, la presión aumenta aún más la posibilidad de errores humanos.