Проверка емкости системы перед обновлением

Перед обновлением GitHub Enterprise Serverнеобходимо выполнить эти проверки емкости и выполнить рекомендуемые действия.

Обновление до более новых версий данных GitHub Enterprise Server обычно увеличивает потребление ресурсов. Каждый выпуск компонента добавляет новые функции, некоторые из которых включены по умолчанию, другие варианты, которые требуют больше мощности обработки. Шаблоны использования клиентов также влияют на спрос; Например, предприятия с десятками тысяч организаций могут видеть более высокое использование ресурсов.

Увеличение ресурсов чаще всего отображается как более высокая загрузка ЦП, больше операций ввода-вывода в секунду (операций ввода-вывода в секунду), больше использования памяти или более крупных невыполненных операций очереди Aqueduct. Чтобы подготовиться к этим изменениям, проверьте доступную емкость вашей системы и примените все рекомендации по исправлению перед обновлением. Выполните эти проверки в течение самых загруженных времен дня и недели, чтобы получить самые точные результаты.

Потребности ресурса

Перед обновлением экземпляра важно убедиться, что система соответствует необходимым требованиям к ресурсам:

  1.        [Использование ЦП ниже 70 %](#cpu-usage-below-70)

  2.        [Использование памяти ниже 70 %](#memory-usage-below-70)

  3.        [Диск не насыщенный](#disk-not-saturated)

  4.        [Очередь юникорна до 200–300](#unicorn-queue-under-200300)

  5.        [Невыполненная работа акведука в возрасте до 1–2 часов](#aqueduct-backlog-under-12-hours)

Использование ЦП ниже 70 %

  1.           **Проверьте использование ЦП.**

В Консоль управленияперейдите на страницу мониторинга (https://HOSTNAME.com:8443/setup/monitor) и просмотрите CPU граф.

  • Если использование регулярно ниже 70%, продолжайте использовать память.
  • Если использование регулярно превышает 70%, система не соответствует критериям для обновления.
  1.           **Сравнение использования с средним показателем загрузки ЦП.**

Сравнение помогает определить возможное насыщенность диска.

  • Перейдите в представление "Работоспособность операций" и проверьте Load график.

  • В матрице найдите значение, в котором shortterm строка пересекается со столбцом avg .

  • Вычислите средний процент нагрузки:

    (short-term avg ÷ number of vCPUs) × 100

  • В том же представлении CPU проверьте граф. В матрице найдите значение, в котором idle строка пересекается со столбцом avg . Вычитайте это значение из 100, чтобы получить использование.

  1.        **Интерпретация результатов.**

    Если средний процент загрузки ЦП превышает 50 % выше, чем использование, это, скорее всего, указывает на состязание ресурсов. Не продолжайте обновление, пока не изучили возможное заполнение диска (см. раздел "Диск не насыщенный").

Использование памяти ниже 70 %

  1.           **Проверьте использование памяти.**

В Консоль управленияперейдите на страницу мониторинга (https://HOSTNAME.com:8443/setup/monitor) и просмотрите Memory граф.

  1.        **Интерпретация результатов.**
    • Если использование памяти регулярно ниже 70%, продолжайте использовать диск не насыщенным.
    • Если использование памяти регулярно превышает 70%, система не соответствует критериям обновления.

Диск не насыщенный

  1.           **Проверьте спецификации поставщика.**

Если поставщик облачных служб или оборудования предлагает метрики использования дисков, используйте их для подтверждения того, является ли диск насыщенным.

  • Если метрики недоступны, запросите спецификации дисков от поставщика, включая максимальную пропускную способность и максимальный объем операций ввода-вывода в секунду.
  • Сравните эти ограничения с наблюдаемыми сведениями об использовании диска. Если использование приближается к максимальным значениям, диск насыщенный.
  1.           **Проверьте графики дисков в Консоль управления.**

Перейдите на страницу монитора (https://HOSTNAME.com:8443/setup/monitor).

  • Disk Operations Просмотр и Disk Traffic графов.

  • Сравните значения оси Y со спецификациями поставщика (не максимальным масштабом, отображаемым на графе).

  • Просмотрите как данные, так и корневые диски.

Эти графы доступны в представлении System &Application Insights.

  1.           **Интерпретация результатов.**

Если использование диска приближается к максимальному значению, определяемого поставщиком, диск будет насыщенным. В этом случае система не соответствует критериям обновления.

Очередь юникорна до 200–300

  1.           **Проверьте граф очередных запросов.**

В Консоль управленияперейдите на страницу мониторинга (https://HOSTNAME.com:8443/setup/monitor) и просмотрите Queued Requests граф.

Этот граф доступен в представлении System &Application Insights.

  1.        **Интерпретация результатов.**
    • Если запросы в очереди последовательно ниже 200, продолжайте отработку невыполненной работы в Aqueduct до 1–2 часов.
    • Если запросы в очереди регулярно находятся в диапазоне от 200 до 300, система не соответствует критериям обновления.
  2.           **Необязательно. Проверьте использование рабочих ролей единорога.**

В административной оболочке выполните следующую команду:

ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git
 ```

Просмотрите последний столбец выходных данных. Если все процессы показывают `> 90% utilization`, требуются больше рабочих ролей единорога.

### Невыполненная работа акведука в возрасте до 1–2 часов

1. 
              **Проверьте глубину очереди Aqueduct.**
В Консоль управленияперейдите на страницу мониторинга (`https://HOSTNAME.com:8443/setup/monitor`) и просмотрите `Aqueduct queue depth` граф.



Этот граф доступен в представлении System &Application Insights.


1. 
           **Интерпретация результатов.**

* Если невыполненная работа **длится менее 1–2 часов**, вы соответствуете этому требованию.
* Если невыполненная работа **регулярно длится более 1–2 часов**, система не соответствует критериям обновления.

1. 
              **
           `index_high` Мониторинг очереди.**
Крупные развертывания могут привести к значительному увеличению `index_high` глубины очереди, что может привести к ухудшению невыполненной работы. Обратите особое внимание на эту очередь при мониторинге.

Если **выполнены все критерии** (ЦП, память, диск, очередь единокорна, невыполненная работа по Aqueduct), можно продолжить обновление до целевой версии компонента. После обновления ожидается, что потребление ресурсов увеличится дальше.

Если **какие-либо критерии не выполнены**, устраните базовые проблемы перед попыткой обновления.

## Обновление аппаратных и точно настроенных рабочих ролей

Если система не соответствовала одному или нескольким требованиям к ресурсам, необходимо увеличить емкость перед обновлением. В следующих разделах описывается, как добавить аппаратные ресурсы и настроить конфигурацию рабочей роли для устранения распространенных узких мест.

1. 
           [ЦП выше 70 %](#cpu-above-70)
1. 
           [Память выше 70 %](#memory-above-70)
1. 
           [Насыщенный диск](#disk-saturated)
1. 
           [Очередь юникорна выше 200–300](#unicorn-queue-above-200300)
1. 
           [Невыполненная работа акведука выше 1–2 часов](#aqueduct-backlog-above-12-hours)

### ЦП выше 70 %

Если загрузка ЦП регулярно превышает 70%:

* **Увеличьте ресурсы ЦП.**
Добавьте по крайней мере 20 % больше виртуальных ЦП.
* **Учетная запись для новых работников.**
Выделить 1 виртуальный ЦП на рабочую роль. Например, если добавить 5 рабочих ролей единокорна и 10 рабочих ролей Resque, увеличьте виртуальные ЦП по крайней мере на 15.

### Память выше 70 %

Если использование памяти регулярно превышает 70%:

* **Увеличьте память.**
Добавьте дополнительный ОЗУ для уменьшения среднего использования ниже 70 %.
* **Учетная запись для новых работников.**
Выделите 1 ГБ памяти на рабочую роль. Например, если добавить 5 рабочих ролей единорога и 10 рабочих ролей Resque, увеличьте память не менее чем на 15 ГБ.

### Насыщенный диск

Если проверка насыщенности диска указывает на насыщенность, обновление до дисков с более высокой пропускной способностью и максимальным числом операций ввода-вывода в секунду.

### Очередь юникорна выше 200–300

Если запросы единокорна последовательно помещаются в очередь выше 200–300, может потребоваться добавить больше рабочих ролей единорога. Выполните следующие действия, чтобы определить общее целевое число рабочих ролей и обновить конфигурацию.

#### 1. Оценка дополнительных рабочих ролей

Выполните следующую команду во время пиковых часов, чтобы просмотреть использование для каждой рабочей роли:

```shell
ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git

Пример результата:

git      3048972 3045762  0 Aug01 ?        00:07:47 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[00]: 20491 reqs,  10.8 req/s,   13ms avg,   85.2% util
git      3048979 3045762  0 Aug01 ?        00:07:53 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[01]: 20951 reqs,  12.5 req/s,   13ms avg,   80.3% util
git      3048985 3045762  0 Aug01 ?        00:08:04 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[02]: 21502 reqs,  10.5 req/s,   15ms avg,   76.5% util
git      3048992 3045762  0 Aug01 ?        00:07:45 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[03]: 20249 reqs,  14.2 req/s,   15ms avg,   86.9% util

Средние запросы/секунду — 12 req/s.

Из этих выходных данных вычислите средние запросы в секунду (req/s).

  • В приведенном выше примере: 12 req/s.

  • Цель — уменьшить количество запросов в очереди до ≤100.

  • Формула:

    (Queued requests – 100) ÷ avg req/s

  • Пример: (280 –100) ÷ 12 = 15 дополнительных рабочих ролей.

    Совет

    Если вы хотите подтвердить свои выводы, вы можете обратиться к нам, перейдя к Поддержка GitHub Enterprise, отправив пакет и запросить общее целевое число рабочих единорогов.

2. Проверка текущей конфигурации

Убедитесь, что общее количество рабочих ролей (юникорн + Resque) не превышает виртуальные ЦП. Выделить по крайней мере 1 виртуальный ЦП на рабочую роль.

Проверьте текущие номера:

  • Работники единорога

    ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git | wc -l

    Добавьте в это значение вычисляемое число новых рабочих ролей, чтобы получить общий целевой объект.

  • Повторное изменение рабочих ролей

    ps -ef | grep aqueduct-1.1.0 | grep -v "grep aqueduct-1.1.0" | wc -l

3. Настройка конфигурации

Если сумма рабочих ролей unicorn + Resque превышает виртуальные ЦП, добавьте дополнительные виртуальные ЦП перед продолжением.

Обновите число рабочих ролей единорога:

ghe-config app.github.github-workers <NUM-WORKERS>
ghe-config-apply

Замените общим целевым числом рабочих единорогов.

Невыполненная работа акведука выше 1–2 часов

Если задания Aqueduct регулярно отложены более чем на 1–2 часа, добавьте рабочие нагрузки с низкими разрешениями, чтобы снизить риск резервного копирования очередей. Эта проблема часто ухудшается после обновления.

1. Добавление рабочих ролей с низким значением resqued

  • Увеличьте число рабочих на 5–10. Помните о емкости ЦП. Для каждой рабочей роли требуется по крайней мере 1 виртуальный ЦП.
ghe-config app.github.resqued-low-workers <NUM-WORKERS>
ghe-config-apply

Замените новым общим числом рабочих с низким уровнем размера.

2. Проверка общего количества рабочих ролей

Убедитесь, что объединенное число рабочих ролей юникорна и resque не превышает общее количество виртуальных ЦП. Инструкции по проверке текущей рабочей конфигурации см . в очереди юникорна выше 200–300 .