Проблемы с оборудованием

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (16)

просмотр истории страницы
{toc:maxLevel=3}

h1. Перед обращением в техподдержку

h2. Включение SSH в установщике

{color:#333333}[http://mirror.yandex.ru/centos/6.6/isos/x86_64/]{color}{color:#333333}  ({color}[CentOS-6.6-x86_64-minimal.iso|http://mirror.yandex.ru/centos/6.6/isos/x86_64/CentOS-6.6-x86_64-minimal.iso]{color:#333333}).{color}

h2. Полезные утилиты и способы диагностики

h3. Посмотреть тип оборудования

Устанавливаем утилиту:

{code}
yum install dmidecode
{code}

запускаем

{code}
dmidecode -t system | head -n20
{code}

анализируем в выводе Manufacturer: и Product Name:

Примеры:
а) Manufacturer: HP
Product Name: ProLiant DL360 Gen9
Это сервер HP
б) Manufacturer: Supermicro
Product Name: SYS-5019S-MR
Это тоже сервер
в) Manufacturer: System manufacturer
Product Name: System Product Name
Это обычное "десктопное" оборудование -- часто производитель не заполняет эти поля
г) Manufacturer: VMware, Inc.
Product Name: VMware Virtual Platform
Это виртуализированное окружение, хост-машина может быть на любой платформе


h3. Контроль температуры

1) Серверные платформы

{code}
yum -y install ipmitool

modprobe ipmi_si

modprobe ipmi_devintf

{code}

теперь можно посмотреть сенсоры:

{code}
ipmitool sdr list
{code}

2) Обычные "десктопные" платформы

{code}
yum install lm_sensors
{code}
после установки ищем сенсоры
{code}
sensors-detect
{code}
теперь можно посмотреть сенсоры:
{code}
sensors
{code}

(пока поддерживаются не все современные материнские платы)


h3. Проверка процессора

Подготовка: если сервер многопроцессорный, устанавливаем утилиту numactl

{code}
yum -y install numactl
{code}

Она позволит ограничить выполнение определенными ядрами процессора.
Смотрим конфигурацию машины:

{code}
numactl --show
{code}

Анализируем вывод: если в параметре "cpubind:" только 0, то система считает себя однопроцессорной, и ограничение не имеет смысла
Далее любую команду выполняем так: "numactl --cpubind <номер процессора> <ваша команда>"
Для проверки правильности можно вызвать командой саму себя:

{code}
numactl --cpubind 1 numactl --show
{code}

Должно показать "cpubind: 1"

Устанавливаем утилиту:

{code}
yum -y install stress
{code}

Используем утилиту stress: stress -t <время теста> -c <количество потоков>
количество потоков задаем как кол-во ядер процессора
Пример: stress -t 120 -c 16 — две минуты (120 секунд) и 16 потоков

Во время выполнения теста контролируем температуру процессора и вывод в /var/log/messages
Если в messages во время теста появилось что-то типа "Сore temperature above threshold, cpu clock throttled", значит имеются проблемы с охлаждением
Если в messages во время теста появилось "[Hardware Error]: Machine check events logged", значит есть реальные проблемы с аппаратной частью машины

h1. Сетевые карты


h2. CentOS не видит новый подключенный диск

# Убедитесь, что в BIOS/UEFI диск виден и настроен корректно (не отключен порт, настроено автоопределение и BIOS корректно распознал устройство)
# Hotplug дисков может не работать, поэтмоу попробуйте [перезагрузить |CarbonBilling:Выключение, перезагрузка сервера] сервер
# Если диск подключался к выключенному серверу, но ОС не увидела его после загрузки, попробуйте еще раз перезагрузить сервер
# Если диск не виден после второй перезагрузки, проверьте dmesg (лог */var/log/messages*), возможно там есть упоминание ошибок определения дисков
# Если ошибки отсутствуют, но диск все равно не виден ОС, загрузите сервер с LiveCD Linux (например [Ubuntu|https://www.ubuntu.com/download/desktop]), проверьте определится ли диск
добавить в grub: clocksource_failover clocksource=hpet

h2. Биллинг работает медленно

Убедитесь что сервер соответствует [системным требованиям|CarbonBilling:Системные требования].

Обратите внимание - важно не только количество потоков процессора или объём ОЗУ, но так же поколение и скорость работы компонентов:
* CPU не менее 3ГГц
* ОЗУ не менее 1600Мт/с
* Диски (HDD, SSH) должны быть достаточно новыми и производительными:
** HDD: скорость оборотов стабильно 7200 RPM или выше
** HDD: скорость чтения 150 МБ/с и записи не менее 80 МБ/с
** SSD: скорость чтения записи не менее 400 МБ/с,
** SSD: IOPS +произвольного+ чтения/записи - не менее 50000
** SSD: диск должен быть заполнен не более чем на 80%

h2. Высокая нагрузка на процессор.

Необходимо проверить скорость дисков. Скорость чтения с диска должна быть не меньше 150 MB/sec. Скорость записи не менее 80 MB/sec.
Проверить скорость дисков можно с помощью утилит fio, hdparm и dd.
h3. Пример проверки скорости
h4. Чтение

h2. Как проверить скорость диска?

h3. Рекомендуемый способ: fio, чтение и запись

*Рекомендуемый способ проверки - утилита fio*, только она позволяет проверить скорость диска, минуя буфер ФС, контроллера и самого диска, так же это единственная утилита показывающая отзывчивость диска (latency), что особенно важно для раздела с БД.



Сам fio отдаёт довольно запутанный вывод, поэтому мы сделали скрипт, который выводит основную информацию в более понятном виде:

{code:title=Команда}chroot /app/asr_billing/ python2.7 /usr/lib/python2.7/site-packages/python_tools/test_utils/test_disk_fio.py -l 1 -s 64 -f /mnt/db/{code}
{code:title=Вывод}
--------------------------------------------------------------------------------
Test | T | Speed | IOPS | Latency
--------------------------------------------------------------------------------
Sequential Q32T1 read 1 MiB | R | 489 MiB/s | 15678 | 2038 usec
Sequential Q32T1 write 1 MiB | W | 106 MiB/s | 3406 | 9390 usec
Random read 4KiB | R | 32 MiB/s | 8323 | 118 usec
Random write 4KiB | W | 117 MiB/s | 30114 | 32 usec
Random read 4KiB Q32T1 | R | 377 MiB/s | 96696 | 330 usec
Random write 4KiB Q32T1 | W | 223 MiB/s | 57311 | 557 usec
Random read 4KiB Q8T8 | R | 249 MiB/s | 63750 | 125 usec
Random write 4KiB Q8T8 | W | 210 MiB/s | 53894 | 147 usec
--------------------------------------------------------------------------------
{code}

* *Test* - имя теста с пояснением что именно он делает
* *T* - тип теста, чтение или запись,
* *Speed* - *больше = лучше*, средняя скорость передачи данных за тест в мебибитах, например 100 мебибайт = 104,858 мегабайт
* *IOPS* - *больше = лучше*, количество операций ввода-вывода прошедшее за тест, в абсолютных значениях, в примере - 6538 операций за время теста
* *Latency* - *меньше = лучше*, задержка выполнения запроса в микросекундах. 1 секунда = 1 000 000 микросекунд

h4. Тест раздела с базой данных /mnt/db
|| Тест || Пояснение по-русский || Рекомендуемые значения ||
| Sequential Q32T1 read 1 MiB | Последовательное чтение блоков размером 1 мегабайт, 32 задачи в очереди, в 1 потоке | 380 Mib/с, 12000 IOPS, 2600 usec |
| Sequential Q32T1 write 1 MiB | Последовательная запись блоков размером 1 мегабайт, 32 задачи в очереди, в 1 потоке | 230 Mib/с, 7500 IOPS, 4500 usec |
| Random read 4KiB | Случайное чтение блоков размером 4 килобайта, 1 задача в очереди, в 1 потоке | 25 Mib/с, 6900 IOPS, 149 usec |
| Random write 4KiB | Случайная запись блоков размером 4 килобайта, 1 задача в очереди, в 1 потоке | 75 Mib/с, 19000 IOPS, 58 usec |
| Random read 4KiB Q32T1 | Случайное чтение блоков размером 4 килобайта, 32 задачи в очереди, в 1 потоке | 270 Mib/с, 70000 IOPS, 470 usec |
| Random write 4KiB Q32T1 | Случайная запись блоков размером 4 килобайта, 32 задачи в очереди, в 1 потоке | 195 Mib/с, 50000 IOPS, 640 usec |
| Random read 4KiB Q8T8 | Случайное чтение блоков размером 4 килобайта, 8 задач в очереди, в 8 потоках | 22 Mib/с, 5900 IOPS, 170 usec |
| Random write 4KiB Q8T8 | Случайная запись блоков размером 4 килобайта, 8 задач в очереди, в 8 потоках | 65 Mib/с, 16800 IOPS, 65 usec |

h3. Устаревший способ: hdparm, чтение
{code}hdparm -t /dev/sda3{code}
Вывод:
Timing buffered disk reads: 64 MB in 0.21 seconds =299.07 MB/sec
{code}
h4. Запись
Наиболее точный результат можно получить сделав проверку несколько раз подряд, в этом Вам поможет небольшой скрипт:
{code}for i in 1 2 3 4 5 6; do hdparm -t /dev/sda; sleep 1; done{code}

h3. Устаревший способ: dd, запись

Разные области диска могут иметь различный износ. Для проверки скорости записи в тот или иной раздел выполните следующую команду:
{code}sync; dd if=/dev/zero of=/mnt/var/write.test conv=fdatasync bs=1M count=1k && sync; rm -f /mnt/var/write.test
скопировано 1073741824 байта (1,1 GB), 12,3008 c, 87,3 MB/c{code}

h2. Внезапная перезагрузка сервера.
h1. Сервер перезагрузился, как понять почему?

Возможно имеет место быть kernel panic. Необходимо проверить лог в /var/crash/'дата перезагрузки системы'/vmcore-dmesg.txt
{info}В любом случае нестандартного поведения сервера полезно проверять системный лог

{code}tail -f /var/log/messages{code}{info}



Перезагрузить сервер могут:
# Softdog_agent
Необходимо проверить лог /var/log/softdog_agent.log на предмет правильного чередования строк со словами Stopping и Starting
Если порядок нарушен - значит перезагрузка была внезапной
Пример штатной перезагрузки:
{code}
[2020-03-13T14:25:27.232Z] (sys) Stopping
Trap exit!
[2020-03-13T14:53:51.297Z] (sys) Starting
{code}
# Пункты меню "Выключить сервер" и "Перезагрузить сервер" в base-интерфейсе.
Для проверки необходимо проверить лог /app/base/var/log/base_web_server.log на наличие слов shutdown или reboot
{code}
grep shutdown /app/base/var/log/base_web_server.log | grep -v '^\+'
[pid: 3102|app: 0|req: 27592/120314] 85.140.78.107 () {40 vars in 997 bytes} [Fri Mar 13 14:24:43 2020] GET /shutdown/ => generated 4196 bytes in 43975 msecs (HTTP/1.1 200) 2 headers in 73 bytes (1 switches on core 0)
{code}
# Возможно имеет место быть *kernel panic*. Необходимо проверить лог:
{code}
/mnt/var/crash/'дата перезагрузки системы'/vmcore-dmesg.txt
{code}
# Если сервер перезагрузился из-за *kernel panic* необходимо проверить аппаратную часть сервера. Оперативную память, процессор, дисковую подсистему.