[TC] DrWeb 4.33 и виртуальная память Windows XP.

Здравствуйте, Виктор!!!
Подобное сообщение о нехватке виртуальной памяти обычно выдаёт XP.
Она тут же и предлагает увеличить файл подкачки, достаточно нажать "да".
Если не предлагает, а только сообщает, тогда вы можете увеличить виртуальную
память сами, открыв настройки быстродействия в свойствах системы, но
помните, возможно, сама система после этого может начать работать тормознее.
С уважением, Алексей.

Hello Виктор Лавриненко, 22-Oct-2005 23:57 you wrote:

Если выскакивает диалоговый ящик, то в заголовке написано имя программы, от
которой данное сообщение. Если о нехватке виртуальной памяти сообщает винда
(ХР), то выскакивает балун в области уведомлений.

Смотрите в корне диска.

Зайдите "панель управления", "система", вкладка "дополнительно", рядом с
надписью "Быстродействие. Визуальные эффекты, использование процессора,
оперативной и виртуальной памяти" есть кнопка "параметры" (в данном окне
таких кнопок три, так вот эта - первая). В выскочившем окне выбираем вкладку
"дополнительно", внизу есть кнопка "изменить". Далее в окне технология
такая. Есть список дисков, для каждого есть параметры. Выбираем нужный диск
и для него можно выбрать, какого размера файл подкачки должен на нём быть.
Если для диска мы что-то меняем, то после этого надо нажать кнопку "задать".

Для выбора оптимального размера свопа рекомендуют следующую методику. Жмём
CTRL+ALT+DEL, в выскочившем диспетчере задач выбираем вкладку
"быстродействие". Там есть надпись "выделение памяти (КБ)", под ней
написано, каков текущий размер свопа ("всего"), его максимальный
возможный размер ("предел") и "пик" - каков был максимальный объём
выделенной памяти за текущий сеанс (или пиковое выделение памяти). Нам надо
смотреть как раз на "пик".

После этого работаем как обычно некоторое время. Затем смотрим на пиковое
значение. Его максимальное значение - это тот минимум свопа, что вам нужно
выставить. Обычно к этому значению прибавляют ещё сколько-то и ставят таким
же размер своп-файла. Рекомендуется поставить минимальный размер =
максимальный размер - это для того, чтобы не возникало вопросов про
увеличение.

Для вашего случая, после запуска Др.Веба (и вопроса про увеличение свопа)
посмотрите, каков пик выделения.

P.S. По умолчанию, pagefile.sys имеет размер, который указан в пункте
"минимальный размер файла подкачки" для этого диска. Если этого размера
системе недостаточно, то она увеличивает его размер, при этом
возникает то самое сообщение, и некоторым программам может быть отказано в
выделении памяти (т.е., иными словами, возможны глюки). После этого размер
pagefile.sys не уменьшается до следующей перезагрузки.
Поэтому рекомендую ставить мин. и макс. размеры одинаковыми.

P.P.S. В плане производительности. Она не повысится, если вы разместите своп
на том же диске, но на другом разделе. Если у вас есть второй винчестер, то
рекомендуется поместить своп туда, если, конечно, второй винч не намного
медленнее, чем первый :-).

Здравствуйте, дамы и господа.
Подскажите пожалуйста, могу ли я при создании образа диска исключить файл
pagefile.sys. Правильно ли я полагаю, что он сам собою сгенерируется при
первом запуске системы после восстановления из образа.

Да еще есть там в корне довольно увесистый файл hiberfil.sys, можно ли
создавать образ без него.

С уважением Сергей.

Hello, Smirnov!
You wrote to "industry.comp.tiflocomp (3211847)" <urm***@h*****.ru> on Fri,
28 Oct 2005 00:01:16 +0400:

Совершенно верно!

Можно вообще без него работать, особливо если спящий режим вам не нужен.
Зайдите "панель управления \ электропитание", снимайте галочку на вкладке
"спящий режим" и файл автоматически прибьётся.

With best regards, Serge Kolomeitsev(AKA Soundless Falser)
MailTo: urm***@h*****.ru
HomePage Url: http://www.urmas.hotmail.ru
ICQ# 241908556

Здравствуйте, Сергей,

Файл виртуальной памяти имеет несколько параметров, от настроек
которых существенно зависит его поведение. Для наиболее эффективной
работы размер этому файлу лучше указывать фиксированный. Это позволяет
избежать его фрагментации, что положительно сказывается на скорости
работы и долговечности HDD. В одном из параметров можно указать, чтобы
файл уничтожался каждый раз при выходе из виндоуз. Не уверен, что эти
параметры совместимы, так что перед созданием имиджа лучше повозиться с
параметрами виртуальной памяти.

Это файл дампа памяти для спящего режима. Я на всех компьютерах (кроме
ноутбуков) этот режим убиваю на корню. Соответственно и файла не
будет.

--
С наилучшими пожеланиями
Владимир Лукьянов
Москва
mailto:lvu20***@y*****.ru

Hello Владимир Лукьянов, 30-Oct-2005 13:16 you wrote:

Это не факт. Сам файл, может, и не фрагментируется, но ведь страницы памяти
выгружаются в него тоже не последовательно, а по мере надобности, так что
внутри файла они могут лежать и не по порядку. Следовательно, небольшая
фрагментация файла подкачки не только не должна сказываться на скорости, но
и может дать его прирост.

Здравствуйте, Егор,

но

Вы не точно рассуждаете, Егор. Ваши рассуждения можно применить к
любому файлу, и получится, что дефрагментация не только не полезна, но
и вредна. Спору нет, можно подобрать примеры машин и приложений, где
дефрагментация не целесообразна. Однако, доказывать ее неэффективность
в статистическом смысле Вашими аргументами нельзя. Контрпример в
статистике не имеет значения. И если уж Вы утверждаете, что "небольшая
фрагментация файла подкачки не только не должна сказываться на
скорости, но и может дать его прирост" я прошу Вас доказать это, на
мой взгляд, абсурдное утверждение. Здесь можно просто пример привести.

--
С наилучшими пожеланиями
Владимир Лукьянов
Москва
mailto:lvu20***@y*****.ru

Hello Владимир Лукьянов, 1-Nov-2005 01:54 you wrote:

Некоторые сисадмины говорят, что фрагментация диска в 25% положительно
сказывается на скорости.

Согласен. Однако я не пытался доказывать, я просто сказал, что "это не
факт", т.е. надо проверять.

Хм, ну тогда надо разработать методику, на основании которой можно провести
тестирование. Ваши предложения?

Ответ на письмо от 06.11.2005
Здравствуйте, Егор,

По-моему, это не так. То есть, говорить-то разные люди могут разное.
Я поясню своё понимание.

В чём, собственно, выигрыш при дефрагментации? Во-первых, из
технических характеристик винчестеров давно известно, что самая
медленная операция - это переход с дорожки на дорожку. И чем больше
отдалены дорожки, тем дольше этот переход. Таким образом, чем меньше
переходов с дорожки на дорожку, и чем эти переходы короче, тем быстрее
считываются данные. Во-вторых, буферизация (упреждающее чтение) ввода
в операционной системе позволяет получать выигрыш при "близком"
расположении читаемых данных. То есть, если файл читается
последовательно и небольшими кусками, то количество обращений к диску
уменьшается за счёт кэширования данных в памяти. А разнесение данных
по фрагментам ли, по не фрагментированному файлу ли, снижает
эффективность буферизации. Если исходить из того что большинство
программ и пишут, и читают куски данных последовательно, то несложно
доказать, что дефрагментация файлов выгодна. Однако, можно исходить из
другого предположения, что программы в основном читают не
последовательно, а прыгают по файлу вперёд-назад. Например, при работе
с базой данных такое вполне может происходить. Не знаю точных оценок,
а собственные представления и опыт программирования говорят в пользу
первого варианта. Конечно, в статистическом смысле, а не в смысле
общего закона.

Гораздо более туманна для меня картина с записью. Затуманивается она
журнальными файловыми системами вроде NTFS, где сам факт записи
сопровождается записью в журнал. А поскольку журнал лежит явно не
рядом с файлом, то на головки винчестера ложится дополнительная
нагрузка. Другой затуманивающий фактор - наличие на хороших
винчестерах аппаратного кэша. Его размер (2 - 8 Мб) не внушает особого
оптимизма на существенное повышение эффективности чтения, а вот на
запись может влиять.

Мне кажется, наличие дефрагментаторов в операционной системе и наличие
на рынке коммерческих дефрагментаторов косвенно говорит о
востребованности этого класса программ. Если Ваши слова понимать узко,
то я, пожалуй, соглашусь, эффективность дефрагментации не есть факт на
конкретной отдельно взятой машине. Но оспаривать её эффективность в
общем случае мне представляется весьма рискованным.

Нет, за методиками и испытаниями - это не ко мне. Есть фирмы
производители, есть интернет ресурсы с тестами независимых экспертов,
например, компьютерные журналы, или тот же ixbt. Я имел в виду
контрпример файла, на котором чтения в случае фрагментации файла
эффективнее чем в дефрагментированном случае того же файла. Я могу
привести такой пример. Большой файл, который заведомо расположен на
нескольких дорожках. Файл состоит из логических кусков А, Бэ и Цэ, где
А и Цэ сравнительно маленькие куски в начале и конце файла
соответственно, а Бэ - большой кусок между ними. Если программа должна
прочитать только А и Цэ, то на дефрагментированном файле головка
винчестера должна перепрыгнуть несколько дорожек. Можно представить
себе, что фрагменты файла располагаются на диске не последовательно, а
в порядке А, Цэ, Бэ. Тогда чтение явно будет более эффективным на этом
фрагментированном варианте.

Пример-то я придумал, но тут возникает вопрос: насколько вероятна
такая ситуация? Комбинаторно совершенно ясно, что таких случаев
ничтожно мало. Но это если считать расположение фрагментов совершенно
случайным. На деле же и программы и операционная система делают эту
зависимость не очень-то случайной, так что, не берусь математически
рассчитать вероятность и размер выигрыша в эффективности. На уровне
понимания, мне представляется, что дефрагментация файлов весьма
выгодна на большинстве компьютеров.

Есть ещё один аспект, касающийся эффективности виртуальной памяти. Это
её размещение. Достаточно очевидно, что размещение файла подкачки на
другом физическом диске может быть очень выгодно. Виндоуз и без того
всё время дёргает свой системный диск, так что если он будет дёргать
два диска, то головкам винчестера несколько полегчает. Конечно, это
при том условии, что диск с файлом подкачки не используется
каким-нибудь шустрым приложением.

Небезразличен файл подкачки и к физическому расположению на диске.
Давно я не мерил характеристики винчестеров, но лет 7 назад, ещё на
дисках меньше 10 гб, я с изумлением смотрел на скоростные
характеристики первых и последних цилиндров. На каком-то максторе
разница в скорости достигала четырёх раз, то есть, если файл лежал в
начале диска, он читался в четыре раза быстрее, чем он же, но в конце
диска. Думаю, что на современных винчестерах эта разница не так
драматична, но сильно подозреваю, что она таки имеет место быть. А это
значит, что размещение самых часто используемых файлов в начале диска
увеличивает среднюю скорость работы компьютера. Помнится, в
нортоновском СпидДиске можно было указывать какие файлы ставить
вперёд, и по умолчанию первым среди таких файлов был файл подкачки.

Другое дело, что дефрагментация сама по себе чрезвычайно тяжёлый для
винчестера процесс потому, что при ней головки диска всё время скачут
вперёд-назад. Получается диалектическая картина: чтобы облегчить жизнь
винчестеру, и немного поднять производительность всей системы, нужно
запускать тяжёлую для винчестера процедуру. Отсюда следует, что нельзя
чрезмерно увлекаться дефрагментацией. Я бы сказал, что её надо
проводить один раз в один или два месяца. Важно понимать, что если
большие файлы вроде музыки, фильмов, или того же фиксированного
размера файла подкачки один раз дефрагментировать, то в следующие разы
они уже останутся дефрагментированными.

Кстати сказать, во встроенных в виндоуз дефрагментаторах меня всегда
изумляла их тенденция перекладывать нефрагментированный файл
по-своему. Даже в экс-пи и в сервере 2003 встроенный дефрагментатор не
делает всего, чего хотелось бы. Поэтому, имеет смысл присмотреться к
продуктам независимых производителей. В современных дефрагментаторах
(например в диск-киппере и в ашампуне) есть режим дефрагментации на
лету, то есть дефрагментатор работает не сессиями по запуску
пользователем, а работает всё время, перехватывая запись, и
минимизируя фрагментацию. Соответственно, один раз поставив и настроив
эту фичу про дефрагментацию можно вообще забыть.

--
С наилучшими пожеланиями
Владимир Лукьянов
Москва
mailto:lvu20***@y*****.ru

Hello Владимир Лукьянов, 14-Nov-2005 13:12 you wrote:

[skip]

Следует также учесть, что, даже если программа читает данные из файла
последовательно, то в мультизадачной ОС (каковой всё же является винда)
могут одновременно работать две такие программы, и одновременно делать
запросы на чтение. Тогда чтение данных с винта будет отнюдь не
последовательное, а наоборот, головка будет прыгать туда-сюда.

[skip]

Я думаю, на чтение он тоже очень влияет. В сети (т.е. в интернете)
проводились тесты, где замерялась скорость работы винтов одного объёма, но с
разным кэшем (2 и 8 МБ). Больший кэш даёт прирост около 5-15%. Конечно, у
меня есть претензии к этим тестам, ибо там не всё так однозначно, но всё же,
результат есть. Всё дело в алгоритме, по которому этот самый кэш работает.

:-))))
Другое дело, из-за чего возникает эта востребованность. По аналогии: есть
бесплатный линух, и есть винда, так во всём мире винда пока востребована
больше, хотя за неё надо платить (разумеется, я рассматриваю только
лицензионные копии). Конечно, я не хочу развязывать священную войну по
поводу того, какая операционка лучше, я просто привёл это для примера. Т.е.
востребованность дефрагментаторов может быть вызвана тем, что пользователю
сказали, что он нужен и полезен, вот он и пользуется. А нужен ли он в
большинстве случаев - не знаю...

Самое главное - это что понимать под общим случаем. К тому же я и не пытаюсь
оспаривать голословно. Надо либо смотреть тесты, либо проводить такое
тестирование самому.

Всё верно, и это вытекает из принципов физического размещения информации на
блинах (читай: дисках). На диске информация хранится на круговых
дорожках. Длина дорожки разная - у внешнего края диска она длиннее, а у
внутреннего - короче. Скорость вращения диска - постоянна. Поэтому сектор,
записанный на внешней дорожке, получается длиннее, чем на внутренней - так
обстоит дело в обычных флоппи-дисках. При этом ясно, что происходит
бесполезная потеря места, ибо на внешней дорожке линейная плотность записи
получается существенно меньше, чем на внутренней.

На CD-дисках применили такой подход. Там линейная плотность записи
постоянна, достигается это изменением скорости вращения диска.

На винчестерах угловая скорость постоянна, но изменяется плотность записи:
на внешней дорожке располагается больше секторов, чем на внутренней. Но,
т.к. угловая скорость, т.е. скорость вращения диска, постоянна, то скорость
считывания информации с внешней дорожки идёт быстрее, чем с внутренней. Даже
параметр такой был: write precompensation, который обозначал цилиндр,
начиная с которого на дорожку приходилось большее количество секторов. В
современных винчестерах несколько таких зон. В каждой зоне количество
секторов на дорожку одинаково. Поэтому можно построить график скорости
считывания с винчестера в зависимости от номера цилиндра, и на этом графике
будут ступеньки, точнее, "лестница" - при переходе к следующей зоне скорость
скачком падает. Это наблюдается на реальных тестах.

Совершенно верно.

Тут я с вами не соглашусь. Если винчестер сдохнет из-за того, что на нём
провели дефрагментацию, то туда ему и дорога. Это, разумеется, ни в коей
мере не относится к данным, их всегда жалко :-), но винчестер должен быть
надёжным. Помнится, когда вышла вин2000, то на форумах стали появляться
сообщения, что, мол, "поставил 2000, и через некоторое время сдох винч".
Просто 2000-я более интенсивно испоользовала винчестер, он работал в более
тяжёлых условиях и не выдерживал и умирал.

Современные винчестеры должны выдерживать такую нагрузку. Ещё один фактор -
при интенсивной работе винч может сильно нагреваться, и именно из-за этого
выходить из строя. Поэтому во время дефрагментации желательно смотреть на
его температуру.

А как сказывается на скорости работы такой вот перехват?

Здравствуйте, Егор,

Это, по-моему, должно хорошо сглаживаться буферизацией чтения самой ОС.

но с

у

же,

Ага, понял. я ожидал, что результат должен быть хуже. 10 процентов -
это много.

Вы привели хороший пример. По многим объективным критериям Линукс
наверняка обойдёт винды. Вы, судя по вашему "пока" считаете, что народ
глуп, и не понимает своего счастья в Линуксе, что нехороший Билл Гейтс
обманывает доверчивых наивных пользователей. Я этой точки зрения не
разделяю. Мне кажется, в обозримом будущем Линукс сможет потеснить
винды только при использовании административного ресурса, когда
государство навяжет его бюджетникам. По-моему на востребованность
объективные достоинства влияют, но не определяющим образом. Я могу
привести такой пример: Моцарт и Пугачёва. Можно бесконечно доказывать,
что музыка Моцарта лучше, а востребованней будет Пугачёва. А ведь тут
вопрос ещё и в деньгах. Люди вот уже лет 10 платят за дефрагментаторы,
и почему-то упорно игнорируют тот же бесплатный Линукс. И я не считаю,
что это похоже на лохотрон. Но, это, пожалуй, выходит за рамки данного
обсуждения. Остановимся, на том, что Вы ни считаете востребованность
аргументом, а я считаю.

Вообще, мне кажется наше обсуждение зашло в тупик. Мои аргументы и
рассуждения не убеждают Вас, Ваши сомнения Вы ничем не подкрепляете. Я
думаю, нет смысла в дальнейшей дискуссии о полезности или вредности
дефрагментации файлов вообще, и и файла подкачки в частности. Каждый
имеет право на свою точку зрения.

Вы именно голословно и оспариваете. То есть, не приводите никаких
доказательств, ни даже рассуждений, оспаривая чужую точку зрения.
Откровенно говоря, я так и не понял, что же, собственно, Вы имеете
против дефрагментации, кроме изначального неприятия её. Может быть, Вы
просто больше доверяете мнению тех людей, на чью точку зрения
ссылались. Но Вы-то их знаете и доверяете им, а мы не знаем.

Я вижу и третий путь: довериться мнению других. Я даже не хочу
перечислять сколько решений мы на самом деле принимаем по этому
принципу. Ведь не станете же Вы настаивать на тестировании или
проверке результатов сторонних тестирований для каждой программы,
которую мы используем. По-моему, именно этот механизм решений лежит в
подоплёке этой рассылки. Каждый сам мог бы выяснить все свои вопросы,
но спросить других - это экономит время. А уж кому из ответивших
доверять - сие есть дело личных предпочтений.

Понимаете, Егор, ведь у любого винчестера есть определённый ресурс
работы. Вопрос заключается вот в чём: дефрагментация призвана
уменьшить нагрузку на винчестер, с тем, чтобы при том же ресурсе
увеличить срок жизни винчестера. Но поскольку сама дефрагментация -
операция и долгая и тяжёлая, то её чрезмерно частое использование
приведёт к тому, что заметная доля ресурса работы винчестера будет
затрачена на неё. Как крайность, можно весь ресурс потратить на якобы
продление жизни винчестера. Вывод - не надо злоупотреблять
дефрагментацией. С чем Вы тут не согласны я не понимаю. Откуда и зачем
выплыл тезис о том что "винчестер сдохнет из-за того, что на нём
провели дефрагментацию" я тоже не понимаю.

Я о таких программах только читал, а сам не пользовался. Мне кажется,
что из-за колоссальной разницы между скоростью обработки информации в
оперативной памяти и скоростью дисковых операций вполне можно ожидать
высокой эффективности подобной технологии, при этом, значимо вероятна
большая прожорливость в отношении оперативной памяти. То есть,
наверное, имеет смысл пробовать такие программы на машинах с памятью
от 1 гб и больше. Думаю, что торможение не должно быть заметным, иначе
программа просто не окупится в рыночном смысле.

--
С наилучшими пожеланиями
Владимир Лукьянов
Москва
mailto:lvu20***@y*****.ru

Hello Smirnov Sergey, 28-Oct-2005 00:01 you wrote:

Да.

Да.

А разве программа, с помощью которой вы создаёте образ, автоматически не
исключает эти файлы из образа?

На самом деле, "правильная" прога для создания образа запоминает место, где
лежит файл подкачки, и его конфигурацию, а потом, при восстановлении из
образа, просто воссоздаёт его на том же месте.