Как тестировать память быстрей?

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

Для диагностики модулей есть хорошая программа memtest86+, но если памяти у нас 1ТБ, то полное тестирование растягивается на несколько дней, а бизнес не может так долго ждать.

Как же быть? В этой публикации я поделюсь опытом тестирования памяти сервера Gigabyte R292-4S0 с СУБД на Enteprice Linux 8 (EL8) и 1 ТБ памяти двумя методами:

• С EFI загрузкой memtest86+ v7;

• С автоматизированным созданием сотни libvirt-KVM виртуальных машин с memtest86+ внутри.

Запуск memtest внутри виртуальной машины… «Фу…», — скажут некоторые. И будут неправы:

• На Хабре описан успешный пример такого запуска в VirtualBox;

• У меня есть положительный опыт с автоматизированной PXE загрузкой сотни виртуальных машин с memtest в ESXi. Гипервизор с ошибкой в памяти падал за минуты, пока за несколько тестов мы не вычислили неисправный модуль. А с рабочими («боевыми») виртуальными машинами сбой проявлялся раз в неделю;

• Такое тестирование по моему подсчету охватывает ~97% памяти, и велик шанс того, что именно тут есть сбойные ячейки;

• Такое тестирование существенно быстрей.

Приступим.

Нам понадобится сам memtest86+, его можно найти на сайте https://memtest.org. Можно было бы попробовать установить его через yum. Но, увы, в тестируемом мной EL8 так установился только memtest86+ v5.01, который EFI загрузку вообще не поддерживает. Нужна версия memtest 6 или новее.

EFI загрузка memtest+

Скачиваем Binary Files (.bin/.efi), распаковываем memtest64.efi в созданную папку /boot/efi/EFI/memtest (/boot/efi — примонтированная ФС VFAT). Мы готовы к EFI-загрузке .

Как загрузить memtest через EFI-загрузчик? На тестируемом сервере Gigabyte во время запуска нажимаем F10, попадаем в меню выбора загрузочного устройства, в нем выбираем EFI-shell.

В EFI-shell нужны следующие команды:

1. map покажет, какие FAT-совместимые файловые системы у нас есть;

2. fs0: (с двоеточием) переключится на первую файловую систему (ранее она у нас была смонтирована в /boot/efi);

3. cd EFI/memtest поменяет текущую папку на ту, куда вы положили memtest (тут даже работает автодополнение TAB, удобно);

4. ls позволит посмотреть, какие файлы есть в текущей папке;

5. memtest64.efi — имя скачанного бинарного файла, который нужно запустить.

После этого загрузится сам memtest, в моем случае он еще несколько минут просто так показывал зависший экран и ничего не делал. Видимо, определял объем работы. Затем работа пошла и продолжалась… 95 часов (4 дня) до первого прохода!

libvirt-KVM загрузка memtest86+

Для загрузки memtest внутри виртуальных машин нам потребуется добавить в наш EL8 дополнительные утилиты для управления kernel-virtual-machine. Запустим сразу libvirtd.service и уберем поднятый внутренний сетевой мост default — сеть нам тут не пригодится.

yum install -y qemu-kvm libvirt virt-install virt-manager virt-viewer qemu-img  systemctl enable --now libvirtd.service virsh net-autostart default --disable  virsh net-destroy default 

Создадим пустую папку, например, /opt/vm-memtest, положим в нее уже знакомый memtest64.efi. Далее в ней же необходимо создать пустой файл empty.

touch empty

В этой же папке создадим скрипт запуска, который будет использовать подобную команду:

virt-install -n memtest1 \             --memory 12288 \             --vcpus 2 \             --disk "none" \             --network "none" \             --os-variant "detect=off,name=generic" \             --location "/opt/vm-memtest,kernel=memtest64.efi,initrd=empty" \             --noautoconsole \             --serial file,path=/opt/vm-memtest/console-out-vm-memtest1 \             --extra-args "console=ttyS0,115200 console=tty0"

Разберем, что она делает:

• задаст имя новой виртуальной машины — memtest1;

• выделит 12GB RAM;

• выделит 2vCPU;

• не будет выделять диск;

• не будет подключать сетевые адаптеры;

• отключит контроль успешной загрузки ОС со стороны virt-install;

• запустит ядро из /opt/vm-memtest/memtest64.efi с пустым initrd файлом (без него virt-install не получится, empty — это костыль);

• не будет открывать консоль виртуальной машины в virt-viewer;

• подключит COM-порт из файла /opt/vm-memtest/console-out-vm-memtest1 (файл будет создан автоматически);

• ядру ОС виртуальной машины будут переданы параметры загрузки о том, что свой вывод нужно дублировать как в указанный COM-порт (файл), так и на консоль tty0 (к ней можно подключиться через virt-viewer, если захочется).

Объём памяти в 12ГБ появился удвоением (2vcpu в вм) деления количества памяти в системе на общее количество vcpu в 4-х сокетном сервере.

До создания виртуальных машин нужно остановить «боевые» приложения и не забыть, что СУБД (если она у вас есть) должна вернуть свои huge pages в ОС, отключить swap, а еще сбросить все КЭШи из памяти на диск:

swapoff -a sysctl -w vm.nr_hugepages=0 sync echo 3 > /proc/sys/vm/drop_caches

Конечный скрипт запуска получился такой:

#!/bin/bash  # Written by Alex Golikov 2023.11.22  ## Prepare host to provide KVM service  # yum install -y qemu-kvm libvirt virt-install virt-manager virt-viewer qemu-img  # systemctl enable --now libvirtd.service # virsh net-autostart default --disable  # virsh net-destroy default   ## To get Memory per One vCPU in this system run: # awk '/MemTotal/{ printf("%.0f\n",$2/1024/'$(grep -c processor /proc/cpuinfo)') }' /proc/meminfo  vcpu_per_vm=2 memory_per_vm=12288 vmprefix="memtest"  ## uncomment to limit VM number #max_vm_number=3  #create lastvm to spend all the rest available memory lastvm=true  #memtest_kernel="memtestx64.efi.6.20" memtest_kernel="memtest64.efi"  startvm() {      #avail_mem=$(awk '/MemAvailable/{ printf("%.0f",$2/1024) }' /proc/meminfo)    avail_mem=$(free -m | awk '/Mem/{print $7}')     #calculate vm_num (number of VMs to create)    vm_num=$(($avail_mem / $memory_per_vm))    [[ -z "${vm_num}" ]] && echo "Unable to calculate vm_num (number of VMs to create)" && exit 1     #Check vm limit variable    [[ -n ${max_vm_number} ]] && [[ ${vm_num} -gt ${max_vm_number} ]] && vm_num=${max_vm_number}     #Check current memtest VMs that have already created before    current_vm_number=$(virsh list --all| awk '{if($2~/'${vmprefix}'/) {print $2}}' | sed 's|'${vmprefix}'||' | sort -n | tail -1)    [[ -z "${current_vm_number}" ]] && current_vm_number=0     echo "Creating ${vm_num} VMs with ${memory_per_vm}MB onboard to test ${avail_mem}MB of RAM."     for (( i=$((${current_vm_number}+1)) ; i<=$((${vm_num} + ${current_vm_number})); i++ )); do       echo -e "##############\n\nCreating ${vmprefix}${i}..."       virt-install -n ${vmprefix}${i} \                 --memory ${memory_per_vm} \                 --vcpus ${vcpu_per_vm} \                 --disk "none" \                 --network "none" \                 --os-variant "detect=off,name=generic" \                 --location "${MyDir},kernel=${memtest_kernel},initrd=empty" \                 --noautoconsole \                 --serial file,path=${MyDir}/console-out-vm-${vmprefix}${i} \                 --extra-args "console=ttyS0,115200 console=tty0"    done }   stopvm() {          for vm in $(virsh list --all | awk '{if($2~/'${vmprefix}'/) print $2}'); do                 echo -e "##############\n\nRemoving $vm"                 virsh destroy $vm                  virsh undefine $vm          done         echo -e "##############\n\nWork completed"  }   checklogs() {         for console_out in $(ls -1 console-out-vm-*); do                 echo -en "\n${console_out}        "                 sed -n 's/.*\(Time: [ 0-9:]*\).*\(Pass: [ 0-9]*\).*\(Errors: [0-9]*\).*/\1 \2 \3/p' $console_out         done         echo -e "\n\nRun command 'rm -f ${MyDir}/console-out-vm-*' to remove VM console logs" }  [[ "$1" =~ start|stop|check ]] || { echo "Usage: $0 {start|stop|check}"; exit 1; }  MyDir=$(dirname "$0") && cd "${MyDir}" && MyDir="$(pwd)"  [[ "$1" == "start" ]] && {         startvm         [[ "${lastvm}" == "true" ]] && {               memory_per_vm=$(free -m | awk '/Mem/{print $7 - 100 }')               #memory_per_vm=$(awk '/MemAvailable/{ printf("%.0f",$2/1024 - 100) }' /proc/meminfo)                #Create one more VM if we have at least 500MB of RAM left               [[ "${memory_per_vm}" -gt 500 ]] && {                    echo "Spending the last ${memory_per_vm}MB"                    startvm                }         }         echo -e "##############\n\nWork completed:"         virsh list --all | awk '{if($2~/'${vmprefix}'/) print $0}'         free -m         } [[ "$1" == "stop"  ]] && stopvm [[ "$1" == "check" ]] && checklogs 

Команда запуска

./vm-manage.sh start 

последовательно запустит почти сотню виртуальных машин:

Команда анализа выводов в консолях виртуальных машин:

./vm-manage.sh check

Команда остановки всех созданных виртуальных машин:

./vm-manage.sh stop

Память во всех запущенных виртуальных машинах была протестирована за 5 часов, что существенно быстрей, чем на bare-metal.

Выводы

Сравним два описанных метода.

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

Об этом можно косвенно судить даже по скорости оборотов вентиляторов сервера. Во время нативного исполнения memtest их скорость отображалась как 10К RPM, а с libvirt они же разогнались до 20K RPM. «Здесь мерилом работы считают усталость«, — посмеются некоторые, но в случае с нативным исполнением memtest сервер никак не выдает метрики загрузки своих процессоров; приходится выкручиваться.

Метод тестирования через виртуальные машины охватывает ~97% памяти, нагружает процессоры целиком (зафиксировано с node_exporter), и в большинстве случаев этот результат будет достаточным, чтобы с стресс-тесте отбраковать неисправный модуль. Основной упор на то, что метод должен быстро воспроизводить неисправность. Ведь серия тестов может быть длинной, возможно придется несколько раз менять конфигурацию памяти в сервере перед тем, как мы найдем «виновный» модуль.

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