Как протестировать оперативную память ecc registered
Перейти к содержимому

Как протестировать оперативную память ecc registered

  • автор:

Как выбрать оперативную память для сервера

Оперативная память – один из ключевых компонентов сервера, ПК, ноутбука, смартфона и других компьютерных девайсов. Без нее устройство попросту не будет работать, так как операционная система не запустится. Оперативная память (RAM или ОЗУ) отвечает за временное хранение данных, качество их обмена, а также скорость выполнения ряда операций. Ее характеристики и объем напрямую влияет на скорость работы устройства. Внешний вид ОЗУ – это планки памяти в форме печатных плат. Они бывают разной емкости: 4, 8, 16, 32, 64, 128 Gb. Количество устанавливаемых модулей памяти зависит от возможности слотов материнской платы. Чтобы правильно подобрать оперативную память для сервера, необходимо разобраться в ее типах, параметрах и свойствах.

Как работает оперативная память

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

Отличие серверной оперативной памяти от обычной

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

Автоматическая коррекция ошибок

На плашках серверной оперативной памяти находятся дополнительные микросхемы, которые отвечают за коррекцию ошибок – ECC (Error Correcting Code). Именно эта функция весомо отличает компьютерную ОЗУ от серверной. Такую реализацию оперативки не используют на обычных компьютерных устройствах, когда для серверного оборудования она обязательна. ECC осуществляет автоматическую коррекцию возникающих ошибок, что увеличивает стабильность работы, которая так необходима серверам. Вместе с повышенной отказоустойчивостью памяти с ECC несильно, но снижается ее быстродействие, так как эта опция требует дополнительной мощности для своей работы. Кроме того, функция ECC должна поддерживаться используемым процессором и материнской платой.

Регистровая память и буферизация

На модуле памяти RDIMM (Registered Memory) присутствует еще одна дополнительная микросхема (регистр), которая обеспечивает буферизацию при выполнении команд. Регистр помогает снизить нагрузку на контроллер памяти при одновременном выполнении ряда задач. Такое решение обеспечивает стабильную работу серверного оборудования и позволяет устанавливать большее количество модулей памяти. Регистровая или буферизированная RAM по умолчанию содержит функцию коррекции ошибок ECC. Такие планки памяти имеют маркировку ECC REG.

Серверная ОЗУ также может обладать технологией NVDIMM. Это энергонезависимый тип оперативки со встроенной флеш–памятью NAND и небольшим источником резервного питания. Такая ОЗУ может сохранять обрабатываемые данные даже в ситуациях с аварийным отключением питания. Есть несколько реализаций модуля NVDIMM. В основном они используются на типах памяти DDR4 и имеют определенные требования по совместимости.

Характеристики оперативной памяти

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

Поколение

Всего существует пять типов памяти: DDR, DDR2, DDR3, DDR4, DDR5. Где цифра обозначает переход от старого и медленного выпуска к новой и более быстрой версии. С каждым обновлением улучшаются и характеристики ОЗУ: падает рабочее напряжение памяти, уменьшается ее нагрев, увеличивается пропускная способность, растет частота и максимальный объем одного модуля.

DDR и DDR2 уже полностью устарели и не используются. DDR5 на данном этапе только появляются для оборудования корпоративного сектора и практически не встречаются в серверах. Самым распространенным поколением ОЗУ для сервера являются DDR3 и DDR4. Тип памяти DDR3 чаще встречается в старых сборках оборудования. Более современные конфигурации серверов по умолчанию используют 4-ю версию DDR.

Каждый модуль памяти разного поколения имеет свои конструктивные особенности. Они различаются расположением соединительного ключа на планке и количеством контактов. У каждого поколения данный ключ находится в разных местах. В свою очередь разъемы в виде выступов на материнской плате имеют также свои ключи под RAM. Поэтому часто при апгрейде или замене модулей памяти, выбор поколения ОЗУ будет продиктован спецификацией материнской платы.

Частота

Основной показатель производительности оперативной памяти, отвечающий за скорость обработки данных. Общая производительность ОЗУ коррелирует с показателем частоты. Чем выше частота, тем больше пропускная способность памяти. Однако, тут тоже есть свои особенности. Во-первых, для каждого поколения памяти частота может быть разной. Чтобы выбрать подходящий вариант, необходимо убедиться, что материнская плата поддерживает модули с выбранной частотой. Для этого следует свериться со спецификацией материнской платы. В противном случае RAM будет работать на той чистоте, которая будет поддерживаться процессором, либо не запустится вовсе. Во-вторых, частота бывает реальная и эффективная. Реальная частота измеряется в мегагерцах MHz, а эффективная частота измеряется в мегатрансферах (миллионах передач данных в секунду) – MT/s. Указанная на плате частота – это максимальные показатели, которые доступны для данной памяти.

Тайминги

Латентность памяти или тайминги – это временные задержки между командой и ее выполнением. Они необходимы для того, чтобы память подготовилась к следующей команды. Чем меньше тайминги, тем быстрее работает RAM. Тайминги измеряются в тактах и маркируются как 4 цифры через дефис, либо используется только первый показатель (CL), так как в основном от него будет зависеть скорость ОЗУ.

  1. CL (AS Latency) – показатель времени отклика от отправки сигнала до передачи запрашиваемых данных.
  2. tRCD (RAS to CAS Delay) – время задержки между открытием строки и началом выполнения команды чтения или записи.
  3. tRP (Row Precharge Time) – интервал времени между закрытием доступа к одной строке данных и переходом к следующей.
  4. tRAS (Row Active Time) – временной интервал между командами активации доступа и закрытия строки с данными.

Пропускная способность

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

Объем

Если говорить коротко, – чем больше объем памяти, тем лучше. Но если рационально подходить к вопросу, то нужно ориентироваться исходя из задач, которые будет выполнять сервер. Первоначально при выборе ОЗУ следует рассчитать необходимый объем для каждой задачи и количества единовременных обращений, начиная с используемой ОС. Например, Windows более требователен к системе, чем Linux-дистрибутивы. О том, как выбрать операционную систему для сервера мы уже писали. Далее в зависимости от целей оборудования и используемых на нем программ. Например, для файлового сервера много ОЗУ не требуется, когда для работы в графических приложениях 32 Гб будет минимальным значением. Все зависит от системных требований самих программ и от количества пользователей. Например, для сервера под платформу 1С расчет производится по формуле 1 Гб оперативной памяти на 1 пользователя.

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

Как выбрать оперативную память для сервера?

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

Память для нового сервера:

– Определить объем под задачи, программы, ОС.

– Выбрать тип ОЗУ, на сегодняшний день для серверов лучше брать DDR4 ECC REG.

– Выбрать частоту, которая будет сочетаться с процессором и материнской платой по их спецификациям.

– RAM с низкими таймингами обойдется дороже, а разница будет не сильно ощутима, поэтому лучше подбирать средние показатели.

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

Память для апгрейда текущего сервера:

– Проверить совместимость с процессором в его спецификации. Например, частота ОЗУ не может превышать показатели CPU. Либо поколение может не поддерживаться старой версией процессора.

– Ознакомиться со спецификацией материнской платы на поддержку: типа ОЗУ, напряжения, режима многоканальности, частоты, максимальной емкости одного модуля.

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

поделиться с друзьями:

Протестируйте сервер перед оплатой

Оставьте свои данные, чтобы мы могли подобрать нужную конфигурацию выделенного сервера

Обратная связь

Оставьте свои контакты и наш специалист свяжется с вами.

Спасибо за обращение!

Наши специалисты свяжутся с вами в ближайшее время.

Хотим выразить благодарность специалистам технической поддержки за оперативную реакцию и решение любых вопросов. Сотрудники ООО «Микс Телеком» обеспечивают качественную работу нашего оборудования, находясь на связи круглосуточно.

Как протестировать оперативную память ecc registered

Категория: Инструкции Опубликовано: 29 июля 2020

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

1. Средство проверки памяти Windows — это встроенная утилита Windows, позволяет проверить RAM на ошибки. Для её запуска, нажмите клавиши Win+R на клавиатуре, введите mdsched и нажать Enter, или воспользуйтесь поиском Windows 10 и 8, введите запрос «Средство проверки памяти Windows».

После запуска утилиты Вам будет предложено перезагрузить компьютер для выполнения проверки памяти на ошибки. Выбираем «Выполнить перезагрузку и проверку».

После перезагрузки начнется выполнение сканирования.

В процессе сканирования можно нажать клавишу F1 для изменения параметров проверки:
Набор тестов — базовый, обычный или широкий.
Использование кэша — вкл или выкл.
Число проходов теста — максимум 15.

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

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

В Просмотре событий выберите «Журналы Windows» -> «Система» и найдите сведения о результатах проверки памяти — MemoryDiagnostics-Results, по двойному клику по событию или внизу окна во вкладке «Общие» Вы увидите результат, «Память компьютера проверена с помощью средства проверки памяти Windows; ошибок не обнаружено», это если с памятью всё в прядке.

2. Проверка памяти в Memtest86+.

Скачайте Memtest86+ с официального сайта для создания загрузочной флешки

Распакуйте архив, запустите «Memtest86+ USB Installer.exe», выберите флешку и нажмите кнопку «Create», установщик сделает флешку загрузочной с утилитой memtest86+

После того, как загрузочный накопитель с утилитой Memtest86+ готов, заходим в BIOS, в меню загрузки (Boot) устанавливаем в приоритет загрузку с нашей флешки, сохраняем настройки и перезагружаемся. Каких-то действий с вашей стороны не потребуется, тест начнется автоматически.

Прервать тест Вы можете в любой момент, нажав клавишу Esc.

В случае, если будут обнаружены ошибки, это будет выглядеть как на скриншоте ниже.

3. Проверка стабильности памяти в MemTest64

MemTest64 — это автономная утилита, которая позволяет проверять системную память на наличие проблем на аппаратном уровне. Она имеет графический интерфейс и может быть запущена из под Windows. Данной утилитой можно проверить память на стабильность после её разгона, или установок таймингов.

Скачать утилиту MemTest64 можно с официального сайта.

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

После завершения теста, если всё в порядке, утилита сообщит что в ходе теста ошибок не обнаружено

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

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

  1. В Google не использовали ECC, когда собирали свои серверы в 1999 году.
  2. Большинство ошибок ОЗУ — это ошибки систематические, а не случайные.
  3. Ошибки ОЗУ возникают редко, потому что аппаратное обеспечение улучшилось.
  4. Если бы память 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.

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

Как проверить оперативную память на ошибки

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

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

Как проверить оперативную память на ошибки

Как проверить оперативную память на ошибки

Встроенные методы диагностики Windows

Для проверки оперативной памяти на компьютере Windows существуют встроенные средства, не требующие дополнительных программ диагностики. Утилита для этой цели доступна начиная с операционной системы Windows 7.

Выполнить проверку можно несколькими способами:

  1. Нажать одновременно Win + R, а затем в окне «Выполнить» ввести команду mdsched.
  2. В строке поиска ОС ввести «Проверка памяти Windows».

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

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

Во время сканирования можно изменить параметры проверки, нажав клавишу F1. Вы можете выбрать тип проверки:

  • Расширенная.
  • Стандартная.
  • Базовая.

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

Если результаты тестирования по какой-либо причине не отображаются на экране, их можно просмотреть с помощью утилиты Windows Просмотр событий. Для этого выберите «Журналы Windows» и перейдите в раздел «Система». Результаты тестирования будут представлены в виде событий с источником MemoryDiagnostics-Results.

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

Как проверить оперативную память на ошибки

Как проверить оперативную память на ошибки

Программы для диагностики оперативной памяти

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

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

MemTest86+

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

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

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

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

По умолчанию, один цикл тестирования включает 11 проходов, включая нулевой. Обнаруженные ошибки отображаются красным цветом. Для полной проверки рекомендуется выполнить не менее 10 циклов (на экране выглядит как Pass) при этом количество ошибок должно быть 0.

TestMem5

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

TestMem5 доступен для скачивания в виде архива, который после распаковки устанавливается на ваш компьютер. Для проверки оперативной памяти в Windows 10 или другой версии операционной системы, достаточно запустить программу tm5.exe. Проверка осуществляется автоматически, а результаты выводятся на экран.

Можно оценить результаты тестирования, руководствуясь следующей информацией:

  • Количество тестов в разделе «Cycle» (желательно, чтобы было 10).
  • Количество ошибок в разделе «Error» (должно быть равно 0).

Prime95

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

При запуске Prime95 необходимо настроить параметры тестирования:

  • Выберите режим «Custom».
  • В поле «Memory to use» укажите значение, приблизительно равное 75% доступной оперативной памяти.
  • В поле «Time to run each FFT size» установите значение 120, что означает, что проверка будет продолжаться в течение 120 минут.

После настройки параметров следует запустить цикл. По его завершению утилита выведет результат.

Как проверить оперативную память на ошибки

Как проверить оперативную память на ошибки

Как найти поврежденный модуль ОЗУ

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

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

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

Поиск неисправностей может включать следующие этапы:

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

В итоге

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

Если же в результате тестов все же был сделан вывод о неисправности модуля ОЗУ, его следует заменить. Для этого можно воспользоваться гарантией производителя, если она еще действует. В ином случае его необходимо докупить модуль памяти и установить его в ПК самостоятельно.

Читайте также

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *