Skip to main content

Enterprise Server 3.20 actualmente está disponible como versión candidata para lanzamiento.

Solución de problemas de asignación de recursos

Solución de problemas comunes de asignación de recursos que pueden producirse en el dispositivo GitHub Enterprise Server.

Solucionar problemas de la asignación de los recursos comunes en su aparato

Nota:

Hacer solicitudes repetidas (polling) a tu instancia de GitHub Enterprise Server desde sistemas de integración continua (CI), servidores de compilación u otros clientes (como los de Git o API) puede sobrecargar el sistema. Esto puede provocar un ataque por denegación de servicio (DoS), lo que provoca problemas de rendimiento significativos y saturación de recursos.

Para evitar estos problemas, se recomienda encarecidamente usar webhooks para recibir actualizaciones. Los webhooks permiten al sistema insertar actualizaciones automáticamente, lo que elimina la necesidad de sondear constantemente. Además, considere la posibilidad de usar solicitudes condicionales y estrategias de almacenamiento en caché para minimizar las solicitudes innecesarias. Evite ejecutar trabajos en lotes grandes y simultáneos (oleadas masivas) y, en su lugar, espere a que los eventos del webhook desencadenen acciones.

Para más información, consulta Acerca de webhooks.

Recomendamos utilizar el tablero del monitor para mantenerse informado sobre la salud del recurso de su aparato y tomar decisiones sobre cómo corregir los problemas de alto uso, como los que se señalan en esta página.

En el caso de problemas críticos del sistema y antes de realizar modificaciones en el dispositivo, se recomienda encarecidamente ponerse en contacto con nosotros visitando Soporte técnico para GitHub Enterprise e incluyendo el conjunto de soporte técnico. Para más información, consulta Proporcionar datos al soporte técnico de GitHub.

Uso elevado de CPU

Causas posibles

  • La CPU de tu instancia está bajoaprovisionada para la carga de trabajo.
  • La actualización a una nueva versión de GitHub Enterprise Server a menudo aumenta el uso de CPU y memoria debido a nuevas características. Además, la migración posterior a la actualización o los trabajos en segundo plano de conciliación pueden degradar temporalmente el rendimiento hasta que se completen.
  • Solicitudes elevadas contra Git o API. El aumento de las solicitudes a Git o API puede producirse debido a varios factores, como la clonación excesiva de repositorios, los procesos de CI/CD o el uso accidental por scripts de API o cargas de trabajo nuevas.
  • Aumento del número de GitHub Actions tareas.
  • La cantidad elevada de comandos de Git ejecutó un repositorio grande.

Recomendaciones

  • Asegúrese de que los núcleos de CPU se aprovisionan correctamente.
  •         [Establecer umbrales de alertas](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/recommended-alert-thresholds).
    
  • Después de una actualización, compruebe si se han completado los trabajos de actualización en segundo plano mediante la ejecución de ghe-check-background-upgrade-jobs.
  • Utilice webhooks en lugar de sondeo.
  • Use la limitación de volumen de API.
  • Analice el uso de Git comprobando las operaciones actuales y el tráfico de Git.

Uso de memoria alto

Causas posibles:

  • La memoria de la instancia está subaprovisionada.
  • Solicitudes elevadas contra Git o API. El aumento de las solicitudes a Git o API puede producirse debido a varios factores, como la clonación excesiva de repositorios, los procesos de CI/CD o el uso accidental por scripts de API o cargas de trabajo nuevas.
  • Servicios individuales que superan su uso esperado de memoria y se están quedando sin memoria (OOM).
  • Aumento del procesamiento de trabajos en segundo plano.

Recomendaciones

  • La memoria de la instancia no está lo suficientemente aprovisionada para la carga de trabajo, el volumen de datos, dado el uso a lo largo del tiempo, puede superar los requisitos mínimos recomendados.
  • Dentro de los gráficos de Nomad, identifique los servicios con tendencias de quedarse sin memoria, que a menudo son seguidas por tendencias de liberar memoria después de reiniciarse. Para más información, consulta Acerca de paneles de supervisión.
  • Comprueba los registros de los procesos que salen de la memoria mediante la ejecución de rg -z 'kernel: Out of memory: Killed process' /var/log/syslog* (para ello, primero inicie sesión en el shell administrativo mediante SSH; consulta Acceder al shell administrativo (SSH).
  • Asegúrese de que se cumple la proporción correcta de memoria a los servicios de CPU (al menos 6.5:1).
  • Comprueba la cantidad de tareas en cola para el procesamiento en segundo plano: consulta Acerca de paneles de supervisión.

Baja disponibilidad de espacio en el disco

Ambos volúmenes de almacenamiento, el montado en la ruta de acceso del sistema de archivos raíz (/) y el otro en la ruta de acceso del sistema de archivos de usuario (/data/user) pueden provocar problemas en la estabilidad de la instancia si hay poco espacio en disco disponible.

Tenga en cuenta que el volumen de almacenamiento raíz se divide en dos particiones del mismo tamaño. Una de las particiones se montará como el sistema de archivos raíz (/). La otra partición solo se montará durante actualizaciones y reversiones de actualizaciones como /mnt/actualización, para facilitar esas reversiones en caso de que sea necesario. Para más información, consulta Información general del sistema.

Causas posibles

  • Error de servicio que provoca un aumento de la cantidad de registros
  • Uso elevado del disco por tráfico orgánico

Recomendaciones

  • Compruebe el uso de disco de la carpeta /var/log ejecutando (sudo du -csh /var/log/*) o fuerce manualmente una rotación de registros (sudo logrotate -f /etc/logrotate.conf).
  • Busque en el disco los archivos grandes que se han eliminado, pero siguen teniendo identificadores de archivo abiertos (ghe-check-disk-usage).
  • Aumento de la capacidad de almacenamiento en disco: consulta Aumentar la capacidad de almacenamiento.

Tiempos de respuesta más altos que lo común

Causas posibles:

  • Solicitudes elevadas contra Git o API. El aumento de las solicitudes a Git o API puede producirse debido a varios factores, como la clonación excesiva de repositorios, los procesos de CI/CD o el uso accidental por scripts de API o cargas de trabajo nuevas.
  • Consultas de base de datos lentas.
  • Después de la actualización, se elevó el uso de recursos de servicio en ElasticSearch.
  • Alcanzar las cuotas de IOPS en el disco o la contención de E/S intensiva.
  • Trabajadores saturados.
  • Retrasos en la entrega del webhook.

Recomendaciones

  • Busque picos o números sostenidos en los gráficos operaciones pendientes de disco: número de operaciones en cola.
  • Compruebe el panel Solicitud y respuesta de la aplicación para ver si solo se ven afectados determinados servicios.
  • Después de una actualización, compruebe si se han completado los trabajos de actualización en segundo plano mediante la ejecución de ghe-check-background-upgrade-jobs.
  • Compruebe los registros de base de datos para ver si hay consultas lentas en /var/log/github/exceptions.log (para esto, primero inicie sesión en el shell administrativo mediante SSH; consulta Acceder al shell administrativo (SSH)), por ejemplo, comprobando las 10 solicitudes lentas principales por dirección URL: grep SlowRequest github-logs/exceptions.log | jq '.url' | sort | uniq -c | sort -rn | head.
  • Compruebe el gráfico de solicitudes en cola para determinados trabajos y considere la posibilidad de ajustar su recuento de trabajos activos.
  • Aumente los discos de almacenamiento a unos que tengan un mayor IOPS/rendimiento.
  • Comprueba la cantidad de tareas en cola para el procesamiento en segundo plano: consulta Acerca de paneles de supervisión.

Índices de error elevados

Causas posibles

  • Solicitudes elevadas contra Git o API. El aumento de las solicitudes a Git o API puede producirse debido a varios factores, como la clonación excesiva de repositorios, los procesos de CI/CD o el uso accidental por scripts de API o cargas de trabajo nuevas.
  • Fallo haproxy en el servicio o indisponibilidad de servicios individuales.
  • Error en el mantenimiento de red del repositorio a lo largo del tiempo.

Recomendaciones

  • Compruebe el panel Solicitud y respuesta de la aplicación para ver si solo se ven afectados determinados servicios.
  • Compruebe los registros haproxy e intente identificar si los actores malintencionados pueden ser la causa.
  • Compruebe los trabajos fallidos de mantenimiento de red del repositorio (visite http(s)://[hostname]/stafftools/networks).