Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 81
При пролистывании кажется что кулеры крутятся, мистика…
8-летний комп дома стал подтормаживать. Теперь догадываюсь, почему.
Виноваты во всем космические лучи?
Если бы я поставил смайлик, было бы понятней, что я шучу?
Тут дело в том, что на хабре накопилась критическая масса людей, которые могут такое сообщить не в виде шутки, а абсолютно серьёзно. Поэтому, если бы вы так пошутили в узком кругу, то вас поняли бы без смайлика, но здесь скорее всего подумают, что человек сказал не шутку, а глупость.
Да, к сожалению чувствую, что если хочешь откликов, надо на Хабре переходить на статьи вида «Копирасты ацтоооой! Отобрать у америки и раздать всем по ноуту, а мой новый мобильник такая аняняня, зырьте мой видеоблог!» :-)
Вот тут будет сотня плюсов в карму и двести комментов :)
Вот тут будет сотня плюсов в карму и двести комментов :)
Нет, что вы. Статья замечательная. Я прочитал её с удовольствием, но что-то комментировать по теме не стал просто потому что нечего добавить, а повышать энтропию нет желания. Но информацию взял на заметку и плюсики расставил.
А в холиварных статьях, понятно, может высказаться каждый, даже не обладая какими-либо знаниями, поэтому там движуха.
Здесь, чтобы понять, надо же знать что такое ECC, где оно используется, зачем и т.п. Я думаю, что даже программисты отдельных отраслей могут не обладать требуемыми для осмысления знаниями.
А в холиварных статьях, понятно, может высказаться каждый, даже не обладая какими-либо знаниями, поэтому там движуха.
Здесь, чтобы понять, надо же знать что такое ECC, где оно используется, зачем и т.п. Я думаю, что даже программисты отдельных отраслей могут не обладать требуемыми для осмысления знаниями.
тогда вам придётся пройти хаброквест по правильному комментированию. модераторы почему-то не реагируют на тупые комментарии, на бесполезные и т.д. на отмечают комментарии со смайликами.
В школу уже пошел? =)
исследование старое, с тех пор техпроцесс поменялся 3 раза уже. в 2009 году только DDR1 и ранние DDR2 (с таким выделением, что надо было радиаторы ставить) можно было наблюдать 3 года подряд.
ЕСС память как раз и нужна для коррекции ошибок, обычно это работает отлично.
ЕСС память как раз и нужна для коррекции ошибок, обычно это работает отлично.
исследование старое, с тех пор техпроцесс поменялся 3 раза уже.
У вас есть сведения, что сейчас ситуация изменилась столь радикально, что выводы исследования уже неверны?
С удовольствием посмотрю ваши данные.
Видите ли, свойства научных результатов как раз и заключаются в том, что они устанавливают общие правила, законы; например законы Ньютона в макромире не устарели за триста с лишним лет, прошедших с момента их публикации, и никто не набирается смелости утверждать, что «исследование старое, с тех пор техпроцесс поменялся 3 раза уже».
Именно этим наука и отличается от маркетингового булшита.
думаю так. память сейчас делают на 22нм уверенно. напряжение снизилось, LV DIMM 16Gb ЕСС жрет максимум 5Вт.
что бы сделать 16Гб в машинах позапрошлого поколения надо было ставить 4 DDR2 ECC REG димма, которые делались по два или в три раза более широкому процессу, www.dailycomm.ru/m/2320/ — 45нм, а до этого и 60. грелись они сильно, электричества жрали много. Чем теплее — тем больше AFR для тонкой электроники такого типа. Больше плашек — больше вероятность выхода.
никто и не спорит что такое бывает и надо думать когда набиваешь на ноду 512Г памяти, вероятность появления ошибки бита на мегабайт является константой для заданного типа памяти и техпроцесса. Но для этого ЕСС и есть =)
у меня сведения сугубо практические — раз в год меняем планку памяти по гарантии из нескольких тысяч что стоят у меня в серверах, в основном ДДР3.
что бы сделать 16Гб в машинах позапрошлого поколения надо было ставить 4 DDR2 ECC REG димма, которые делались по два или в три раза более широкому процессу, www.dailycomm.ru/m/2320/ — 45нм, а до этого и 60. грелись они сильно, электричества жрали много. Чем теплее — тем больше AFR для тонкой электроники такого типа. Больше плашек — больше вероятность выхода.
никто и не спорит что такое бывает и надо думать когда набиваешь на ноду 512Г памяти, вероятность появления ошибки бита на мегабайт является константой для заданного типа памяти и техпроцесса. Но для этого ЕСС и есть =)
у меня сведения сугубо практические — раз в год меняем планку памяти по гарантии из нескольких тысяч что стоят у меня в серверах, в основном ДДР3.
Специально для такого рода возражений в работе проделан анализ для всех шести типов разных поколений DRAM, установленных на протяжении нескольких лет в модулях кластера, и никакой статистически существенной разницы в результатах между ними замечено не было. Учитывая же, что никакого принципиального технологического скачка между DDR2 и DDR3, а также при переходе от 45 к 22, не было, то результаты вполне экстраполируются линейно.
Опять же, если у вас есть иные результаты — показывайте, мы же не в церкви, чтобы оперировать аргументами «а я не верю, вот не верю и все!»
Опять же, если у вас есть иные результаты — показывайте, мы же не в церкви, чтобы оперировать аргументами «а я не верю, вот не верю и все!»
И кстати прочитайте все же работу целиком, вам по работе положено такое читать, а не довольствоваться «пересказом для школьников» ;) В особенности обратите внимание, где они говорят о scrubbing и о величинах soft и hard errors. Возможно вы найдете ответы на свои вопросы, почему вы видите меньше ошибок, чем их в действительности происходит.
По поводу памяти. Мне вот интересно насколько забиваются пылью сервера. Потому что на обычных компах, ошибки памяти часто лечатся банальной чисткой контактов. Станет ли кто то замораживаться с сервера в этом плане для меня вопрос, но вот можно ли говорить о «старении» модулей тоже интересно.
В нормальном датацентре пыли нет, насколько я знаю, поэтому такой проблемы просто не существует.
Чистят контакты не от пыли, а от окисла.
По наблюдениям — пыли практически нет. Сервер двух-трёх летней давности имеет едва заметный на пальце слой пыли (эквивалент 1-2 дня в помещении). Никаких легендарных чёрных монстров, живущих под кулерами процессоров и в БП нет.
Цена этого удовольствия — отвратительный воздух в серверной. Сухой, холодный, плюс шум. (час работы в серверной выбивает из колеи на целый день, а то и больше).
Цена этого удовольствия — отвратительный воздух в серверной. Сухой, холодный, плюс шум. (час работы в серверной выбивает из колеи на целый день, а то и больше).
Я в дц, где организация аредует стойку, езжу как на праздник. Там хорошо, прохладно, комфортно и людей нет =) думаю над сменой работы с офисного linux-админа на инженера дц, но зп печальная. реально вообще получать ~50т.р., работая в дц с железками?
Серверам плохо, если человеку хорошо. По нормативам в машинном зале должно быть сухо — много более сухо, чем в помещениях. Мгновенно начинает першить в горле. Плюс сквозняки, плюс шум, плюс вибрации.
По моим оценкам инженер в ДЦ по статусу ближе к «эникейщику», а не к админу.
По моим оценкам инженер в ДЦ по статусу ближе к «эникейщику», а не к админу.
А вот, кстати, интересно. Вроде бы где-то пишут, что да, 45-55. По моим наблюдениям такого не бывает (ибо после кондиционеров воздух нужно увлажнять — вы видели хоть раз увлажнители в серверной?)
Относительная влажность же! Чем холоднее воздух — тем относительная влажность выше при одинаковой абсолютной, поэтому из кондеев и течёт летом. Это в машине после кондиционера сухо, потому что он сильно охлаждает, влага конденсируется, потом печка греет и в итоге воздух сушится. В серверных же чуть ли не замкнутый цикл воздухообмена, если кондеями охлаждается, влаге некуда деться.
Я вполне понимаю. Но в серверной на кондеях тоже оседает влага и выводится наружу. Соответственно, воздух сушится, причём в силу большого потока, очень сильно. Плюс на выходе с серверов он нагревается и становится ещё суше. Вердикт — в серверных обычно невыносимо сухо.
Говорю и по теории, и по суровой практике.
Говорю и по теории, и по суровой практике.
А забор воздуха снаружи есть? Вообще, проще всего гигрометр повесить да посмотреть, сколько покажет. 50% влажности — это уже очень-очень сухой воздух, и тут верить собственным ощущениям сложно, они не откалиброваны. Я давненько в серверных не был, но прям першения в горле не запомнилось В серверной ММВБ даже очень холодно было, хотя мы там больше получаса провели. Вот дубеющие пальцы, когда работаешь у открытого шкафа — это да, не в перчатках же на клавиатуре кнопки нажимать.
Отдельных увлажнителей я не видел, но промышленные кондиционеры с управлением влажностью встречал, в том числе и в серверных.
Да, у нас стоят прецизионники с увлажнителями.
Когда занимался согласованием, читал, что сухой воздух помимо статики еще влияет на состояние смазки в кулерах и HDD.
Когда занимался согласованием, читал, что сухой воздух помимо статики еще влияет на состояние смазки в кулерах и HDD.
Понятно, что нижеследующие расчёты не претендуют на точность. Я только попытался осмыслить цифры из статьи и сделать выводы.
Итак, в среднем получается 50 ошибок на миллион часов работы сервера или одна ошибка за 2 года и 4 месяца.
Если допустить что в среднюю ячейку производится считывание или запись 1000 раз в секунду, то получим вероятность ошибки 1,4 * 10-11, что на 3-4 порядков больше, чем вероятность ошибки для HDD.
Что странно выглядит и действительно ломает мои представления о сравнительной надёжности памяти и HDD. Хотя с другой стороны, если винт стал ошибаться, то ему дорога на кладбище, а после зависания можно перегрузиться и ещё 2,5 года работать…
Однако если учесть, что 20% модулей дают 90% ошибок, то если повезёт с модулями памяти (вероятность везения 0.8*n, где n число модулей), мы получим вероятность ошибки в 10 раз меньшую.
То есть 1 ошибка на 23 года. Что очень круто.
В практическом смысле получается, что даже из-за одной такой ошибки есть смысл менять модули памяти для ответственных серверов, так как с вероятностью 0,9 мы имеем глючный модуль с повышенной вероятностью ошибок. Если, конечно, BIOS позволяет точно детектировать какой модуль дал ошибку.
Второй практический вывод: вероятность того, что у сервера не будет проблем с памятью зависит от числа её модулей. Есть смысл ставить минимальное число модулей максимальной ёмкости. С оговоркой, что иногда потенциал контроллера памяти раскрывается при чётном или троичном числе модулей.
Итак, в среднем получается 50 ошибок на миллион часов работы сервера или одна ошибка за 2 года и 4 месяца.
Если допустить что в среднюю ячейку производится считывание или запись 1000 раз в секунду, то получим вероятность ошибки 1,4 * 10-11, что на 3-4 порядков больше, чем вероятность ошибки для HDD.
Что странно выглядит и действительно ломает мои представления о сравнительной надёжности памяти и HDD. Хотя с другой стороны, если винт стал ошибаться, то ему дорога на кладбище, а после зависания можно перегрузиться и ещё 2,5 года работать…
Однако если учесть, что 20% модулей дают 90% ошибок, то если повезёт с модулями памяти (вероятность везения 0.8*n, где n число модулей), мы получим вероятность ошибки в 10 раз меньшую.
То есть 1 ошибка на 23 года. Что очень круто.
В практическом смысле получается, что даже из-за одной такой ошибки есть смысл менять модули памяти для ответственных серверов, так как с вероятностью 0,9 мы имеем глючный модуль с повышенной вероятностью ошибок. Если, конечно, BIOS позволяет точно детектировать какой модуль дал ошибку.
Второй практический вывод: вероятность того, что у сервера не будет проблем с памятью зависит от числа её модулей. Есть смысл ставить минимальное число модулей максимальной ёмкости. С оговоркой, что иногда потенциал контроллера памяти раскрывается при чётном или троичном числе модулей.
То есть 1 ошибка на 23 года. Что очень круто.
Я думаю, что вы допускаете ту же ошибку, что допускают при неправильном оперировании цифрами MTBF для жестких дисков.
Вроде в таких цифрах для оперативной памяти (в отличие от HDD) нет ничего удивительного — 22 года работал Пионер 11 и 29 лет Пионер 10.
Тем более что
Т.е. если использовать память высочайшего качества, то отсутствие движущихся частей всё-таки даёт о себе знать.
Тем более что
Парадоксальным образом статистика демонстрирует увеличивающиеся темпы роста correctable errors с увеличением возраста модулей, но снижающийся темп для Uncorrectable errors, однако скорее всего это просто результат плановой замены памяти в серверах, которые были замечены за сбоями.
Т.е. если использовать память высочайшего качества, то отсутствие движущихся частей всё-таки даёт о себе знать.
Неправильное предположение.
Откуда там 1000 раз в секунду? Самые нагруженные области меняются несколько сотен миллионов раз за секунду. И никого не волнует, что это всего лишь обновляющийся счётчик времени или ещё какая-нибудь не особо интересная вещь.
Просто для интереса осознайте, сколько раз в секунду меняются значения у сервера, раздающего по сети что-нибудь на 10-20 гигабит.
Откуда там 1000 раз в секунду? Самые нагруженные области меняются несколько сотен миллионов раз за секунду. И никого не волнует, что это всего лишь обновляющийся счётчик времени или ещё какая-нибудь не особо интересная вещь.
Просто для интереса осознайте, сколько раз в секунду меняются значения у сервера, раздающего по сети что-нибудь на 10-20 гигабит.
Такие сервера, которые 10-20 гигабит раздают, ещё хорошо поискать надо. У гугловских серверов-картриджей (у тех что на картинке) на более 1Гбита сетевуха.
А 1000 — ну это же в среднем. А есть области, которые вообще почти не меняются: коды программ, кешированные данные.
В принципе даже легко ПРИБЛИЗИТЕЛЬНО прикинуть: если 800 МГц шина памяти, 2-х канальный контроллер памяти, допустим каждый канал способен 16 байт передать за рабочий цикл, а всего памяти стоит 8ГБ. Это означает что за 1 секунду в RAM можно записать 25Гб. Что в среднем означает в каждую ячейку всего чуть более 3-х записей/чтений в секунду происходит. И это при максимальной загрузке памяти.
Реальное среднее значение операций чтения/записи на одну ячейку памяти скорее всего будет близко к 1 разу за секунду.
А 1000 — ну это же в среднем. А есть области, которые вообще почти не меняются: коды программ, кешированные данные.
В принципе даже легко ПРИБЛИЗИТЕЛЬНО прикинуть: если 800 МГц шина памяти, 2-х канальный контроллер памяти, допустим каждый канал способен 16 байт передать за рабочий цикл, а всего памяти стоит 8ГБ. Это означает что за 1 секунду в RAM можно записать 25Гб. Что в среднем означает в каждую ячейку всего чуть более 3-х записей/чтений в секунду происходит. И это при максимальной загрузке памяти.
Реальное среднее значение операций чтения/записи на одну ячейку памяти скорее всего будет близко к 1 разу за секунду.
DMA забываете. С диска читаем — данные в памяти без копирования через процессор. Данные по сети отсылаем — с учётом offload'а на сетевую карту рассчёта контрольных сумм и части tcp, аналогично, процессор там только часть заголовков дописывает, а payload как был, так и передаётся.
По цифрам — на новых серверах уже давно 4х канальная память, по попугаям там до 40-60ГБ/с.
А «среднее» учитывать некорректно — потому что если одну область памяти долбят со скоростью среды всю жизнь, а другую — раз в пол-года перечитывают, то когда планка вылетает в «горячей» области, никого не волнует состояние здоровья «холодной».
Заметим, любые механизмы виртуальной памяти, которые бы слегка уменьшить износ, не работают для ядра. Есть unrelocable области, которые где положены, там лежать и должны.
По цифрам — на новых серверах уже давно 4х канальная память, по попугаям там до 40-60ГБ/с.
А «среднее» учитывать некорректно — потому что если одну область памяти долбят со скоростью среды всю жизнь, а другую — раз в пол-года перечитывают, то когда планка вылетает в «горячей» области, никого не волнует состояние здоровья «холодной».
Заметим, любые механизмы виртуальной памяти, которые бы слегка уменьшить износ, не работают для ядра. Есть unrelocable области, которые где положены, там лежать и должны.
А вот DMA тут не причём. Да оно уменьшает загрузку процессора, но в моих расчётах процессор вообще не фигурировал, а только контроллер памяти, который обслуживает и процессор и устройства с DMA.
Есть у меня смутное подозрение, что сама природа DRAM, когда происходят постоянные обновления, даёт примерно такую же нагрузку, что и долбёжка в какую-то определённую ячейку…
Есть у меня смутное подозрение, что сама природа DRAM, когда происходят постоянные обновления, даёт примерно такую же нагрузку, что и долбёжка в какую-то определённую ячейку…
Возможно.
Кстати, я, кажется, вижу важную деталь. Память, как и многие другие устройства, имеет режимы энергосбережения с понижением напряжения.
Возможно, на нагруженных серверах нет моментов энергосбережения, то есть память на боевых напряжениях всегда. Тогда ситуация ясна: чем дольше срок с приложенным высоким (относительно низкого standby) напряжением, тем больший процент отказов.
Кстати, я, кажется, вижу важную деталь. Память, как и многие другие устройства, имеет режимы энергосбережения с понижением напряжения.
Возможно, на нагруженных серверах нет моментов энергосбережения, то есть память на боевых напряжениях всегда. Тогда ситуация ясна: чем дольше срок с приложенным высоким (относительно низкого standby) напряжением, тем больший процент отказов.
кстати
«ECC DRAM — ненужная трата денег, ведь у меня десктоп работает без ECC, и ничего»
в сервер последнее время ничего кроме ЕСС и не вставишь, а регистровая на большие объемы только ЕСС и бывает.
разницы по цене между ЕСС и не-ЕСС нет уже года 3 как, как DDR3 появилась
«ECC DRAM — ненужная трата денег, ведь у меня десктоп работает без ECC, и ничего»
в сервер последнее время ничего кроме ЕСС и не вставишь, а регистровая на большие объемы только ЕСС и бывает.
разницы по цене между ЕСС и не-ЕСС нет уже года 3 как, как DDR3 появилась
Разница в цене есть в остальных комплектующих. Нельзя в произвольную десктопную плату вставить ECC память.
И часто вы в сервера ставите десктопные матери?
Понятие «севрер», в особенности для впервые этим вопросом занимающихся, может трактовать ну очень широко и вольно.
К тому же, если я правильно помню, во многие сервера начального уровня действительно можно поставить память без ECC, хотя это и не рекомендуется производителями их.
К тому же, если я правильно помню, во многие сервера начального уровня действительно можно поставить память без ECC, хотя это и не рекомендуется производителями их.
Отвечу вопром на вопрос — часто ли вы в серверные платы ставите не ECC память?
Речь о цене на комплектующие. Без ECC можно собрать дешевле.
Речь о цене на комплектующие. Без ECC можно собрать дешевле.
Не ставлю в сервера не ECC память.
Мы говорим о нормальном — брендовом сервере или самосборе на коленке из дектопного железа? Такое я себе только для домашнего применения позволяю, не более.
Мы говорим о нормальном — брендовом сервере или самосборе на коленке из дектопного железа? Такое я себе только для домашнего применения позволяю, не более.
В данном случае мы не о статье, а о том, что комментирует ULP.
ULP говорит о том что нет особой разницы в цене между ECC и неECC, вы же о десктопных матерях в серверах начали говорить. Для вас сервер это всё что работает не на ХР/7/8, без оглядки на железо?
Я как раз говорю о том что есть разница в цене между ECC и не-ECC. Она кроется в цене матплаты. Сама же матплата серверная vs десктопная формально ничем не отличается, кроме поддержки ECC.
(бывают отличия в дорогих вариантах в портах sas, встроенных raid и отсутствии usb и в формфакторе). Отличия в качестве комплектующих вещь недокументированная.
А вообще сам давно мечтаю приобрести домой себе ECC железо, workstation. И сервера (vps хостинг) выбираю дорогой но качественный, и только на брендовом железе, никакой ни дестопный хертзнер.
(бывают отличия в дорогих вариантах в портах sas, встроенных raid и отсутствии usb и в формфакторе). Отличия в качестве комплектующих вещь недокументированная.
А вообще сам давно мечтаю приобрести домой себе ECC железо, workstation. И сервера (vps хостинг) выбираю дорогой но качественный, и только на брендовом железе, никакой ни дестопный хертзнер.
Хорошо — задам вопрос по другому — вы много встречали брендовых серверов с дектопными матерями? Я вообще не понимаю как можно говорить о разнице в стоимости памяти, экстраполируя это на стоимость материнских плат — разного назначения? Тем более что просто так в магазине кроме серверных интелов или супермикро — ничего не купить. И документированных различий там тоже хватает: чипсет мат.платы (от которого зависит поддержка процессоров и памяти), чипсет видео, сети, raid -контроллера, да даже требуемое питание (24+8 у серверных против 24+4 у десктопных), различные чипы аппаратного мониторинга и управления + ПО к ним и т.д. Так что глупо сравнивать продукты, различного назначения. Всё-равно что внедорожник со спорт-каром сравнивать.
А вообще сам давно мечтаю приобрести домой себе ECC железо, workstation
Ну посмотрите на Хьлетовские workstation, обалдейте от цен… А потом посмотрите цены на ML110 G7.
Учитывая количество любителей дешевых серваков на Хецнере — часто. Там ведь только дорогие серии с ECC.
Конечно старает, диффузию никто не отменял. Чем меньше техпроцесс тем сильнее влияет диффузия. А так как количество элементов в современных чипах гигантское, то вроятность фатальных изменений со временем тоже не маленькое.
Специально для вас, раз вы читаете выборочно:
«Было установлено, что сравнительно новые модули, выполненные с более высокой плотностью и более тонкими техпроцессами, не показывают более высокого уровня отказов. По-видимому пока в технологии DRAM технологический предел, близ которого начинаются проблемы с надежностью, пока не достигнут. В наблюдаемом парке модулей было примерно шесть разных типов и поколений памяти (DDR1, DDR2 и FBDIMM разных типов), и корреляции между высокой плотностью и числом отказов и сбоев выявлено не было.»
«Отсутствие корреляции» более простым языком, означает, что «разницы нет».
«Было установлено, что сравнительно новые модули, выполненные с более высокой плотностью и более тонкими техпроцессами, не показывают более высокого уровня отказов. По-видимому пока в технологии DRAM технологический предел, близ которого начинаются проблемы с надежностью, пока не достигнут. В наблюдаемом парке модулей было примерно шесть разных типов и поколений памяти (DDR1, DDR2 и FBDIMM разных типов), и корреляции между высокой плотностью и числом отказов и сбоев выявлено не было.»
«Отсутствие корреляции» более простым языком, означает, что «разницы нет».
Если кто-то прочитал ссылки — там идет исследование «consumer-серии железа».
На фотке я так же вижу кусок несерверного железа. Так о каком ECC сейчас речь? О какой статистике по винтам, если это SATA? Саташные винты вообще не рекомендуются к использованию в production.
Мой совет: s/сервер/pc + не делать таких глобальных выводов основываясь на данных которым больше 3/5 лет
На фотке я так же вижу кусок несерверного железа. Так о каком ECC сейчас речь? О какой статистике по винтам, если это SATA? Саташные винты вообще не рекомендуются к использованию в production.
Мой совет: s/сервер/pc + не делать таких глобальных выводов основываясь на данных которым больше 3/5 лет
1. Какие из ссылок? «Там» их много.
2. Google как раз и известен тем, что самый активный в индустрии проводник commodity-решений, то есть созданных не на специальных супер-пупер, а на общедоступном и массовом.
3. ECC, и даже Chipkill, тем не менее в его кластерах применяются. Причины этому — выше.
4. Если у вас есть другие, более точные данные — приведите их, иначе это пустой разговор. Как я уже сказал выше, мы не в церкви, чтобы разговаривать на уровне «верю — не верю». Как раз этим и отличается наука от веры, что у науки есть доазательства, а у веры — только «мнение».
2. Google как раз и известен тем, что самый активный в индустрии проводник commodity-решений, то есть созданных не на специальных супер-пупер, а на общедоступном и массовом.
3. ECC, и даже Chipkill, тем не менее в его кластерах применяются. Причины этому — выше.
4. Если у вас есть другие, более точные данные — приведите их, иначе это пустой разговор. Как я уже сказал выше, мы не в церкви, чтобы разговаривать на уровне «верю — не верю». Как раз этим и отличается наука от веры, что у науки есть доазательства, а у веры — только «мнение».
Не рекомендуются кем? SAS диски, к сожалению, слишком мелкие по объёму. К тому же у производителей есть enterprise-ready SATA диски, типа WD RE.
В оригинальной статье же написано, что память с ECC (иначе как бы они ошибки отследили?), а уж картинка для привлечения внимания на совести автора.
В оригинальной статье же написано, что память с ECC (иначе как бы они ошибки отследили?), а уж картинка для привлечения внимания на совести автора.
Есть такое. В условиях виртуализации с плотным заполнением хостов отказы памяти (MCE) более часты и более неприятны, чем у «самостоятельных» серверов.
Меня вот что в данном исследовании смутило:
«Однако существенно коррелировали отказы с загрузкой памяти и интенсивностью обмена с ней»
Тут авторы исследования зашли не в ту сторону. Просто, пока нет обмена с памятью, ошибки в ней не обнаруживаются. Информация может измениться в какой-нибудь ячейке и ждать своего часа, пока не произойдет ее считывание и проверка ECC. А если считывание не произойдет, или если произойдет запись — то такая ошибка никогда не будет обнаружена (правда, она и не повлияет никак на работу компьютера).
Неверны выводы по поводу последствий неисправленных ошибок памяти. Далеко не каждая такая ошибка приведет к падению системы (BSOD, Kernel Panic). Чтобы оценить вероятность тех или иных последствий, нужно рассмотреть, чем заполнена память во время работы системы. Как правило, она в основном заполнена данными приложений и дисковым кешем. Следовательно, наиболее вероятные последствия — порча памяти приложений. Но тот, кто разрабатывал софт на каком-нибудь языке типа С, должен не понаслышке знать о том, что далеко не каждая порча памяти приводит к краху приложения. Многие порчи остаются долгое время незамеченными или приводят к малозаметным, трудновоспроизводимым последствиям. Могут испортиться данные пользовательских документов.
Последствия порчи информации в дисковом кеше — то же самое, что порча информации в файлах. Может привести к краху приложения, может остаться незамеченной, может иметь тяжелые последствия (если, например, данные были зашифрованы — ошибка в одном бите может убить весь файл).
Ну и наконец, само ядро ОС принципиально ничем не отличается от приложений с точки зрения последствий порчи памяти в его структурах. Может пройти незамеченным, может привести к малозаметным последствиям, и лишь в некоторой части случаев произойдет крах ядра.
«Однако существенно коррелировали отказы с загрузкой памяти и интенсивностью обмена с ней»
Тут авторы исследования зашли не в ту сторону. Просто, пока нет обмена с памятью, ошибки в ней не обнаруживаются. Информация может измениться в какой-нибудь ячейке и ждать своего часа, пока не произойдет ее считывание и проверка ECC. А если считывание не произойдет, или если произойдет запись — то такая ошибка никогда не будет обнаружена (правда, она и не повлияет никак на работу компьютера).
Неверны выводы по поводу последствий неисправленных ошибок памяти. Далеко не каждая такая ошибка приведет к падению системы (BSOD, Kernel Panic). Чтобы оценить вероятность тех или иных последствий, нужно рассмотреть, чем заполнена память во время работы системы. Как правило, она в основном заполнена данными приложений и дисковым кешем. Следовательно, наиболее вероятные последствия — порча памяти приложений. Но тот, кто разрабатывал софт на каком-нибудь языке типа С, должен не понаслышке знать о том, что далеко не каждая порча памяти приводит к краху приложения. Многие порчи остаются долгое время незамеченными или приводят к малозаметным, трудновоспроизводимым последствиям. Могут испортиться данные пользовательских документов.
Последствия порчи информации в дисковом кеше — то же самое, что порча информации в файлах. Может привести к краху приложения, может остаться незамеченной, может иметь тяжелые последствия (если, например, данные были зашифрованы — ошибка в одном бите может убить весь файл).
Ну и наконец, само ядро ОС принципиально ничем не отличается от приложений с точки зрения последствий порчи памяти в его структурах. Может пройти незамеченным, может привести к малозаметным последствиям, и лишь в некоторой части случаев произойдет крах ядра.
Вот ещё одна статья о аппаратных отказах, на этот раз от Microsoft Research: research.microsoft.com/pubs/144888/eurosys84-nightingale.pdf
Мечтаю о ноуте с ECC но увы не видел таких даже среди всяких ToughBook и т.п.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статистика отказов в серверной памяти