Комментарии 27
На клавиатуре слева есть кнопка CapsLock...
Когда пишите заголовки, ее можно нажать (выключить)
Почему зеркало, а не level 5 (хотя бы)?
Почему только для Xeon Scalable? Как насчёт AMD?
Где почитать про алгоритмы этой ADDDC, кто их проверял математически?
Наконец, ПРЕКРАТИТЕ КРИЧАТЬ, пожалуйста.
Действительно, а кто-нибудь реально сталкивался с этими пресловутыми однобитными ошибками памяти? Насколько часто это происходит и от чего зависит, от вспышек на солнце?
У меня на десктопе ECC'шная память (спасибо, райзен), и я несколько раз в dmesg'е ловил их. На серверах тоже иногда происходят. Если эти ошибки редкие, то их игнорируют, если рейт ошибок выше определённого уровня, то память меняется.
На серверах тоже иногда происходят
у меня не так много серверов, ситуации «ошибка памяти встречается один/несколько раз в год» я не встречал.
или за год встречается 0 ошибок (>>90% серверов), или ошибки идут пачками и исчезают после замены памяти.
А где вы смотрите ошибки памяти? В зависимости от того, где смотрите, их будет, или их не будет.
в мониторинге (из dmesg) и в ipmi
mce надо ещё смотреть. В целом, странно, что вы не видите, потому что одиночные отказы памяти таки происходят. Если бы они не происходили, то потребности в multibit ecc не было бы.
ну вот вам пример с одного сервера:
root@someserver:~# edac-util -v
mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
mc0: csrow0: 0 Uncorrected Errors
mc0: csrow0: mc#0csrow#0channel#0: 0 Corrected Errors
mc0: csrow0: mc#0csrow#0channel#1: 0 Corrected Errors
mc0: csrow1: 0 Uncorrected Errors
mc0: csrow1: mc#0csrow#1channel#0: 0 Corrected Errors
mc0: csrow1: mc#0csrow#1channel#1: 0 Corrected Errors
mc0: csrow2: 0 Uncorrected Errors
mc0: csrow2: mc#0csrow#2channel#0: 0 Corrected Errors
mc0: csrow2: mc#0csrow#2channel#1: 0 Corrected Errors
mc0: csrow3: 0 Uncorrected Errors
mc0: csrow3: mc#0csrow#3channel#0: 0 Corrected Errors
mc0: csrow3: mc#0csrow#3channel#1: 0 Corrected Errors
edac-util: No errors to report.
root@someserver:~# uptime
17:26:23 up 352 days, 19:16, 1 user, load average: 0.69, 0.69, 0.77Ну, для одного сервера это нормально. Я говорю про большое количество. Я ткнулся в мониторинг, за последний месяц больше 300 серверов имело срабатывания.
Ну, для одного сервера это нормально. Я говорю про большое количество.
да, у меня перед глазами немного серверов, десятка 2-3.
но этого количества уже достаточно чтобы оценить ошибки ecc — это норма или же нет.
Я ткнулся в мониторинг, за последний месяц больше 300 серверов имело срабатывания.
из какого количества?
мне встречалось два исследования, от гугла 2009 года:
https://research.google.com/pubs/archive/35162.pdf
и от fb 2014 года:
https://users.ece.cmu.edu/~omutlu/pub/memory-errors-at-facebook_dsn15.pdf
в первом, ещё с ddr1 и ddr2, хостов с ошибками достаточно много (примерно треть), но есть явная корреляция между моделью платформы (читай материнской платы) и количеством ошибок, что намекает на то, что эти ошибки всё-таки вызваны аппаратными недоработками, а не являются свойствами памяти как таковой.
во втором, более свежем, более 90% хостов не встретили за год ни одной ошибки:
To compare against prior work, we measured the correctable error incidence rate over the course of twelve months (7/13 up to and including 7/14, excluding 1/14) and found that, cumulatively across all months, around 9.62% of servers experience correctable memory errors
хотя даже второе исследование не согласуется с моими ощущениями, у fb получается, что половина из сбойных серверов (то есть ≈5% от общего числа) за год встречалась с 1-10 ошибками в месяц, на моей практике таких не встречалось вовсе.
все случаи машин с ошибками ecc, с которыми я встречался (а таких было буквально 4-5 штук) были связаны с массовыми ошибками и решались заменой железа.
Серверов много. Часть из ошибок - реальные отказы памяти, но есть и флуктуации (единичные отказы).
тут порядок важен. если ориентироваться на статистику fb, то это должно быть порядка 10к серверов.
в общем-то, раз у вас есть статистика как минимум сотен серверов, то можно провести своё исследование, какие-то идеи можно почерпнуть в приведённых выше исследованиях fb и google, что-то своё тоже можно придумать (например, попробовать оценить корреляцию загруженности сервера и числа ошибок).
я бы на вашем месте занялся, интересно же.
вдогонку, сейчас подумал, что бо́льшая встречаемость ошибок у вас и у fb/google, чем у меня, может объясняться:
a. тем, что у вас больше памяти на хост (у меня на многих хостах 4 планки памяти);
b. большей нагрузкой на сервера, у меня многие сервера недозагружены (ecc обнаруживает ошибки при чтении; чем сильнее нагружена память, тем больше вероятность обнаружения ошибок).
Действительно, а кто-нибудь реально сталкивался с этими пресловутыми однобитными ошибками памяти? Насколько часто это происходит и от чего зависит, от вспышек на солнце?
на исправной памяти — фактически никогда.
но «битая» память — это, наверное, самая частая неисправность в компьютере.
моё мнение:
ecc — это в первую очередь механизм обнаружения ошибок.
без ecc тесты памяти изнурительны (длятся много часов и не позволяют использовать компьютер).
а то, что в большинстве случаев эти ошибки получается исправлять, я расцениваю как приятный бонус.
Я очень хочу послушать про программные ошибки в памяти на серверах HP. Либо там случилась технологическая революция, которую я пропустил, либо переводчик не до конца понимал, что переводит и назвал soft errors "программными ошибками".
Да, к технологии зеркалирования памяти у меня главный вопрос: а что делать, если расхождение между планками? Я вижу один вариант - падать. Нет ни одной причины доверять DIMM1A больше, чем DIMM1B.
А вот тройное зеркалирование я пока в серверах не видел.
Ну, это просто. Планка А "говорит" при чтении: "неисправимая ошибка", Планка Б "говорит": "ошибок не имею/исправимая ошибка". ECC же. Выбор очевиден.
А, окей, в таком сценарии понятно. Жертвуем 50% памяти ради +1 бита ECC. Но что делать в ситуации, когда обе планки уверены, что правы, но цифра различается?
В целом, memory mirroring выглядит как недоделанная технология. Она была бы куда полезнее, если бы при этом был hotswap memory. Тогда было бы круто. Одна планка вылетела, в это время её дублирует другая, заменили, полёт проходит без сбоев.
Вероятность такого события, при отсутсвии аппаратных неисправностей, я оцениваю в порядок 1е-111. Т.е. событие, которое вероятно НЕ произойдет до тепловой смерти вселенной. =) Если две планки показывают разные значения при отсутсвии ошибок - это аппаратная неисправность. Тут уж извольте как вам угодно плясать.
У вас multibit ecc, и она всё-таки бьётся. Вместо того, чтобы добавить ещё один бит для коррекции ошибки, вы добавляете вторую планку памяти?
Именно мультибит. Но, чтоб этот мультибит обозначился как безошыбочный, ошибочных битов должнобыть минимум 5, если я правильно помню ecc. Вот и считайте вероятность случайной ошибки в 5 разрядов на одной планке и более одного разряда на второй по тому же адресу.
Да, можно скурпулезно высчитывать эти вероятности. Но, главный факт в том, что событие космически маловероятно.
Предположение. Вероятность возникновения одинаковой ошибки в двух разных модулях очень мала. Вероятность возникновения разных ошибок с совпадающими результирующими кодами ЕСС исчезающе мала. Это все равно, что изменить символ в тексте, так чтобы контрольная сумма не изменилась
Была такая штука у меня на старых серверах на 604 чипсете, но чуть сложнее - не отдельный модуль, а блок памяти с несколькими модулями можно было отключить и заменить на горячую.
4 блока в серваке, то есть теоретически 2 зоны мирроринга.
Однако, мы не использовали - дорого очень такая избыточность обходилась бы.
Технологии обеспечения максимальной надежности (RAS) для оперативной памяти в серверах