На арендованном сервере я сталкиваюсь с некоторыми проблемами синхронизации с приложением, которое требует точного времени. Сервер представляет собой Dual Xeon E5410, работающий на материнской плате Supermicro X7DVL-3 под CentOs 5.5 x64.
Приложение, которое я запускаю, чувствительно к таймеру и продолжает определять дрейф как под нагрузкой, так и в режиме ожидания, но особенно под нагрузкой. Я провел небольшое расследование с помощью atop и dd и нашел несколько потрясающих цифр. Имейте в виду, я не гуру Linux, но что-то явно не в порядке.
Я побежал:
dd bs=4096 if=/dev/zero of=/bigtestfile
для генерации дисковой активности. Независимо от того, записал ли я его в sda или sdb, мое значение DSK в верхней части превысит 100%, а за один раз достигнет 1700%. Опять же, не имеет значения, пишу я в sda или sdb.
DSK | sdb | busy 675% | read 0 | write 110 | avio 78 ms |
Вот результаты работы smartctl:
# smartctl -A /dev/sda
smartctl version 5.38 [x86_64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF READ SMART DATA SECTION ===
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 0x000b 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0007 165 165 021 Pre-fail Always - 2750
4 Start_Stop_Count 0x0032 100 100 040 Old_age Always - 21
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x000a 200 200 051 Old_age Always - 0
9 Power_On_Hours 0x0032 065 065 000 Old_age Always - 25831
10 Spin_Retry_Count 0x0012 100 253 051 Old_age Always - 0
11 Calibration_Retry_Count 0x0012 100 253 051 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21
194 Temperature_Celsius 0x0022 116 093 000 Old_age Always - 27
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0012 200 200 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 051 Old_age Offline - 0
# smartctl -A /dev/sdb
smartctl version 5.38 [x86_64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF READ SMART DATA SECTION ===
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 0x000f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0003 180 180 021 Pre-fail Always - 3958
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 22
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0
9 Power_On_Hours 0x0032 068 068 000 Old_age Always - 24087
10 Spin_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21
194 Temperature_Celsius 0x0022 122 096 000 Old_age Always - 25
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0009 200 200 051 Pre-fail Offline - 0
Есть идеи, что здесь не так? Плохая материнская плата? Казалось бы, редко когда оба диска выходят из строя (smartctl говорит, что они PASS_, поэтому в моих глазах виновником остается mobo.
Это странно. В общем, я бы попробовал сначала переустановить кабели, а затем заменить их, если переустановка не работает.
Я видел, как жесткие диски начинали заболеть плохими секторами и очень низкой производительностью. Вероятность того, что два диска выйдут из строя одновременно, поддается контроллеру или материнской плате, как вы упомянули.
Если это вообще возможно, я бы попытался удалить один диск за раз и снова запустить тесты, чтобы увидеть, присутствуют ли проблемы с производительностью только с одним из них или только с обоими.
Удачи.
Некоторый дрейф неизбежен. Дисциплина времени, обеспечиваемая такими вещами, как NTP, помогает сгладить это. В Linux есть несколько используемых таймеров, и некоторые из них уязвимы для дрейфа, связанного с загрузкой. Дисковый ввод-вывод, вызывающий дрейф, неудивителен для двухдисковой системы, поскольку вполне возможно, что контроллер хранилища и контроллер времени находятся на одном кристалле южного моста.
Таймер HPET более точен, но требует корректировки, чтобы оставаться верным UTC. Для более точных таймеров потребуется программное обеспечение, чтобы убедиться, что время не дрейфует (например, ntp) или специальное оборудование.
Что касается чрезмерного времени DSK, я видел случаи, когда IOWAIT поднимался до безумного уровня. Это результат того, что дисковая подсистема не может справиться со спросом, и ваша команда dd предназначена для много данных на диске за короткий промежуток времени. В двухдисковой системе это кажется ... необычным. Я подозреваю неправильный путь к данным где-то в прошивке материнской платы; аппаратные сбои должны оставлять кричащие следы в dmesg.