получим кучу несжимаемых данных
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.
URL: http://www.lexa.ru/inet-admins/msg15225.html
Обсуждается: https://www.opennet.ru/tips/info/837.shtml
прикольно )
А причем тут память?Процессор действительно нагружен, а какое отношение это имеет к памяти - непонятно.
Согласен. Прошу обосновать.
ПРИЧЕМ ТУТ ПАМЯТЬ???
Так.Что мы точно не протестируем, навскидку:
1. невыгружаемые блоки памяти занятые ядром
2. Блоки памяти которые запрещено отправлять в своп (например SGA oracle если он залочен в RAM)
3. Блоки памяти занятые bzip в данный моментПотом, даже если мы распаковываем файл, этот процесс не займет всю память системы.
Очень странная статья
Ну да - по теории неправильно, но на практике - вот только на прошлой неделе отловил битую память! На FreeBSD5.3 решил зажать iso образ одного CD, bzip2 не захотел, сказал что то типа "Unreliable memory". Поскольку gzip cъел без проблем - я забил (ругаясь мол что из фряхи совсем глюкало сделали :) ССЗБ - буквально на следуюший понедельник оно отказалось собирать большой прилад к второму апачу и понеслось ... :(А ведь мог заранее поменять :) Так что, автору верю!
Тут е вся память тестится, а какой-то ее кусок. Причем тестится не только память но и вся система... Есть глюки или нету :)
Т.к. все алгоритмы сжатия достаточно критичны к ошибкав в вычеслениях... Я бы от себя добавил еще распоковать архивчик в файл random2.dat и сравнить их diff'ом (
http://www.qcc.ca/~charlesc/software/memtester/ - полезная вещь для этого
Под виндой я уже довольно давно использую для подобных же целей 7zip.Берем его архив на ~гиг или больше (главное чтобы достаточно долго работало) и распаковываем несколько раз(особенно если не слишком большой) чтобы RAM и CPU прогрелись как следует.
Эффективность метода очень хорошая:если за ~час-два мучений не вылезло ни 1 CRC Error можно спать спокойно (ну почти).Я так выловил редкий сбой случающийся примерно раз в полчаса и только при полной загрузке системы который все поюзанные мной RAM тесты успешно про%%али даже после суток тестирования.Видимо дело в том что тут еще проц качественно греется а RAM обычно недалеко от него. А как известно частота ошибок RAM сильно растет с ростом температуры.Так что если в холодном виде модуль работает но параметры "на грани фола" то в горячем виде бывает вот такое...
Лично я теперь себе оперативку только так и тестирую :-) и перезагружаться не надо и надежность как минимум не хуже БОЛЬШИНСТВА мемтестов.Допускаю что есть какие-то не попавшиеся мне в руки, но...
Что до сбоя кусками:сбой обычно по всему модулю или хотя бы чипу идет.Так что заметный кусок RAM сбоит.Из подобных соображений видимо стоит юзать алгоритмы компрессии с интенсивным использованием достаточно большого объема RAM(bzip тут не самый лучший выбор т.к. он сравнительно скромен в плане ресурсоемкости).
После выполнения
# dd if=/dev/urandom of=random.dat bs=1M count=600посыпался диск, с ошибками записи
после чего система отказалась запускаться после перезагрузки...это дефект диска? или же команда каким-то образом способствовала его разрушению?
Команда просто создаёт файл, размером 600 MiB. Поэтому, можно сказать, что оттестировали плохой hard drive.