Лучший скрипт для теста железа сервера linux, о котором не знают даже старые и опытные админы

Как любой синтетический тест stress-ng не умеет тестировать весь объём доступной памяти.

любой

1. memtest?
2. А кто сказал, что упаковка или распаковка архива используют ВСЮ доступную память? Это как минимум не так и исходя из алгоритмов подсистемы управления памятью в Linux это даже почти невозможно устроить.

далее ядро его убивает по OOM.

Правильно. И упаковка с распаковкой тоже не сможет так же занять всю память. Да даже файлоый кэш в Linux и все его буферы - никогда не займут ВСЮ память. Всегда останется что-то свободное даже от этого.

А простейший скрипт который я привел - умеет.

Абзацем выше я только что написал обратное. Ну или покажите пруф. Например, моя система при 32 гигах рамы держит минимум 500 метров не занятыми ничем, пока я в конец не охамею нагрузками. Но и тогда 100-200 мегабайт остаются свободными. Мне можно рассказать про дефрагментацию памяти и то, что оно используется для занятия новых блоков и потом другие высвобождаются и что реально память может быть занята полностью, но это не так. Точнее, не совсем так и с огромной долей вероятности система даже через несколько дней не тронет ряд ячеек памяти даже под серьезной нагрузкой.

и он не тестирует одновременно все 3 компонента системы.

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

Ещё раз. Был сервер с 8 дисками, 6 из них - HDD по 8 терабайт, ещё два - две SSD духтерабайтных под кэш. Всё было собрано в массив с SSD-кэшем на аппаратном RAID. Потом заметили, что иногда случайный диск из массива вылетает. Выяснилось, что при длительной (десятки часов) нагрузке определённого типа Adaptec RAID начинает «подвисать» и может выбросить один или два диска из массива. Проблема оказалась в его перегреве - вылетел один корпусный вентилятор, который его обдувал до этого, но его таходатчик продолжил показывать значения оборотов близкие к нормальной работе, а мониторинг его температуры сделан не был. Чтобы определить проблему удалённо пришлось воспользоваться как раз таки синтетическими нагрузками после вывода железки из эксплуатации, генерирующими конкретный тип нагрузки.

CPU, RAM, disk в сложной нагрузке, похожей на реальную.

Исходя из вышеприведённого абзаца вы можете видеть, что ни о какой «реальной» нагрузке в вашем скрипте речи не идёт. Точно так же можно просто на любом сервере сделать wget && tar zxvf и всё.

Есть разница в том, как работает stress-ng и как работает скрипт. stress-ng выделяет память под себя и работает с ней. Скрипт же не выделяет память под себя, вместо этого он просто пишет на диск быстрее чем диск способен принять, что приводит к переполнению файлового буфера. При достижении предела в 85-90% ядро, также как и в случае с stress-ng, тоже начинает притормаживать этот процесс и оставляет свободными 10% для других нужд, но если продолжать писать, то освобождающиеся страницы кеша постепенно заполнят и эти 10% (ротация), что задействует их при записи. В итоге всегда остаются свободными 10% памяти, на длинной дистанции работы скрипта вся свободная память и эти 10% будут протестированы косвенно.

И, я всё ещё не вижу аналогичного конфига для stress-ng, ну хоть кто-то выложит? Хоть кто-то хоть что-то у себя тестирует с его помощью?

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

И что это должно бы значить? Что память будет занята вся? НЕТ! Не будет, будет оставлен резерв. И тюнится этот резерв через sysctl. Совсем убрать - нет, нельзя.

ри достижении предела в 85-90% ядро, также как и в случае с stress-ng

Фантазии. Не будет такого достижения. Тюнится, опять же, через sysctl.

постепенно заполнят и эти 10% (ротация) Да ладно? =). А точно будет ротация? Или будет вытеснен кэш, набранный ранее (тюнится через sysctl).

на длинной дистанции работы скрипта вся свободная память и эти 10% будут протестированы косвенно.

И bit-fade будет протестирован? ). Кстати, я же сказал выше - 100% памяти проверить даже в этой ситуации маловероятно. Особенности управления памятью и борьба с её фрагментацией, видите ли. Открою страшную тайну: даже memtest не может протестировать ВСЮ память. Такие вот дела.

И, я всё ещё не вижу

Ну почините зрение, прочитайте man, запустите с нужными параметрами. Стресс-тест системе он устроит ГОРАЗДО более серьезный чем ваш скрипт. Диагностика же оборудования это немного более сложный процесс.

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

Да даже файлоый кэш в Linux и все его буферы - никогда не займут ВСЮ память.

Займут. Точнее не именно всю, а уже занятая + то самое до упора.

а этот похороникс вроде имел аналогичные тесты плюс ещё компиляция

а, его тут уже посоветовали

https://github.com/phoronix-test-suite/phoronix-test-suite

1. reserved. Эту память вообще не факт что кто-то использует и как использует.
2. Да ладно? Та память, что помечена free всегда будет иметь сободный кусочек. Ситуация free=0 почти невозможна. И в зависимости от крутилок система, скорее, сначала вынесет старый кэш, а потом только полезет в эту область памяти. Такие вот дела.

Ситуация free=0 почти невозможна.

За давностью лет последнего случая уже непомню там ровно 0 или 0.00001 от которого не легче.