Acerca de Governor
Governor es un monitor integrado para la actividad de Git en la instancia. Use el ghe-governor comando para ver qué repositorios, usuarios, direcciones IP y operaciones de Git están creando carga.
Use estos datos cuando aumente el uso de CPU, memoria o disco y debe confirmar si el tráfico de Git es la causa. Para ver la sintaxis de comandos y los subcomandos, consulte Utilidades de la línea de comandos.
Governor solo registra las operaciones de Git. No incluye api ni tráfico web. Para inspeccionar las operaciones que se están ejecutando actualmente, consulte la ghe-btop utilidad en Utilidades de la línea de comandos.
Acerca de los archivos de datos de Governor
Governor almacena sus datos en archivos en /data/user/governor/. Cada archivo contiene una hora de datos y se conserva durante dos semanas. Los nombres de archivo contienen marcas de tiempo de Unix que indican el período de tiempo que cubre cada archivo.
Nota:
En GitHub Enterprise Server 3.13 y versiones anteriores, los archivos de datos de Governor se ubican en /data/user/gitmon/ y siguen el patrón de nomenclatura gitmon.<timestamp>.db.
Para confirmar el intervalo de datos que se encuentran actualmente en el disco, convierta las marcas de tiempo en los nombres de archivo más antiguos y más recientes en fechas legibles para personas.
for epoch in $(sudo ls /data/user/governor/ 2>/dev/null | grep '^governor\.' | sort | sed -n '1p;$p' | cut -f2 -d.); do echo "${epoch} = $(date -d @${epoch})"; done
La salida muestra la hora de inicio de los archivos de datos más antiguos y más recientes.
1551186000 = Tue Feb 26 13:00:00 UTC 2019
1552392000 = Tue Mar 12 12:00:00 UTC 2019
Antes de comenzar
Antes de ejecutar consultas en Governor, reúna esta información:
- Acceso SSH al dispositivo. Necesita acceso al shell administrativo para ejecutar
ghe-governor. Consulte Acceder al shell administrativo (SSH). - Nodo que se va a consultar. Para implementaciones independientes o de alta disponibilidad, inicie en el nodo principal. En el caso de los clústeres, ejecute consultas en cada
git-servernodo porque ningún nodo único contiene todo el tráfico de Git. - Ventana de impacto. Tenga en cuenta las horas de inicio y finalización de la degradación notificada para que pueda definir el ámbito de las consultas con
-ty-u. - Nombres de repositorio u organización, si los usuarios han notificado problemas con repositorios o organizaciones específicos.
Identificar si Git contribuye a la carga
Comience con un resumen general y, a continuación, atribuya la carga a repositorios o programas específicos.
-
Resumir toda la actividad de Git reciente en la instancia:
ghe-governor health -
Busque repositorios con el tiempo medio de respuesta más lento:
ghe-governor aggregate repo avg_rt -
Busque repositorios con la operación única más larga:
ghe-governor aggregate repo max_rt -
Busque las operaciones individuales más lentas (no agrupadas):
ghe-governor top rt -n 50 -
Busque los repositorios que consumen más tiempo de CPU:
ghe-governor aggregate repo cpu -
Para un repositorio que destaca, busque qué subprograma de Git es responsable de su uso de CPU:
ghe-governor aggregate program cpu -r OWNER/REPOSITORY -
Encuentre los repositorios en los que
pack-objectsconsumió más tiempo de CPU. El programapack-objectsensambla los datos enviados a los clientes durante las clonaciones y las recuperaciones; un recuento elevado supone una carga importante para la CPU y la memoria del dispositivo:ghe-governor aggregate repo cpu -P pack-objects -
Busque las operaciones individuales que usaron la mayor cantidad de tiempo de CPU (no agrupadas):
ghe-governor top cpu -n 50 -
Busque los repositorios que impulsan la mayoría de las escrituras de disco durante un intervalo de tiempo específico:
ghe-governor aggregate repo disk_write_kb -t START-TIME -u END-TIME -
Compruebe si hay alta simultaneidad, que indica que muchas operaciones de Git se ejecutan simultáneamente:
ghe-governor aggregate repo max_parallelism
Si los resultados apuntan a un repositorio o programa específicos, continúe con la sección correspondiente a continuación.
Identifica el tráfico principal de clonación y obtención
El programa upload-pack gestiona los datos que se sirven a los clientes durante las operaciones de clonado y fetch. Use estas consultas para buscar qué repositorios, usuarios y direcciones IP impulsan la mayor actividad de clonación y captura.
-
Recuento de operaciones de clonación y captura por repositorio:
ghe-governor aggregate repo count -P upload-pack -
Identifique a los usuarios que realizan clones y fetches y cuente sus operaciones:
ghe-governor aggregate user_id count -P upload-pack -
Identifique las direcciones IP que generan la mayoría de las solicitudes de clonación y captura. Un pequeño conjunto de direcciones IP con un recuento alto suele indicar una flota de ejecutores de CI:
ghe-governor aggregate ip count -P upload-pack -
Mida el volumen total de datos servidos por repositorio:
ghe-governor aggregate repo uploaded_kb -P upload-pack -
Mida el volumen medio de datos cargados por usuario:
ghe-governor aggregate user_id avg_uploaded -P upload-pack -
Busque el clon máximo y capture la simultaneidad por repositorio. La
MAXPLcolumna muestra el mayor número de operaciones simultáneas registradas para cada repositorio. Un valor alto en un pequeño número de repositorios sugiere un efecto manada:ghe-governor aggregate repo max_parallelism -P upload-pack -
Busque las operaciones de clonación o captura individuales más grandes (no agrupadas):
ghe-governor top uploaded -P upload-pack -n 50
Identificación del tráfico intensivo de inserción
Los programas receive-pack y spokes-receive-pack gestionan los datos recibidos de los clientes durante los pushes. Usa estas consultas para identificar qué repositorios, usuarios y direcciones IP generan la mayor actividad de push.
-
Recuento de operaciones de inserción por repositorio:
ghe-governor aggregate repo count -P receive-pack -P spokes-receive-pack -
Identifique a los usuarios que realizan envíos a una organización y cuente sus operaciones de envío:
ghe-governor aggregate user_id count -o ORGANIZATION -P receive-pack -P spokes-receive-pack -
Mida el volumen total de datos recibidos por repositorio:
ghe-governor aggregate repo received_kb -P receive-pack -P spokes-receive-pack -
Identifique las direcciones IP que envían más datos push:
ghe-governor aggregate ip received_kb -P receive-pack -P spokes-receive-pack -
Busque las operaciones de inserción individuales más grandes (no agrupadas):
ghe-governor top received -P receive-pack -P spokes-receive-pack -n 50
Restringir el análisis
Puede agregar cualquier combinación de las siguientes opciones a un ghe-governor top comando o ghe-governor aggregate para centrar la consulta en un período de tiempo específico, repositorio, propietario o programa.
Filtros de tiempo
| Option | Description |
|---|---|
-t <timespec> | Considere solo las operaciones desde una hora de inicio determinada. El valor predeterminado es de hace 48 horas. |
-u <timespec> | Considere solo las operaciones hasta una hora de finalización determinada. El valor predeterminado es la hora actual. |
Los siguientes formatos se aceptan para <timespec>.
| Formato | Example | Meaning |
|---|---|---|
| Marca de tiempo de Unix | -t 1371614483 | Segundos desde el 1 de enero de 1970 |
| marca de tiempo de Java | -t 1371614483637 | Milisegundos desde el 1 de enero de 1970 |
| Días relativos | -t 1d | El último día |
| Horas relativas | -t 2h | Las últimas dos horas |
| Minutos relativos | -t 20m | Los últimos veinte minutos |
Filtros de ámbito
| Option | Description |
|---|---|
-r <owner>/ | Considere solo las operaciones que coinciden con un propietario y un repositorio determinado. Especifique esta opción varias veces para que coincida con varios repositorios. |
-o <owner> | Considere solo las operaciones que coincidan con un propietario determinado, como un usuario o una organización. Especifique esta opción varias veces para que coincida con varios propietarios. |
-P <program> | Considere solo las operaciones que ejecutaron un subprograma de Git determinado, como upload-pack, receive-pack, rev-listo pack-objects. Especifique esta opción varias veces para que coincida con varios programas. |
-I <address> | Considere solo las operaciones de una dirección IP específica. Especifique esta opción varias veces para que coincida con varias direcciones. |
Opciones de salida
| Option | Description |
|---|---|
-j | Establezca el formato de salida en JSON en lugar de en una tabla ASCII. |
-n <N> | Limite la salida a N registros. El valor predeterminado es 20 para las consultas agregadas y 200 para las consultas principales. |
--count-only | Mostrar solo las columnas KEY y COUNT. Solo se aplica a las consultas agregadas. |
Interpretación de columnas de resultados
Las abreviaturas siguientes aparecen en ghe-governor las tablas de resultados.
| Column | Meaning |
|---|---|
AVG RT | Promedio de tiempo, en segundos, que tomaron las invocaciones de Git |
MAX RT | Tiempo de ejecución, en segundos, de la invocación de ejecución más larga, por host |
MAXPL / AVGPL | Paralelismo máximo y promedio: cuántas invocaciones de Git estaban pendientes al mismo tiempo |
CPU/SEC | Segundos de tiempo de CPU usados por Git por segundo de tiempo de reloj. Divida por el número de núcleos de CPU y multiplique por 100 para obtener el porcentaje de CPU específico de Git. Este valor no puede superar el número de núcleos de CPU. |
UPL | Datos que el servidor subió a los clientes, como durante las obtenciones y las clonaciones |
RECV | Datos que el servidor recibió de los clientes, como durante las inserciones |
Las READcolumnas , WRITE, UPLy RECV se notifican en gigabytes (GB) y la tasa correspondiente se notifica en megabytes por segundo (MB/s).
Interpretación de patrones comunes
En la tabla siguiente se asignan patrones de salida comunes del regulador a sus causas probables.
| Pattern | Causa probable |
|---|---|
Número elevado de upload-pack procedente de un pequeño conjunto de direcciones IP | Una flota de ejecutores de CI clona repetidamente uno o más repositorios en lugar de reutilizar copias de trabajo locales |
Alto max_parallelism para un pequeño número de repositorios | Efecto estampida: muchos ejecutores que inician clones concurrentes al mismo tiempo, a menudo porque las tareas programadas se inician simultáneamente |
Gran uploaded_kb por repositorio y alto avg_uploaded por usuario | Clones completos repetidos; los clientes no reutilizan las copias de trabajo locales o no usan clones superficiales o parciales |
Nivel alto received_kb para un repositorio u organización | Carga de trabajo con uso intensivo de push; puede implicar archivos binarios grandes o commits frecuentes en un monorepo |
Cpu alta pack-objects con recuentos de operaciones moderadas | Empaquetado costoso de objetos; El repositorio puede beneficiarse de una ejecución de mantenimiento o del uso del lado cliente de clones parciales con --filter |
Nivel alto avg_rt o max_rt para un repositorio | Operaciones lentas; a menudo causadas por ejecuciones extensas de pack-objects, alta concurrencia o contención de recursos provocada por otra carga de trabajo |
Acciones recomendadas para la reducción de carga de Git
Si los datos del regulador muestran que un repositorio, usuario o flota de ejecutor genera una carga excesiva, las siguientes acciones pueden reducir el impacto.
- Reutiliza las copias de trabajo locales. Reemplace clones nuevos por
git fetchen flujos de trabajo automatizados. Esto evita la transferencia del gráfico de objetos completo en cada ejecución. - Utiliza clones superficiales. En el caso de los flujos de trabajo que no requieren historial de confirmación completo, pase
--depthal comando clone, por ejemplogit clone --depth 1. Esto reduce tanto los datos transferidos como el trabajo quepack-objectsdebe realizar. - Use clones parciales. En el caso de los repositorios con objetos binarios grandes o muchos archivos no necesarios en un flujo de trabajo determinado, use
--filterpara solicitar solo los objetos que requiere el flujo de trabajo, por ejemplogit clone --filter=blob:none. - Agregue un proxy de reflejo local o almacenamiento en caché. Para grandes flotas de ejecutores que clonan repetidamente los mismos repositorios, un proxy de caché o una réplica local pueden absorber el tráfico de recuperación y reducir la carga de su instancia.
- Escalonar trabajos programados. Desplazamiento de flujos de trabajo de CI/CD desencadenados según una programación para que no todos los ejecutores se inicien al mismo tiempo, lo que reduce el tamaño de las ráfagas de clonación simultáneas.
- Reduzca el paralelismo de flujo de trabajo. Los flujos de trabajo que clonan varios repositorios en paralelo se pueden volver a configurar para limitar la simultaneidad y distribuir la carga a lo largo del tiempo.
Cuándo ponerse en contacto con el GitHub soporte técnico
Póngase en contacto con Soporte técnico para GitHub Enterprise e incluya un paquete de soporte si se da alguno de los siguientes supuestos.
- El rendimiento sigue siendo deficiente después de reducir la presión de clonación o de escalonar las tareas programadas.
- La instancia está atendiendo errores generalizados de Git o errores de conexión que no se explican por la carga de trabajo del cliente.
- Governor muestra valores persistentes
max_parallelismque sugieren que la instancia está en su capacidad máxima o cerca de ella, y es poco probable que los cambios en la carga de trabajo por sí solos resuelvan el problema. - Ve un patrón claro en la salida del regulador, pero no sabe cómo interpretarlo ni qué medidas tomar.
Para obtener más información sobre cómo generar un paquete de soporte técnico, consulte Proporcionar datos al soporte técnico de GitHub.
Lectura adicional
Para obtener más información sobre la supervisión de los recursos del sistema, consulte Acerca de los paneles de supervisión.