"Viktor Belzetskiy" ...
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Г для каждого. В крайнем случае так
объяснили админы.
Это был бы очень большой маразм. Файловый кеш не может быть per-process,
иначе в нём нет никакого смысла и возникнет огромная пробема синхронизации
частных кешей. На своей W2K3 R2 x64 8GB я спокойно забиваю файловый кеш под
завязку используя 32-битный FB и большую БД. Так что админы пусть поищут другие
объяснения :) Может они virtual address space имели в виду ? И что такое VST ?
Это кстати подтверждают показатели того-же таскинфо на боевом сервере Win2008
32бита не R2!!!
Там сейчас работает 91 FB-процесс но
RAM Usage 55%
File Cache 5%
Windows end programs 50%
Я не знаю, что такое таскинфо, какие показатели он имеет в виду, и что
делает 91 FB-процесс (может select * from rdb$database ?) :)
Process Explorer более привычный для меня инструмент...
При 16Г оперативки и отсутствии свопа.
Что имеется в виду под "отсутствии свопа" ? Нет своп-файла или нет
своп-активности ?
Правда там никакой нбекап не запущен.
Не понято. Раньше nbackup грузил ядро на 100% и всё тормозило.
Теперь - "нбекап не грузит ядро на 100% и все по прежнему тормозит".
Тут нет описки ?
Под торммозами я имею ввиду очень низкий файловый I/O и длительность создания
бекапа (соизмерим с показателем на Win x64)
А можно исключить inter raid matrix из рассмотрения ? Для сравнения.
И, кстати, у него есть свои настройки кеширования дисков\массивов...
Да, должен заметить, что скорость чтения\записи с FILE_FLAG_NO_BUFFERING
может (и должна) быть в несколько раз меньше, чем через файловый кеш. Может
эти тормоза имеются в виду ? Так они вполне ожидаемы.
Я не увидел принцыпиальной разныцы в скорости создание бекапа с ключем (-D ON) на разных операционках с соизмеримым железом (т.е.
на одном и на другом сервере мы не упираемся в потолок.) Хотя на x64 забивается вся доступная память файловым кешем и загрузка
ядра процессом nbackup достигает 100%
Давай тут определимся : т.к. было выяснено, что загрузка именно *ядра ОС*,
то сам nbackup можно не "обвинять" в *загрузке* процессора - это делает
системный
обработчик, вызываемый nbackup'ом.
Недостаточно места на диске.
А как смотрится размер дельтафайла ? Винда редко обновляет на диске
размер быстрорастущего файла и добиться от неё правды во время этого
процесса
не так просто.
Серией тестов проверено что удаление 100 млн записей приводит к созданию дельтафайла в размере ~9Гб. Ты абсолютно прав что в
некорых случая в Фаре/проводнике я видел размер не корректируемый с показаниями таскинфо.
Обычно просмотр свойств файла в проводнике форсирует сброс кеша каталога
операционкой и обновление р-ра файла.
Размер этого файла контролируется мной с помощью таскнифо. В ряде случаев перемещение по нему имеет линейный характер. + после
отвала этого процесса остался файл такого размера.
Какое перемещение ? Что за таскинфо такое ? :)
FB не придумал описание ошибки, его дала ОС.
Я понимаю что FB сложно отдать ошибку с текстом "Недостаточно места на диске".
И это мое утверждение выглядит как бред но...
База размером 56Гб, свободное место 70Гб. Размер дельты 9Гб.
Ладно, давай этот момент временно упустим. Если текущее состояние (с ошибкой) не понадобиться, то я потом повторю тест ничего не
меняя.
Странно это. Или система выдаёт кривой код ошибки (маловероятно), или FB
выдаёт не совсем корректное сообщение (тоже верится слабо, но всё возможно)...
PS Кстати, на Win2008 R2 x64 - какой разрядности был FB и какие опции в
конфиге
были изменены ?
FB в обеих случаях 32битный. Опции изменены следующие
DefaultDbCachePages = 4096
TempCacheLimit = 268435456
OldSetClauseSemantics = 1
RelaxedAliasChecking = 1
Дело в том, что FB 2.5 пытается ограничить размер файлового кеша до 30% от
имеющегося размера RAM (см. FileSystemCacheSize). Но, если в системе установлено
более 4GB памяти, то 32-битный FB не сможет применить это ограничие. Или если у
процесса нет прав. Посему было бы интересно попробовать FB x64.
Напомню это все на тестовых серверах. На боевом параметры кэшей немного меньше,
но он (боевой сервер) в этих тестах не участвует.
P.S. Чувствую нужно делать тестовый пример и рисовать картинки (диаграммы)
Чем больше инф-ции, тем лучше ;)
--
Хорсун Влад
