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 la versión 3.13 y anteriores, los archivos de datos governor se encuentran en /data/user/gitmon/ y usan el patrón gitmon.<timestamp>.dbde nomenclatura .
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 de Governor, recopile 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 amplio y, a continuación, cargue atributos en 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 -
Busque los repositorios en
pack-objectslos que consumió más tiempo de CPU. Elpack-objectsprograma ensambla los datos enviados a los clientes durante los clones y capturas; un recuento elevado coloca una presión significativa de CPU y memoria en el 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.
Identificación del tráfico de clonación y captura principales
El upload-pack programa controla los datos servidos a los clientes durante los clones y capturas. 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 ejecutan clones y captura y cuenta 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 para un pequeño número de repositorios sugiere una manada estruendo: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 receive-pack programas y spokes-receive-pack controlan los datos recibidos de los clientes durante las inserciones. Use estas consultas para buscar qué repositorios, usuarios y direcciones IP generan la actividad de inserción más importante.
-
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 insertan en una organización y cuente sus operaciones de inserción:
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 la mayoría de los datos de inserción:
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 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 KEY columnas 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 cargó en los clientes, como durante las capturas y los clones |
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 |
|---|---|
Recuento elevado upload-pack de un pequeño conjunto de direcciones IP | Una flota del ejecutor de CI clona repetidamente uno o varios repositorios en lugar de reutilizar las desprotecciones locales |
Alto max_parallelism para un pequeño número de repositorios | Herdado de truenos: muchos ejecutores que desencadenan clones simultáneos al mismo tiempo, a menudo porque los trabajos programados comienzan simultáneamente |
Grande uploaded_kb por repositorio combinado con un alto avg_uploaded por usuario | Clones completos repetidos; Los clientes no reutilizan las desprotecciones locales o no usan clones poco profundos o parciales |
Alto received_kb para un repositorio u organización | Carga de trabajo intensiva de inserción; puede implicar archivos binarios grandes o confirmaciones 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 |
Alto avg_rt o max_rt para un repositorio | Operaciones lentas; a menudo causado por ejecuciones grandes pack-objects , alta simultaneidad o contención de recursos de 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.
- Reutilización de las desprotecciones 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. - Use clones poco profundos. 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 trabajopack-objects. - 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é. En el caso de las flotas de ejecutores grandes que clonan repetidamente los mismos repositorios, un proxy de extracción o un reflejo local puede absorber el tráfico de captura y reducir la carga en la 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 Soporte técnico para GitHub Enterprise e incluya una agrupación de soporte técnico si se aplica alguna de las siguientes acciones.
- El rendimiento permanece degradado después de reducir la presión de clonación o reducir los trabajos programados sorprendentes.
- La instancia está atendiendo errores generalizados de Git o errores de conexión que no se explican por la carga de trabajo del cliente.
- El regulador muestra valores persistentes
max_parallelismque sugieren que la instancia está en una capacidad cercana o cercana, y los cambios de carga de trabajo por sí solos son poco probables para resolver el problema. - Verá un patrón claro en la salida del regulador, pero no sabe cómo interpretarlo o qué acción realizar.
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.