Ecc память что это

Оперативная память: ECC, REG, RDIMM, LRDIMM, и другие

ECC (Error Correction Code) или код коррекции ошибок, позволяет исправлять некоторые ошибки в процессе работы оперативной памяти. В том числе, случайные неточности, то есть те, которые могут возникать под воздействием электромагнитных помех или высокоэнергетических элементарных частиц. Подобная погрешность появляется из-за изменения значения одного бита в машинном слове. Результат такой ошибки может быть самым непредсказуемым. От изменения одного символа в набранном тексте до зависания всей системы. При чтении данных из памяти или записи в память код ECC позволяет исправлять одиночные битовые ошибки. Что повышает надежность работы памяти в окружениях, где это необходимо. Например, в серверах и рабочих станциях. Для кода ECC добавляются 8 дополнительных бит (64 базовых + 8 дополнительных = 72).

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

Алгоритм ECC позволяет исправлять битовые ошибки, а также определять два ошибочных бита, но уже не исправлять их. Технологии Chipkill или Advanced ECC расширяют алгоритм ECC, позволяя корректировать до 4 ошибочных битов и определять до 8 ошибочных битов. Если ошибок будет много, то данная функция позволяет скрыть сбойный чип в системе без перезагрузки (отсюда и название «Chipkill»), при этом сервер продолжает стабильную работу. Технологии Chipkill или Advanced ECC работают как массив RAID на жестких дисках, опираясь на распределенное избыточное хранение данных.

Технология Memory Scrubbing производит постоянную проверку памяти на наличие ошибок, результаты отправляются серверным утилитам управления, например, IPMI (Intelligent Platform Management Interface) в BMC (Baseboard Management Controller).

Но для работы ECC вместе с функцией ChipKill/Advanced ECC необходимо чтобы процессор, материнская плата с BIOS и оперативная память поддерживали ECC. Данная технология обязательна для всех RDIMM, но также встречаются и UDIMM с ECC.

RDIMM — Регистровой памятью (Registered DIMM, RDIMM) называют модули ОЗУ, которые имеют на «борту» отдельный регистр для адресов «оперативки» и команд. Контроллер ОЗУ в процессоре обращается к регистрам, регистры же направляют информацию в микросхемы памяти. Такая организация «оперативки» позволяет увеличить количество модулей на канал RAM за счет снижения электрической нагрузки на контроллер памяти. Контроллер находится либо в северном мосту материнской платы, либо в процессоре. Также вдвое уменьшается емкость модулей памяти, если модуль содержит два регистра.

Регистровая память отличается от обычной, небуферизованной ОЗУ, более высокими задержками при чтении и записи информации в модулях ОЗУ. Это происходит из-за того, что модули содержат дополнительный промежуточный узел — буфер. Чтение/запись производит контроллер памяти в процессоре или северном мосту материнской платы. Работа с этим узлом, естественно, требует дополнительного времени работы. Но при этом отметим то, что уменьшается нагрузка на процессор, так как буфер отвечает за непосредственную работу с банками памяти.

Регистровая и буферизованная память — одно и то же

Регистровая память — это буферизованная память. Как было обозначено выше — регистр — это буфер для адресов и команд при работе с памятью. Процессор или северный мост материнской платы отправляют данные, адреса ячеек памяти и команды. Регистры выполняют команды по указанным адресам.

Такая память стоит дороже обычной, небуферизованной памяти. Используется она исключительно в серверах, потому что позволяет получить больший объем памяти на один процессор в сервере.

LRDIMM (Load Reduced Dual In-Line Memory Modules) — модуль со сниженной нагрузкой, относительно новый тип памяти для серверов. Поддерживается процессорами Intel Xeon E5 и AMD Opteron 6200 начиная с 2012 года.

Модули LRDIMM очень похожи на «обычные» модули памяти типа Registered DIMM (RDIMM) и даже используют те же печатные платы и чипы памяти DRAM. Однако принцип работы модулей существенно различается.

Смешивать в одной системе LRDIMM и DIMM модули категорически запрещено! (система не запустится).

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

При работе контроллера с модулями LRDIMM управление сводится к отправке пакетной информации (данные и команды) в буфер модуля — iMB (Isolation Memory Buffer). В свою очередь, именно буфер управляет всеми операциями чтения и записи в микросхемах DRAM. Проще говоря, за счет иного механизма «общения» модуля памяти с контроллером памяти нагрузка многорангового модуля становится в два раза ниже (то есть Quad Rank модуль контроллер воспринимает как Dual Rank, а Octal Rank модуль — как Quad Rank).

На практике LRDIMM становится полезен для увеличения скорости работы большого объема памяти и/или вообще возможности организации большого объема памяти. Для большей ясности приведем конкретный пример.

Процессоры Intel Xeon E5 v1, v2, v3 и v4 содержат четырехканальный контроллер памяти и поддерживают до восьми логических рангов на канал. Итого можно установить максимум восемь Quad Rank модулей объемом 32 Гб на каждый процессор (по 2 на каждый канал). Суммарный объем памяти на двухпроцессорной плате в этом случае не может превышать 512 ГБ. Одноранговых или двуранговых модулей можно поставить больше (до 3 модулей на канал), но эти модули будут иметь меньшую емкость.

Если использовать физически Quad Rank модули LRDIMM, которые контроллер памяти «воспринимает» как двуранговые, то можно использовать максимум 12 модулей по 32 Гб на процессор. Итого 768 ГБ памяти, которая, к тому же, сможет работать на более высокой частоте.

Процессоры третьего и четвертого поколения (Intel Xeon E5 v3 и v4) совместимы с модулями 3DS LRDIMM. Объем каждого модуля такой памяти может составлять 128 ГБ. Значит, двухпроцессорные системы с 24 слотами памяти могут использовать до 3 ТБ оперативной памяти. А планками RDIMM, при прочих равных, можно достичь только 768 ГБ.

NVDIMM (non-volatile DIMM) — Модули NVDIMM явили собой пример комплексного использования двух технологий: оперативной и энергонезависимой памяти. Сам по себе стандарт не является новинкой: он был утвержден в 2014 году, и многие компании уже представили свои модули памяти с «батарейкой». Однако, в связи с активным развитием микросхем Flash, современный NVDIMM стал включать в себя достаточный объем NAND-памяти. Теперь NVDIMM позволяет не только сохранить целостность данных на момент аварийного отключения питания, но и кэшировать все проходящие через ОЗУ данные на лету.

Энергонезависимая память NVDIMM бывает разных видов: NVDIMM-N, NVDIMM-F, NVDIMM-P. Модуль типа NVDIMM-N включает в себя как микросхему SDRAM (ОЗУ), так и микросхему флеш-памяти (SSD) для резервного хранения данных ОЗУ на случай аварии.

Если NVDIMM-N — это «оперативка» с расширенным функционалом, то NVDIMM-F – это своего рода хранилище. В «F» модулях нет ячеек ОЗУ, они содержат только микросхемы Flash-памяти. NVDIMM-P комбинирует функции NVDIMM-F и NVDIMM-N в рамках одного модуля. Доступ идёт одновременно как к DRAM, так и к NAND на одной планке. Все три конфигурации позволяют существенно увеличить производительность при работе с большими данными, HPC и т.д.

В 2017 году произошел своего рода прорыв в отношении памяти NVDIMM в серверном сегменте. Компания Micron представила новые модули емкостью 32 Гбайт. Эти модули работают на частоте DDR4-2933 с задержками CL21 — что гораздо быстрее других DDR4 для серверного применения. Несколько раньше были выпущены модули памяти на 8 и 16 Гбайт.

В конфигурации с двумя контроллерами любой из NVDIMM-N модулей заменяется вместе с контроллером в любой удобный момент, без прерывания доступа к данным. Когерентность NVDIMM может быть обеспечена не только программными, но и аппаратными средствами. Таким образом, исчезает необходимость обслуживать аккумуляторы (BBU в старых RAID-контроллерах или UPS). При вертикальном и горизонтальном масштабировании решения больше не требуется переоценка рисков потери данных!

DCPMM — Intel Optane DC (DCPMM), которая имеет большую емкость, чем DRAM, а её производительность выше, чем у SSD и HDD. Иными словами, это некий гибрид между модулем оперативной памяти и накопителем. И он стирает грань между DRAM и хранилищем данных при вычислениях в памяти.

Другое преимущество — Intel Optane DC сохраняет данные, если пропало питание сервера или оно нестабильно. При этом сохраняется производительность DRAM. Таким образом, данные сохраняются в оперативной памяти после выключения устройства.

Для работы с OLTP, базами данных в памяти и других сложных задач нужно использовать ресурсы процессора, и памяти по максимуму и при этом сокращать задержки при передаче информации. Решения по базе энергонезависимой памяти (NVM) не могут до конца решить эту проблему. Выходом может стать энергонезависимая память NVRAM/NVDIMM, в том числе Intel Optane DCPMM.

Разработка DCPMM началась в середине 2000-х. В 2012 году Intel и Micron объединили усилия для совместной работы. В июле 2015 технология была показана широкой публике.

Тогда технология называлась 3D XPoint («Трехмерная точка пересечения»).

Идея заключалась в создании памяти, которая бы отвечала следующим критериям:

Энергонезависимость
Надежность
Скорость выше, чем у Flash

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

Новый слой NVRAM оказывается между двумя «кольцами»: SSD (хранение данных) и DRAM с CPU (запуск приложения). Модули DCPMM фактически переопределяют привычную иерархию памяти и хранения. На практике необходимая для запуска приложений информация оказывается доступна в течение сотен наносекунд по сравнению с десятками микросекунд для SSD и миллисекунд для HDD.

Ещё одно существенное преимущество технологии: модули Intel Optane DCPMM устанавливаются в те же стандартные слоты памяти, что и DRAM.

Модули Intel Optane DCPMM были выпущены в апреле 2019 года вместе со вторым поколением процессоров Intel Xeon Scalable. Одной из первых компаний, которая получила новые процессоры и DCPMM стала Fujitsu. Компания внедрила новшества в системы PRIMERGY и PRIMEQUEST.

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

В режиме Memory Mode вся емкость DCPMM работает как «классическая» ОЗУ. В этом случае операционная система и приложения рассматривают её как пул энергозависимой памяти, а DRAM используется в роли кэша.

Процессор контроллера памяти обрабатывает все операции управления кэшем. Это означает, что при запросе данных из памяти, он сначала проверяет кэш DRAM. Если данные присутствуют, скорость передачи и время ожидания идентичны DRAM. В противном случае данные считываются из модулей DCPMM с немного большей задержкой. К слову, наличие в сервере планок памяти DRAM обязательно.

MM предпочтителен, когда нужно увеличить объем основной памяти. Например, в средах с высокой степенью виртуализации, модули DCPMM могут вмещать больше виртуальных машин и в то же время предоставлять больше памяти для каждой из них. При этом затрачивается меньше средств, чем на сравнительную по эффективности конфигурацию DRAM.

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

Режим App Direct позволяет приложениям напрямую взаимодействовать с частями DCPMM. Таким образом, все важные данные хранятся в постоянной памяти в непосредственной близости от процессора, а значит сразу же доступны при загрузке части программного обеспечения.

В этом режиме ОС распознает два отдельных пула памяти и обрабатывает их соответствующим образом: часть DCPMM, резервируется для AD как постоянная память, а SDRAM функционирует как основная память.

Еще одним преимуществом такой конфигурации: DCPMM с поддержкой AD выполняет роль постоянного запоминающего устройства, но адресация проходит по байтам, как SDRAM.

Кроме того, данные из пространства App Direct DCPMM кэшируются в памяти ЦП точно так же, как из SDRAM. Система получается более согласованной, а все ядра ЦП в системе сразу получают одинаковые данные.

Ещё одна возможность: пространство App Direct можно монтировать непосредственно в ОС как сверхбыстрый SSD, делая его доступным для неизменяемых приложений.

AD Mode максимально использует DCPMM с точки зрения производительности, емкости, гибкости и простоты использования. Поэтому неудивительно, что эксперты считают этот режим работы предпочтительным для сценариев, в которых устойчивость систем и приложений, а также быстрое время загрузки/перезапуска имеют первостепенное значение.

DCPMM в конфигурациях AD особенно хорошо работает с приложениями, которые в значительной степени зависят от объема и производительности памяти, такими как базы данных в памяти и приложения для сверхбыстрого хранения.

Смешанный режим (Mixed Mode) — разновидность AD. В этом случае можно настроить DCPMM таким образом, чтобы одна часть работала в режиме памяти (Memory Mod), а другая — в режиме App Direct.

Ключевое отличие от AD: «разделение» емкости и функциональности должно быть с самого начала, чтобы поддерживать приложения с различными требованиями, которые должны выполняться параллельно.

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

Следует ли покупать память ECC?

Джефф Этвуд, возможно, самый читаемый программист-блоггер, опубликовал пост против использования памяти ECC. Как я понимаю, его доводы такие:

В Google не использовали ECC, когда собирали свои серверы в 1999 году.
Большинство ошибок ОЗУ — это ошибки систематические, а не случайные.
Ошибки ОЗУ возникают редко, потому что аппаратное обеспечение улучшилось.
Если бы память ECC имела на самом деле важное значение, то она использовались бы везде, а не только в серверах. Плата за такого рода опциональный материал явно слишком сомнительна.

1. В Google не использовали ECC в 1999 году

Если вы делаете нечто только из-за того, что когда-то это сделал Google, то попробуйте:

A. Поместите свои серверы в транспортные контейнеры.

Сегодня все ещё пишут статьи о том, что это — отличная идея, хотя Google всего лишь провёл эксперимент, который был расценен как неудачный. Оказывается, даже эксперименты Google не всегда удаются. Фактически, их известное пристрастие к «прорывным проектам» («луншоты») означает, что у них имеется больше неудачных экспериментов, чем у большинства компаний. По-моему, для них это существенное конкурентное преимущество. Не стоит делать это преимущество больше, чем оно есть, слепо копируя провалившиеся эксперименты.

B. Вызывайте пожары в своих собственных центрах обработки данных.

Часть поста Этвуда обсуждает, насколько удивительными были эти серверы:

Некоторые могут взглянуть на эти ранние серверы Google и увидеть непрофессионализм в отношении опасности пожара. Не я. Я вижу здесь дальновидное понимание того, как недорогое стандартное оборудование будет формировать современный интернет.

Последняя часть высказанного — это правда. Но и в первой части есть доля правды. Когда Google начал разрабатывать свои собственные платы, одно их поколение имело проблему «роста» (1 ), вызвавшую ненулевое число возгораний.

Кстати, если вы перейдёте к посту Джеффа и посмотрите на фотографию, на которую ссылается цитата, то вы увидите, что на платах много кабелей-перемычек. Это вызывало проблемы и было исправлено в следующем поколении оборудования. Также можно видеть довольно неряшливо выполненную кабельную разводку, что дополнительно вызывало проблемы и что также было быстро устранено. Были и другие проблемы, но я оставлю их в качестве упражнения для читателя.

C. Создавайте серверы, которые травмируют ваших сотрудников

Острые грани одного из поколений серверов Google заработали им репутацию сделанных из «бритвенных лезвий и ненависти».

D. Создавайте свою погоду в ваших центрах обработки данных

После разговоров с сотрудниками многих крупных технологических компаний создаётся впечатление, что в большинстве компаний был такой климат-контроль, что в их центрах обработки данных образовывались облака или туман. Можно было бы назвать это расчётливым и коварным планом Google по воспроизведению сиэтловской погоды, чтобы переманивать сотрудников Microsoft. Как вариант, это мог быть план создания в буквальном смысле «облачных вычислений». А может и нет.

Обратите внимание, что всё указанное Google попробовал, а затем изменил. Делать ошибки, а затем устранять их — распространённое явление в любой организации, успешно занимающейся разработками. Если вы боготворите инженерную практику, то следует держаться, по крайней мере, за современную практику, а не за сделанное в 1999 году.

Когда Google использовал серверы без ECC в 1999 году, на них проявился ряд симптомов, которые, как в конце концов выяснилось, были вызваны повреждением памяти. В том числе индекс поиска, который возвращал фактически случайные результаты в запросы. Реальный режим сбоя здесь поучителен. Я часто слышу, что на этих машинах можно игнорировать ECC, потому что ошибки в отдельных результатах являются допустимыми. Но даже если вы считаете для себя случайные ошибки допустимыми, их игнорирование означает, что существует опасность полного повреждения данных, если только не проводить тщательный анализ с целью убедиться, что одна ошибка может лишь незначительно исказить один результат.

В исследованиях, проведённых на файловых системах, неоднократно было показано, что, несмотря на героические попытки создания систем, устойчивых к одной ошибке, сделать это крайне сложно. По существу, каждая сильно тестируемая файловая система может иметь серьёзный сбой из-за единственной ошибки (см. результаты работы исследовательской группы Андреа и Ремзи, Висконсин, если вам интересно это). Я не собираюсь нападать на разработчиков файловых систем. Они лучше разбираются в таком анализе, чем 99,9% программистов. Просто неоднократно уже было показано, что эта проблема настолько трудная, что люди не могут достаточно обоснованно обсуждать её, и автоматизированное инструментальное средство для такого анализа ещё далеко от процесса простого нажатия кнопки. В своём справочнике по компьютерной обработке складских данных Google обсуждает обнаружение и исправление ошибок, и память ECC рассматривается как самый правильный вариант, когда очевидно, что необходимо использовать исправление ошибок аппаратного обеспечения (2 ).

Google имеет отличную инфраструктуру. Из того, что я слышал об инфраструктуре в других крупных инфотехнологических компаниях, Google представляется лучшим в мире. Но это не значит, что следует копировать всё, что они делают. Даже если рассматривать только их хорошие идеи, для большинства компаний нет смысла копировать их. Они создали замену планировщику перехвата работ Linux, который использует как аппаратную информацию времени выполнения, так и статические трассировки, чтобы позволить им использовать преимущества нового оборудования в серверных процессорах Intel, что позволяет динамически разбивать кэш между ядрами. Если использовать это на всём их оборудовании, то Google сэкономит за неделю больше денег, чем компания Stack Exchange потратила на все свои машины за всю свою историю. Означает ли это, что вы должны скопировать Google? Нет, если на вас уже не свалилась манна небесная, например, в виде того, что ваша основная инфраструктура написана на высокооптимизированном C++, а не на Java или (не дай бог) Ruby. И дело в том, что для подавляющего большинства компаний написание программ на языке, который влечёт 20-кратное снижение производительности, — совершенно разумное решение.

2. Большинство ошибок ОЗУ — это систематические ошибки

Аргументация против ECC воспроизводит следующий раздел исследования ошибок DRAM (выделение дано Джеффом):

Наше исследование имеет несколько основных результатов. Во-первых, мы обнаружили, что приблизительно 70% сбоев DRAM является повторяющимися (например, постоянными) сбоями, тогда как только 30% является неустойчивыми (перемежающимися) сбоями. Во-вторых, мы обнаружили, что большие многобитовые сбои, такие как сбои, которые затрагивают всю строку, столбец или блок, составляют более 40% всех сбоев DRAM. В-третьих, мы обнаружили, что почти 5% отказов DRAM влияют на схемы на уровне платы, такие как линии данных (DQ) или стробирования (DQS). Наконец, мы обнаружили, что функция Chipkill уменьшила частоту отказов системы, вызываемих сбоями DRAM, в 36 раз.

Цитата кажется несколько ироничной, поскольку она выглядит не аргументом против ECC, а аргументом за Chipkill — определённый класс ECC. Отложив это в сторону, пост Джеффа указывает, что систематические ошибки встречаются в два раза чаще, чем ошибки случайные. Затем пост сообщает, что они запускают memtest на своих машинах, когда происходят систематические ошибки.

Во-первых, соотношение 2:1 не столь велико, чтобы просто игнорировать случайные ошибки. Во-вторых, пост подразумевает веру Джеффа, что систематические ошибки, по существу, неизменны и не могут проявиться через некоторое время. Это неверно. Электроника изнашивается точно так же, как изнашиваются механические устройства. Механизмы разные, но эффекты схожи. Действительно, если сравнить анализ надёжности чипов с другими видами анализа надёжности, то можно видеть, что они часто используют одни и те же семейства распределений для моделирования отказов. В-третьих, ход рассуждений Джеффа подразумевает, что ECC не может помочь в обнаружении или исправлении ошибок, что не только неверно, но и прямо противоречит цитате.

Итак, как часто вы собираетесь запускать memtest на своих машинах в попытках поймать эти системные ошибки и сколько потерь данных вы готовы пережить? Одно из ключевых применений ECC состоит не в том, чтобы исправить ошибки, а в том, чтобы сигнализировать об ошибках, благодаря чему оборудование может быть заменено до того, как произойдёт «silent corruption» («скрытое повреждение данных»). Кто согласится закрывать всё на машине каждый день, чтобы запустить memtest? Это было бы намного дороже, чем просто купить ECC-память. И даже если бы вы смогли убедить гонять тестирование памяти, memtest не обнаружил бы столько ошибок, сколько сможет найти ECC.

Когда я работал в компании с парком в примерно тысячу машин, мы заметили, что у нас происходят странные отказы при проверке целостности данных, и примерно через полгода мы поняли, что отказы на одних машинах более вероятны, чем на других. Эти отказы были довольно редкими (может быть, пару раз в неделю в среднем), поэтому потребовалось много времени для накопления информации и понимания, что же происходит. Без знания причины анализ логов с целью понять, что ошибки были вызваны единичными случаями инвертирования битов (с большой вероятностью), также был нетривиальным. Нам повезло, что в качестве побочного эффекта процесса, который мы использовали, контрольные суммы вычислялись в отдельном процессе на другой машине в разное время, так что ошибка не могла исказить результат и распространить это повреждение на контрольную сумму.

Если вы просто пытаетесь защитить себя с помощью контрольных сумм в памяти, есть немалая вероятность того, что вы выполните операцию вычисления контрольной суммы на уже повреждённых данных и получите правильную контрольную сумму неправильных данных, если только вы не делаете некоторые действительно необычные операции с вычислениями, которые дают их собственные контрольные суммы. А если вы серьёзно относитесь к исправлению ошибок, то вы, вероятно, всё же используете ECC.

Во всяком случае, после завершения анализа мы обнаружили, что memtest не мог обнаружить какие-либо проблемы, но замена ОЗУ на плохих машинах привела к уменьшению частоты ошибок на один-два порядка. У большинства сервисов нет такого рода контрольных сумм, которые были у нас; эти сервисы будут просто молча записывать повреждённые данные в постоянное хранилище и не увидят проблему, пока клиент не начнёт жаловаться.

3. Благодаря развитию аппаратного обеспечения ошибки стали очень редкими

Данных в посте недостаточно для такого утверждения. Обратите внимание, что поскольку использование ОЗУ возрастает и продолжает увеличиваться экспоненциально, отказы ОЗУ должны уменьшаться с большей экспоненциальной скоростью, чтобы фактически уменьшить частоту повреждения данных. Кроме того, поскольку чипы продолжают уменьшаться, элементы становятся меньше, что делает более актуальными проблемы износа, обсуждаемые во втором пункте. Например, при технологии 20 нм конденсатор DRAM может накпливать где-то электронов 50, и это число будет меньше для следующего поколения DRAM при сохранении тенденции уменьшения.

Исследование 2012 года, которое цитирует Этвуд, имеет этот график по исправленным ошибкам (подмножество всех ошибок) на десяти случайно выбранных отказавших узлах (6% узлов имели по крайней мере один отказ):

Рис. 1. Исправленные за месяц ошибки для выбранных случайным образом узлов. Количество ошибок показывает тип сбоя, возникший в каждом узле.

Речь идёт о количестве ошибок от 10 до 10 тыс. для типичного узла, у которого происходит отказ, и это — тщательно отобранное исследование с поста, утверждающего, что вам не нужна память ECC. Обратите внимание, что здесь рассматриваются узлы с ОЗУ только 16 ГБ, что на порядок меньше, чем у современных серверов, и что исследование было проведено на более старом техпроцессе, который был менее уязвим для шума, чем нынешний.

Для тех, кто привык иметь дело с проблемами надёжности и просто хочет знать значение FIT (единица измерения интенсивности отказов): исследование показывает, что значение FIT составляет 0,057-0,071 сбоев на один мегабит (что — в противоположность утверждению Этвуда — не является поразительно низким числом).

Если взять самое оптимистичное значение FIT, равное 0,057, и провести расчёт для сервера не с самой большой оперативной памятью (здесь я использую 128 ГБ, поскольку серверы, которые я вижу в настоящее время, обычно имеют ОЗУ от 128 до 1,5 ТБ), то получим ожидаемое значение 0,057 * 1 000 * 1 000 * 8 760 /1 000 000 000 = 0,5 сбоя в год на каждый сервер. Обратите внимание, что это относится к сбоям, а не к ошибкам. Из графика выше видно, что сбой может легко вызвать сотни или тысячи ошибок в месяц. Ещё нужно отметить, что есть несколько узлов, у которых нет ошибок в начале исследования, но ошибки появляются позже.

Компания Sun/Oracle серьёзно столкнулась с этим несколько десятилетий назад. Транзисторы и конденсаторы DRAM становились всё меньше, как это происходит и сейчас, а использование памяти и кэши росли, так же как и в настоящее время. Столкнувшись, с одной стороны, со всё уменьшающимся транзистором, который был менее стойким к временному нарушению и более сложным в изготовлении, а, с другой стороны, с растущим встроенным кэшем, подавляющее большинство поставщиков серверов ввело ECC в свои кэши. Компания Sun решила сэкономить несколько долларов и не использовать ECC. Прямым результатом было то, что ряд клиентов Sun сообщил о периодических повреждении данных. В результате затем Sun несколько лет занималась разработкой новой архитектуры с кэшем на ECC и заставляла клиентов подписывать NDA для замены чипов.

Конечно, невозможно постоянно скрывать подобные вещи, и когда они всплыли, репутация Sun по созданию надёжных серверов получила сильный удар, во многом похожий на случай, когда Sun пыталась скрыть плохие показатели производительности, введя в свои условия использования запрет на бенчмарки.

Ещё одно замечание: когда вы платите за ECC, вы платите не просто за память ECC — вы платите за детали (процессоры, платы), которые являются более качественными. Такое легко можно видеть с частотой отказа дисков, и я слышал, что многие замечают такое в своих личных наблюдениях.

Если приводить общедоступные исследования: насколько помню, группа Андреа и Ремзи несколько лет назад выпустила документ SIGMETRICS, который показал, что вероятность сбоя при чтении у диска SATA в 4 раза выше, чем у диска SCSI, а вероятность скрытого повреждения данных — в 10 раз выше. Это соотношение сохранялось даже при использовании дисков одного изготовителя. Нет особой причины думать, что интерфейс SCSI должен быть более надёжным, чем интерфейс SATA, но речь идёт не об интерфейсе. Речь идёт о покупке высоконадёжных серверных компонентов по сравнению с клиентскими. Возможно, конкретно надёжность диска вас не интересует, потому что у вас всё на контрольных суммах, и повреждения легко находятся, но есть некоторые виды нарушений, которые обнаружить труднее.

4. Если бы память ECC имела, действительно, важное значение, то её использовали бы везде, а не только в серверах.

Немного перефразируя этот аргумент, можно сказать, что «если бы эта характеристика была, действительно, важна для серверов, то она использовалась бы и в не-серверах». Можно применить этот аргумент к довольно большому количеству аппаратных средств сервера. На самом деле это одна из наиболее неприятных проблем, стоящих перед крупными поставщиками облачных решений.

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

Одной из немногих областей, где нет каких-либо жизнеспособных конкурентов, является производство центральных процессоров и видеоускорителей. К счастью для крупных поставщиков, видеоускорители им обычно не нужны, нужны процессоры, много — уже давно так сложилось. Было несколько попыток поставщиков процессоров войти на серверный рынок, но всегда каждая такая попытка с самого начала имела фатальные недостатки, делавшие очевидной её обречённость (а это часто проекты, требующие не менее 5 лет, т.е. необходимо было потратить очень много времени без уверенности в успехе).

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

Почти полная непригодность текущих вариантов ARM (и POWER) (не считая гипотетических вариантов впечатляющего чипа ARM от Apple) для большинства рабочих нагрузок серверов с точки зрения производительности на доллар совокупной стоимости владения (TCO) — эта тема немного в стороне, поэтому я оставлю её для другой публикации. Но дело в том, что Intel имеет такую позицию на рынке, что может заставить людей платить сверху за серверные функции. И Intel это делает. Кроме того, некоторые функции действительно важнее для серверов, чем для мобильных устройств с несколькими гигабайтами оперативной памяти и энергетическим бюджетом в несколько ватт, мобильных устройств, от которых всё равно ожидают периодические вылеты и перезагрузки.

Заключение

Следует ли покупать ECC-ОЗУ? Это зависит от многого. Для серверов это, вероятно, хороший вариант, учитывая затраты. Хотя на самом деле трудно провести анализ затрат/выгод, потому что довольно сложно определить ущерб от скрытого повреждения данных или затраты на риск потерять полгода времени разработчика на отслеживание перемежающихся сбоев, только чтобы обнаружить, что они вызваны использованием памяти без ECC.

Для настольных компьютеров я тоже сторонник ECC. Но если вы не делаете регулярные бэкапы, то вам полезнее вложиться в регулярные бэкапы, чем в ECC-память. И если у вас есть резервные копии без ECC, то вы можете легко записать повреждённые данные в основное хранилище и реплицировать эти повреждённые данные в резервную копию.

Спасибо Прабхакару Рагде, Тому Мерфи, Джею Вайскопфу, Лии Хансон, Джо Уайлдеру и Ральфу Кордерою за обсуждение / комментарии / исправления. Кроме того, спасибо (или, может быть, не-спасибо) Лии за то, что убедила меня написать этот устный экспромт как пост в блоге. Приносим извинения за любые ошибки, отсутствие ссылок и возвышенную прозу; это, по существу, запись половины обсуждения, и я не объяснил условия, не предоставил ссылки или не проверил факты на том уровне детализации, как я обычно делаю.

1. Одним из забавных примеров является (по крайней мере, для меня) магическая самовосстанавливающаяся плавкая перемычка. Хотя реализаций много, представим себе плавкую перемычку на чипе как некоторый резистор. Если вы пропускаете через неё какой-то ток, то вы должны получить соединение. Если ток слишком большой, то резистор разогреется и, в конце концов, разрушится. Это обычно используется для отключения элементов на микросхемах или для таких действий, как задание тактовой частоты. Основной принцип состоит в том, что после сгорания перемычки нет возможности вернуть её в исходное состояние.

Давным давно жил да был производитель полупроводниковых устройств, который немного поторописля со своим производственным процессом и несколько чрезмерно уменьшил допуски в некотором технологическом поколении. Через несколько месяцев (или лет) соединение между двумя концами подобной перемычки смогло снова появиться и восстановить его. Если вам повезёт, то такая перемычка будет чем-то вроде старшего бита множителя тактовой частоты, который в случае его изменения будет выводить чип из строя. Если не повезёт, то это приведёт к скрытому повреждению данных.

Я слышал от многих людей в разных компаниях о проблемах в этом технологическом поколении этого производителя, так что это не были отдельные случаи. Когда я говорю, что это забавно, я имею в виду, что забавно услышать эту историю в баре. Менее забавно обнаружить через год тестирования, что некоторые из ваших чипов не работают, потому что их установки для перемычек бессмысленны, и необходимо переделать ваш чип и отложить выпуск на 3 месяца. Кстати, эта ситуация с восстановлением плавкой перемычки — ещё один пример класса ошибок, остроту которых можно сгладить с помощью ECC.

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

2. Если вы не хотите копаться во всей книге, то вот нужный фрагмент:

В системе, которая может выдержать ряд отказов на программном уровне, минимальное требование, предъявляемое к аппаратной части, заключается в том, что сбои этой части всегда обнаруживаются и сообщаются программному обеспечению достаточно своевременно, чтобы позволить программной инфраструктуре ограничить их и принять соответствующие действия по восстановлению. Необязательно, чтобы аппаратное обеспечение явно справлялось со всеми сбоями. Это не означает, что оборудование для таких систем должно быть спроектировано без возможности исправления ошибок. Всякий раз, когда функциональные возможности исправления ошибок могут быть предложены с разумной ценой или сложностью, поддержка их часто окупается. Это означает, что, если аппаратная коррекция ошибок была бы чрезвычайно дорогостоящей, то система могла бы иметь возможность использования более дешёвой версии, которая предоставляла бы возможности только обнаружения. Современные системы DRAM являются хорошим примером ситуации, в которой мощная коррекция ошибок может быть предоставлена при очень низких дополнительных затратах. Однако смягчение требования об обнаружении аппаратных ошибок было бы намного сложнее, поскольку это означало бы, что каждый программный компонент был бы обременён необходимостью проверки его собственного правильного выполнения. На начальном этапе своей истории Google пришлось иметь дело с серверами, на которых у DRAM отсутствовал даже контроль чётности. Создание индекса веб-поиска состоит, по существу, из очень большой операции сортировки/слияния, использующей длительно несколько машин. В 2000 году одно из ежемесячных обновлений веб-индекса Google не прошло предварительную проверку, когда обнаружилось, что некоторое подмножество проверенных запросов возвращает документы, по-видимому, случайным образом. После некоторого исследования в новых индексных файлах была выявлена ситуация, которая соответствовала фиксации бита на нуле в определённом месте в структурах данных, что было негативным побочным эффектом потоковой передачи большого количества данных через неисправный чип DRAM. В структуры данных индекса были добавлены проверки непротиворечивости, чтобы свести к минимуму вероятность повторения этой проблемы, и в дальнейшем проблем такого характера не было. Однако следует отметить, что этот способ не гарантирует 100% обнаружения ошибок в проходе индексации, так как не все позиции памяти проверяются — инструкции, например, остаются без проверки. Это сработало потому, что структуры данных индекса были настолько больше, чем все другие данные, участвующие в вычислении, что наличие этих самоконтролируемых структур данных делало очень вероятным, что машины с дефектным DRAM будут идентифицированы и исключены из кластера. Следующее поколение машин в Google уже содержало обнаружение чётности в памяти, и как только цена памяти с ECC опустилась до конкурентного уровня, все последующие поколения использовали ECC-DRAM.

Серверное администрирование
Восстановление данных
Хранение данных

ECC vs non-ECC: так ли медлительна память с коррекцией ошибок?

На просторах Рунета зачастую можно встретить открытые темы на форумах с вопросами – стоит ли брать рабочую станцию с ECC-памятью? И в данных ветках можно прочесть утверждения о том, что коррекция ошибок сильно замедляет память, а следовательно и процессор. Но мало кто на деле это проверял. Сегодня мы разберемся в этом вопросе.

18 июня 2015, четверг 00:00
Сергей Валарский для раздела Лаборатория

Страницы материала

Вступление, коррекция ошибок, финансовая сторона, тестовый стенд и методика, результаты тестирования: тест памяти, 3DMark, 7Zip, Cinebench

Вступление

На сегодняшний день на просторах Рунета можно встретить открытые темы на форумах с вопросами – стоит ли брать рабочую станцию с ECC-памятью или можно обойтись обычной? В данных ветках можно прочесть множество противоречивых утверждений, и часть из них говорит о том, что коррекция ошибок сильно замедляет память, а следовательно и ЦП. Но мало кто это проверял на деле на современных процессорах.

Сегодня мы разберемся в этом вопросе и сравним производительность серверного процессора с обоими типами памяти. Но для начала небольшой экскурс.

Коррекция ошибок

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

Почему же так необходима коррекция ошибок в рабочих станциях и серверах? Однобитовая ошибка в 64-битном слове меняет содержимое ячейки памяти, а в конечном итоге на жесткий диск может быть записано другое число, другие данные, при этом компьютер не зафиксирует эту подмену. А изменение бита в оперативной памяти может вызвать сбой программы, что для рабочей станции и сервера недопустимо.

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

В свое время было предложено много различных способов решения данной проблемы, но на сегодняшний день наибольшее распространение получил метод коррекции ошибок или ECC (Error-Correcting Code). Данный метод позволяет автоматически исправлять однобитовые ошибки в 64-битном слове – SEC (Single Error Correction) и детектировать двухбитовые – DED (Double Error Detection).

Физическая реализация ECC заключается в размещении дополнительной микросхемы памяти на модуле ОЗУ – соответственно, при одностороннем дизайне модуля памяти вместо восьми чипов располагается девять, а при двустороннем вместо шестнадцати – восемнадцать. Таким образом, ширина модуля становится не 64 бита, а 72 бита.

Метод коррекции ошибок работает следующим образом: при записи 64 бит данных в ячейку памяти происходит подсчет контрольной суммы, составляющей 8 бит. Когда процессор обращается к этим данным и производит считывание, проводится повторный подсчет контрольной суммы и сравнение с исходной. Если суммы не совпадают – произошла ошибка. Если она однобитовая, то неправильный бит исправляется автоматически, если двухбитовая – детектируется и сообщается ОС.

Финансовая сторона

Стоимость обычного модуля памяти DDR3-1600 с напряжением 1.35 В и объемом 8 Гбайт составляет около 3600 рублей, а с коррекцией ошибок – 4800 рублей. На первый взгляд ECC-память выходит на 30-35% дороже, что, в целом, не позволяет их сравнивать в силу существенно большей стоимости последней. Но почему же тогда такой вопрос возникает при сборке рабочей станции? Все просто – необходимо смотреть на данный вопрос шире, а именно – смотреть на общую стоимость рабочей станции.

Ценник однопроцессорной станции на базе четырехъядерного восьмипоточного Xeon (настольные процессоры серий i5 и i7 не поддерживают ECC-память) с 32 Гбайтами памяти, материнской платы с чипсетом C222/С224/С226 (десктопные наборы логики Z87/Z97 и другие также не поддерживают память с коррекцией ошибок) будет превышать 70 000 рублей (при условии, что устанавливаются серверные SSD с повышенным ресурсом). А если включить в эту стоимость и дискретную видеокарту, и прочие сопутствующие компоненты, например, ИБП, то ценник из пятизначного превратится в шестиизначный, перевалив планку в 100 000 рублей.

Покупка 32 Гбайт памяти с коррекцией ошибок потребует дополнительных 4-6 тысяч рублей, что по отношению к общей стоимости рабочей станции не превышает 5%, то есть не является критичным. Также переход от десктопного к серверному железу предоставит и другие преимущества, например: интегрированные графические карты P4600 в процессорах Intel Xeon E3-1200 третьего поколения получили оптимизированные драйверы, которые должны повышать производительность в профессиональных приложениях, например, в CAD; поддержка технологии Intel VT-d, которая позволяет пробрасывать устройства в виртуальную среду, например, видеокарты; прочие серверные технологии – Intel AMT или IPMI, WatchDog и другие, которые также могут оказаться полезными.

Таким образом, хоть и сама ECC-память стоит заметно дороже обычной, в общей стоимости рабочей станции данная статья затрат является несущественной, и переплата не превышает 5%.

Тестовый стенд

Для данного обзора использовалась следующая конфигурация:

Материнская плата: Supermicro X10SAE (Intel C226, LGA 1150);
Процессор: Xeon E3-1245V3 (Turbo Boost – off, EIST – off, HT – on);
Оперативная память:
- 2x Kingston DDR3-1600 ECC 8 Гбайт (KVR16LE11/8 CL11, 1.35 В);
- 2x Kingston DDR3-1600 8 Гбайт (KVR16LN11/8 CL11, 1.35 В);
Методика тестирования

В рамках тестирования были произведены замеры производительности как при одноканальном режиме работы ИКП, так и при двухканальном. Суммарный объем ОЗУ составил 8 (один модуль) и 16 Гбайт (два модуля) соответственно.
- 3DMark 2006 1.2;
- 7Zip 9.20;
- AIDA64 Extreme 5.20.3400;
- Cinebench R15;
- CrystalMark 2004R3;
- Fritz 4.20;
- LinX 0.6.5;
- wPrime 2.10.
Результаты тестирования

Тест памяти

Перед тем, как приступить к тестированию, проведем замер пропускной способности памяти и латентности.

реклама

При изучении результатов можно заключить, что производительность ECC- и non-ECC- памяти находится на одном и том же уровне в рамках погрешности.

Если в предыдущем тесте от замера к замеру выигрывал то один, то другой тип памяти, то при замере латентности ECC-память постоянно показывает большие задержки. Но разница несущественна – всего лишь 1 нс.

Таким образом, замер ПС и латентности памяти не показал особых различий между ECC- и non-ECC-памятью. Посмотрим, повторится ли это в последующих тестах.

3DMark

Тестовый пакет 3DMark содержит подтесты как для процессора, так и для графической карты. Здесь и кроется самое интересное – давно известно, что встроенному видеоядру не хватает существующей ПСП в 25.6 Гбайт/с, поэтому именно в графических подтестах можно выявить негативное влияние коррекции ошибок, если оно вообще есть,…

. но разницы нет – что ECC, что non-ECC. Ни процессор, ни интегрированное ядро никак не реагируют на замену обычной памяти на DDR с коррекцией ошибок – результаты одинаковы в рамках погрешности. Среднеарифметическая разница составила 0.02% в пользу ECC-памяти для одноканального режима и 1.6% для двухканального режима.

При этом нельзя сказать, что встроенная видеокарта P4600 не зависит от скорости ОЗУ – при одноканальном доступе общий результат почти на 30% ниже, чем при двухканальном. Другими словами, скорость ОЗУ критична для графического ядра, но сами по себе «ECC-версии» не влияют ни на скорость ОЗУ, ни на видеокарту.

7Zip

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

Ситуация с архивацией неоднозначная: с одной стороны – в одноканальном режиме (как при распаковке, так и при сжатии) ECC-память уверенно оказывается медленнее на 2%; с другой – в двухканальном режиме при сжатии ECC-память уверенно быстрее, а при распаковке – медленнее, а среднее арифметическое – быстрее на 0.65%.

Скорее всего, причина в следующем – пропускной способности памяти при одноканальном доступе процессору явно недостаточно, и поэтому чуть большая латентность ECC-памяти сказывается на производительности; а при двухканальном доступе ПСП полностью покрывает нужды CPU и поэтому чуть большая латентность памяти с коррекцией ошибок не сказывается на производительности. В любом случае зафиксировать существенного влияния на скорость архивации не получилось.

Cinebench

Тестовый пакет Cinebench содержит подтест как процессора, так и видеокарты.

Но ни первый, ни вторая никак не отреагировали на ECC-память.

Зато налицо явная зависимость видеокарты от ПСП – при одноканальном доступе результат в OpenGL оказался на 25% ниже, чем при двухканальном. Вспоминая результаты 3DMark и смотря на нынешние, можно заключить, что производительность интегрированной видеокарты хоть и зависит от ПСП, но ECC-память не оказывает на нее негативного влияния.

Для каких ПК и рабочих нагрузок стоит использовать память ECC

Вы ищете память, которая имеет доступ к более высоким скоростям и совместима с большим количеством платформ? Или вы ищете долговечную память, которая может работать 24 часа в сутки, 7 дней в неделю, выявлять больше ошибок, но для этого приходится жертвовать скоростью?

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

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

Думайте о памяти без ECC как о памяти, ориентированной на скорость, а ECC – памяти, ориентированной на выносливость и надёжности.

Поскольку не все платформы поддерживают ECC-память, и не каждой системе она нужна, давайте обсудим, что такое ECC-память, как она работает и нужна ли она вам.

Что такое ECC-память

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

Однобитовая ошибка – это когда один бит (двоичный 0 или 1) в данных в ОЗУ случайно изменяется на противоположное значение.

Такого рода ошибки незначительны, и компьютер может не распознать их автоматически, что может привести ко многим проблемам.

Вы можете думать об однобитовых ошибках как о метафорических сорняках на лужайке. Ваш газон – это оперативная память, а ECC-часть вашей памяти – это использование гербицида.

Память без ECC не избавит вас от «сорняков». ECC уничтожит все сорняки, но газон будет расти немного медленнее.

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

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

Память ECC позаботится об этих ошибках и исправит их до того, как они превратятся в большую проблему.

Память с ECC очень похожа на память без ECC. Самая большая разница между ними заключается в том, что память ECC обычно имеет немного дополнительной памяти, предназначенной исключительно для обеспечения того, чтобы фактическая память работала без ошибок.

ECC – это, по сути, небольшой чип на обычной планке ОЗУ, который гарантирует, что каждый бит данных, который входит и выходит, является именно тем, чем он должен быть.

Что он делает, так это то, что создаёт зашифрованный фрагмент кода из данных, записываемых в основную память, и сохраняет этот код в дополнительном бите памяти. Когда необходимо получить доступ к данным, хранящимся в основной памяти, он создаёт новый код и сравнивает этот фрагмент кода с кодом, который был сгенерирован ранее.

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

Если он не сможет найти ошибку, то, по крайней мере, гарантирует, что вы будете знать, что что-то пошло не так, вместо того, чтобы молча продолжать работать.

Это похоже на сравнение хэшей MD5 при загрузке программы, чтобы убедиться, что вы загружаете именно то, что вам действительно нужно, а не другой мошеннический секретный файл.

Вот почему ECC работает немного медленнее – потому что ему приходится создавать эти дополнительные коды.

Согласно исследованиям, вероятность возникновения такой ошибки составляет одна однобитовая ошибка каждые 14-40 часов на гигабит ОЗУ.

Необходимость исправления ошибок на серверах и рабочих станциях

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

Если вы ведёте бизнес, специализирующийся на финансах, однобитовая ошибка может привести к сбою сервера, который потенциально может стереть транзакции с вашего сервера.

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

Очевидно, что это наносит ущерб честности и надёжности бизнеса. Если бы вы пошли покупать кошке новую игрушку и в итоге заплатили 1000 рублей вместо 100, это было бы довольно трагично.

Если вы посетили своего врача, и счет составил 56 987 рублей вместо 5945 рублей, вы только что стали жертвой компьютерной ошибки, связанной с ECC. И вы, скорее всего, больше никогда не воспользуетесь их услугами.

Потеря времени – ещё одна проблема, которую может предотвратить память ECC. Если вы визуализируете сложные изображения в высоком разрешении или работаете с моделью глубокого обучения, необходимость начинать заново после нескольких недель обработки из-за некоторых ошибок памяти – это огромная трата времени и денег для вашего бизнеса.

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

Выбор памяти может создать или уничтожить репутацию бизнеса.

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

Какие платформы поддерживают память ECC

Что касается серверов, то линейки процессоров Intel Xeon и линейки серверов AMD Epyc поддерживают память ECC. Обратите внимание, что для использования памяти ECC и процессор, и используемая материнская плата должны поддерживать память ECC.

Помните аналогию с газоном и гербицидом? Думайте о процессоре и материнской плате как об инструментах, которые вы используете для эффективной работы с ECC. Вам нужны подходящие инструменты для распространения гербицидов на газоне.

На основных платформах, используемых сегодня, большинство процессоров Intel (даже некоторые бюджетные модели Celeron) будут поддерживать память ECC, если вы используете материнскую плату, совместимую с такой памятью.

С AMD все процессоры Ryzen поддерживают память ECC с совместимой материнской платой с набором микросхем X570, тогда как набор микросхем B550 не поддерживает память ECC с процессорами Ryzen 2000. Процессоры Ryzen со встроенной видеокартой или ускоренным процессором (APU), серии 3000 G и серии 4000 G потребуют от вас использования процессора PRO для поддержки ECC.

Недостатки использования памяти ECC

Наиболее распространенная проблема с памятью ECC – совместимость. Несмотря на то, что большинство современных платформ поддерживают её, вы должны убедиться, что конкретная комбинация процессора и материнской платы работает с памятью ECC.

Это менее проблематично в мире серверов, где обычно используется память ECC. Серверное оборудование обычно поддерживает ECC по умолчанию.

Ценник тоже отличается. Модули памяти с ECC дороже, чем модули без ECC из-за дополнительных функций. В зависимости от емкости, которую вы покупаете, разница в цене составляет около 10-20%.

Также наблюдается небольшой спад производительности из-за дополнительного времени, которое требуется памяти ECC для проверки наличия ошибок. По словам Corsair, можно ожидать падения около 2%.

Подведение итогов – нужна ли вам память ECC

Когда вы создаете профессиональную рабочую станцию или сервер, который должен работать круглосуточно и без выходных, память ECC просто необходима.

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

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

Вы ведь не хотели бы перепроверять каждую квитанцию, чтобы убедиться, что она верна, верно? Проявите такую же любезность к своим клиентам и заказчикам.

Но если всё, что вы делаете, это играете в игры и используете свой компьютер для другой некритической работы, вам, скорее всего, не понадобится ECC, и вам важнее сохранить эти 2% производительности.
Похожие публикации: