Вопрос или проблема
У меня есть несколько серверов на RHEL, которые ранее имели проблемы с авариями java/JVM и иногда выдавали сообщения об ошибках памяти на уровне ядра. Сейчас эти серверы в основном простаивают, так как рабочие нагрузки были перемещены в другое место, ожидая замены памяти.
После прочтения поста Алексея Шипилёва Пожалуйста, проверьте вашу память, я хотел бы запустить memtester на хосте, чтобы проверить, заметит ли он эти проблемы без перезагрузки. Обычно мы просто используем “нормальный” memtest при перезагрузке, но было бы интересно иметь альтернативы.
Сколько времени потребуется для завершения теста memtester на сервере 2016 года с памятью 3 ТБ?
Запуск memtest86+ занял около 3 дней на одном из таких хостов. Вероятно, помогает то, что memtest многопоточен, как упоминает статья Шипилёва.
На том же сервере запуск memtester 2700g 3 (версия 4.5.1) все еще находился на первом цикле из 3 после 21 дня времени на часовах. Он постоянно использовал 100% одного ядра.
В заключение, перезагрузка машины и запуск обычного memtest86+, предоставляемого при загрузке, остается лучшим решением. Рабочие нагрузки необходимо остановить или переместить в другое место для проведения такого рода расследований.
Проверка памяти таким образом не является опцией заранее, поэтому, возможно, стоит проводить тестирование памяти только после обнаружения некоторых ошибок ядром или когда количество аварий JVM настолько велико, что рабочие нагрузки уже пришлось остановить или переместить. Использование memtester может быть полезным в случаях, когда объем памяти для тестирования ограничен, а физический доступ или перезагрузка являются слишком дорогостоящими.
Пример журнала
$ free -g
total used free shared buff/cache available
Mem: 3023 76 2934 0 11 2933
Swap: 55 1 54
$ time nice -n 10 sudo memtester 2700g 3
memtester version 4.5.1 (64-bit)
Copyright (C) 2001-2020 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).
pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 2764800MB (2899102924800 bytes)
got 2764800MB (2899102924800 bytes), trying mlock ...locked.
Loop 1/3:
Stuck Address : ok
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV : ok
Compare OR : ok
Compare AND : ok
Sequential Increment: ok
Solid Bits : ok
Block Sequential : ok
Checkerboard : ok
Bit Spread : ok
Bit Flip : ok
Walking Ones : ok
Walking Zeroes : setting 11^C
real 30966m20.456s
user 27802m43.020s
sys 3084m14.099s
Общий ответ невозможен: это будет зависеть от ОЗУ и контроллера памяти процессора, и можно ожидать несколько порядков различий от доступного серверного оборудования.
Вообще, тестирование физической памяти путем тестирования виртуальной памяти из пользовательского пространства — это плохая идея по дизайну. Вы потратите больше времени на тестирование логики пейджинга в вашем ядре, ММУ вашего процессора, множества уровней когерентности кэша на многоядерных машинах (а машина с 3 ТБ, скорее всего, многоядерная), чем на взаимодействие с физической ОЗУ, и если вы не будете осторожны, делая это способом, оптимизированным вашим процессором для доступа к памяти (на машинах x86_64/AVX2 и более поздних, mm256_stream_* против классических загрузок/загрузок и т. д.), вы получите еще один фактор, часто в порядке 5×, на потери производительности.
Таким образом, переход на memtest86+ вместо этого (что действительно делает этот вопрос/ответ не по теме для этого сайта, не так ли?) был правильным шагом, в каком-то смысле (я не думаю, что он действительно знает топологию кэша и когерентности вашей машины, поэтому не может действительно проверять параллельно хорошо). Но честно: зачем? Даже тот блог, который предполагает гораздо меньшие машины (128 ГБ ОЗУ кажется для них большим), говорит, что все начинается с ECC RAM. И ни за что у вас не может быть одного узла, подключенного к 3 ТБ ОЗУ, который не является ECC RAM. А если у вас есть ECC RAM, то у вас будет счётчик того, сколько ошибок пришлось исправить. Ожидаются битовые сбои в ОЗУ, и в 3 ТБ ОЗУ можно быть уверенным, что по крайней мере один произошел — но работа ECC заключается в том, чтобы преобразовать физическую ошибку обратно в правильные данные, чтобы вы получали надежную память.
Но, конечно, хотя ECC исправляет большинство ошибок, иногда (по невезению) может произойти, что ошибки настолько серьезны, что результат выглядит как допустимые данные (или что-то, что легче “исправить” на неправильные допустимые данные, чем на правильные данные). Так что, если вы знаете, какого поколения ОЗУ использует ваша машина и какой тип ECC используется, вы можете сделать выводы из количества исправленных ECC ошибок о количестве неправильно исправленных. Это гораздо лучше на практике, чем запуск синтетической проверки памяти — которая может или не может замечать такие вещи, как соседние эффекты (подумайте о вещах типа Rowhammer), тогда как счётчики ECC фактически наблюдают, что идет не так в процессе использования. Резкий рост исправимых ECC ошибок будет поводом для расследования.
Если взглянуть на это с другой стороны: если у вас есть ECC память, у вас должны быть счетчики исправленных и неисправленных ошибок. На RHEL8 и RHEL9 установите пакет rasdaemon и затем ras-mc-ctl --error-count покажет количество ошибок, зафиксированных оборудованием с момента загрузки:
# ras-mc-ctl --error-count
Label CE UE
mc#0csrow#1channel#1 0 0
mc#0csrow#0channel#0 0 0
…
Кроме того, вы можете настроить запуск службы rasdaemon при загрузке, и она будет записывать обнаруженные ошибки в базу данных, которую вы можете запросить с помощью ras-mc-ctl --errors. Это позволит вам сравнить временные метки известных ошибок памяти с временными метками аварий и ошибок ядра.
Наконец, конфигурация rasdaemon в /etc/sysconfig/rasdaemon позволяет настроить её так, чтобы она сообщала ядру об “отключении” плохих страниц памяти, если они имеют слишком много исправленных ошибок за определенный период времени; если вы это настроите и увидите слишком много отключенных страниц, вы узнаете, что у вас неисправная память. Это также даст вам шанс поддерживать работу системы с неисправной памятью, уменьшая емкость памяти, чтобы удалить дефектную память.
.
Ответ или решение
Запуск memtester на сервере с 3 ТБ оперативной памяти — это задача, которая может занять значительное время и требует понимания различных технических аспектов. В этой ситуации важно учесть, как работает memtester и какие ограничения накладывает аппаратное обеспечение.
Теория (Т):
Memtester — это инструмент для проверки памяти, который может быть запущен в пользовательском пространстве без необходимости перезагрузки системы. Его целью является выявление ошибок памяти, таких как битовые ошибки, и обеспечение надежности работы сервера. Однако его работа ограничена рядом факторов, включая эффективность использования процессорного времени и работу с виртуальной памятью.
Пример (Э):
В рассмотренном случае запуск memtester на сервере с 3 ТБ оперативной памяти был чрезвычайно длительным. Первый проход из трех занял 21 день, используя при этом 100% одного процессорного ядра. Это подчеркивает, что memtester не использует многопоточности, в отличие от memtest86+, который за аналогичный объем памяти выполнил проверку примерно за 3 дня благодаря оптимально реализованной параллельной обработке.
Приложение (А):
Исходя из предоставленных данных, рекомендуется использовать memtest86+ для подобных проверок, особенно если сервер поддерживает перезагрузку и остановку рабочих нагрузок. Это связано с тем, что memtester, работающий в пользовательском пространстве, неэффективно взаимодействует с физической памятью из-за стресса на логике страничной памяти ядра и множественных уровней кэш-когерентности в многоядерных системах. В условиях 3 ТБ памяти эффективнее будет использовать проверки оперативной памяти при перезагрузке системы, так как они лучше управляют многопоточностью и учитывают кэш-топологию.
Кроме того, для серверов с оперативной памятью ECC (Error-Correcting Code) можно использовать инструменты мониторинга, такие как rasdaemon в RHEL, для отслеживания и записи ошибок памяти без необходимости длительного запуска memtester. Это позволит вести статистику корректируемых и некорректируемых ошибок и принимать обоснованные решения по обслуживанию и замене модулей памяти.
Таким образом, memtester может быть использован для небольших объемов памяти или когда физический доступ к серверу ограничен и перезагрузка недоступна, однако для полноценных проверок и обслуживания серверов стоит прибегать к более эффективным инструментам при предоставленной возможности.