Расчет критических значений Load Average для системы мониторинга сервера

Сегодня подкручивал настройки Nagios и решил добавить статью по расчету значений лимитов load average для различных конфигураций серверов. Чтобы понимать суть load average я советую прочесть эту статью.

Поскольку лимиты load average зависят от количества доступных ядер процессора, то у различных серверов будут значения будут различаться. Наиболее распространенные варианты конфигурации процессоров:

• 1 физическое ядро
• 2 физических ядра
• 2 физических ядра + hyperthreading (4 виртуальных ядра)
• 4 физических ядра
• 4 физических ядра + hyperthreading (8 виртуальных ядер)

Я не буду рассматривать варианты дальше, поскольку там все аналогично. Для себя я определил следующие лимиты, которые по моему мнению не приводят к заметному снижению производительности сервера относительно процессора.

State/Load Average	1 min	5 min	15 min
Warning	CPU cores * 2	CPU cores * 1.5	CPU cores * 1.25
Critical	CPU cores * 4	CPU cores * 2	CPU cores * 1.5

Поскольку ядро процессора, которое эмулируется hyperthreading, не является полноценным, то такие ядра я исключаю из расчета. Чтобы узнать свое количество физических ядер вы можете выполнить этот скрипт

#!/bin/bash
if [ `grep -c processor /proc/cpuinfo` != 1 ]; then
    grep 'core id' /proc/cpuinfo | sort | uniq | wc -l
else
    echo 1
fi

Готовые значения лимитов для плагина check_load из состава Nagios.

• Single core: check_load -w 2,1.5,1.25 -c 4,2,1.5
• Dual core: check_load -w 4,3,2.5 -c 8,4,3
• Quad core: check_load -w 8,6,5 -c 16,8,6

Преобразование имен файлов при распаковке архива tar

Если вам попался архив tar вида

$ tar -tf /tmp/backup_2013-07-31.tar.gz
backups/servers/server.example.org/var/www/example.org/file1
backups/servers/server.example.org/var/www/example.org/file2
backups/servers/server.example.org/var/www/example.org/file3
...
backups/servers/server.example.org/var/www/example.org/fileN

и распаковать его нужно в /var/www/example.org желательно не применяя mv, то сделать это можно так:

$ tar --strip-components=6 --show-transformed -xvf /tmp/backup_2013-07-31.tar.gz -C /var/www/example.org
file1
file2
file3
...
fileN

У tar еще есть опция --transform, которая позволяет сделать произвольную замену имени в отличии от --strip-components, которая только отбрасывает нужное количество уровней вложенности.

$ tar --transform 's,backups/servers/server.example.org/var/www/example.org,example.com,g' --show-transformed -xvf /tmp/backup_2013-07-31.tar.gz -C /var/www
example.com/file1
example.com/file2
example.com/file3
...
example.com/fileN

История спасения данных с "умирающего" жесткого диска

Очередное утро началось с чтения письма от smartd. Один из дисков сервера, который используется для резервного копирования всех остальных серверов, начал свой путь в лучший мир. В письме говорилось о появлении одного pending sector, но пока я ехал в офис от smartd пришло второе письмо, в котором говорилось, что этот сектор уже перешел в разряд offline uncorrectable. А вот это уже плохо, значит с большой долей вероятности считать данные из этого сектора уже не удастся.

JMicron JM20337 USB combo bridge - несовместимость с дисками Advanced Format

Собрался стереть суперблоки старого raid массива перед добавлением дисков в сервер. Подключил 2TB WDC WD20 EARX диск через USB переходник ([152d:2338] JMicron JM20337 Hi-Speed USB to SATA & PATA Combo Bridge). Но при попытке выполнить

$ sudo mdadm --zero-superblock /dev/sdb{1,2}

получил ошибку (к сожалению саму ошибку я не сохранил, возможно добавлю в пост позже).

Полез в логи

[184450.592853] usb 1-3.1.3: new high speed USB device using ehci_hcd and address 8
[184450.685697] usb 1-3.1.3: New USB device found, idVendor=152d, idProduct=2338
[184450.685700] usb 1-3.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[184450.685703] usb 1-3.1.3: Product: USB to ATA/ATAPI bridge
[184450.685704] usb 1-3.1.3: Manufacturer: JMicron
[184450.685705] usb 1-3.1.3: SerialNumber: 000001D91CA8
[184450.685794] usb 1-3.1.3: configuration #1 chosen from 1 choice
[184450.686383] scsi10 : SCSI emulation for USB Mass Storage devices
[184450.686474] usb-storage: device found at 8
[184450.686475] usb-storage: waiting for device to settle before scanning
[184455.684536] usb-storage: device scan complete
[184455.685016] scsi 10:0:0:0: Direct-Access     WDC WD20 EARX-00PASB0          PQ: 0 ANSI: 2 CCS
[184455.685496] sd 10:0:0:0: Attached scsi generic sg1 type 0
[184455.687848] sd 10:0:0:0: [sdb] 488378646 4096-byte logical blocks: (2.00 TB/1.81 TiB)
[184455.690581] sd 10:0:0:0: [sdb] Write Protect is off
[184455.690585] sd 10:0:0:0: [sdb] Mode Sense: 28 00 00 00
[184455.690587] sd 10:0:0:0: [sdb] Assuming drive cache: write through
[184455.691505] sd 10:0:0:0: [sdb] 488378646 4096-byte logical blocks: (2.00 TB/1.81 TiB)
[184455.692239] sd 10:0:0:0: [sdb] Assuming drive cache: write through
[184455.692245]  sdb: sdb1 sdb2
[184456.128375] sdb: p2 size 30585128320 exceeds device capacity, enabling native capacity

Оказывается через USB мост информация о жестком диске искажена и вместо 512/4096 (размер логического/физического сектора) получилось 4096/4096. Тут и тут нашлись аналогичные жалобы на работу этого моста и дисков с advanced format.

Узнать свой текущий IP адрес

Чтобы узнать свой текущий IP адрес можно воспользоваться услугами DynDNS http://checkip.dyndns.com/. Вывод страницы простой и легко поддается разбору в скриптах.

Ошибка при удалении снапшота LVM: Can't remove open logical volume

Выкроил пару часов времени чтобы переписать скрипты резервного копирования на работу с LVM снапшотами.

В процессе работы скрипт создает снапшоты для всех точек монтирования, которые нужно бэкапить и которые расположены на LVM. У меня это все, кроме /boot.

Снапшот создается как обычно

# lvcreate --snapshot --name rootfs-backup --size 500M /dev/VolGroup0/rootfs

Затем идет логика резервного копирования и по завершении снапшоты удаляются. Вот тут меня и поджидали грабли.

# lvremove -f /dev/VolGroup0/rootfs-backup
Can't remove open logical volume "rootfs-backup"

Ошибка проявляется не всегда, что наводит на мысли о гонке. Пробую гуглить и натыкаюсь на обсуждение аналогичной проблемы. Оказывается корень проблемы в установленном udisks, который использует современный десктопный софт в Linux.

Как вариант, можно закомментировать строку KERNEL=="dm-*", OPTIONS+="watch" в файле /lib/udev/rules.d/80-udisks.rules, но вместо этого я добавил костыльworkaround в свой скрипт, который несколько раз повторяет действие, если была ошибка.

for i in rootfs usr var home
do
  for j in 1 2 3 4 5 6 7 8 9 10
    lvremove -f /dev/VolGroup0/${i}-backup && break
    sleep 3
  done
  if [ -e /dev/VolGroup0/${i}-backup ]; then
    echo "Failed to remove LVM snapshot VolGroup0/${i}-backup"
    exit 1
  fi
done

Анонимные комментарии

Сегодня окончательно решил отключить анонимное комментирование. Причин для этого действия несколько:

• мне лень разбираться в какофонии, которую порой генерируют анонимные комментаторы. Одно дело, когда оставленный комментарий не подразумевает диалога и другое дело, когда несколько человек одновременно что-то спрашивают и ждут ответа - поди разберись что и кому писать;
• сегодня у большинства есть аккаунты, позволяющие комментировать не регистрируясь в моем блоге (google, facebook, openid, etc);
• сетевые партизаны мне не интересны.