Я хочу оптимизировать размер файла подкачки под свои реальные нужды. И я хочу следовать формуле, предложенной Марком Руссиновичем:Минимальное значение должно быть равно пиковому объему выделенной памяти за вычетом физического объема оперативной памяти, а максимальное значение должно быть вдвое больше.
Чтобы быть уверенным, что я все делаю правильно, я хотел бы прояснить следующее:
1) Является ли эта цифра, выделенная красным, той пиковой ставкой, о которой говорил г-н Руссинович?
На экране находится окно «Информация о системе»Обозреватель процессов
2)В Панели управления > Система написано, что мойУстановленная оперативная память составляет 4 ГБ, из которых доступно только 2,45 ГБ.. И, очевидно, в диспетчере задач мой общий объем физической памяти также составляет 2509 МБ. Это потому, что моя ОС 32-битная. Итак,правильно ли я понимаю, что именно 2509 (а не 4 ГБ) — это число, которое мне следует использовать для расчета размера файла подкачки?
Я знаю, что это может показаться глупым вопросом, но, как я уже сказал, я хочу убедиться, что делаю все правильно.
Большое спасибо.
решение1
Вы, без сомнения, имеете в виду«Расширяя границы Windows: виртуальная память»Марк Руссинович.
- Да, это тот самый номер.
- Да, у вас доступно всего 2,5 ГБ оперативной памяти (приблизительно — здесь нет необходимости в излишней точности).
Однако... вы пишете о "правильном выполнении". Я должен отметить, что статья Марка посвящена "расширению границ", и эта формула дает вамабсолютный минимумдля размера файла подкачки. Если вы хотите, чтобы ваша система работала хорошо, вам не нужно «выходить за рамки».
В этой статье нет рекомендаций, которые бы говорили, что выдолженсделайте настройки такими маленькими. Только если вы действительно этого хотите, то можете обойтись без этого. (Предполагая, что вам никогда не понадобится больше выделенной памяти.)
(И вам может понадобиться больше. Помните, что этот «пик», который вы здесь увидели, — это всего лишь пик за время работы Process Explorer. Он имеет смысл только в том случае, если в это время вы запустите максимальную рабочую нагрузку приложения. Это не просто означает запуск всех приложений, которые, как вы думаете, вы когда-либо будете запускать одновременно. Вам также нужно заставить каждое приложение использовать максимальный объем частной памяти («выделенной» памяти), который вы когда-либо запросите. Это сложная задача для настройки и тестирования. И кто скажет, что вы никогда не добавите еще одно приложение к своей типичной рабочей нагрузке? Поэтому информация, которую вы получаете с помощью инструментов мониторинга, не дает гарантии, что вам никогда не понадобится больше.)
Обратите внимание, что если вы снова столкнетесь с этим пиком и файл подкачки будет установлен на минимум, который вы вычислили таким образом, в ОЗУ не останется места для ОЗУ, используемого отображенными файлами, такими как файлы кода, например exe и dll. (Это связано с тем, что количество «зафиксированной» виртуальной памяти не включает кодовые страницы или другие страницы, поддерживаемые отображенными файлами.) Поскольку для выполнения код должен находиться в ОЗУ, это является проблемой.
Хорошо, поскольку вы включаете расширение файла подкачки, это не "критическая" проблема. Но это определенно ударит по производительности.
Поэтому, если только вы не пытаетесь по каким-то академическим причинам продемонстрировать абсолютный минимальный размер файла подкачки, который не приведет к сбоям приложения, независимо от проблем с производительностью, я бы не стал делать этого таким образом. (Я не могу придумать практической причины для этого.)
Если вы действительно хотите сократить все до минимума,практичныйминимум, т. е. без ограничения ОЗУ, доступного для кода, просто установите минимальный размер файла подкачки на ваш наблюдаемый максимальный коммит-сбор. Это означает, что ОЗУ все еще будет доступно для кода, даже если приложения и ОС создали столько выделенной памяти (и ссылались на нее всю).
Нет смысла ограничивать максимальный размер только в 2 раза больше минимального, если только вас не очень беспокоит использование дискового пространства.
Видите ли, нет ничего плохого (кроме использования дискового пространства), если файл подкачки будет больше, чем когда-либо понадобится системе. В частности, больший файл подкачки, чем необходимо, не будет «привлекать» больше подкачки. И нет никакого преимущества в том, чтобы сделать его едва достаточно большим (опять же, кроме использования дискового пространства). Так зачем беспокоиться? т. е. вы не «оптимизируете» ничего, кроме дискового пространства, занимаемого этим упражнением.
Учитывая, что превышение лимита фиксации данных может привести к сбоям приложения (и, следовательно, потере данных), а в редких случаях даже к сбоям системы, я бы не был так уж заинтересован в том, чтобы сделать файл подкачки как можно меньше.
С другой стороны, если системе приходится много писать в файл подкачки (а в системе Windows 7 с ОЗУ всего 2,5 ГБ, я полагаю, так и будет), то наличие файла подкачки, который значительно больше, чем система когда-либо будет использовать, ускорит работу. Почему? Потому что алгоритм распределения пространства, используемый для файла подкачки, может быть намного быстрее, если свободного места много.
По этой причине мне хотелось бы, чтобы счетчик Pagefile %usage в PerfMon оставался ниже 25 процентов.