 |
 |
 |
| |
Авторизация
Не зарегистрировались? Вы можете сделать это, нажав здесь. Когда Вы зарегистрируетесь, Вы получите полный доступ ко всем разделам сайта. |
|
 |
 |
 |
|  |
|
|
|
| |
Размер ОЗУ и время жизни винчестера
Разместил 03/09/2006 от admin |
|
 |
|
 |
| |
ОЗУ - оперативное запоминающее устройство. Винчестер - долговременное. Казалось бы, это и все, что в них есть общего. Мало кто даже из опытных пользователей ПК задумывался над тем, как одно устройство может влиять на другое
Скорость, размеры и круг задач этих двух совершенно разных запоминающих устройств настолько различны, что их взаимосвязь прослеживается очень плохо. А между тем связь эта самая непосредственная, поскольку размер ОЗУ влияет не только на температуру винчестера, но и на его производительность. То, что от размера ОЗУ зависит быстродействие ПК в целом, знают все, а вот влияние на температуру и срок жизни винчестера требует некоторого пояснения
Что же именно связывает размер ОЗУ и винчестер? Да то, что Windows любой версии использует знаменитый файл подкачки WIN386.SWP.
В этой связке основные факторы, влияющие на температуру винчестера, это:
размер ОЗУ и файла подкачки;
фрагментированность файла подкачки;
размер кэша винчестера.
Размер ОЗУ
От размера ОЗУ напрямую зависит размер файла подкачки WIN386.SWP. Можно сказать, файл подкачки - это продолжение ОЗУ, но уже на винчестере. Как работает ПК?
1. Процесссор считает.
2. ОЗУ временно хранит сосчитанное.
3. Винчестер надолго запоминает сосчитанное процессором и оперативно запомненное ОЗУ.
Казалось бы, все очень просто. Но как-то ускользает из поля зрения тот факт, что процессор в ходе вычислений все время использует только ОЗУ разных уровней, а винчестер в вычислительном процессе вовсе не участвует.
Мысль эта проста и незатейлива для профессионалов, но эвристична для начинающих. Если бы я осознал ее на заре своей ПК-юности, то избежал бы многих глупостей. Например, не мучил бы в течение полугода Celeron 366 и винчестер на 7,6 Гбайт с 512 Кбайт кэша всего тридцатью двумя мегабайтами ОЗУ (и это все в Windows 98 и многозадачной среде с десятком одновременно выполняемых программ!).
Фразы насчет минимально допустимой величины ОЗУ для операционной системы и игрушек начинающие пользователи воспринимают не головой, а кошельком. Зачем платить лишние деньги за не очень-то значительное ускорение работы ПК? Аргументы типа "Все будет работать медленно" плохо воспринимаются на слух, но если бы это наставление звучало чуть иначе - "Все будет работать не просто медленно, а еще и не долго", то многие призадумались бы. А подумать есть над чем.
Процессор работает с информацией из ОЗУ, в которое с винчестера переносятся при загрузке ОС или игрушек данные о запущенных задачах. Места в ОЗУ всегда мало, и ОС начинает использовать часть свободной памяти винчестера как дополнительную память с "прямой сквозной адресацией". Последнее словосочетание означает, что операционная система обращается к адресам памяти, абсолютно не интересуясь тем, где они расположены, в ОЗУ или на винчестере. Алгоритм работы файла подкачки сложен и подразумевает динамическое изменение собственного размера в зависимости от нагрузки на ПК. Много задач выполняет процессор - много нужно и дополнительной памяти, мало - размер файла подкачки уменьшается.
После очередной переустановки Windows ME я стал фиксировать с помощью системного монитора размер выделенной памяти, файла подкачки и оставшейся свободной памяти из имеющейся в наличии 256 Мбайт, постепенно наращивая "фактор многозадачности". В таблице 1 первая строка отражает состояние памяти сразу после запуска только что установленной ОС с тремя выполняемыми задачами (Explorer, Internat и Sistray), а последняя - после инсталляции всех драйверов дополнительных устройств и при одновременной работе уже 20 программ!
Величина выделенной и подкачиваемой памяти в таблице зафиксирована сразу после запуска ОС и на холостом ходу. Если начать активно работать или играть на ПК, их размер начинает увеличиваться прямо пропорционально времени и интенсивности "фактора многозадачности".
Как только наступает момент обращения процессора не к ОЗУ, а к памяти в файле подкачки, наступают две неприятные вещи:
1. Работа ПК резко замедляется, иногда в сотни и даже тысячи раз, потому что...
2. Вступает в активную работу и начинает греться винчестер, причем тем интенсивнее, чем более фрагментирован файл подкачки.
Оптимизация файла подкачки
Устранение "динамического изменения размера файла подкачки в зависимости от нагрузки на ПК", которым по непонятным причинам так гордится Microsoft, сразу же ускоряет работу всего ПК и уменьшает нагрузку на винчестер.
Чем больше ОЗУ, тем позже начинает работать файл подкачки и тем меньше нагрузка на винчестер. Чем менее "динамично изменяется размер файла подкачки", тем опять-таки меньше нагрузка на винчестер.
Вы только представьте, какое количество погибших винчестеров (и не только от Quantum, но и от IBM) можно было бы сохранить или значительно продлить срок их жизни простым увеличением размера ОЗУ или оптимизацией файла подкачки!
Итак, сразу после начала работы ПК нужно облегчить условия работы винчестера путем устранения "динамического" расползания файла подкачки по всему логическому диску. Делается это просто: Мой компьютерСвойстваБыстродействие и далее - разумный подход к расположению и выбору min и мах размера файла подкачки.
Дефрагментация файла подкачки
О пользе дефрагментации логических дисков сказано много и предельно ясно, а вот о дефрагментации файла подкачки - практически ничего и нигде.
Мне всегда хотелось понять, насколько разумно само "динамическое изменение размера..." приличной части логического диска, занимаемого файлом подкачки. Ведь основная цель любой дефрагментации как раз и состоит в устранении "динамического изменения размера" любого файла и в предотвращении его расползания по диску. Мало того, знаменитый DEFRAG считает файл подкачки не перемещаемым и при дефрагментации диска обходит его стороной. Эта особенность DEFRAG и позволила понаблюдать за динамичностью изменения размера файла подкачки.
Суть эксперимента очень простая. Я каждый раз после установки дополнительных программ и драйверов запускал дефрагментатор Speed Disk из Norton Utilities, но саму дефрагментацию не делал, а только использовал программу для визуального контроля расположения файла подкачки на диске С.
То что я увидел, поразило меня до глубины души. Windows ME раз за разом использовал одни и те же кластеры диска для размещения файла подкачки! Сначала я подумал о разумности такого подхода к распределению дискового пространства для динамично изменяющегося файла, особенно при однотипной загрузке одной и той же ОС, но призадумался, когда получал один и тот же порядок размещения различных частей файла подкачки после экспериментов по изменению папки C:WINDOWSГлавное менюАвтозагрузка, а также различных вариантов установки и удаления дополнительных программ и записи на диск С файлов большого размера (100-200 Мбайт).
Каждый раз перед выключением ПК в течение месяца я проверял расположение различных частей файла подкачки на диске С и каждый раз оно было одинаковым, за исключением размера и, соответственно, последнего кластера последней части файла подкачки. Мало того, при записи непрерывного файла большого размера (аудио-видео) часть или даже несколько частей файла подкачки иногда оказывались внутри записанного файла, разбивая его на части.
Я усугубил этот процесс тем, что в течение этого месяца (сразу после чистой переустановки Windows ME) ни разу не делал дефрагментацию вообще. Варварство, конечно, но зато удалось определить самый последний кластер на диске С, занятый файлом подкачки. Он настолько "динамически наизменялся в размерах", что оказался аж на уровне 564923 кластера, что соответствует размеру 2314 Мбайт. А теперь представьте - на диске размером 3 Гбайт установлено около 1,2 Гбайт программ (40% емкости), а последний кластер файла подкачки размером всего 104 Мбайт оказался на уровне 2314 Мбайт (77%). Максимальное количество зафиксированных кусочков файла подкачки составило 17 штук, причем их размеры и местоположение были всегда те же.
Очень странное динамическое изменение размера получается: один раз заняв свободный кластер диска, файл подкачки пользуется им всю оставшуюся жизнь. Мало того, даже не используемые в данный момент кластеры все равно изымаются из оборота и фрагментируют другие файлы в ущерб общей производительности ПК.
Ну, а теперь представьте себе, каково винчестеру - ему нужно ползать по 17 разным кускам файла подкачки размером в сотню мегабайт, разбросанного на "площади" размером 2314 Мбайт. А если к тому же размер ОЗУ всего 32 Мбайт и собственный кэш 128 Кбайт - совсем тяжело и горячо приходится микросхеме контроллера привода головок.
Только теперь становится ясна причина появления бэд-блоков на винчестере офисного сервера именно в начале диска, где расположены первые кластеры файла подкачки. Если не делать дефрагментацию месяцами и использовать DEFRAG вместо Speed Disk, то результат - вполне закономерный.
Размер кэша винчестера
И, напоследок, еще один фактор, в немалой степени влияющий на нагрев и надежность винчестеров. Это размер буфера кэша самого винчестера. Буферная память большинства современных IDE-винчестеров равна 2 Мбайт, а у отдельных экземпляров уже достигла и 8 Мбайт. Ее размер напрямую влияет на степень нагрузки контроллера привода головок винчестера и, соответственно, на его нагрев.
Логика работы большинства винчестеров сводится к записи в буфер обмена не кусочка необходимой информации, а целиком всей дорожки или нескольких дорожек сразу. И уже из буфера обмена достается необходимая часть информации и отправляется по назначению. Исходя из этого, становится ясна проблема перегрева контроллера привода головок некоторых винчестеров Quantum lct и IBM DTLA: у них не так давно был самый маленький по сравнению с другими винчестерами размер кэша - всего 128 Кбайт.
Давайте сравним, сколько раз необходимо переместиться считывающей головке, например, для перенесения файла размером 200 Мбайт с начала диска в конец. При размере кэша 2 Мбайт - 100 раз (200:2), при 8 Мбайт - 25 раз (200:8), а при 128 Кбайт - 1600 раз (200:0,128)! Неразумная экономия на размере кэша привела к увеличению нагрузки на контроллер привода головок винчестера в десятки раз по сравнению с современными моделями. Отсюда и перегрев со всеми последствиями.
Чтобы проверить это умозаключение, я измерил температуру контроллера привода головок Quantum lct при переносе с первого диска С на последний Q трех файлов размерами 3,2 Мбайт (0,128х25), 12,8 Мбайт (0,128х100) и 200 Мбайт (0,128х1600). Получилось некая имитация увеличения размера кэша со 128 Кбайт до 2 и 8 Мбайт. Она, конечно, дает довольно-таки условное приближение к реальной ситуации с увеличением размера кэша, но все равно результат весьма показателен.
Резюме
Чем больше размер ОЗУ и буфера памяти самого винчестера, тем меньше нагрузка на контроллер привода головок и, соответственно, меньше его нагрев, а значит, выше надежность и срок службы. Устранение динамического изменения размера файла подкачки с разумным выбором его максимального и минимального размера дает точно такой же эффект. Причем для современных винчестеров эти меры не менее актуальны, учитывая рост их объемов, плотности записи и оборотов, даже несмотря на значительное увеличение размера буфера по сравнению с винчестерами предыдущих годов выпуска.
Оптимизация файла подкачки WIN386.SWP, разумное увеличение размера ОЗУ и индивидуальные системы охлаждения винчестеров - вот три кита, на которых покоится проблема повышения надежности и срока хранения самого ценного, что есть в современных ПК - с таким трудом собранной или созданной в творческих муках информации.
Источник: http://www.winzone.ru
|
|
 |
 |
 |
| |
|
|
|
| |
Рейтинг статьи
Средняя оценка: 0
Ответов: 0
|
|
|
|
|
|
|
