The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Как протестировать целостность ОЗУ не останавливая машину на memtest
получим кучу несжимаемых данных
    dd if=/dev/urandom of=random.dat bs=1M count=БОЛЬШЕРАЗМЕРАОЗУ
    bzip2 -c < random.dat > random2.dat.bz2

распакуем в /dev/null (можно и на диск конечно)
    bzip2 -dc < random2.dat.bz2 > /dev/null

Сбой обычно выглядит так:
    bzcat: Data integrity error when decompressing.
 
22.04.2005 , Автор: poige , Источник: http://www.lexa.ru/inet-admins/msg1...
Ключи: memory, trouble, crash
Раздел:    Корень / Администратору / Система / Поддержка аппаратного обеспечения

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, ми (?), 17:43, 25/04/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    прикольно )
     
  • 1.2, Lesha (?), 14:45, 26/04/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А причем тут память?

    Процессор действительно нагружен, а какое отношение это имеет к памяти - непонятно.

     
     
  • 2.3, Андрей (??), 18:41, 26/04/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен. Прошу обосновать.
     

  • 1.4, Vano (??), 14:58, 27/04/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ПРИЧЕМ ТУТ ПАМЯТЬ???
     
  • 1.5, Michael (??), 09:34, 28/04/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так.

    Что мы точно не протестируем, навскидку:
    1. невыгружаемые блоки памяти занятые ядром
    2. Блоки памяти которые запрещено отправлять в своп (например SGA oracle если он залочен в RAM)
    3. Блоки памяти занятые bzip в данный момент

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

    Очень странная статья

     
  • 1.6, GR (??), 23:19, 28/04/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну да - по теории неправильно, но на практике - вот только на прошлой неделе отловил битую память! На FreeBSD5.3 решил зажать iso образ одного CD, bzip2 не захотел, сказал что то типа "Unreliable memory". Поскольку gzip cъел без проблем - я забил (ругаясь мол что из фряхи совсем глюкало сделали :) ССЗБ - буквально на следуюший понедельник оно отказалось собирать большой прилад к второму апачу  и понеслось ... :(

    А ведь мог заранее поменять :) Так что, автору верю!

     
  • 1.7, catap (?), 10:08, 30/04/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тут е вся память тестится, а какой-то ее кусок. Причем тестится не только память но и вся система... Есть глюки или нету :)
    Т.к. все алгоритмы сжатия достаточно критичны к ошибкав в вычеслениях... Я бы от себя добавил еще распоковать архивчик в файл random2.dat и сравнить их diff'ом (
     
  • 1.8, GRisha (?), 11:29, 30/04/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://www.qcc.ca/~charlesc/software/memtester/ - полезная вещь для этого
     
  • 1.9, poweruser (?), 08:21, 11/05/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Под виндой я уже довольно давно использую для подобных же целей 7zip.Берем его архив на ~гиг или больше (главное чтобы достаточно долго работало) и распаковываем несколько раз(особенно если не слишком большой) чтобы RAM и CPU прогрелись как следует.
    Эффективность метода очень хорошая:если за ~час-два мучений не вылезло ни 1 CRC Error можно спать спокойно (ну почти).Я так выловил редкий сбой случающийся примерно раз в полчаса и только при полной загрузке системы который все поюзанные мной RAM тесты успешно про%%али даже после суток тестирования.Видимо дело в том что тут еще проц качественно греется а RAM обычно недалеко от него. А как известно частота ошибок RAM сильно растет с ростом температуры.Так что если в холодном виде модуль работает но параметры "на грани фола" то в горячем виде бывает вот такое...
    Лично я теперь себе оперативку только так и тестирую :-) и перезагружаться не надо и надежность как минимум не хуже БОЛЬШИНСТВА мемтестов.Допускаю что есть какие-то не попавшиеся мне в руки, но...
    Что до сбоя кусками:сбой обычно по всему модулю или хотя бы чипу идет.Так что заметный кусок RAM сбоит.Из подобных соображений видимо стоит юзать алгоритмы компрессии с интенсивным использованием достаточно большого объема RAM(bzip тут не самый лучший выбор т.к. он сравнительно скромен в плане ресурсоемкости).
     
  • 1.10, zeiter (ok), 10:21, 26/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    После выполнения
    # dd if=/dev/urandom of=random.dat bs=1M count=600

    посыпался диск, с ошибками записи
    после чего система отказалась запускаться после перезагрузки...

    это дефект диска? или же команда каким-то образом способствовала его разрушению?

     
     
  • 2.11, poige (ok), 08:38, 07/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Команда просто создаёт файл, размером 600 MiB. Поэтому, можно сказать, что оттестировали плохой hard drive.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру