sweep не работает и молчит :( help!

Администирование клиентской и серверной части InterBase, Firebird, Yaffil. Настройка файла конфигурации и т.п.

Модераторы: kdv, Alexey Kovyazin

Ответить
iamhere
Сообщения: 21
Зарегистрирован: 27 дек 2005, 09:45

sweep не работает и молчит :( help!

Сообщение iamhere » 24 мар 2006, 13:43

Имеется база, sweep interval установлен в 0.

Каждую ночь запускается скрипт, который:
* отключает всех клиентов (httpd) и не дает подключаться новым;
* Запускает gfix -sweep /path/db_name;
* после окончания работы gfix снова пускает клиентов.

Иногда sweep отрабатывает нормально (Sweep gap по показаниям IBAnalyst уменьшается).

А иногда - нет. :(

Самое неприятное, что gfix вообще ничего не пишет, ни при успешной очистке, ни при неуспешной. В логах сервера тоже ничего нет.

Что может посоветовать all?

Можно ли надеяться, что когда-нибудь появятся нормальные средства диагностики (логи хотя бы развитые)? И как быть, пока их нет? Как понять причины происходящего?

* RedHat 9.0
* Firebird LI-V1.5.3.4870 Firebird 1.5

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 24 мар 2006, 14:04

Если GFIX не выдал ошибки, то свип сработал успешно. А уж насколько успешно - вопрос другой. Он и не обещает всегда подвинуть тебе gap. Например, сокращение разрыва на 10% - это по твоему успешное выполнение или нет? Кроме того, свип - это не только очистка TIP, это еще и глобальная сборка мусора.

iamhere
Сообщения: 21
Зарегистрирован: 27 дек 2005, 09:45

Сообщение iamhere » 24 мар 2006, 14:20

А почему же sweep не обещает уменьшения gap'а?
А кто обещает?
В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...
:?
Можно ли как-то продиагностировать количество "мусора" в базе?

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 24 мар 2006, 15:02

Клиент недобитый остался. С открытым снапшотом.

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 24 мар 2006, 15:13

iamhere писал(а):1. А почему же sweep не обещает уменьшения gap'а?
2. А кто обещает?
3. В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...
:?
4. Можно ли как-то продиагностировать количество "мусора" в базе?
1. Потому что ему могут помешать активные транзакции.
2. Гарантировано эксклюзивный доступ + свип.
3. Молодцы.
4. GSTAT-ом

Отключение httpd не гарантирует мгновенного отстрела коннектов и транзакций.

iamhere
Сообщения: 21
Зарегистрирован: 27 дек 2005, 09:45

Сообщение iamhere » 24 мар 2006, 15:31

1. А почему же sweep не обещает уменьшения gap'а?
1. Потому что ему могут помешать активные транзакции.
2. А кто обещает?
2. Гарантировано эксклюзивный доступ + свип.
Повторюсь - никаких пользователей гарантированно не подключено. С базой работает только apache и мы его останавливаем и все текущие сессии обрубаем на время sweep'а.
3. В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...
3. Молодцы.
Но хочется, чтобы все-таки это в состоянии была сделать машина. Она для того и придумана - выполнять неблагодарную работу. Но gfix не всегда отрабатывает. :x
4. Можно ли как-то продиагностировать количество "мусора" в базе?
4. GSTAT-ом
Можно подробнее - какой там параметр смотреть, чтобы убедиться, что sweep все-таки отработал?

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 24 мар 2006, 15:58

У меня однажды (давно, ещё на IB4) после kill остался висеть даже не процесс, а его сокет. Поскольку базу копировали а не b/r, ей пришёл трындец...

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 24 мар 2006, 16:34

iamhere писал(а):
1. А почему же sweep не обещает уменьшения gap'а?
1. Потому что ему могут помешать активные транзакции.
2. А кто обещает?
2. Гарантировано эксклюзивный доступ + свип.
Повторюсь - никаких пользователей гарантированно не подключено. С базой работает только apache и мы его останавливаем и все текущие сессии обрубаем на время sweep'а
Кем это гарантированно ?
Как обрубаете ?
Как в этом убеждаетесь ?
iamhere писал(а):
3. В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...
3. Молодцы.
Но хочется, чтобы все-таки это в состоянии была сделать машина. Она для того и придумана - выполнять неблагодарную работу. Но gfix не всегда отрабатывает. :x
gfix всегда отрабатывает, если его не снимают, конечно

sweep gap не имеет прямого отношения к кол-ву мусора
Кол-во версий может показать gstat -r

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 24 мар 2006, 16:40

Кроме того - OST двигается при старте любой тр-ции.
Свип не делает ничего специального для подвижки OST. Он просто стартует тр-цию (в этот момент OST может увеличиться) и читает всю БД

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 24 мар 2006, 21:53

короче, IBAnalyst, жмем F1, и читаем про описание транзакций, почему и когда sweep не срабатывает. Еще рекомендую прочитать хелп по IBAnalyst хотя бы один раз ЦЕЛИКОМ.

Теперь дальше. Есть одна организация. FB 1.5.2. SS, Windows. На одном сервере 2 базы. Одна база ведет себя нормально. Во второй - барабашки. То есть - после рестора образуются какие-то непонятные коннекты, OAT/OST постоянно застревают, и это при 3-5 одновременных клиентах.
Первая база - идеально. Программы писали разные люди (организации).

iamhere
Сообщения: 21
Зарегистрирован: 27 дек 2005, 09:45

Сообщение iamhere » 27 мар 2006, 10:02

Спасибо за наводки, попробуем проверить насчет "барабашек" и вспомнить подробнее про транзакции IB.

Но на наш взгляд, все равно это ужасно, что sweep не выдает никакой информации - отработал он, не отработал, помешал ему кто-то, не помешал, что он сделал и чего - нет... Сиди и гадай, изучай принципы работы IB. Были ли какие-то левые подключения за время sweep'а - тоже не узнать - лога подключений в сервере тоже нет. :(

Может у кого-то есть уже какие-то отлаженные скрипты, которые работая с gfix, gstat и чем там еще все-таки обеспечивают некое "стандартное" обслуживание БД? С более высокой вероятностью успеха и низкими издержками на "шаманство"? Были бы признательны.

Ответить