Аналог Profiler а(для MSSQL) для Firebird 2.0

← →
Megabyte © (2006-11-09 16:59) [0]

Последнее время начал тормозить сервер(100% загрузка проца). Лечится пока только закрытием всех приложений и перезапуском сервера.
Отловить момент начала торможения тоже не удается пока.
Причем в Tasc Manager"е висят процессы(или один процесс), кот жрут все ресурсы проца, но при этом на вкладке TCP\IP процессов с данным PID нет вообще, т.е. не понятно кто и откуда их запустил.

Вот хочется что-то подобное аля Профайлер для MSSQL, чтобы собирать статистику с сервера. Может там информация поможет разобраться.

← →
unknown © (2006-11-09 17:34) [1]

http://www.ibase.ru/download/ibanalyst_r.zip
Не профайлер, но поможет с бд разобраться.
Еще полезно покурить firebird.conf и http://www.ibase.ru/devinfo/badperf.htm
Ну и конечно проверить бд gfix-ом

← →
Desdechado © (2006-11-09 17:49) [2]

Есть подозрения на автоматический сборщик мусора.
Стратегии общения с ним описаны на ibase.ru

← →
Megabyte © (2006-11-10 12:24) [3]

gfix - это что, какая-то утилита? Она по умолчанию есть или надо устанавливать дополнительно?

Посмотрел статистику, там sweep interval = 0
И я не знаю, запускает ли кто-то sweep вручную(я не сопровожаю основную БД, просто хочу им помочь)... Это может как-то тормозить БД?

← →
Romkin © (2006-11-10 12:54) [4]

Качай с ibase.ru IBMonitor, ставь его на пару дней, потом смотри, что делается.
Как называются процессы?

← →
Megabyte © (2006-11-10 13:09) [5]

>Как называются процессы?

Как говорит Админ, процессы каждый раз разные.
Как мне кажется, тут дело не в том, что кто-то что-то криво делает в БД, а то, что кто-то порождает внутренний процесс на сервере, кот. уже и тормозит сервак. Потому как даже закрытие всех процессов не помогает, только перезагрузка...
Что-то не так в самой БД!

Тут недавно случай произошел: основной программист создавал механизм автоматической репликации. И как-то так совпало, перезапускали сервер и механизм репликации применился на основной БД. Конечно, потом разобрались, отключили механизм репликации, но не восстанавливали БД из бекапа(т.к. инфа не пропала, а только добавилась неправильная), т.к. последний нормальный бекап был сделан достаточно давно(слишком много инфы уже внесли). После этого по ходу и начались проблемы... Но все равно, пока не получается отловить момент начала 100%-й загрузки проца.

← →
Romkin © (2006-11-10 13:13) [6]

Тут двояко: вполне может быть и ошибка в FB2, релиза-то еще нет ;)
Но скорее всего, ошибка именно в программе, скорее всего транзакция какая-нибудь открыта.
Бекап/ресторе прежде всего сделай.

← →
unknown © (2006-11-10 14:46) [7]

> Megabyte © (10.11.06 12:24) [3]
> gfix - это что, какая-то утилита?

\Program Files\Firebird\Firebird_2_0\bin\gfix.exe
http://www.ibase.ru/devinfo/db_repair.htm

← →
Megabyte © (2006-11-14 10:46) [8]

Где можно посмотреть список кодов ошибок, кот. пишутся в лог-файл?
В логе много таких ошибок: INET/inet_error: read errno = 10054

← →
Romkin © (2006-11-14 12:09) [9]

Это ошибки сокетов. У тебя конкретные неполадки с сетью - канал рвется.

← →
Romkin © (2006-11-14 12:20) [10]

http://www.ibase.ru/devinfo/errors.htm
http://www.ibase.ru/download/ibconsvc.zip - монитор подключений к IB по tcp/ip. Установить и сопоставить...
Ошибка, собственно:
WSAECONNRESET (10054)
• Translation: Connection reset by peer.
• Description: An existing connection was forcibly closed by the remote host. This error typically occurs if the peer program on the remote host is suddenly stopped, the host is restarted, or the remote host uses a hard close. See setsockopt (Wsapiref_94aa.asp) for more information about the SO_LINGER option on the remote socket. This error may also result if a connection was broken because of keep-alive activity that detects a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.

На практике - при установленном соединении выдерни сетевой шнур :)

← →
Megabyte © (2006-11-14 12:35) [11]

Хм.
Но все же, где можно посмотреть все коды и описания ошибок?

И еще: возможно ли такое, что запрос на выборку, даже после того, как он не получился, нагрузил базу так, что после его отмены загрузка была бы 100%?

← →
Megabyte © (2006-11-14 12:37) [12]

офтоп: сорри, пока писал сообщение следующее, ты уже [10] написал :)

Я же тебе дал ссылки :)
А, все коды ошибок сокетов здесь: http://support.microsoft.com/kb/819124
Чаще всего встречаются 60, 61, 49 и 54 - на клиенте :)

> И еще: возможно ли такое, что запрос на выборку, даже после
> того, как он не получился, нагрузил базу так, что после
> его отмены загрузка была бы 100%?

Что значит после отмены? Транзакцию откатил? Тогда еще как может...

Поставили новую версию сервера, по крайней мере его хоть не надо перегружать. Приходит через некоторое время в норм. состояние.

Но вот в чем сабж.

> Что значит после отмены? Транзакцию откатил? Тогда еще как может..

Ну просто как-то бредово выглядит. Есть запрос аля "аналитический отчет".
select G.group_title, L.fio, count(distinct P.repair_id) from repair_progress P, repair_progress R, user_list L, right_group G, user_link_group Gl where (P.responsible_personal_id = L.personal_id) and (P.is_delete > 0) and (P.repair_id = R.repair_id) and (R.repair_state_id = 11/*R.progress_timestamp > P.progress_timestamp*/) and (cast(P.progress_timestamp as date) = current_date) and (L.User_List_id = Gl.user_list_id) and (G.right_group_id = Gl.right_group_id) and (L.user_list_id = any( select Lg.user_list_id from user_link_group Lg where Lg.right_group_id in (7000, 17000, 26000, 3000, 10000, 9000))) group by G.group_title, L.fio
Меняю в нем одно условие(то что в комментариях), более качественно отражающее отчетность. Запрос вешает вроде как БД, притом, что на локальном серваке на этой же базе тот же самый запрос работает в пределах 4х секунд. После отката транзакции с этим запросом на основной БД и закрытием коннекта в процессах сервака висит какой-то процесс(по ходу внутренний), кот. жрет все ресурсы.
Логики не вижу...

С этим я бы тебе посоветовал на ibase.ru. Но прежде всего - поставь FB2 release, и попробуй на нем. У тебя же наверняка rc какой-нибудь.
А версии локально и удаленно - разные?

> А версии локально и удаленно - разные?

В этом вся и фишка была. :) На локальном серваке сначала стояла версия, на кот. данные были где-то трехнедельной давности. И запрос работал.
А сегодня из бэкапа поставил поновее версию с основной БД, и запрос локально тоже начал тормозить.
Интересно, неужели так разко увеличилось кол-во записей за день, чтобы запрос стал неэффективным...

Ну ладно, поменял условие запроса, на другое, чтоб не тормозил.

Хм. Вообще-то я говорил о версиях Firebird :)
План запроса всегда смотреть надо - он зависит, в числе прочего, от селективности индексов (и, разумеется, от их наличия), а она может меняться. У тебя, скорее всего, что-то именно с индексами :)

пусть покажет статистику. у него клиенты не выдерживают тормозов и килляют программу, отсюда и 10054
а в статистике посмотрим, сколько мусора в базе. :)

Аналог Profiler а(для MSSQL) для Firebird 2.0 Найти похожие ветки