Пользователь
0,0
рейтинг
6 марта 2013 в 11:39

Администрирование → Статистика отказов в серверной памяти



В 2009 году, на ежегодной научной конференции SIGMETRICS, группа исследователей, работавших в Университете Торонто с данными, собранными и предоставленными для изучения компанией Google, опубликовала крайне интересный документ "DRAM Errors in the Wild: A Large-Scale Field Study" посвященный статистике отказов в серверной оперативной памяти (DRAM). Хотя подобные исследования и проводились ранее (например исследование 2007 года, наблюдавшее парк в 300 компьютеров), это было первое исследование, охватившее такой значительный парк серверов, исчисляемый тысячами единиц, на протяжении свыше двух лет, и давшее столь всеобъемлющие статистические сведения.

Отмечу также, что та же группа исследователей, во главе с аспирантом, а ныне профессором Университета Торонто, Бианкой Шрёдер (Bianca Shroeder) ранее, в 2007 году публиковала не менее интересное исследование, посвященное статистике отказов жестких дисков в датацентрах Google (краткую популярную выжимку из работы Failure Trends in a Large Disk Drive Population (pdf 242 KB), если вам скучно читать весь отчет, можно найти здесь: http://blog.aboutnetapp.ru/archives/tag/google). Кроме того, их перу принадлежит еще несколько работ, в частности об влиянии температуры и охлаждении, и о статистике отказов в оперативной памяти, вызываемой, предположительно, космическими лучами высоких энергий. Ссылки на публикации можно найти на домашней странице Шрёдер, на сервере университета.

Кратко о том, как именно происходила сборка статистических данных. Дело в том, что на протяжении довольно продолжительного времени (в опубликованной работе проанализирован период около 2,5 лет), в датацентрах Google собираются разнообразные данные мониторинга и иных событий в жизни оборудования в большой базе, данные которой в дальнейшем можно анализировать за любой желаемый промежуток времени.



(на фото, кстати, подлинный вид серверной платформы Google, именно из таких «кирпичиков» собираются гугловские кластеры, размером в многие тысячи узлов, впрочем, про них тут уже писалось)

Результаты такого анализа и представлены в опубликованной работе. И результаты во многом удивительные, заставляющие по-иному смотреть на вопросы надежности и привычные допущения в области надежности серверного оборудования.

Исследование со всей убедительностью продемонстрировало, что влияние отказов в оперативной памяти существенно недооценивается, что отказы оперативной памяти случаются куда чаще, чем до этого это было принято считать, наконец, многие допущения, например что оперативная память практически не «стареет», как «стареют», повышая вероятность отказов, компоненты с движущимися частями, такие как, например, жесткие диски, или что перегрев губительно сказывается на работе ОЗУ, являются неверными, и требуют пересмотра.

Несомненно тот факт, что в последние несколько лет, в связи со сравнительным удешевлением DRAM, и широким распространением систем серверной виртуализации, крайне охочих до объемов памяти, концентрация в одной серверной системе все больших и больших объемов ОЗУ, повышает и требования к ее надежности.

Исследование показало, что примерно каждый третий сервер (или 8% модулей памяти) в наблюдаемых датацентрах на протяжении 2,5 лет исследования встречался со сбоем в оперативной памяти. Число сбоев, зарегистрированных системой мониторинга составило свыше 4000 в год! Большая часть из них конечно была устранена использованием ECC (Error Correction Code), используемого в оперативной памяти, и более сложными его вариантами, такими как Chipkill (позволяет устранить многобитовые ошибки, например сразу в группе ячеек). Тем не менее, Uncorrectable Errors, то есть ошибки, которые не удалось исправить, и которые, почти наверняка привели к фатальным последствмяи типа BSOD или kernel panic встречаются куда чаще, чем это принято считать. А в случае использования памяти без ECC каждая из таких ошибок — это почти наверняка BSOD или kernel panic, или серьезный сбой в работе приложения. Ведь, например, очень многие хранят данные баз в памяти для ускорения ее работы.

В сравнении с ранее опубликованным исследованием, работа группы Шрёдер резко повысила «ожидания» сбоев. Так, они оценили события отказов в 25-70 тысяч сбоев на миллиард часов работы сервера, что почти в пятнадцать раз превышает более раннюю оценку, сделанную на меньшей популяции.
С отказами в результате неисправимых (uncorrectable, неисправленных ECC или Chipkill) встретились 1,3% серверов в год, или около 0,22% DIMM.
Системы, использующие «многобитные» механизмы, такие как Chipkill, имели число отказов в 4-10 раз меньше, по сравнению с обычным ECC.

Другие интересные выводы, сделанные в опубликованной работе это:

Рабочая температура, и ее повышение крайне мало коррелирует с вероятностью сбоя в DRAM. Это еще один факт, который указывает, что бытующее до сих пор в индустрии мнение о губительности повышенной температуры на полупроводники и компьютерное оборудование (мнение, основанное на исследовании 80-х годов) на сегодняшний день следует радикально пересмотреть. Это еще одно подтверждение этому факту, который уже был установлен, например в работе о жестких дисках. Парадоксальным образом там было установлено, что наименьшее количество отказов HDD наблюдалось при температурах в районе 40-45 градусов, а ее понижение количество отказов увеличивало (!).
В случае DRAM кореляция между температурой (в наблюдавшемся диапазоне около 20 градусов между самой низкой и самой высокой) и отказами была крайне незначительной.



(здесь и далее на слайдах: CE — correctable errors, ошибки, зарегистрированные, но исправленные ECC, UE — uncorrectable errors)

Однако существенно коррелировали отказы с загрузкой памяти и интенсивностью обмена с ней (отчасти высокая загрузка памяти влияет и на ее температуру, конечно, но не всегда). Вполне вероятно, что интенсивный обмен и большой относительный объем заполненных данными памяти значительно повышает вероятность быстрого обнаружения сбоя.



Было установлено, что вероятность получить повторный сбой в уже ранее сбоившем модуле памяти в сотни раз выше, по сравнению с не сбоившем ранее. Это может быть вызвано как наличием плохо выявляемого технологического брака, так и тем, что отказ, например пробой заряженной частицей космических лучей, не проходит для памяти бесследно, даже если ошибка была скорректирована ECC.
70-80% случаях, когда регистрировалась неисправимая ошибка в модуле памяти, это модуль уже имел исправимый ECC или Chipkill отказ в этом или предыдущем месяце.



Было установлено, что сравнительно новые модули, выполненные с более высокой плотностью и более тонкими техпроцессами, не показывают более высокого уровня отказов. По-видимому пока в технологии DRAM технологический предел, близ которого начинаются проблемы с надежностью, пока не достигнут. В наблюдаемом парке модулей было примерно шесть разных типов и поколений памяти (DDR1, DDR2 и FBDIMM разных типов), и корреляции между высокой плотностью и числом отказов и сбоев выявлено не было.

Наконец, с пугающей ясностью был продемонстрирован эффект «старения» в модулях DRAM. Более того, в памяти он проявился куда более явно, чем, напрмер, в HDD, где порог, после которого отказы растут в разы, составил примерно 3-4 года.



Парадоксальным образом статистика демонстрирует увеличивающиеся темпы роста correctable errors с увеличением возраста модулей, но снижающийся темп для Uncorrectable errors, однако скорее всего это просто результат плановой замены памяти в серверах, которые были замечены за сбоями.



Удивительным образом, DRAM, лишенная каких-либо движущихся частей, показывает существенный и продолжающийся рост correctable отказов уже после года-полутора эксплуатации.

Подводя итоги, хотелось бы отметить, что приведенные статистические данные заставляют пересмотреть привычные для многих, основанные на «житейском опыте» принципы построения серверных платформ и эксплуатации датацентров, и позиция «чем холоднее — тем лучше», «память не изнашивается», «если север правильно собран, то он не ломается» и «ECC DRAM — ненужная трата денег, ведь у меня десктоп работает без ECC, и ничего». И чем скорее будут изжиты подобные шапкозакидательские настроения в столь серьезной области, как построение датацентров, тем, в итоге, будет лучше.
А занимающимся темой хочу порекомендовать неизбывный источник сладости, интеллектуального упражнения и пищи для мозгов, как публикации ежегодных конференций группы USENIX, это вам, господа, не маркетинговый булшит, столь привычный нам уже всем, а настоящая серьезная наука, от которой не отмахнешься.
@track
карма
28,7
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (81)

  • +9
    При пролистывании кажется что кулеры крутятся, мистика…
    • +2
      «Это круто, Бивис!» ;)
    • 0
      Это мамка или бп гудит, такая же фигня, пека стоит открытый на столе и электрический звук только при скроле появляется.
  • +1
    8-летний комп дома стал подтормаживать. Теперь догадываюсь, почему.
    • +3
      Виноваты во всем космические лучи?
      • +1
        Если бы я поставил смайлик, было бы понятней, что я шучу?
        • +8
          Тут дело в том, что на хабре накопилась критическая масса людей, которые могут такое сообщить не в виде шутки, а абсолютно серьёзно. Поэтому, если бы вы так пошутили в узком кругу, то вас поняли бы без смайлика, но здесь скорее всего подумают, что человек сказал не шутку, а глупость.
          • +5
            Да, к сожалению чувствую, что если хочешь откликов, надо на Хабре переходить на статьи вида «Копирасты ацтоооой! Отобрать у америки и раздать всем по ноуту, а мой новый мобильник такая аняняня, зырьте мой видеоблог!» :-)
            Вот тут будет сотня плюсов в карму и двести комментов :)
            • +2
              Нет, что вы. Статья замечательная. Я прочитал её с удовольствием, но что-то комментировать по теме не стал просто потому что нечего добавить, а повышать энтропию нет желания. Но информацию взял на заметку и плюсики расставил.

              А в холиварных статьях, понятно, может высказаться каждый, даже не обладая какими-либо знаниями, поэтому там движуха.

              Здесь, чтобы понять, надо же знать что такое ECC, где оно используется, зачем и т.п. Я думаю, что даже программисты отдельных отраслей могут не обладать требуемыми для осмысления знаниями.
            • 0
              Про копирастов и особенно (!) Америку лучше не пишите, я проверял, результат — в профиле.
        • 0
          тогда вам придётся пройти хаброквест по правильному комментированию. модераторы почему-то не реагируют на тупые комментарии, на бесполезные и т.д. на отмечают комментарии со смайликами.
    • –7
      В школу уже пошел? =)
  • +4
    исследование старое, с тех пор техпроцесс поменялся 3 раза уже. в 2009 году только DDR1 и ранние DDR2 (с таким выделением, что надо было радиаторы ставить) можно было наблюдать 3 года подряд.
    ЕСС память как раз и нужна для коррекции ошибок, обычно это работает отлично.
    • +1
      исследование старое, с тех пор техпроцесс поменялся 3 раза уже.

      У вас есть сведения, что сейчас ситуация изменилась столь радикально, что выводы исследования уже неверны?
      С удовольствием посмотрю ваши данные.

      Видите ли, свойства научных результатов как раз и заключаются в том, что они устанавливают общие правила, законы; например законы Ньютона в макромире не устарели за триста с лишним лет, прошедших с момента их публикации, и никто не набирается смелости утверждать, что «исследование старое, с тех пор техпроцесс поменялся 3 раза уже».
      Именно этим наука и отличается от маркетингового булшита.
      • 0
        думаю так. память сейчас делают на 22нм уверенно. напряжение снизилось, LV DIMM 16Gb ЕСС жрет максимум 5Вт.
        что бы сделать 16Гб в машинах позапрошлого поколения надо было ставить 4 DDR2 ECC REG димма, которые делались по два или в три раза более широкому процессу, www.dailycomm.ru/m/2320/ — 45нм, а до этого и 60. грелись они сильно, электричества жрали много. Чем теплее — тем больше AFR для тонкой электроники такого типа. Больше плашек — больше вероятность выхода.
        никто и не спорит что такое бывает и надо думать когда набиваешь на ноду 512Г памяти, вероятность появления ошибки бита на мегабайт является константой для заданного типа памяти и техпроцесса. Но для этого ЕСС и есть =)
        у меня сведения сугубо практические — раз в год меняем планку памяти по гарантии из нескольких тысяч что стоят у меня в серверах, в основном ДДР3.
        • 0
          Специально для такого рода возражений в работе проделан анализ для всех шести типов разных поколений DRAM, установленных на протяжении нескольких лет в модулях кластера, и никакой статистически существенной разницы в результатах между ними замечено не было. Учитывая же, что никакого принципиального технологического скачка между DDR2 и DDR3, а также при переходе от 45 к 22, не было, то результаты вполне экстраполируются линейно.
          Опять же, если у вас есть иные результаты — показывайте, мы же не в церкви, чтобы оперировать аргументами «а я не верю, вот не верю и все!»
        • +1
          И кстати прочитайте все же работу целиком, вам по работе положено такое читать, а не довольствоваться «пересказом для школьников» ;) В особенности обратите внимание, где они говорят о scrubbing и о величинах soft и hard errors. Возможно вы найдете ответы на свои вопросы, почему вы видите меньше ошибок, чем их в действительности происходит.
  • +1
    По поводу памяти. Мне вот интересно насколько забиваются пылью сервера. Потому что на обычных компах, ошибки памяти часто лечатся банальной чисткой контактов. Станет ли кто то замораживаться с сервера в этом плане для меня вопрос, но вот можно ли говорить о «старении» модулей тоже интересно.
    • +1
      В нормальном датацентре пыли нет, насколько я знаю, поэтому такой проблемы просто не существует.
    • +1
      Чистят контакты не от пыли, а от окисла.
    • 0
      По наблюдениям — пыли практически нет. Сервер двух-трёх летней давности имеет едва заметный на пальце слой пыли (эквивалент 1-2 дня в помещении). Никаких легендарных чёрных монстров, живущих под кулерами процессоров и в БП нет.

      Цена этого удовольствия — отвратительный воздух в серверной. Сухой, холодный, плюс шум. (час работы в серверной выбивает из колеи на целый день, а то и больше).
      • 0
        Я в дц, где организация аредует стойку, езжу как на праздник. Там хорошо, прохладно, комфортно и людей нет =) думаю над сменой работы с офисного linux-админа на инженера дц, но зп печальная. реально вообще получать ~50т.р., работая в дц с железками?
        • 0
          Серверам плохо, если человеку хорошо. По нормативам в машинном зале должно быть сухо — много более сухо, чем в помещениях. Мгновенно начинает першить в горле. Плюс сквозняки, плюс шум, плюс вибрации.

          По моим оценкам инженер в ДЦ по статусу ближе к «эникейщику», а не к админу.
          • 0
            Разве излишняя сухость не ведёт к повышенному накоплению статики? Я всегда думал, что оптимальная влажность порядка 45-55%
            • 0
              А вот, кстати, интересно. Вроде бы где-то пишут, что да, 45-55. По моим наблюдениям такого не бывает (ибо после кондиционеров воздух нужно увлажнять — вы видели хоть раз увлажнители в серверной?)
              • 0
                Относительная влажность же! Чем холоднее воздух — тем относительная влажность выше при одинаковой абсолютной, поэтому из кондеев и течёт летом. Это в машине после кондиционера сухо, потому что он сильно охлаждает, влага конденсируется, потом печка греет и в итоге воздух сушится. В серверных же чуть ли не замкнутый цикл воздухообмена, если кондеями охлаждается, влаге некуда деться.
                • 0
                  Я вполне понимаю. Но в серверной на кондеях тоже оседает влага и выводится наружу. Соответственно, воздух сушится, причём в силу большого потока, очень сильно. Плюс на выходе с серверов он нагревается и становится ещё суше. Вердикт — в серверных обычно невыносимо сухо.

                  Говорю и по теории, и по суровой практике.
                  • 0
                    А забор воздуха снаружи есть? Вообще, проще всего гигрометр повесить да посмотреть, сколько покажет. 50% влажности — это уже очень-очень сухой воздух, и тут верить собственным ощущениям сложно, они не откалиброваны. Я давненько в серверных не был, но прям першения в горле не запомнилось В серверной ММВБ даже очень холодно было, хотя мы там больше получаса провели. Вот дубеющие пальцы, когда работаешь у открытого шкафа — это да, не в перчатках же на клавиатуре кнопки нажимать.
                    • 0
                      Дубение пальцев по современным представлениям — пустая трата электричества :) Уже предлагают поддерживать температуру чуть ли не до 40градусов, а ниже 25 — вообще бессмысленно считается.
                      • 0
                        Ну есть еще сторонники «олдскула», в такой консервативной области, как создание и обслуживание датацентров, их естественным образом особенно много.
              • 0
                Отдельных увлажнителей я не видел, но промышленные кондиционеры с управлением влажностью встречал, в том числе и в серверных.
                • 0
                  Попробую вспомнить в понедельник и уточнить у людей, которые за кондиционеры отвечают.
              • 0
                Да, у нас стоят прецизионники с увлажнителями.
                Когда занимался согласованием, читал, что сухой воздух помимо статики еще влияет на состояние смазки в кулерах и HDD.
  • +1
    Понятно, что нижеследующие расчёты не претендуют на точность. Я только попытался осмыслить цифры из статьи и сделать выводы.

    Итак, в среднем получается 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 позволяет точно детектировать какой модуль дал ошибку.

    Второй практический вывод: вероятность того, что у сервера не будет проблем с памятью зависит от числа её модулей. Есть смысл ставить минимальное число модулей максимальной ёмкости. С оговоркой, что иногда потенциал контроллера памяти раскрывается при чётном или троичном числе модулей.
    • 0
      То есть 1 ошибка на 23 года. Что очень круто.

      Я думаю, что вы допускаете ту же ошибку, что допускают при неправильном оперировании цифрами MTBF для жестких дисков.
      • –1
        Вроде в таких цифрах для оперативной памяти (в отличие от HDD) нет ничего удивительного — 22 года работал Пионер 11 и 29 лет Пионер 10.

        Тем более что

        Парадоксальным образом статистика демонстрирует увеличивающиеся темпы роста correctable errors с увеличением возраста модулей, но снижающийся темп для Uncorrectable errors, однако скорее всего это просто результат плановой замены памяти в серверах, которые были замечены за сбоями.


        Т.е. если использовать память высочайшего качества, то отсутствие движущихся частей всё-таки даёт о себе знать.
        • 0
          Ну, вы бы еще память на ферритовых колечках вспомнили :)
    • 0
      Неправильное предположение.

      Откуда там 1000 раз в секунду? Самые нагруженные области меняются несколько сотен миллионов раз за секунду. И никого не волнует, что это всего лишь обновляющийся счётчик времени или ещё какая-нибудь не особо интересная вещь.

      Просто для интереса осознайте, сколько раз в секунду меняются значения у сервера, раздающего по сети что-нибудь на 10-20 гигабит.
      • 0
        Такие сервера, которые 10-20 гигабит раздают, ещё хорошо поискать надо. У гугловских серверов-картриджей (у тех что на картинке) на более 1Гбита сетевуха.

        А 1000 — ну это же в среднем. А есть области, которые вообще почти не меняются: коды программ, кешированные данные.

        В принципе даже легко ПРИБЛИЗИТЕЛЬНО прикинуть: если 800 МГц шина памяти, 2-х канальный контроллер памяти, допустим каждый канал способен 16 байт передать за рабочий цикл, а всего памяти стоит 8ГБ. Это означает что за 1 секунду в RAM можно записать 25Гб. Что в среднем означает в каждую ячейку всего чуть более 3-х записей/чтений в секунду происходит. И это при максимальной загрузке памяти.

        Реальное среднее значение операций чтения/записи на одну ячейку памяти скорее всего будет близко к 1 разу за секунду.
        • 0
          DMA забываете. С диска читаем — данные в памяти без копирования через процессор. Данные по сети отсылаем — с учётом offload'а на сетевую карту рассчёта контрольных сумм и части tcp, аналогично, процессор там только часть заголовков дописывает, а payload как был, так и передаётся.

          По цифрам — на новых серверах уже давно 4х канальная память, по попугаям там до 40-60ГБ/с.

          А «среднее» учитывать некорректно — потому что если одну область памяти долбят со скоростью среды всю жизнь, а другую — раз в пол-года перечитывают, то когда планка вылетает в «горячей» области, никого не волнует состояние здоровья «холодной».

          Заметим, любые механизмы виртуальной памяти, которые бы слегка уменьшить износ, не работают для ядра. Есть unrelocable области, которые где положены, там лежать и должны.
          • +1
            А вот DMA тут не причём. Да оно уменьшает загрузку процессора, но в моих расчётах процессор вообще не фигурировал, а только контроллер памяти, который обслуживает и процессор и устройства с DMA.

            Есть у меня смутное подозрение, что сама природа DRAM, когда происходят постоянные обновления, даёт примерно такую же нагрузку, что и долбёжка в какую-то определённую ячейку…
            • +1
              Возможно.

              Кстати, я, кажется, вижу важную деталь. Память, как и многие другие устройства, имеет режимы энергосбережения с понижением напряжения.

              Возможно, на нагруженных серверах нет моментов энергосбережения, то есть память на боевых напряжениях всегда. Тогда ситуация ясна: чем дольше срок с приложенным высоким (относительно низкого standby) напряжением, тем больший процент отказов.
  • 0
    кстати
    «ECC DRAM — ненужная трата денег, ведь у меня десктоп работает без ECC, и ничего»
    в сервер последнее время ничего кроме ЕСС и не вставишь, а регистровая на большие объемы только ЕСС и бывает.
    разницы по цене между ЕСС и не-ЕСС нет уже года 3 как, как DDR3 появилась
    • +1
      Разница в цене есть в остальных комплектующих. Нельзя в произвольную десктопную плату вставить ECC память.
      • –1
        И часто вы в сервера ставите десктопные матери?
        • +2
          Понятие «севрер», в особенности для впервые этим вопросом занимающихся, может трактовать ну очень широко и вольно.
          К тому же, если я правильно помню, во многие сервера начального уровня действительно можно поставить память без ECC, хотя это и не рекомендуется производителями их.
          • –1
            Ну в статье всё-таки не о серверах начального уровня идёт речь, да и люди там далеко не «впервые этим вопросом занимающиеся».
            • +1
              В данном случае мы не о статье, а о том, что комментирует vsespb.
              • –1
                Ну вы — может быть, я же — применительно к статье.
        • 0
          Отвечу вопром на вопрос — часто ли вы в серверные платы ставите не ECC память?
          Речь о цене на комплектующие. Без ECC можно собрать дешевле.
          • 0
            Не ставлю в сервера не ECC память.
            Мы говорим о нормальном — брендовом сервере или самосборе на коленке из дектопного железа? Такое я себе только для домашнего применения позволяю, не более.
            • 0
              В данном случае мы не о статье, а о том, что комментирует ULP.
              • 0
                ULP говорит о том что нет особой разницы в цене между ECC и неECC, вы же о десктопных матерях в серверах начали говорить. Для вас сервер это всё что работает не на ХР/7/8, без оглядки на железо?
                • +1
                  Я как раз говорю о том что есть разница в цене между ECC и не-ECC. Она кроется в цене матплаты. Сама же матплата серверная vs десктопная формально ничем не отличается, кроме поддержки ECC.
                  (бывают отличия в дорогих вариантах в портах sas, встроенных raid и отсутствии usb и в формфакторе). Отличия в качестве комплектующих вещь недокументированная.

                  А вообще сам давно мечтаю приобрести домой себе ECC железо, workstation. И сервера (vps хостинг) выбираю дорогой но качественный, и только на брендовом железе, никакой ни дестопный хертзнер.
                  • –1
                    Хорошо — задам вопрос по другому — вы много встречали брендовых серверов с дектопными матерями? Я вообще не понимаю как можно говорить о разнице в стоимости памяти, экстраполируя это на стоимость материнских плат — разного назначения? Тем более что просто так в магазине кроме серверных интелов или супермикро — ничего не купить. И документированных различий там тоже хватает: чипсет мат.платы (от которого зависит поддержка процессоров и памяти), чипсет видео, сети, raid -контроллера, да даже требуемое питание (24+8 у серверных против 24+4 у десктопных), различные чипы аппаратного мониторинга и управления + ПО к ним и т.д. Так что глупо сравнивать продукты, различного назначения. Всё-равно что внедорожник со спорт-каром сравнивать.
                  • 0
                    А вообще сам давно мечтаю приобрести домой себе ECC железо, workstation

                    Ну посмотрите на Хьлетовские workstation, обалдейте от цен… А потом посмотрите цены на ML110 G7.
                    • +1
                      Я как-то больше к самосбору тяготею. Самосбор с ECC.
                      • 0
                        Делов-то, сейчас всё доступно и весьма недорого. Разница между самосбором и брендом (кроме цены конечно) заключается в сервисе, который дома всё равно такого уровня не нужен.
        • 0
          Учитывая количество любителей дешевых серваков на Хецнере — часто. Там ведь только дорогие серии с ECC.
          • 0
            Вот кстати да. Дешевый hetzner-like вебхостинг, так популярный на Хабре. «А если не видно разницы, то зачем платить больше?» (С)
  • 0
    Конечно старает, диффузию никто не отменял. Чем меньше техпроцесс тем сильнее влияет диффузия. А так как количество элементов в современных чипах гигантское, то вроятность фатальных изменений со временем тоже не маленькое.
    • 0
      Специально для вас, раз вы читаете выборочно:
      «Было установлено, что сравнительно новые модули, выполненные с более высокой плотностью и более тонкими техпроцессами, не показывают более высокого уровня отказов. По-видимому пока в технологии DRAM технологический предел, близ которого начинаются проблемы с надежностью, пока не достигнут. В наблюдаемом парке модулей было примерно шесть разных типов и поколений памяти (DDR1, DDR2 и FBDIMM разных типов), и корреляции между высокой плотностью и числом отказов и сбоев выявлено не было.»

      «Отсутствие корреляции» более простым языком, означает, что «разницы нет».
      • –2
        Не вижу в ваших слайдах и в ваших словах никаких графиков по зависимости время+техпроцесс, только отдельно техпроцесс и отдельно время.
        • 0
          Да, поставить минус не вдумавшись в то что я написал, очень умно.
  • –2
    Если кто-то прочитал ссылки — там идет исследование «consumer-серии железа».
    На фотке я так же вижу кусок несерверного железа. Так о каком ECC сейчас речь? О какой статистике по винтам, если это SATA? Саташные винты вообще не рекомендуются к использованию в production.

    Мой совет: s/сервер/pc + не делать таких глобальных выводов основываясь на данных которым больше 3/5 лет
    • 0
      1. Какие из ссылок? «Там» их много.

      2. Google как раз и известен тем, что самый активный в индустрии проводник commodity-решений, то есть созданных не на специальных супер-пупер, а на общедоступном и массовом.

      3. ECC, и даже Chipkill, тем не менее в его кластерах применяются. Причины этому — выше.

      4. Если у вас есть другие, более точные данные — приведите их, иначе это пустой разговор. Как я уже сказал выше, мы не в церкви, чтобы разговаривать на уровне «верю — не верю». Как раз этим и отличается наука от веры, что у науки есть доазательства, а у веры — только «мнение».
    • 0
      Не рекомендуются кем? SAS диски, к сожалению, слишком мелкие по объёму. К тому же у производителей есть enterprise-ready SATA диски, типа WD RE.

      В оригинальной статье же написано, что память с ECC (иначе как бы они ошибки отследили?), а уж картинка для привлечения внимания на совести автора.
  • +1
    Есть такое. В условиях виртуализации с плотным заполнением хостов отказы памяти (MCE) более часты и более неприятны, чем у «самостоятельных» серверов.
  • 0
    Меня вот что в данном исследовании смутило:

    «Однако существенно коррелировали отказы с загрузкой памяти и интенсивностью обмена с ней»

    Тут авторы исследования зашли не в ту сторону. Просто, пока нет обмена с памятью, ошибки в ней не обнаруживаются. Информация может измениться в какой-нибудь ячейке и ждать своего часа, пока не произойдет ее считывание и проверка ECC. А если считывание не произойдет, или если произойдет запись — то такая ошибка никогда не будет обнаружена (правда, она и не повлияет никак на работу компьютера).

    Неверны выводы по поводу последствий неисправленных ошибок памяти. Далеко не каждая такая ошибка приведет к падению системы (BSOD, Kernel Panic). Чтобы оценить вероятность тех или иных последствий, нужно рассмотреть, чем заполнена память во время работы системы. Как правило, она в основном заполнена данными приложений и дисковым кешем. Следовательно, наиболее вероятные последствия — порча памяти приложений. Но тот, кто разрабатывал софт на каком-нибудь языке типа С, должен не понаслышке знать о том, что далеко не каждая порча памяти приводит к краху приложения. Многие порчи остаются долгое время незамеченными или приводят к малозаметным, трудновоспроизводимым последствиям. Могут испортиться данные пользовательских документов.

    Последствия порчи информации в дисковом кеше — то же самое, что порча информации в файлах. Может привести к краху приложения, может остаться незамеченной, может иметь тяжелые последствия (если, например, данные были зашифрованы — ошибка в одном бите может убить весь файл).

    Ну и наконец, само ядро ОС принципиально ничем не отличается от приложений с точки зрения последствий порчи памяти в его структурах. Может пройти незамеченным, может привести к малозаметным последствиям, и лишь в некоторой части случаев произойдет крах ядра.
    • 0
      Вы, пожалуйста, не делайте выводы на основании моего беглого и крайне упрощенного пересказа, рассчитанного на довольно специфическую ныне аудиторию Хабра, прочтите оригинал, там есть все ответы на ваши вопросы.
  • +1
    Вот ещё одна статья о аппаратных отказах, на этот раз от Microsoft Research: research.microsoft.com/pubs/144888/eurosys84-nightingale.pdf
    • 0
      Спасибо, хорошее дополнение.
  • 0
    Мечтаю о ноуте с ECC но увы не видел таких даже среди всяких ToughBook и т.п.
    • +1
      • 0
        Спасибо.
      • 0
        Непонятно одно: видяхи с ECC GDDR5 памятью я там нашёл, а собственно оперативную память с ECC — нет :-(
        • 0
          Вообще ecc sodimm существует, может быть они просто не указывают в спецификациях? Можно запросить у них точную информацию.
          • 0
            Что ecc sodimm существует я знаю, по-этому меня и удивляло, что не существуют ноутбуки с её поддержкой. Надо будет спросить, да.
          • 0
            Спросил. Ответили. Нету. Вариант ECC у них есть только для видях.
            • 0
              Тогда увы, да.
        • 0
          Вообще ecc sodimm существует, может быть они просто не указывают в спецификациях? Можно запросить у них точную информацию.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.