hi all

Если есть вот это:

- то должен ли стартануть свип при таком маленьком интервальчике, как сейчас (1000) ?
В логе ФБ - пустошь, в трейсе тоже ничего.

Гаджимурадов Рустам,

ничего не путаю.

$ /opt/fb30trnk/bin/fbsvcmgr localhost/3333:service_mgr user sysdba password masterke info_server_version info_svr_db_info
Server version: LI-T3.0.0.31208 Firebird 3.0 Alpha 2
Databases:
Number of attachments: 0
Number of databases: 0

В логе ФБ - ничего просвип нету.
Заголовок базы - см "фотку".

Насколько могу вспомнить, этот OST < OIT получился "как обычно": открыл в ИБЭ что-то (у него TIL = RC), забыл про него на 3-5 минут, а затем сделал rollback. При молотилках, работающих с TIL = snapshot, получаю этот самый застрявший OST.

dimitrкакое отношение имеет OST к свипу. И заодно - как собирать мусор при таком OST.ну, я вот смотрю в garbage_collection.pdf (материалы "транзакционного семинара"), и там из написанного на стр. 27 делаю вывод: автозапуск свипа движком происходит, когда “sweep gap” : OST - OIT достигает лимита, либо дефолтного (20000), либо проставленного врукопашную.

dimitrИ заодно - как собирать мусор при таком OST.еще бы понять, из-за чего такое вообще происходит (OST < OIT).
Вот запустил сейчас 40 окошек, и периодически дёргаю gstat -h. И каждый раз вижу, что OST отстаёт от OIT на 400-500. Т.е. все счетчики движутся "параллельно", но отставание OST от OIT - постоянно в этих пределах.
Коннекты не килял, все молотят свою работу.

dimitrты пока можешь перечитать тынц раз и тынц два . А KDV с Владом пусть уже договорятся: OST - OIT или OAT - OIT :-) А то сколько лет уже разброд и метания.
Почитал. http://www.ibase.ru/devinfo/sweep.htm в созданной базе данных есть параметр Sweep Interval, равный 20000. Как только разница между транзакциями Oldest Snapshot и Oldest (см. gstat -h db.gdb) (в InterBase 7.x и выше, и в Firebird 2.1 и выше - разница между Oldest Active и Oldest ) дQ1: про "ФБ 2.1 и выше" - это действительно так, т.е. сравнивается O A T ?
(и эта же фраза повторяется в тынц_два , только ФБ тут явно не упоминается: "Процесс сборки мусора (sweep) контролируется разницей между Oldest Interesting Transaction и Oldest Active Transaction (примечание kdv: в версиях InterBase ранее 7.1 данная разница считается между Oldest Interesting Transaction и Oldest Snapshot Transaction). ")

Мой случай, когда OST < OIT и OST < OAT, показан в тынц_два в таком виде:
kdvЕсли в базе данных не было большого rollback, но есть активная транзакция snapshot, то порядок будет:

OST -> OIT = OAT -> NTQ2: у меня стопудово ЕСТЬ большие роллбаки, которые невозможно сделать через отмены+коммит. И все активные транзакции работают в snapshot'e.
Застрявших транзакций нет, вот что вижу сейчас (через 4 часа после начала молотьбы):
Ну так по какой причине OST всё время меньше OIT (хотя и движется вслед за ним) ? Свип из-за этого так и не стартует, и как тогда мусор убирать - каунтить таблицы периодически ?

hvladТаблоидQ2: у меня стопудово ЕСТЬ большие роллбаки, которые невозможно сделать через отмены+коммитТа ты шо ! И OIT у тебя не движется ? И свип не делается ? Ну я же говорю: OIT - движется. Они все вместе прут вверх, с почти постоянным интервалом OIT - OST =~500.
Но свип не стартует из-за отрицательной разницы OST - OIT, а в статистике некоторых таблиц - мусорная свалка. И мну она не нравится что-то... :-)
hvladИ стопудово роллбеки большие ? Ай-яй-яй...да, есть и большие (лок-обломы при отменах поднятых инвойсов, там тысячи строк меняются).

hvladТаблоидQ1: про "ФБ 2.1 и выше" - это действительно так, т.е. сравнивается O A T ?Нет, нет и ещё раз НЕТ.
Задолбало это уже. 2 kdv : ну поправь доку уже, что ле...
hvladТаблоидНу так по какой причине OST всё время меньше OIT (хотя и движется вслед за ним) ?А какая вообще связь между OST и OIT ? С чего ты взял, что OST обязан быть больше OIT ?в бол-ве продакшен-систем - как они соотносятся ? что-то встряло в голову, что OIT обычно меньше OST.
hvladВ идеальном случае, когда нет роллбеков через TIP, OIT всегда будет равен OAT-1.
С чего ты взял, что OST должен быть равен OAT ??? Это возможно, только когда нет snapshot тр-ций.не, я как раз OST и не сравнивал с OAT. Просто привёл цитату с ibase.ru, там соотношение показано между ними.

hvladТаблоидСвип из-за этого так и не стартует, и как тогда мусор убирать - каунтить таблицы периодически ?Ты же был на семинаре, я же 100500 раз там акцентировал внимание на том, что эти счётчики НЕ ИМЕЮТ никакого отношения к кол-ву мусора в БД...

Ты статистику снимал ? На кол-во версий смотрел ? Оно только увеличивается ?Статистику снимал, но не логировал, к сож-ю. И не по всем таблицам.
Сегодня запущу задание в кроне, пущай откладывает.

dimitrТаблоидда, есть и большиетогда бы OIT застыл намертво (до свипа)Тогда, если они не большие, я должен был бы видеть в трейсе по каждому роллбаку (для транзакций, которые действительно что-то меняли) статистику его действий по таблицам - так или нет ?

kdvтвоя картинка (когда OST отстает от OIT) рассказывается тут
"Когда ReadCommitted блокирует Oldest Snapshot"
http://www.ibase.ru/devinfo/summary.htm
и то же самое есть в последней презентации AK на семинаре по транзакциям.kdv, спасибо! есть у мну одна догадка: это служебная ХП, которая регулярно стартует с TIL = RC и выполняет пересчет статистики индексов. Я её затолкал в RC... не помню уже, для чего :-)
Других аттачей с TIL = RC нету, так что сейчас переделаю эту штуку.

kdvЕсли у тебя были "настоящие роллбэки", то из-за мелкого sweep interval ты скорее всего проглядел авто-запуск sweep. В логе точно свипа нет?Точно нету.

hvladТы статистику снимал ? На кол-во версий смотрел ? Оно только увеличивается ?Запустил 50 молотилок, работают почти 2 часа.
Запустил также два .sh-скрипта, которые с интервалом 10 сек делают:
1) gstat -h с фильтром значений счетчиков
2) gstat -r с фильтром значений версий в тех таблицах, что мну сильнее всего сейчас интересуют (т.к. они меняются самым интенсивным образом).

Результат:
1) число версий в таблицах сначала выросло до нек. значений, а затем стало "танцевать" вокруг них, с небольшими амлитудами. Но постоянного роста - нету;
2) счетчики стабильно прут вверх, но и интервал OST - OIT также стабилен.

Логи в аттаче.

http://www.ibase.ru/devinfo/summary.htm Обратите внимание, что Oldest transaction больше Oldest snapshot. И Sweep gap имеет отрицательное значение. Это может произойти в двух случаях.
Первый случай , когда есть периодически стартуемые и завершаемые транзакции snapshot. То есть, эта картинка показывает наличие "долгоживущих" snapshot так же, как и предыдущая.
Второй случай происходит на серверах, кроме IB 7.1, при работе с ReadCommitted транзакциями (или в комбинации read_committed и snapshot). Здесь транзакция ReadCommitted блокирует Oldest Snapshot точно таким же образом, как транзакции Snapshot.Переделал процедуру, собиравшую статистику по индексам в RC, под снапшот.
Теперь ReadCommitted транзакций нет. Вообще.

Увы и ах, но по прежнему OST < OIT, причём опять на какую-то стабильную величину около 500: Остается тогда только первый случай - наличие долгих снапшотов.
Значит, автосвип так и не будет стартовать.
Утешает, впрочем, что число версий не растёт после того, как достигнет некоторого потолка.

ЗЫ. Пока не появится фича, позволяющая разобраться в причинах сумасшедших значений времени при небольших числах fetches / marks и практически отсутствующих reads/writes - причину застреваний не найти :(