|
| 1.2, Lesha (?), 14:45, 26/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.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.
| | |
|
|