Плохая материнская плата / контроллер / HD?
На арендованном сервере я сталкиваюсь с некоторыми проблемами синхронизации с приложением, которое требует точной синхронизации. Сервер представляет собой 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 виновником в моих глазах.
2 ответа
Некоторый дрейф неизбежен. Часовая дисциплина, обеспечиваемая такими вещами как NTP, помогает сгладить это В Linux используется выбор таймеров, и некоторые из них уязвимы для дрейфа, связанного с нагрузкой. Дисковый ввод-вывод, вызывающий дрейф, неудивителен в двухдисковой системе, поскольку вполне возможно, что контроллер памяти и контроллер времени находятся на одном чипе южного моста.
Таймер HPET более точен, но требует корректировки, чтобы оставаться верным UTC. Более точные таймеры потребуют программного обеспечения, чтобы убедиться, что время не дрейфует (например, ntp) или специального оборудования.
Что касается чрезмерного времени DSK, я видел случаи, когда IOWAIT поднимается до безумных уровней. Это результат того, что дисковая подсистема не в состоянии удовлетворить спрос, а ваша команда dd предназначена для того, чтобы за короткое время выбросить на диск много данных. В двухдисковой системе это кажется... необычным. Я подозреваю, что где-то в прошивке материнской платы указан неверный путь к данным; аппаратные сбои должны оставлять кричащие следы в dmesg.
Это странно. В общем, я бы попытался сначала переустановить кабели, а затем заменить их, если переустановка не работает.
Я видел, как жесткие диски начинают болеть с плохими секторами и очень низкой производительностью. Как вы упомянули, вероятность того, что два диска выйдут из строя одновременно, поддается контроллеру или материнской плате.
Если это вообще возможно, я бы попытался удалить один диск за раз и снова запустить ваши тесты, чтобы увидеть, все ли проблемы с производительностью все еще присутствуют при использовании одного или только с обоими.
Удачи.