У нас есть приложение, которое делает много регистрации. Среда, к которой мы подключаемся, - это SSD-накопители SLC, однако мы начинаем видеть некоторые сбои в этой области. Мы могли бы отключить регистрацию (у нас есть), иметь уровни журналирования (у нас есть), однако иногда инженер включает регистрацию, чтобы диагностировать ошибку и забывает отключить ее, что приводит к отказу SSD через некоторое время.

Глядя на код журнала, мы сохраняем запись журнала в очереди и каждые 5 секунд перебираем коллекцию и используем File.AppendAllText для записи строки в файл.

Согласно MSDN это пишет в файл, а затем закрывает его.

Какой режим лучше использовать для достижения той же функциональности, но для предотвращения (или уменьшения) повреждения SSD?

Было бы лучше открыть FileStream при запуске программного обеспечения, записать в поток во время использования и закрыть до завершения работы программного обеспечения? Как это облегчило бы ситуацию на уровне диска? Какие процессы задействованы и как это лучше, чем открывать файл и закрывать его немедленно. Использование FileStream «лучше», но перед внесением изменений мне нужно более конкретное обоснование.

Может быть, есть лучший способ, который мы не рассмотрели.

|источник

1 ответ1

1

ОК, я почти уверен, что у меня есть твой ответ.

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

Не глядя точно на то, как реализован AppendAllText , мы можем также предположить, что в лучшем случае на диск записываются только дополнительные данные плюс соответствующие метаданные (материал файловой системы).

Тысячи итераций вышеперечисленного за определенный период времени действительно разрушат SSD (типы MLC быстрее, чем SLC). Это связано с тем, что твердотельные накопители могут записывать в свое внутреннее хранилище только большие блоки.

пример

Возьмите 128 ГБ SSD с внутренним размером блока 512 КБ. Всего 262 144 блока.

Проще говоря, даже не считая метаданных (файловая система) записи, если вы откроете-закроете 262 144 маленьких файла, вы вызовете запись каждого блока на SSD. Сделайте это еще 1000-4000 раз (в зависимости от SSD), и вы в значительной степени убили его.

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

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

Возможные решения

  • Пишите в журнал реже, скажем каждые 60 секунд и / или ...

  • Откройте файл журнала в виде Stream , добавьте в цикл все, что хотите, а затем очистите / закройте поток. Этот подход означает, что файл открывается только один раз , записывается, а затем закрывается. .NET и ОС оптимизируют запись.

  • Используйте жесткий диск без SSD для регистрации. Если изменение кода регистрации невозможно, но вы можете указать путь регистрации, тогда это может быть лучшим вариантом. Даже жесткий диск USB будет хорошо! Пока это не SSD.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .