Skip to main content

Enterprise Server 3.15 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: Realizar solicitudes repetidas (sondear) a tu instancia de GitHub Enterprise Server desde sistemas de integración continua (CI), servidores de compilación o cualquier otro cliente (como clientes 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 (manada enorme) y, en su lugar, espere a que los eventos de webhook desencadenen acciones.

Para obtener más información, vea «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, vea "Suministro de datos al soporte técnico de GitHub Enterprise".

Uso elevado de CPU

Causas posibles

  • La CPU de la instancia tiene un aprovisionamiento insuficiente 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 con privilegios elevados en 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 trabajos de Acciones de GitHub.
  • La cantidad elevada de comandos de Git ejecutó un repositorio grande.

Recomendaciones

Uso de memoria alto

Causas posibles:

  • La memoria de la instancia no está lo suficientemente aprovisionada.
  • Solicitudes con privilegios elevados en 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 ejecutando con memoria insuficiente (OOM).
  • Mayor 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 nomad, identifique los servicios con tendencias de memoria insuficiente que a menudo siguen las tendencias de memoria libre después de que se reinicien. Para obtener más información, vea «Acceder al tablero del monitor».
  • Compruebe 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; consulte "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).
  • Compruebe la cantidad de tareas en cola para el procesamiento en segundo plano: consulte "Acceder al tablero del monitor".

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 la actualización /mnt/, para facilitar esas reversiones en caso de que sea necesario. Para obtener más información, vea «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: consulte "Aumentar la capacidad de almacenamiento".

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

Causas posibles:

  • Solicitudes con privilegios elevados en 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 actualizar el uso de recursos de servicio elevados de 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; consulte "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 trabajadores y considere la posibilidad de ajustar su recuento de trabajos activos.
  • Aumente los discos de almacenamiento a unos que tengan un mayor IOPS/rendimiento.
  • Compruebe la cantidad de tareas en cola para el procesamiento en segundo plano: consulte "Acceder al tablero del monitor".

Índices de error elevados

Causas posibles

  • Solicitudes con privilegios elevados en 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.
  • Servicio haproxy con error o no disponibilidad 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 incorrectos pueden ser causa.
  • Compruebe si hay trabajos de mantenimiento de red con errores del repositorio (visite http(s)://[hostname]/stafftools/networks).