iBase.ru Forum

Win2000prof FireBird1.03 диалект1
~20-30 пользователей лвс 100 Mb
1-2 пользователя лвс 128kb
100% загрузка просессора.
в логе : только ошибка 100054
Пользователи работают но с большими тормозами.
Пытаюсь получить статистику - не дает.
Подождал 10 минут статистику не выдает.
Отключаю сеть на сервере после чего загрузка процессора в норме.
Включаю сеть.Пользователи переподключаюся и нормально работают.
Накануне делал статистку. Все вроде нормально. Сразу после отключения сети выгружаю статистику такая же как обычно.

Код: Выделить всё

Database header page information: 
        Flags                   0 
        Checksum                12345 
        Generation              98693 
        Page size               8192 
        ODS version             10.0 
        Oldest transaction      98685 
        Oldest active           98686 
        Oldest snapshot         98686 
        Next transaction        98687 
        Bumped transaction      1 
        Sequence number         0 
        Next attachment ID      0 
        Implementation ID       16 
        Shadow count            0 
        Page buffers            0 
        Next header page        0 
        Database dialect        1 
        Creation date           Feb 5, 2007 13:53:39 
        Attributes              force write 
 
    Variable header data: 
        Sweep interval:         20000 
        *END*

Можно ли предположить где то открытую транзакцию?
В чем причина и как недопустить в дальнейшем подобной проблемы?
FB1.5 более усточива? может есть смысл перейти на FB1.5.
Нужно ли и Как минимальными усилиями переустановить клиентов с 1.03 на 1.5
_________________
Юрий

Где-то есть кривой запрос. В смысле неотлаженный, с плохим планом. Как один из пользователей на него наткнётся - все курят.

UNK писал(а):Можно ли предположить где то открытую транзакцию?

Нет. Сколько сетевых плат на сервере? Используются ли events? У первой птички любил зацикливаться поток ивентов при обрыве соединения (правда не помню - на сервере или клиенте).
Так что я бы на твоем месте начал тестировать приложение на совместимость с полуторкой...

Dimitry Sibiryakov писал(а): Так что я бы на твоем месте начал тестировать приложение на совместимость с полуторкой...

А то в полуторке оптимизатор гений... Какие-то запросы получше планирует, какие-то похуже. Я бы на его месте сначала статистику индексов пересчитал. А если не поможет, погонял бы задачу и посмотрел, какая информационная функция её вешает. Или поставил бы классику - на ней насмерть зависнет только тот, кто на этот запрос напорется, а остальные худо-бедно будут работать. Вот тогда узнать, что этот несчастный делал и смотреть запрос. Он может и в триггере каком-нить оказаться.

А еще говорят, что я - злой... Я-то начал грешить на ошибку в сервере, а многоопытный Дед - как отрезал: "разработчик виноват".

Дык всё ж на своей зопе пройдено. Когда на IB4 работали, кодер за запрос без секции Plan получал люлей безоговорочно. Но в триггерах тогда планированные запросы не допускались. При попытке перейти на супер 6-ки контора вставала раком по три раза на дню. Вот так я и пришёл к FB

Классику-то борманы похоронили, мы поставили по наводке kdv FB-0.9.1 и быренько нашли этот запросик, в триггере, вместо 0.06 сек на оптимизаторе 4-ки выполнялся 680 сек

база какого размера? на срабатывание автосвипа не похоже, а вот про 100% загрузку - это да, скорее всего запросики "того". Ну и Firebird 1.03 туда же - версия ничего, но уже старая.

Можно ли предположить где то открытую транзакцию?

теоретически можно, но по статистике ничего такого нет. Скорее можно предположить массовое удаление или обновление в какой-нибудь таблице, а юзер своим запросом вызвал сборку мусора. хотя на супере, да еще 1.03, сборка мусора не грузит проц на 100%.

Размер базы ~600mb 1 сетевая плата.P4 2.4 память 1gb
Да event используются. И эта проблема появилась после того как начали пользовать приложения с event. Ситуация повторилась. Начал отключать пользователей. Почти сразу нашел пользователя-источник проблемы. Как только его отключил все нормализовалось. Самое интересное что она продолжала работать как и все с тормозами.
Переподключилась сделала перерасчеты техже заказов(серия ХП с больши кол-вом update) повторили многократно но ситуация не повторилась. Наверное все же проблема в event. Event генерируются не часто. Теоретически min 150 сек в реальности период 10-15 мин

Доброго времени суток!

Merlin писал(а):Когда на IB4 работали, кодер за запрос без секции Plan получал люлей безоговорочно.

Оптимизатор в IB 4, конечно, кривой, но не настолько же. У нас практически нигде PLAN нет, и работаем как-то. Конечно, есть некоторые ограничения на последовательность join (очень не любит inner-left), но жить можно.

Переделал приложение убрал events . Почти месяц в работе - все в норме.

iBase.ru Forum

100% загрузка проц

100% загрузка проц

Re: 100% загрузка проц

Re: 100% загрузка проц

Все таки events