Устранение распространенных проблем с выделением ресурсов на устройстве
Примечание. Регулярное выполнение повторных запросов (опрос) до ваш экземпляр GitHub Enterprise Server из систем непрерывной интеграции (CI), серверов сборки или других клиентов (таких как клиенты Git или API) может перегружать систему. Это может привести к атаке типа "отказ в обслуживании" (DoS), что приводит к значительным проблемам производительности и насыщенности ресурсов.
Чтобы избежать этих проблем, настоятельно рекомендуется использовать веб-перехватчики для получения обновлений. Веб-перехватчики позволяют системе автоматически отправлять обновления, устраняя необходимость постоянного опроса. Кроме того, рекомендуется использовать условные запросы и стратегии кэширования, чтобы свести к минимуму ненужные запросы. Избегайте выполнения заданий в больших, одновременных пакетах (громовых стадах) и вместо этого дождитесь активации событий веб-перехватчика.
Дополнительные сведения см. в разделе Сведения о веб-перехватчиках.
Мы рекомендуем использовать панель мониторинга, чтобы оставаться в курсе работоспособности ресурсов устройства и принимать решения по устранению проблем с высоким уровнем использования, таких как те, которые описаны на этой странице.
Для критически важных системных проблем и до внесения изменений в устройство мы настоятельно рекомендуем обратиться к нам, посетив Поддержка GitHub Enterprise и включив пакет поддержки. Дополнительные сведения см. в статье "Предоставление данных в службу поддержки GitHub Enterprise".
Высокая загрузка ЦП
Возможные причины
- ЦП экземпляра не подготовлен для рабочей нагрузки.
- Обновление до новых выпусков GitHub Enterprise Server часто увеличивает использование ЦП и памяти из-за новых функций. Кроме того, фоновые задания после обновления или выверки могут временно снизить производительность до завершения.
- Повышенные привилегии запросов к Git или API. Увеличение запросов к Git или API может происходить из-за различных факторов, таких как чрезмерное клонирование репозитория, процессы CI/CD или непреднамеренное использование скриптами API или новыми рабочими нагрузками.
- Увеличено число заданий GitHub Actions.
- Повышенный объем команд Git выполнял большой репозиторий.
Рекомендации
- Убедитесь, что ядра ЦП подготовлены соответствующим образом.
- Задайте пороговые значения оповещений.
- После обновления проверьте, завершены ли задания фонового обновления, выполнив команду
ghe-check-background-upgrade-jobs. - Используйте веб-перехватчики вместо извлечения.
- Используйте ограничение скорости API.
- Анализ использования Git путем проверки текущих операций и трафика Git.
Использование большого объема памяти
Возможные причины
- Память экземпляра не подготовлена.
- Повышенные привилегии запросов к Git или API. Увеличение запросов к Git или API может происходить из-за различных факторов, таких как чрезмерное клонирование репозитория, процессы CI/CD или непреднамеренное использование скриптами API или новыми рабочими нагрузками.
- Отдельные службы превышают ожидаемое использование памяти и выполняются вне памяти (OOM).
- Увеличение фоновой обработки заданий.
Рекомендации
- Память экземпляра недостаточно подготовлена для рабочей нагрузки, тома данных, учитывая использование с течением времени, может превышать минимальные рекомендуемые требования.
- В графах Nomad идентифицируйте службы с тенденциями вне памяти, которые часто следуют тенденциям свободной памяти после перезапуска. Дополнительные сведения см. в разделе Доступ к панели мониторинга.
- Проверьте журналы для процессов, выходя из памяти, выполнив (
rg -z 'kernel: Out of memory: Killed process' /var/log/syslog*для этого сначала войдите в административную оболочку с помощью SSH - см. раздел "Доступ к административной оболочке (SSH)". - Убедитесь, что правильное соотношение памяти к службам ЦП выполняется (по крайней мере
6.5:1). - Проверьте количество задач, в очереди для фоновой обработки, см. раздел "Доступ к панели мониторинга".
Недостаточный размер дискового пространства
Оба тома хранилища, подключенные к корневая файловая система пути () и другой к пути пользовательской файловой системы (/``/data/user) могут вызвать проблемы с стабильностью экземпляра, если недостаточно места на диске.
Имейте в виду, что том корневого хранилища разделен на две секции одинакового размера. Один из разделов будет подключен в качестве корневой файловой системы (/). Другая секция подключена только во время обновлений и откатов обновлений в качестве /mnt/обновления, чтобы упростить откаты при необходимости. Дополнительные сведения см. в разделе Обзор системы.
Возможные причины
- Сбой службы, вызывающий увеличение количества журналов
- Высокая загрузка дисков с помощью органического трафика
Рекомендации
- Проверьте использование
/var/logпапки, выполнив (sudo du -csh /var/log/*) или вручную принудив смену журнала (sudo logrotate -f /etc/logrotate.conf). - Проверьте диск для больших файлов, которые были удалены, но по-прежнему имеют открытые дескрипторы файлов (
ghe-check-disk-usage). - Увеличьте емкость дискового хранилища. См. раздел "Увеличение емкости хранилища".
Более длительное время отклика
Возможные причины
- Повышенные привилегии запросов к Git или API. Увеличение запросов к Git или API может происходить из-за различных факторов, таких как чрезмерное клонирование репозитория, процессы CI/CD или непреднамеренное использование скриптами API или новыми рабочими нагрузками.
- Медленные запросы к базе данных.
- После обновления ресурсов эластичного поиска ElasticSearch с повышенными привилегиями.
- Достижение квот операций ввода-вывода в секунду на диске и (или) тяжелых операций ввода-вывода.
- Насыщенные рабочие.
- Задержки доставки веб-перехватчика.
Рекомендации
- Найдите пики или устойчивые числа в ожидающих операциях диска: количество очередных графов операций.
- Проверьте панель запросов и ответов **** приложения, чтобы узнать, затронуты ли только некоторые службы.
- После обновления проверьте, завершены ли задания фонового обновления, выполнив команду
ghe-check-background-upgrade-jobs. - Проверьте журналы базы данных для медленных запросов (для этого сначала войдите в административную оболочку с помощью SSH- см. разделДоступ к административной оболочке (SSH)"), например, проверив 10 медленных
/var/log/github/exceptions.logзапросов по URL-адресу.grep SlowRequest github-logs/exceptions.log | jq '.url' | sort | uniq -c | sort -rn | head - Проверьте граф запросов очередей для определенных работников и рассмотрите возможность корректировки их активного числа рабочих ролей.
- Увеличьте диски хранилища до дисков с более высоким числом операций ввода-вывода в секунду или пропускной способностью.
- Проверьте количество задач, в очереди для фоновой обработки, см. раздел "Доступ к панели мониторинга".
Повышенная частота возникновения ошибок
Возможные причины
- Повышенные привилегии запросов к Git или API. Увеличение запросов к Git или API может происходить из-за различных факторов, таких как чрезмерное клонирование репозитория, процессы CI/CD или непреднамеренное использование скриптами API или новыми рабочими нагрузками.
- Сбой
haproxyслужбы или отсутствие доступности отдельных служб. - Сбой обслуживания сети репозитория с течением времени.
Рекомендации
- Проверьте панель запросов и ответов **** приложения, чтобы узнать, затронуты ли только некоторые службы.
haproxyПроверьте журналы и попытайтесь определить, могут ли плохие субъекты быть причиной.- Проверьте наличие неудачных заданий обслуживания сети репозитория (посетите).
http(s)://[hostname]/stafftools/networks