Следует ли мне отключить кеширование записи на моей виртуальной машине Windows 2008?

Когда приложение Windows записывает данные на диск, эти данные сначала записываются в память хоста.

«Обычный» запрос на запись возвращается сразу после того, как данные оказываются в памяти, и создается запись в очереди, указывающая, что эти данные нуждаются в сбросе в постоянное хранилище. Механизм под названием Ленивый писатель гарантирует, что эта очередь обрабатывается периодически (по умолчанию 1/8-я очередь сбрасывается ленивым писателем каждую секунду). Это механизм, который вы отключаете, снимая флажок «включить кэширование записи на диск» - каждый запрос записи должен ждать, пока он не будет подтвержден как «записанный» устройством хранения, прежде чем он вернется.

Приложения с особыми требованиями к целостности данных (базы данных, драйверы файловой системы) действительно имеют варианты более интеллектуального подхода к кэшированию. Для записи, требующей немедленного сохранения (журнал NTFS, журналы транзакций базы данных) FILE_FLAG_WRITE_THROUGH можно указать с помощью записи. В этом случае вызов записи не вернется, пока данные не будут фактически сохранены в постоянном хранилище. Если вы не активируете флажок «Включить повышенную производительность», который заставляет диспетчер кеширования игнорировать FILE_FLAG_WRITE_THROUGH, немедленно верните вызов и передайте его ленивому писателю, как и любую другую "нормальную" запись.

Поскольку у вас есть два дополнительных уровня кеширования¹ (номер один - это ваша операционная система хоста, на которой запущен гипервизор KVM, номер два - ваш контроллер хранилища с BBWC / FBWC), все становится сложнее. Каждый из этих уровней предоставит вам одинаковые возможности выбора, и поскольку каждый запрос на запись должен проходить через все из них, самое слабое звено цепочки будет эффективно для целостности ваших данных.

Разработчики приложений в целом делать знать и понимать эффекты кэширования и записи через вызовы. Итак, действительно важные части данных записываются с помощью FILE_FLAG_WRITE_THROUGH в то время как все, что не записано с этим флагом, можно считать безопасным для кэширования в энергозависимой памяти. Проблема начинается, когда FILE_FLAG_WRITE_THROUGH игнорируется на любом уровне, и данные фактически теряются в случае отключения электроэнергии или программного сбоя. Такие условия обычно приводят к повреждению файловых систем и журналов транзакций, что приводит к непредсказуемым результатам и, возможно, даже к необходимости восстановления из резервной копии, поэтому этого, очевидно, следует избегать. Если кэш вашего контроллера хранилища имеет "резервное питание" или "флэш-память", его можно в определенной степени считать "энергонезависимым", поэтому обычно считается безопасным использовать его кэш обратной записи даже для сквозной записи. Запросы².

Итог: как правило, безопасно «Включить кэширование записи на диск» если вы не имеете дело с неработающими приложениями, которые не используют FILE_FLAG_WRITE_THROUGH но нужно, чтобы каждая запись была настойчивой. Отключение этого не повредит в вашем случае, так как большинство вызовов должно обрабатываться кешем записи контроллера хранилища и возвращаться почти немедленно (но у вас, вероятно, будут дополнительные накладные расходы из-за этого, а размер кеша будет ограничен DRAM контроллера). Вы никогда должен «Включить повышенную производительность» или "Отключить очистку буфера кэша записи Windows на устройстве" в системе, где вы цените время безотказной работы или требуете целостности данных.

Дальнейшее чтение:

Библиотека MSDN - кэширование файлов Windows
Блог Smallvoid - описание кеша жесткого диска

¹ на самом деле существует еще один уровень кэширования на самом жестком диске, но в большинстве случаев запрос сквозной записи выполняется независимо от настроек кеша диска. Однако некоторые флеш-накопители являются заметными (читаемыми: сломанными) исключениями из этого правила - с флеш-твердотельными накопителями записи обычно кэшируются и сообщаются как записанные немедленно, но фиксируются только в энергозависимом кэше - не только по соображениям производительности, но и для объединения операций записи и продления срока службы. время вспышки ячеек. «Корпоративные» версии флэш-накопителей SSD обычно имеют конденсаторы, обеспечивающие достаточную мощность накопителя для сброса кэш-памяти на ячейки флэш-памяти, в «потребительских» версиях часто нет - остерегайтесь этого.

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

Вы можете безопасно отключить очистку буфера (предварительное кэширование записи) - это ЗАПИСЬ В КЭШ .. ЕСЛИ ... и ТОЛЬКО ЕСЛИ у вас есть ТРИ вещи:

1. Сам компьютер / сервер имеет резервную копию ИБП. Это предотвращает внезапную потерю питания, оставляющую незаписанные или частично записанные данные. Допустим, эта ситуация может произойти без кеширования записи вообще, если питание отключится ТОЛЬКО КАК ДАННЫЕ БЫЛИ ЗАПИСЫВАЮТСЯ ... но шансы редки. ИБП поддерживает работу компьютера

   Однако это НЕ защищает вас от жестких блокировок, BSOD, которые не могут полностью сбросить кеш на диск (только около 50% BSOD могут сбрасывать кеш), внезапных перезагрузок (что-то с ОС или оборудованием выходит из строя, и система просто мгновенно перезагружается) ... и, наконец, МГНОВЕННОЕ ВЫКЛЮЧЕНИЕ ... это редко, но обычно вызвано перегревом процессора или процессора или чипсета, и BIOS просто отключит питание, чтобы предотвратить повреждение

2. Вы можете помочь в борьбе с этим, ЕСЛИ жесткие диски САМИ имеют собственный резервный источник питания. Любые кэшированные данные в Windows будут потеряны, но кеш на диске САМ будет записан.

   В современных версиях Windows Vista, 7, 8.x и т. Д. У вас есть возможность ТОЛЬКО ЧТЕНИЕ, ЗАПИСЬ, ЗАПИСЬ (дополнительно). Если у вас есть RAID-контроллер, вы можете управлять кешем контроллера и самого HD, как правило, как OFF, READ ONLY, WRITE BACK, WRITE THROUGH ... однако кеш обратной записи контроллера / hd НЕ будет включаться, если WINDOWS не имеет того же настройки включены.

3. РЕЗЕРВНОЕ КОПИРОВАНИЕ вашего компьютера. Если вы делаете еженедельное или ежемесячное ПОЛНОЕ резервное копирование с НОЧНЫМ инкрементным, а затем специальное, быстрое, инкрементное резервное копирование каждые 4 часа критически важных данных (это резервное копирование должно выполняться не дольше 10 минут, чтобы не влиять на производительность). Если вы сделаете 1, 2 и 3, я бы сказал РАЗРЕШИТЬ ЗАПИСЬ .... ОСОБЕННО НА ДОМОМ ПК ...

   Что касается бизнеса ... Я бы придерживался ЗАПИСИ ЧЕРЕЗ ... это почти не даст преимуществ обратной записи (обратная запись ускоряет запись до 5 раз быстрее, поскольку она не только сообщает ОС / программам, что данные имеют уже был записан. Кэш записывает данные на диск самым ОПТИМАЛЬНЫМ / БЫСТРЫМ способом, чтобы предотвратить перебивание головки чтения / записи и т. д.). Так что обратная запись может делать УДИВИТЕЛЬНО быстрые вещи ... но для бизнеса лучше всего использовать RAID-массив ... ПРОСТОЙ или сложный (вложенный)

Вы можете перейти на RAID 0 для АБСОЛЮТНОЙ скорости, но тогда, если возникнет проблема, у вас будет время простоя и вы должны восстановить из резервной копии ... вы можете перейти на RAID 5 ... и даже если 1 диск НЕПРАВИЛЬНО ОТКАЗАН, все будет работать нормально (но медленнее ), пока вы не замените диск (большинство серверов горячие замена-able .. и многие домашние рейдовые системы, пусть у вас будет запасной диск - если вы выберете эту опцию, которая может быть добавлена ​​мгновенно в случае сбоя)

Raid 5 ОЧЕНЬ быстр при чтении ... но снижает производительность при записи, потому что он должен записывать биты CRC (полосы) ...

Другие варианты - ВНУТРЕННИЕ рейды ..

Например ... вы можете взять 3 диска и сделать их RAID 0 ... затем взять еще 2 набора по 3 диска и сделать их raid 0 ... затем вы берете 3 тома raid 0 и объединяете их в 1 том raid 5. Это позволит ОДНОМУ массиву raid 0 выйти из строя, и все это продолжит работать .. у вас могут быть все 3 диска в одном массиве r0, и все в порядке ... НО если 1 диск в массиве A выйдет из строя одновременно с диском в массив B .... он ВСЕ пропал .. И это восстановление из резервной копии ...

Вы также можете комбинировать ЗЕРКАЛЬНОЕ ЗЕРКАЛО и рейд 0, где вы нападаете 0 на 2-6 дисков, например ... затем создайте другой диск для рейда 0, чтобы соответствовать ... затем ЗЕРКАЛЬНО их. Это все еще потребует небольшого количества попаданий записи для зеркалирования, но зеркалирование фактически увеличивает скорость чтения, поскольку оно захватывает фрагмент с диска / массива A и захватывает следующий фрагмент с диска / массива B в ТО ЖЕ время.

Мой лучший совет ANYTIME @ HOME:

ЗЕРКАЛЬНО ОТКРОЙТЕ свой C: (диск Windows) ... при условии, что Windows находится на C ... даже если это SSD ... Это не поможет коррупции ... резервные копии для этого ... но это СБРОСИТ вам МНОГО времени простоя при сбое оборудования

ЗАТЕМ сделайте себе диск D ... сделайте ЭТО своим ОГРОМНЫМ, БЫСТРЫМ массивом электростанции ... и делайте это так, как ВЫ этого хотите ... мой диск D: представляет собой массив Raid 0 из ПЯТИ 4 ТБ жестких дисков ... и да, если ЛЮБОЙ сбой .. ВСЕ данные потеряны ... но я выполняю полное резервное копирование раз в месяц и инкрементное резервное копирование ежедневно и специальное каждые 4 часа в raid box usb 3.0, который может вместить до 6 дисков по 4 ТБ (и это то, что у меня есть в нем и это RAID 5) .. НЕ РЕКОМЕНДУЮ D быть SSDS! HYBRID HDDSD в порядке .. но 1) вы не найдете SSD на 4 ТБ .. и если вы это сделаете, они будут стоить УДАЧИ. Используйте RAIDING @ SATA 3 level MINIMAL .. и вы можете получить жесткие диски быстрее, чем SSD.

Затем сделайте себе диск E: ... сделайте из него ОЧЕНЬ МАЛЕНЬКИЙ SSD ... не более 100-200 ГБ .. или что там меньше всего, что вы можете найти

Теперь почему все эти буквы дисков ... Я объясню:

C: зеркальное отображение, медленная запись, БЫСТРОЕ чтение .. используйте только для WINDOWS ... не устанавливайте НИЧЕГО на этот диск, если программа НЕ ТРЕБУЕТ ЭТОГО .. даже если вы устанавливаете программу, игру на D, она часто ставит на C, даже если вы этого не хотите. Дело в том, что вы не хотите, чтобы C: был перегружен окнами загрузки, а затем загружены все службы ПЛЮС предварительная загрузка всего материала, который требуется вашим программам, ПЛЮС ПРЕДВАРИТЕЛЬНОЕ Кэширование всего этого из C: / Вы можете ЛЕГКО получить систему, которая заставляет вас ждать 5 -20 МИНУТ на остановку взбивания до того, как вы сможете его использовать. C: ДОЛЖЕН быть SSD размером около 300 ГБ .. это поможет ускорить загрузку. Когда все установлено на D :, при запуске Windows программы, которые должны загружать, будут поступать из D: vs C: и возьмут на себя загрузку C: ... также superfetch запускается примерно через 15 секунд после появления экрана входа в систему. ... и вы НЕ хотите, чтобы все это сбивало C, даже если это SSd ... вы хотите, чтобы он ТОЛЬКО загружал файлы Windows и позволял ему отбивать D, потому что D: должно быть ПО МЕНЬШЕ 3 или более дисков в конфигурации RAID 0 или 5. Таким образом, вы можете сразу же войти в Windows, и окна будут работать мгновенно.

Если у вас МНОГО ОЗУ (16-32 ГБ) И у вас есть largediskcache в реестре, Windows может ЛЕГКО занять до ЧАСА для предварительного кэширования вещей, НО он будет фоновым этим приоритетом, если вы начнете использовать ПК

D: Диск ... поместите все сюда ... это ваш основной репозиторий ... пусть Windows перемещает папки с документами, изображениями, музыкой, контактами и т.д. в папки на D: Со всем вашим материалом на D: ваши программы будут загружаться БЫСТРО и читать и напиши БЫСТРО

E: в основном только для файла подкачки ... но вы также можете настроить его, если у вас есть Windows 8 для диска для резервного копирования истории файлов ... таким образом у вас есть регулярные резервные копии и история файлов Windows, которые могут мгновенно восстановить поврежденные, случайно удаленный файл и т. д.

Файлы подкачки ... вы хотите по одному на КАЖДОМ диске ... почему? Windows использует несколько дисков подкачки, что-то вроде массива рейдов. Он будет использовать их для параллельного чтения / записи, И, если диск ЗАНЯТО, он ИСКЛЮЧИТ этот диск из операций подкачки, пока его использование не прекратится.

Для диска C: я рекомендую ТОЛЬКО минимум ... это зависит от ОЗУ (и я предполагаю, что это 64-битная ОС, так как все должны быть на 64-битных окнах сейчас в дни) .... для систем с 8 ГБ минимальный размер составляет 400 МБ, 16 ГБ = 800 МБ, 32 ГБ = 1,6 ГБ .. Причина в том, что минимальный размер ТРЕБУЕТСЯ для небольшого / мини-дампа в случае BSOD и позволяет Windows записывать файл, который может помочь объяснить, что пошло не так. Вы МОЖЕТЕ НЕ использовать файл подкачки ВООБЩЕ на C: для повышения производительности системного диска. Это совершенно нормально, если вы не заботитесь об отчетах BSOD - особенно если вы никогда или РЕДКО BSOD

D: будет БОЛЬШОЙ диск и БЫСТРЫЙ ... и он может обрабатывать страницы, даже когда вы его используете. Однако, как только активность диска достигнет 100%, он будет уменьшаться с помощью файла подкачки ... но этот файл подкачки должен быть больше похож на 8 ГБ

E: сделайте 8 ГБ

Это даст вам 16 ГБ пространства для файла подкачки, и он может использовать D&E параллельно. если D занят, то он будет просто использовать E: и E: будет БЫСТРО, поскольку это SSD ... даже если E - HDD или HDDSD, я все же рекомендую эту настройку.

И последнее, о чем следует подумать ... так как большинство ваших действий будет использовать D: .., вы, вероятно, можете поместить файл подкачки хорошего размера на C:, поскольку это не замедлит вас, если вы используете программу INTENSE на D:

8,8,8 - это немного избыточный размер, независимо от того, есть ли у вас 4.8.12.16.32.64GB оперативной памяти. Я бы выбрал 4,4,4 или 5.5.5 для файла подкачки 12 или 15 ГБ.

Многие люди скажут, что если у вас 16+ ГБ оперативной памяти, НЕ использовать файл подкачки - НЕПРАВИЛЬНО!

Вы можете настроить окна таким образом, но он БУДЕТ ИГНОРИРОВАТЬ вас и настраивать временные файлы подкачки на всех HD без вашего ведома. Многие программы ЖЕСТКО ЗАПРЕЩЕНЫ для замены кода простоя в файл подкачки ... ни один файл подкачки не нарушает этот код. Windows РАЗРАБОТАНА для помещения кода простоя в систему подкачки, чтобы оставить больше места для кэша жесткого диска. Таким образом, на самом деле нет НИКАКОГО способа заставить весь код таранить, отключив файлы подкачки.

Фактически ИСПОЛЬЗУЯ файлы подкачки ... вы ускоряете свою систему

Другой вариант - READY boost ... многие люди возражают против этого ... но я большой сторонник ... он будет работать ТОЛЬКО на жестких дисках или HDDSD ... он НЕ будет работать на SSD-дисках ... нет смысла как SSD это НАМНОГО быстрее, чем флешка ....

Но ХОРОШИЙ / высококачественный THumb-накопитель USB 3.0 емкостью 32-64 ГБ может ЧИТАТЬ / ЗАПИСАТЬ со скоростью 150-200 МБ / сек .... обычно требуется МНОГО SATA 3 HDDSD в рейде 0 для достижения такого уровня скорости.

Я использую его ... и он используется только для моего диска D .. это 64 ГБ, вы должны отформатировать его в NTFS, в противном случае он ограничен 4 ГБ .. и 64 ГБ - это самый большой диск RB ... Как только я активирую это моя система тратит 2-3 ЧАСА на ее загрузку ... с более медленными устройствами Windows помещает только небольшие, быстро читаемые файлы ... с диском FAST RB, Windows 8.x сохранит на нем ВСЕ файлы .. как в файлах 1,2,3,5 и т.д. ГБ. Мой рейд-массив может ЧИТАТЬ со скоростью 175 МБ / с и записывать со скоростью 150 МБ, мой диск RB - 200/200 ... поэтому Windows ЗАГРУЖАЕТ его с 64 ГБ данных.

У меня 32 ГБ оперативной памяти ... поэтому Windows помещает самые требовательные файлы в кеш-память ... затем файлы с не таким высоким приоритетом (или если некоторые файлы продолжают выбрасываться из кеш-памяти) ... в случаях таким образом, Windows может поместить файл с высоким приоритетом в ОБЕИХ местах.

Люди говорят, что RB - это ОТХОДЫ в таких системах, как моя ... НЕПРАВИЛЬНО ... когда я меняю области в Dragon Age Inqusition БЕЗ диска RB, загрузка новой области занимает около 60 секунд (когда данные НЕ кэшируются в RAM). ... но если он уже на диске RB, но не в ОЗУ, он загружается через 30 секунд. В отличие от предыдущих версий Windows, Windows 8.x делает данные на диске RB НЕПРЕРЫВНЫМ, и ваш кеш будет сохраняться после выключения, перезагрузки, гибернации и сна. Однако, если Windows думает, что он был удален по какой-либо причине, он стирает его и начинает заново ....

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

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

Обычно следует учитывать две вещи:

1. Что рекомендует производитель вашего диска / контроллера?
2. Если вы доверяете источнику питания своего сервера, первый флажок подходит. Если вы полностью доверяете источнику питания вашего диска, второй флажок в порядке.

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