|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (15)
просмотр истории страницы{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. Сетевые карты |
... |
h1. Жёсткие диски |
h2. CentOS не видит новый подключенный диск # Убедитесь, что в BIOS/UEFI диск виден и настроен корректно (не отключен порт, настроено автоопределение и BIOS корректно распознал устройство) # Hotplug дисков может не работать, поэтмоу попробуйте [перезагрузить |CarbonBilling:Выключение, перезагрузка сервера] сервер # Если диск подключался к выключенному серверу, но ОС не увидела его после загрузки, попробуйте еще раз перезагрузить сервер # Если диск не виден после второй перезагрузки, проверьте dmesg (лог */var/log/messages*), возможно там есть упоминание ошибок определения дисков # Если ошибки отсутствуют, но диск все равно не виден ОС, загрузите сервер с LiveCD Linux (например [Ubuntu|https://www.ubuntu.com/download/desktop]), проверьте определится ли диск # Если у Вас используется аппаратный RAID, это так же может быть причиной - вероятней всего ОС не имеет доступа к SATA-контроллеру при использовании RAID и массив нужно сначала настроить в меню контроллера Если диск корректно определяется BIOS и виден в другой ОС, создайте заявку на портале [HelpDesk|https://helpdesk.carbonsoft.ru], техподдержка поможет Вам определить источник проблемы. |
h2. Не находится рейд-контроллер (smart array) или установка зависает при выборе диска |
... |
добавить в 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{code} |
sync; dd if=/dev/zero of=/mnt/db/write.test conv=fdatasync bs=1M count=1k && sync; rm -f /mnt/db/write.test{code} |
*На время выполнения теста, потребуется 1Гб свободного места.* Вывод: |
... |
1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 12,3008 c, 87,3 MB/c{code} |
h1. Сервер перезагрузился, как понять почему? {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* необходимо проверить аппаратную часть сервера. Оперативную память, процессор, дисковую подсистему. |