Прежде чем я начну, небольшой отказ от ответственности. Я в основном разработчик, вынужденный выполнять роль системного администратора по обстоятельствам, поэтому заранее прошу прощения, если скажу что-то глупое или покажусь, что не знаю, что делаю.
Итак, у нас возникла проблема с одним из жестких дисков на нашем основном сервере. /dev/sda имеет две перегородки, одна установлена как / а другой используется как диск с данными PostgreSQL (/dev/sda2).
$ df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 92G 13G 75G 14% /
udev 10M 0 10M 0% /dev
tmpfs 1.6G 12M 1.6G 1% /run
/dev/disk/by-uuid/8ffca87a-ffe4-4c39-ab30-352b61f039f8 92G 13G 75G 14% /
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.2G 0 3.2G 0% /run/shm
/dev/sda2 826G 66G 719G 9% /var/lib/data/vol1
/dev/sdb1 917G 75G 797G 9% /var/lib/data/vol2
(/ dev / sda1 по какой-то причине монтируется с использованием своего UUID)
В последнее время стали появляться интервалы 100% IO R / W, в течение которых система практически блокируется и не может выполнять простейшие задачи.
Краткая выдержка из dmesg:
[6554534.743764] INFO: task /usr/bin/monito:29408 blocked for more than 120 seconds.
[6554534.743828] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[6554534.743889] /usr/bin/monito D ffff88041fcd3780 0 29408 1 0x00000000
[6554534.743891] ffff880101906780 0000000000000082 ffff880100000000 ffff88040f2c0100
[6554534.743893] 0000000000013780 ffff880187b45fd8 ffff880187b45fd8 ffff880101906780
[6554534.743895] 0000000000000246 000000018134fb39 ffff88041ffc8328 ffff88039bac2dd8
[6554534.743896] Call Trace:
[6554534.743899] [<ffffffffa019e660>] ? do_get_write_access+0x1ad/0x36a [jbd2]
...
Мы знаем, что это вызвано запросами PostgreSQL. Вот вывод iotop, пока это происходит:
22609 be/4 postgres 441.12 K/s 0.00 B/s 0.00 % 98.46 % postgres: db_name~a_1 127.0.0.1(33183) SELECT
24359 be/4 postgres 988.02 K/s 0.00 B/s 0.00 % 98.22 % postgres: db_name~a_1 127.0.0.1(34194) SELECT
Вы можете подумать: «Просто оптимизируй свою БД, чувак. Где загадка?» Однако примите во внимание 3 вещи:
Есть еще один экземпляр того же приложения, использующий ту же схему базы данных на /dev/sdb, при одинаковой нагрузке. Давление ввода-вывода там нормальное, редко превышает 10-20%.
Посмотрите на совокупную пропускную способность двух процессов PostgreSQL в этом листинге. Едва проходит 1 МБ / с. Это кажется слишком низким для процесса базы данных (который следует оптимизировать, чтобы он был как можно более последовательным).
Какой бы ни была нагрузка на жесткий диск, он никогда не должен полностью блокироваться, как здесь, вплоть до появления ошибок ядра и простого ls займет минуту, чтобы завершить.
Мой вывод из всего этого таков: /dev/sda выходит из строя и требует замены. И в этом проблема. Прежде чем связаться с хост-компанией, мне нужно предоставить доказательства того, что жесткий диск действительно неисправен. Тем не мение...
smartctl /dev/sda --all
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Device Model: WDC WD1003FBYZ-010FB0
...
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
...
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 100 253 021 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 2
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 2114
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 2
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 2
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 9
194 Temperature_Celsius 0x0022 112 109 000 Old_age Always - 35
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 2108 -
...
(усеченный вывод, напишите мне комментарий, если я вырезал слишком много)
Как видите, smartctl говорит, что все в порядке. Я даже провел полный тест, и ошибок не обнаружил.
Так что я здесь в растерянности. Все указывает на неисправный жесткий диск, но мониторинг S.M.A.R.T ничего не обнаруживает.
Мои вопросы:
ОБНОВЛЕНИЕ 1
По совету Баруха я выполнил сканирование дисков. К сожалению, он не нашел ничего, на что я мог бы указать.
diskscan /dev/sda
diskscan version HEAD
I: Validating path /dev/sda
I: Opened disk /dev/sda sector size 512 num bytes 1000204885504
I: Scanning disk /dev/sda in 65536 byte steps
I: Scan started at: Sun Aug 31 04:21:33 2014
Access time histogram:
1: 14138808
10: 923503
100: 183268
500: 15944
1000: 436
2000: 1
3000: 0
4000: 0
5000: 0
6000: 0
7000: 0
8000: 0
9000: 0
10000: 0
15000: 0
20000: 0
25000: 0
30000: 0
above that: 0
1290 |
|
| ^
|
|
1075 |
|
| ^
|
|
860 | ^
| ^ ^
|
| ^ ^ ^ ^ ^
| ^ ^^ ^ ^
645 | ^^ ^ ^ ^^^ ^ ^ ^ ^^^^^ ^^ ^
| ^ ^ ^ ^ ^ ^ ^^^ ^
| ^ ^ ^ ^ ^ ^ ^^
| ^ ^ ^ ^
| ^ ^ ^ ^
430 | ^ ^^^ ^ ^ ^
|
| ^ ^ ^^
|
|
215 |
|
|
| **********************************************************************
| ______________________________________________________________________
+-----------------------------------------------------------------------
Conclusion: passed
I: Scan ended at: Sun Aug 31 09:22:34 2014
I: Scan took 18061 second
I: Closed disk /dev/sda
Я также обновил свои частичные резервные копии и собираюсь сделать полную резервную копию, прежде чем продолжить.
Следующие шаги:
Я установил скрипт iosnoop (предложенный Барухом). Я могу заставить его собирать задержки, но я не могу понять, как заставить его производить что-либо, что могло бы быть полезной информацией для хостинговой компании.
Третье предложение Баруха - над моей головой банкомат. Я изучу это подробнее и обновлю, если что-то выясню.
Если к завтрашнему дню ничего не пойму, все равно порекомендую просто купить другой диск и перенести туда sda. Тогда мы узнаем, была ли проблема с диском или что-то еще, и продолжим.
ОБНОВЛЕНИЕ 2
Казнен smartctl -x. Ничего особенного, но вот пастебин с полными результатами.
Включено подробное ведение журнала scsi в соответствии с инструкциями Баруха. Я получаю много подобных вещей в моем / var / log / messages:
Aug 31 15:28:07 swfemail kernel: [7539683.491379] sd 0:0:0:0: [sda] Send:
Aug 31 15:28:07 swfemail kernel: [7539683.491382] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 01 3f ce 80 00 00 10 00
Aug 31 15:28:07 swfemail kernel: [7539683.491526] sd 0:0:0:0: [sda] Send:
Aug 31 15:28:07 swfemail kernel: [7539683.491528] sd 0:0:0:0: [sda] CDB: Synchronize Cache(10): 35 00 00 00 00 00 00 00 00 00
Aug 31 15:28:08 swfemail kernel: [7539684.411573] sd 0:0:0:0: [sda] Send:
Aug 31 15:28:08 swfemail kernel: [7539684.411576] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 01 b6 da d0 00 00 08 00
Aug 31 15:28:08 swfemail kernel: [7539684.411597] sd 0:0:0:0: [sda] Send:
Aug 31 15:28:08 swfemail kernel: [7539684.411598] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 01 b6 ba d0 00 00 08 00
Aug 31 15:28:08 swfemail kernel: [7539684.411639] sd 0:0:0:0: [sda] Send:
Aug 31 15:28:08 swfemail kernel: [7539684.411639] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 05 c6 18 88 00 00 a8 00
Aug 31 15:28:08 swfemail kernel: [7539684.412056] sd 0:0:0:0: [sda] Send:
Aug 31 15:28:08 swfemail kernel: [7539684.412057] sd 0:0:0:0: [sda] CDB: Synchronize Cache(10): 35 00 00 00 00 00 00 00 00 00
Пока ничего особо полезного, но диск вошел в "тихую" фазу. Я постараюсь поймать вывод, когда он снова начнет блокироваться.
С опозданием я подумал проверить старые сообщения об ошибках ядра. Ничего не выскакивает как прямая ошибка. Просто куча предупреждений о таймауте.
ОБНОВЛЕНИЕ 3
Пытался прочитать журналы scsi в течение временного окна 100% давления. Нет записей ERROR или TIMEOUT :-(
Мы добавили еще один HDD. В настоящее время я клонирую его с помощью dd if=/dev/sda of=/dev/sdc bs=32M (позже я сделаю еще один проход с rsync в автономном режиме). Я ожидаю, что это будет сделано к концу дня.
Я обновлю снова через несколько дней с результатами.
ОБНОВЛЕНИЕ 4
Из-за проблем с нашей хостинговой компанией мы не смогли полностью переключиться на новый диск. Пока проблемы не будут решены, мы пошли на компромисс, переместив на новый диск только базу данных. Вот текущий макет (только подходящие устройства):
/dev/sdc1 92G 23G 65G 26% /
/dev/sdb1 917G 170G 701G 20% /var/lib/data/vol2
/dev/sda2 826G 71G 714G 9% /var/lib/data/vol1
/dev/sdc это (потенциально) плохой диск. /dev/sda это новый диск, на котором теперь есть база данных.
Следующим шагом является мониторинг ситуации и выяснение, возвращаются ли 100% всплески использования. Я обновлю (и, надеюсь, опубликую принятый ответ) через несколько дней.
Скорее всего, у вас проблема с диском. Диск выходит из строя, и один довольно распространенный метод сбоя - иметь более высокие задержки из-за увеличения количества повторных попыток в определенных проблемных областях на диске, эти области при попадании вызовут цепную реакцию других операций ввода-вывода, ожидающих на них, и если было несколько операций ввода-вывода. в затронутую область вы увидите такую проблему, поскольку будет несколько блокировок ввода-вывода в течение> 10 секунд.
Могу порекомендовать протестировать диск с diskscan он покажет вам график задержки на диске. Он может работать в режиме только для чтения, поэтому не является разрушительным. Вы также можете попросить его исправить области, которые читаются, но очень медленно, но сначала проверьте диск, чтобы увидеть, как он себя ведет.
Возможно, проблема носит временный характер и не будет замечена программой diskscan. Вы можете запустить iosnoop для сбора истории всех операций ввода-вывода и их задержек. Скрипт добавляет некоторые накладные расходы, но работает очень хорошо. Если проблема возникает нечасто, для более длительного сеанса регистрации может потребоваться сценарий.
Вы можете увеличить уровень ведения журнала подсистемы scsi, чтобы попытаться получить больше информации из ядра, если вы используете LSI SAS HBA для доступа к дискам, вы также можете увеличить уровень ведения журнала драйвера mpt2sas, чтобы получить от него больше информации. Оба могут помочь увидеть, есть ли тайм-ауты и прерывания в ядре. Убедитесь, что вы видите сообщения журнала в ядре, касающиеся тайм-аутов и прерываний, они могут служить еще одной подсказкой.
Изменить 1:
Чтобы включить ведение журнала отладки SCSI, вы можете использовать команду: echo 9411 > /proc/sys/dev/scsi/logging_level вам может потребоваться использовать другое место для файла sys.
Также попробуйте запустить smartctl с параметром -x, он покажет несколько последних ошибок, если они есть.