Re: Тормоза nbackup
Viktor Belzetskiy wrote ... Khorsun Vlad пишет: Это был бы очень большой маразм. Файловый кеш не может быть per-process, иначе в нём нет никакого смысла и возникнет огромная пробема синхронизации частных кешей. На своей W2K3 R2 x64 8GB я спокойно забиваю файловый кеш под завязку используя 32-битный FB и большую БД. Так что админы пусть поищут другие объяснения :) Может они virtual address space имели в виду ? И что такое VST ? Тут я пас, я не админ и не системный программист и внутренней кухни винды не знаю. что такое VST я не с курсе. Учтём Вижу только что на Win2008R2 x64 свободная память забивается файловым кешем FB-процессом или тупым файловым копированием. Ну так причём тут FB-процесс ? На Win 32b этого не происходит. И ещё раз тот же вопрос Process Explorer более привычный для меня инструмент... Iarsn TasckInfo http://www.iarsn.com/ Таскинфо посоветовал давным-давно Кузьменко(?) еще на епселоне, с того времени и пользуем. Оно не бесплатное, скачал триал чтобы посмотреть и удалить Process Explorer-ом тоже пользуюсь, но он на порядок показывает меньше инфы. А если подумать ? Но это конечно дело вкуса. Это - да А где в нем посмотреть размер файлового кеша - не нашел. Системный кеш нашел, но это не то. Это именно то. И TaskInfo, и PE показывают мне одни и теже числа. Иначе и быть не может. А можно исключить inter raid matrix из рассмотрения ? Для сравнения. И, кстати, у него есть свои настройки кеширования дисков\массивов... Кеширование на рейде все включено. И обратное кеширование записи рейда и кеширование на винтах. Попробую позже найти свободный сервер с другим рейдом, но это пока проблематично. А что, все диски в рейде, нет отдельного ? Давай тут определимся : т.к. было выяснено, что загрузка именно *ядра ОС*, то сам nbackup можно не обвинять в *загрузке* процессора - это делает системный обработчик, вызываемый nbackup'ом. Согласен с что грузит какой-то системный обработчик. Судить что нбекан *невиновен* не могу ибо не видел что он там вызывает и как, даже если бы и посмотрел то всеравно не понял бы ибо в этом ни черта не понимаю. Учтём Странно это. Или система выдаёт кривой код ошибки (маловероятно), или FB выдаёт не совсем корректное сообщение (тоже верится слабо, но всё возможно)... Сори. Посыпаю голову пеплом. Действительно закончилось место на диске, я же паралельно запустил нбекам 0 уровня на тот же диск. И не хватило каких-то 10-ков мегабайт места и после этого нбекап удалил за собой неполный архив, вот потому я и увидел свободное место. Повторный тест поставил все на свои места. Ну хоть что-то имеет чёткое объяснение. Может ещё где-то что-то как-то не совсем так, как казалось сначала ? :) -- Хорсун Влад
Re: Странный план в 2.5.0.26074
Т.е. речь про: 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 ? Да Твоя правда :-) Кстати, NOT NULL ты таки снять можешь (если там UK, а не PK). Но не удалить PK, это да. А на что тогда версионность метаданных? Сервер имеет полное право работать в препарированном запросе по старой версии Насколько я понимаю, тут засада в композитном индексе, где 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 и все должно работать как ожидается. В общем, я вышел из положения создав дополнительный индекс на CONT_RES по двум полям. Благо, сервер его успешно подхватил Ну, или если ты заранее знаешь, что эта выборка по PK фиктивная, то добавь в предикат для CONT_RES любое значения столбца CONT_ID, тогда индексный ключ станет полным и нуллы начнут искаться (и не находиться). Да эта выборка используется как подзапрос другого запроса, и получается что в нее в 95% случаев должен попадать NULL, вот и заметил тормоза Спасибо за участие и консультацию :) P.S. Так ждем 3.0 с реальной многопроцессорностью, что аж сил нет :)
Re: gds32.dll vs fbclient.dll
Hello, Alexey! Alexey Popov wrote: Одного fbclient.dll недостаточно. Ему надо ещё firebird.msg и ещё какая то левая dll, плюс рантайм от VC. Просто кинуть fbclient.dll в system32 нельзя ибо он не найдёт свои файлы без ключа в реестре. Да и MS уже не рекомендует засирать сей каталог. тебе не похужело? Мне казалось, что ты более квалифицирован. Или я ошибался? Просто ведь ахинею какую-то пишешь. кроме того, не знаешь про instclient. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Странные обрывы соединения
Hello, Konstantin! Konstantin R. Beliaev wrote: В ФИБах включена опция восстановления связи при обрыве - после втыкания шнура она срабатывает и восстанавливает соединение. Но насколько я понимаю, это - уже другое соединение с другим процессом классика, разве нет? А предыдущее должно спокойно умереть с отметками в логах. Или я ошибаюсь, и восстанавливается именно предыдущее соединение? оборванное соединение не может быть восстановлено в принципе. ФИБ создает новый коннект (естественно). -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
