Re: Тормоза nbackup
Vlad Khorsun пишет: Это не совсем soft RAID, насколько я понимаю. Он всё же поддерживается чипсетом, но в какой степени - не вникал. В любом случае - это не то железо, на котором имеет смысл работать предприятию. Разработчику и\или тестеру - возможно, но не в бой. Это ТЕСТОВЫЙ сервер, рейд которого переконфигурирован в 0 !!! для обеспечения максимальной производительности дисковой подсистемы специально для экстремальных тестов Нбекап перед его использованием в боевом режиме. Под софтовым я имел ввиду рейд на южном мосту материнки с софтовой реализацией некоторых функций, например просчета контрольных сумм для Raid5. Тогда как аппаратный рейд это отдельный контролер со своим процом, кешпамятью, батарейкой и разными оптимизациями очереди запросов. Боевой сервер на котором все крутится 24-х ядерный HP ProLiant DL580 с P800 RAID котроллером, tpcc тесты которого когда-то здесь публиковались и обсуждались. Ну да ладно... Расклад user\kernel не смотрел ? Да, 99% кернел. Замечено что загрузка ядра нбекапом возвостает при росте файлового кеша и составляем практически 100% при забивании всей доступной памяти файловым кешем. Потому возникло подозрение что это связано с операционкой и я провел тест на немного другом оборудовании (Core 2 duo, 3.2ГГц, RAID0-4HDD) c 32-х битной Win2003. nbackup.exe -u sysdba -p masterkey -B 0 localhost:d:\test_db\retail_m_2010_2.fdb d:\test_db\retail_0_2.nbk С удалением в параллельном коннекте тех-же 100млн записей. При этом выяснилось следующее: Доступная физицеская память не забивается файловым кешем и соответственно нбекап не грузит ядро на 100% и все по прежнему тормозит. + получил удар по голове в виде == RASCHET3Thu Jan 13 17:52:08 2011 I/O error during WriteFile operation for file D:\TEST_DB\RETAIL_M_2010_2.FDB.delta Error while trying to write to file Недостаточно места на диске. RASCHET3Thu Jan 13 17:52:08 2011 Database: D:\TEST_DB\RETAIL_M_2010_2.FDB I/O error during WriteFile operation for file D:\TEST_DB\RETAIL_M_2010_2.FDB.delta Error while trying to write to file Недостаточно места на диске. internal Firebird consistency check (error during savepoint backout (290), file: exe.cpp line: 4129) RASCHET3Thu Jan 13 17:52:10 2011 I/O error during WriteFile operation for file D:\TEST_DB\RETAIL_M_2010_2.FDB.delta Error while trying to write to file Недостаточно места на диске. == Где-то в конце удаления данных ибо розмер дельтафайла 9гиг. При этом на диске с базой свободно 70Гб, на диске с IBTemp 260Гб. Это все естественно на V2.5.0.26074 CS. Гугль подсказал что на тему backout 290 что-то правилось или будет справлено, но в каких версиях пока не разобрался. А если взять xcopy, а не FAR ? Использовался FAR x64 с включенной функцией системного копирования. Но если нужно проверю и с xcopy.
Re: Тормоза nbackup
Dmitry Yemanov пишет: Оба процесса (фб и нбекап) читают базу через файловый кеш. Получается это у них неплохо вроде бы. Неплохо (в крайнем случае понятны показатели), если бы не теоретическая возможность получения вечного нбекап-процесса при постоянно появляющихся коннектах с обработкой большого количества данных. Но этот режим (с ключем -D OFF) ты мне подсказал и я его особо не тестировал на такую возможность Тест4 1. nbackup.exe -u sysdba -p masterkey -D ON -B 0 localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk 2. Удаление данных Эти два варианта делают одно и тоже, на винде у нбекапа режим direct_io по дефолту ON. НБекап читает файл БД напрямую с диска, фб-сервер - через кеш. А вот в этом случае у меня полное непонимание того что происходит. Из-за этого я и создал эту ветку. Процесс удаления закончился, больше никаких FB-процессов нет, а нбекап еле шевелится как по процу так и по диску. Загрузка на процентов 10 от возможной. Сложилось впечатление что он ждет монопольного доступа и как только он (монопольный доступ) появился хоть на секунду нагрузка увеличивается до предельно возможной и быстро завершается бекапирование независимо от того появляются в процессе этого дополнительные коннекты к FB и что они там делают. Вот ты говоришь НБекап читает файл БД напрямую с диска, хотя тупой тест с файловым копированием показал разницу в разы (где-то в 5 раз). Вот тут мне не понятно и хотелось бы все прояснить и протестировать до запуска Нбекапа в боевом режиме, тем более что в связи с запуском нового проекта ожидается рост базы до 500Гб до конца следующего года. А поскольку база работает в мифическом режиме 24/7 (с)Кузьменко и на сегоднешний день допускается остановка сервера на выходные раз на 2-4 месяца для проведения полного B/R c подменой базы и кучей гемора при согласовании этой даты, то работа нбекапа в первом варианте (с ключем -D OFF) меня пугает, т.к. я не могу гарантировать что при его начале не стартанет робот заливающий тех-же 100млн записей (ночью как правило еще висят 5-10 коннектов) и это все не успеет закончится до начала рабочего дня, когда в систему ломанется 100 юзеров и этот дельита-файл будет болтаться целый день, примет угрожающий размер и непонятно с какими тормозами и когда сбросится. Может я конечно возможные проблеммы преувеличиваю (на сегодняшний день их еще больше при существующей схеме бекапа), но пока у меня складывается такое впечатление. И существует страх (не только у меня) получения битой базы именно из-за работы нбекапа. Необходимость полного классического B/R я осознаю даже при использовании нбекапа, как минимум для теста. Спасибо вам с Владом за вникание в проблему(?) и попытки прояснения мне картины.
Re: Тормоза nbackup
Viktor Belzetskiy ... Расклад user\kernel не смотрел ? Да, 99% кернел. Замечено что загрузка ядра нбекапом возвостает при росте файлового кеша и составляем практически 100% при забивании всей доступной памяти файловым кешем. Странно это. При использовании -D ON (FILE_FLAG_NO_BUFFERING) кеш ФС никак не должен забиваться данными, прочитанными nbackup'ом... Правда он ещё и пишет сам бекап, и не использует FILE_FLAG_NO_BUFFERING, независимо от -D... Но последовательная запись *нового* файла на моей памяти ещё не приводила к его полному кешированию и забиванию кеша. Потому возникло подозрение что это связано с операционкой и я провел тест на немного другом оборудовании (Core 2 duo, 3.2ГГц, RAID0-4HDD) c 32-х битной Win2003. Тоже intel raid matrix ? nbackup.exe -u sysdba -p masterkey -B 0 localhost:d:\test_db\retail_m_2010_2.fdb d:\test_db\retail_0_2.nbk С удалением в параллельном коннекте тех-же 100млн записей. При этом выяснилось следующее: Доступная физицеская память не забивается файловым кешем и Очень хорошо, так и должно быть. Соответственно проблема или внутри Win2008 R2 x64, или внутри какого-либо её драйвера (intel raid matrix ?) соответственно нбекап не грузит ядро на 100% Я бы не торопился говорить соответственно в данном месте. Прямая связь между забитым кешем ФС и 100% загрузкой ядра пока не доказана. и все по прежнему тормозит. Не понято. Раньше nbackup грузил ядро на 100% и всё тормозило. Теперь - нбекап не грузит ядро на 100% и все по прежнему тормозит. Тут нет описки ? Да, должен заметить, что скорость чтения\записи с FILE_FLAG_NO_BUFFERING может (и должна) быть в несколько раз меньше, чем через файловый кеш. Может эти тормоза имеются в виду ? Так они вполне ожидаемы. + получил удар по голове в виде == RASCHET3 Thu Jan 13 17:52:08 2011 I/O error during WriteFile operation for file D:\TEST_DB\RETAIL_M_2010_2.FDB.delta Error while trying to write to file Недостаточно места на диске. RASCHET3 Thu Jan 13 17:52:08 2011 Database: D:\TEST_DB\RETAIL_M_2010_2.FDB I/O error during WriteFile operation for file D:\TEST_DB\RETAIL_M_2010_2.FDB.delta Error while trying to write to file Недостаточно места на диске. internal Firebird consistency check (error during savepoint backout (290), file: exe.cpp line: 4129) RASCHET3 Thu Jan 13 17:52:10 2011 I/O error during WriteFile operation for file D:\TEST_DB\RETAIL_M_2010_2.FDB.delta Error while trying to write to file Недостаточно места на диске. == Где-то в конце удаления данных ибо розмер дельтафайла 9гиг. А как смотрится размер дельтафайла ? Винда редко обновляет на диске размер быстрорастущего файла и добиться от неё правды во время этого процесса не так просто. При этом на диске с базой свободно 70Гб, на диске с IBTemp 260Гб. FB не придумал описание ошибки, его дала ОС. Это все естественно на V2.5.0.26074 CS. Гугль подсказал что на тему backout 290 что-то правилось или будет справлено, но в каких версиях пока не разобрался. Конкретно этот случай вряд ли исправлялся. А если взять xcopy, а не FAR ? Использовался FAR x64 с включенной функцией системного копирования. Но если нужно проверю и с xcopy. Вообще говоря интересует утилита копирования, которая не использует файловый кеш (т.е. работает с FILE_FLAG_NO_BUFFERING). -- Хорсун Влад PS Кстати, на Win2008 R2 x64 - какой разрядности был FB и какие опции в конфиге были изменены ?
gds32.dll vs fbclient.dll
По старинке софт юзает gds32.dll из каталога system32 винды. Вроде бы этот метод устаревает. Православный способ -грузить fbclient.dll из Firebird\bin. Но обычно этого пути нет PATH, да и не нужен он там. Поэтому софт должен делать LoadLibrary(fbclient.dll) с точным путём. (Статическая линковка тут вообще пролетает - невозможна). Следовательно софт должен сперва прочитать ключ реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances\DefaultInstance Получаем пучок проблем: 1. Всегда ли ограниченный аккаут может прочитать HKEY_LOCAL_MACHINE? 2. Аналогично невозможно будет поставить клиента под ограниченным аккаунтом. В принципе оно пофиг. 3. Что делать если стоит несколько версий клиента/сервера.
RE: gds32.dll vs fbclient.dll
Привет! Православный способ -грузить fbclient.dll из Firebird\bin. У пользователей установлен сервер? А нафига, если в минимальном случае достаточно fbclient.dll? Но обычно этого пути нет PATH, да и не нужен он там. Поэтому софт должен делать LoadLibrary(fbclient.dll) с точным путём. (Статическая линковка тут вообще пролетает - невозможна). Ну а положить клиентскую библиотеку рядом с основным приложением что мешает? Следовательно софт должен сперва прочитать ключ реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances\DefaultInstance Получаем пучок проблем: 1. Всегда ли ограниченный аккаут может прочитать HKEY_LOCAL_MACHINE? Даже если и может (не знаю, как там в W7 дело обстоит) - не факт, что эта ветка в реестре вообще есть (по причине отсутствия установленного сервера). 2. Аналогично невозможно будет поставить клиента под ограниченным аккаунтом. В принципе оно пофиг. Не актуально, установить можно и под админом. 3. Что делать если стоит несколько версий клиента/сервера. Немного не понял, но рискну предположить что можно ходить через fbclient самой старшей версии. Либо опять-таки ложить рядом к каждой апликухой актуальный для нее fbclient. WBR, Dmitry Beloshistov AKA [-=BDS=-] __ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru/.ml
Re: Тормоза nbackup
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. Чувствую нужно делать тестовый пример и рисовать картинки (диаграммы)
Re: gds32.dll vs fbclient.dll
Dmitry Beloshistov wrote: Православный способ -грузить fbclient.dll из Firebird\bin. У пользователей установлен сервер? А нафига, если в минимальном случае достаточно fbclient.dll? Стандартный инсталятор при указании установки только клиента делает всё аналогично инсталяции сервера, только не все файлы ставит. Одного fbclient.dll недостаточно. Ему надо ещё firebird.msg и ещё какая то левая dll, плюс рантайм от VC. Просто кинуть fbclient.dll в system32 нельзя ибо он не найдёт свои файлы без ключа в реестре. Да и MS уже не рекомендует засирать сей каталог. Ну а положить клиентскую библиотеку рядом с основным приложением что мешает? Этого способа хочется избежать. На компе обычно может несколько программ, работающих с FB. Хочется файлы сервера дежать в одном месте и не размазывать по диску. 1. Всегда ли ограниченный аккаут может прочитать HKEY_LOCAL_MACHINE? Даже если и может (не знаю, как там в W7 дело обстоит) - не факт, что эта ветка в реестре вообще есть (по причине отсутствия установленного сервера). Сейчас инсталятор клиента её создаёт. Без этой ветки никак. Иначе только что то писать в Documents and Settings\All Users
Re: Тормоза nbackup
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. Напомню это все на тестовых серверах. На
Странный план в 2.5.0.26074
Есть две таблицы, CONT_RES Primary Key=(SERV_ID, RESOURCE, CONT_ID) CONTRACTS Primary Key=(CONT_ID) Делаем простой запрос select * from cont_res cr join contracts ct on cr.cont_id=ct.cont_id where cr.serv_id=14 and cr.resource='1006980' Получаем план PLAN JOIN (CT NATURAL, CR INDEX (PK_CONT_RES)) и кучу неиндексирванных чтений из CONTRACTS Логика поведения сервера тут совершенно непонятна. У нас есть условия на CONT_RES, с ней соединяется CONTRACTS по первичному ключу. Почему не использовать индекс первичного ключа на CONT_ID? Переписываю запрос: select * from cont_res cr left join contracts ct on cr.cont_id=ct.cont_id where cr.serv_id=14 and cr.resource='1006980' PLAN JOIN (CR INDEX (PK_CONT_RES), CT INDEX (RDB$PRIMARY13)) Вроде все хорошо, и план, и чтений нет, но до момента когда в запросе не ставим cr.resource is null И тут же получаем полное индексированное чтение CONT_RES Зачем? CONT_RES.RESOURCE определен как NOT NULL, и входит в первичный ключ. Почему сразу не понять, что читать ничего не надо? Какими силами можно заставить оптимизатор нормально выполнить простейшее соединение двух таблиц, с условием на одну из них?
Re: Странный план в 2.5.0.26074
14.01.2011 15:56, Александр Свириденков пишет: Есть две таблицы, CONT_RES Primary Key=(SERV_ID, RESOURCE, CONT_ID) CONTRACTS Primary Key=(CONT_ID) Типы данных какие? Статистика свежая? Делаем простой запрос select * from cont_res cr join contracts ct on cr.cont_id=ct.cont_id where cr.serv_id=14 and cr.resource='1006980' Получаем план PLAN JOIN (CT NATURAL, CR INDEX (PK_CONT_RES)) и кучу неиндексирванных чтений из CONTRACTS Логика поведения сервера тут совершенно непонятна. Без кол-ва записей в таблицах и селективности индексов гадать бесполезно. Переписываю запрос: select * from cont_res cr left join contracts ct on cr.cont_id=ct.cont_id where cr.serv_id=14 and cr.resource='1006980' PLAN JOIN (CR INDEX (PK_CONT_RES), CT INDEX (RDB$PRIMARY13)) Вроде все хорошо, и план, и чтений нет, но до момента когда в запросе не ставим cr.resource is null Как именно ставим? И тут же получаем полное индексированное чтение CONT_RES Так полное или индексированное? CONT_RES.RESOURCE определен как NOT NULL, и входит в первичный ключ. Почему сразу не понять, что читать ничего не надо? А если ты удалишь PK и понапихаешь нуллов, когда запрос уже отпрепарирован и считает, что читать нуллы не надо? :-) -- Дмитрий Еманов
Re: Странный план в 2.5.0.26074
Типы данных какие? Статистика свежая? CREATE TABLE CONT_RES ( SERV_ID INTEGER NOT NULL, RESOURCE VARCHAR(30) NOT NULL, CONT_ID INTEGER NOT NULL ); CREATE TABLE CONTRACTS ( CONT_ID INTEGER NOT NULL, После пересчета статистики, первый запрос и правда стал давать нормальный план PLAN JOIN (CR INDEX (PK_CONT_RES), CT INDEX (RDB$PRIMARY13)) Но если в него поставить cr.resource is null то один фиг получаем полное чтение CONT_RES по индексу Без кол-ва записей в таблицах и селективности индексов гадать бесполезно. В обеих по 1747 записей И тут же получаем полное индексированное чтение CONT_RES Так полное или индексированное? По индексу, но количество чтений=количеству записей в таблице CONT_RES.RESOURCE определен как NOT NULL, и входит в первичный ключ. Почему сразу не понять, что читать ничего не надо? А если ты удалишь PK и понапихаешь нуллов, когда запрос уже отпрепарирован и считает, что читать нуллы не надо? :-) Была бы сермяжная правда в твоих словах, если бы при попытке удалить PK использующийся в препарированном запросе, не получал бы со 100% вероятностью Object ... in use Так что вы уж или крестик снимите...(с) :) Кроме того, мне казалось что с какой-то версии FB уже умеет искать NULL по индексу
Re: Странный план в 2.5.0.26074
14.01.2011 16:56, Александр Свириденков пишет: После пересчета статистики, первый запрос и правда стал давать нормальный план PLAN JOIN (CR INDEX (PK_CONT_RES), CT INDEX (RDB$PRIMARY13)) Ну и замечательно. Но если в него поставить cr.resource is null то один фиг получаем полное чтение CONT_RES по индексу Т.е. речь про: select * from cont_res cr join contracts ct on cr.cont_id=ct.cont_id where cr.serv_id=14 and cr.resource is null ? И тут же получаем полное индексированное чтение CONT_RES Так полное или индексированное? По индексу, но количество чтений=количеству записей в таблице Кажется, картина проясняется. См. ниже. Была бы сермяжная правда в твоих словах, если бы при попытке удалить PK использующийся в препарированном запросе, не получал бы со 100% вероятностью Object ... in use Так что вы уж или крестик снимите...(с) :) Твоя правда :-) Кстати, NOT NULL ты таки снять можешь (если там UK, а не PK). Но не удалить PK, это да. Кроме того, мне казалось что с какой-то версии FB уже умеет искать NULL по индексу Он всегда это умел. Просто раньше там проблемы были. Насколько я понимаю, тут засада в композитном индексе, где NULL - не последний сегмент. Я недавно это объяснял Болтику, цитирую: Это особенность реализации нуллов в индексах. Для ASC-индексов нуллы хранятся как ключи нулевой длины. Поэтому при поиске на частичное соответствие (полей в индексе больше чем в запросе) нулл будет равен любому другому ключу. Аналогия для индекса с 4 сегментами: A = a and B = b and C = c : field like 'abc%' A = a and B = b and C is null : field like 'ab%' т.е. нулл после сегмента B есть, но его при поиске не видно, т.к. это ключ нулевой длины. Отсюда и шире выборка, больше чтений. Таким образом, де-факто имеем поиск лишь по первому сегменту композитного индекса, а им выбираются все 100% значений. Попробуй пересоздать композитный PK как DESC-индекс. В этом случае нуллы хранятся в виде 0xFF и все должно работать как ожидается. Ну, или если ты заранее знаешь, что эта выборка по PK фиктивная, то добавь в предикат для CONT_RES любое значения столбца CONT_ID, тогда индексный ключ станет полным и нуллы начнут искаться (и не находиться). Дмитрий
Re: Тормоза nbackup
Khorsun Vlad пишет: Это был бы очень большой маразм. Файловый кеш не может быть per-process, иначе в нём нет никакого смысла и возникнет огромная пробема синхронизации частных кешей. На своей W2K3 R2 x64 8GB я спокойно забиваю файловый кеш под завязку используя 32-битный FB и большую БД. Так что админы пусть поищут другие объяснения :) Может они virtual address space имели в виду ? И что такое VST ? Тут я пас, я не админ и не системный программист и внутренней кухни винды не знаю. что такое VST я не с курсе. Вижу только что на Win2008R2 x64 свободная память забивается файловым кешем FB-процессом или тупым файловым копированием. На Win 32b этого не происходит. Process Explorer более привычный для меня инструмент... Iarsn TasckInfo http://www.iarsn.com/ Таскинфо посоветовал давным-давно Кузьменко(?) еще на епселоне, с того времени и пользуем. Process Explorer-ом тоже пользуюсь, но он на порядок показывает меньше инфы. Но это конечно дело вкуса. А где в нем посмотреть размер файлового кеша - не нашел. Системный кеш нашел, но это не то. А можно исключить inter raid matrix из рассмотрения ? Для сравнения. И, кстати, у него есть свои настройки кеширования дисков\массивов... Кеширование на рейде все включено. И обратное кеширование записи рейда и кеширование на винтах. Попробую позже найти свободный сервер с другим рейдом, но это пока проблематично. Давай тут определимся : т.к. было выяснено, что загрузка именно *ядра ОС*, то сам nbackup можно не обвинять в *загрузке* процессора - это делает системный обработчик, вызываемый nbackup'ом. Согласен с что грузит какой-то системный обработчик. Судить что нбекан *невиновен* не могу ибо не видел что он там вызывает и как, даже если бы и посмотрел то всеравно не понял бы ибо в этом ни черта не понимаю. Странно это. Или система выдаёт кривой код ошибки (маловероятно), или FB выдаёт не совсем корректное сообщение (тоже верится слабо, но всё возможно)... Сори. Посыпаю голову пеплом. Действительно закончилось место на диске, я же паралельно запустил нбекам 0 уровня на тот же диск. И не хватило каких-то 10-ков мегабайт места и после этого нбекап удалил за собой неполный архив, вот потому я и увидел свободное место. Повторный тест поставил все на свои места.
Re: gds32.dll vs fbclient.dll
Alexey Popov сообщил(а) в новостях следующее:igpdi7$rfg$1...@dough.gmane.org... Dmitry Beloshistov wrote: Православный способ -грузить fbclient.dll из Firebird\bin. У пользователей установлен сервер? А нафига, если в минимальном случае достаточно fbclient.dll? Стандартный инсталятор при указании установки только клиента делает всё аналогично инсталяции сервера, только не все файлы ставит. В смысле? Чего он не ставит? Одного fbclient.dll недостаточно. Ему надо ещё firebird.msg и ещё какая то левая dll, плюс рантайм от VC. Левых там нет. Просто кинуть fbclient.dll в system32 нельзя ибо он не найдёт свои файлы без ключа в реестре. Да и MS уже не рекомендует засирать сей каталог. Кто не найдет? Ну а положить клиентскую библиотеку рядом с основным приложением что мешает? Этого способа хочется избежать. Почему? На компе обычно может несколько программ, работающих с FB. Хочется файлы сервера дежать в одном месте и не размазывать по диску. Если так то или встроенные сервера и тогда пофиг или один сервер, одной версии. Всякие глупости по портам и сервера запущенные как приложения лучше пропустить. 1. Всегда ли ограниченный аккаут может прочитать HKEY_LOCAL_MACHINE? Смотря кто читает. Инсталлятор может проверить и потребовать прав. Сервис - это и так имеет. Даже если и может (не знаю, как там в W7 дело обстоит) - не факт, что эта ветка в реестре вообще есть (по причине отсутствия установленного сервера). Ну да. Дмитрий
