Khorsun Vlad пишет:
Странно это. При использовании -D ON (FILE_FLAG_NO_BUFFERING) кеш ФС
никак не должен забиваться данными, прочитанными nbackup'ом...
Правда он ещё и пишет сам бекап, и не использует FILE_FLAG_NO_BUFFERING,
независимо от -D... Но последовательная запись *нового* файла на моей
памяти ещё не приводила к его полному кешированию и забиванию кеша.
Справедливости ради я не знаю кто забивает файловый кеш. Ибо не вижу его
в разрезе процессов. Подозреваю что забивает его FB-процесс удаления данных.
Тоже intel raid matrix ?
Да.
Доступная физицеская память не забивается файловым кешем и
Очень хорошо, так и должно быть. Соответственно проблема или внутри
Win2008 R2 x64, или внутри какого-либо её драйвера (intel raid matrix ?)
А это не связано с битностью винды, и невозможностью в 32 адресовать
больше 3Гб, вроде бы это касается и файлового кэша?
Якобы в 64 битной винде 1 файловый кеш, а в 32 битной можество (VST?) но
с ограничением в 3Г для каждого. В крайнем случае так объяснили админы.
Это кстати подтверждают показатели того-же таскинфо на боевом сервере
Win2008 32бита не R2!!!
Там сейчас работает 91 FB-процесс но
RAM Usage 55%
File Cache 5%
Windows end programs 50%
При 16Г оперативки и отсутствии свопа.
Правда там никакой нбекап не запущен.
Не понято. Раньше nbackup грузил ядро на 100% и всё тормозило.
Теперь - "нбекап не грузит ядро на 100% и все по прежнему тормозит".
Тут нет описки ?
Под торммозами я имею ввиду очень низкий файловый I/O и длительность
создания бекапа (соизмерим с показателем на Win x64)
Да, должен заметить, что скорость чтения\записи с FILE_FLAG_NO_BUFFERING
может (и должна) быть в несколько раз меньше, чем через файловый кеш. Может
эти тормоза имеются в виду ? Так они вполне ожидаемы.
Я не увидел принцыпиальной разныцы в скорости создание бекапа с ключем
(-D ON) на разных операционках с соизмеримым железом (т.е. на одном и на
другом сервере мы не упираемся в потолок.) Хотя на x64 забивается вся
доступная память файловым кешем и загрузка ядра процессом nbackup
достигает 100%
Недостаточно места на диске.
А как смотрится размер дельтафайла ? Винда редко обновляет на диске
размер быстрорастущего файла и добиться от неё правды во время этого
процесса
не так просто.
Серией тестов проверено что удаление 100 млн записей приводит к созданию
дельтафайла в размере ~9Гб. Ты абсолютно прав что в некорых случая в
Фаре/проводнике я видел размер не корректируемый с показаниями таскинфо.
Размер этого файла контролируется мной с помощью таскнифо. В ряде
случаев перемещение по нему имеет линейный характер. + после отвала
этого процесса остался файл такого размера.
FB не придумал описание ошибки, его дала ОС.
Я понимаю что FB сложно отдать ошибку с текстом "Недостаточно места на
диске". И это мое утверждение выглядит как бред но...
База размером 56Гб, свободное место 70Гб. Размер дельты 9Гб.
Ладно, давай этот момент временно упустим. Если текущее состояние (с
ошибкой) не понадобиться, то я потом повторю тест ничего не меняя.
PS Кстати, на Win2008 R2 x64 - какой разрядности был FB и какие опции в
конфиге
были изменены ?
FB в обеих случаях 32битный. Опции изменены следующие
DefaultDbCachePages = 4096
TempCacheLimit = 268435456
OldSetClauseSemantics = 1
RelaxedAliasChecking = 1
Напомню это все на тестовых серверах. На боевом параметры кэшей немного
меньше, но он (боевой сервер) в этих тестах не участвует.
P.S. Чувствую нужно делать тестовый пример и рисовать картинки (диаграммы)
