miwaonlineно причины периодических тормозов которых не связаны с автосвипом.
я тебе клянусь, что там, где автосвип включен, периодические тормоза связаны с ним. А там где он выключен (sweep interval = 0), разрабы кладут болт на длительные транзакции, и там уже тормоза из-за накопления версий.
Так или иначе, тормоза связаны с непониманием версионности, совсем.

fb userЯ контекст не расширял.
гм. тогда какое еще "бесконечное пространство вариантов" тут возможно?
fb user Для всех остальных систем есть бесконечное пространство вариантов.
для версионника нет никакого "бесконечного пространства". предлагаю подтвердить это утверждение хоть какими-то аргументами.

AriochНапример hvlad мог бы тыкнуть носом, или Сибиряков мог бы, но не тыкнули.
Так что имеем то, что имеем.
да, увы. они это просто не читали. Теперь прочитали. Будем править.

Ariochkdvну каких еще, нафиг, тестов?
Вот таких: 19073621
так проверяется-то элементарно. стартуем транзакцию, добавляем записи, жмем ресет или делаем явный rollback, стартуем еще несколько траназкций, чтобы убедиться, что OIT застряла, потом читаем записи, и проверяем наличие версий по gstat -r -t tablename.
Просто ты какую-то чешую пишешь.
"и заблокировав sweep мы тем самым блокируем счётчик OIT"
ты имеешь в виду, что OIT без свипа не подвинется? Ну да. И что? У меня есть статистика от базы, которая жила год, при этом OIT застряла в самом начале работы. И ничего страшного не случилось. OIT - это просто индикатор.
Застревание OIT можно получить просто стартовав транзакцию, ничего больше не делая, нажать reset.
Что, есть тут какие-то версии? Нет.

"блокируем сборку rollback-мусора между OIT и Next Transaction, так ?"
С чего вдруг? Сборка мусора как работала, так и работает. И она всегда идет между OIT и Next :-)

AriochВот тебе, кстати, ещё две цитаты:
1) sweep вообще не собирает мусор, вообще никогда и никак - 19073506
Сибиряков погорячился, потому что ты посчитал sweep каким-то особым типом сборки мусора. Sweep это и сборка мусора, и попытка подвинуть oit. OIT говорит о том, что есть транзакции rolled back, от которых МОГ остаться мусор. sweep вычитывает этот мусор, убирает его, и превращает rolled back в committed, таким образом "подвигая" OIT выше.
Но есть там мусор или нет - неизвестно, его может и не быть. Он мог быть давно убран другими транзакциями, которые НЕ умеют двигать OIT.
Допустим, OIT равно 50. свип должен убедиться, что либо нет мусора принадлежащего этой транзакции, либо этот мусор есть, и его надо убрать. Поэтому свип это И сборка мусора И продвижение OIT.

AriochЯ правильно понимаю, что единственный "rollback автоматически превращаемый в commit" - это rollback который по той или иной причине вообще не создавал версий ?
непонятно, что ты читаешь. в http://www.ibase.ru/mga/ в разделе "Commit, Rollback" написано, в каких случаях rollback превращается в коммит.
Добиться настоящего роллбэка не так-то просто. Его можно организовать
- обновив в одной транзакции около 100к записей или больше, сделать rollback
- стартануть транзакцию, нажать reset. при первом обращении к БД сервер обнаружит активную транзакцию, которая не может быть активной. И превратит ее из активной в rolled back
- стартовать транзакцию с параметром no_auto_undo, сделать роллбэк.

Arioch,

предваряя ужасный вопрос "а как же версии от rollback может убрать обычная сборка мусора?", заранее отвечаю:
при сборке мусора (которая возникает как минимум во время чтения) проверяется id транзакции, создавшей версию. И сравнивается с OST. И проверяется состояние этой транзакции. Если версия не последняя, и никому не нужна - убираем. Если версия создана транзакцией в состоянии rollback - убираем однозначно.
В этот момент превратить rollback в commit и подвинуть OIT невозможно, потому что нет уверенности, что мы видим все версии, созданные этой транзакцией rollback. Они могут быть еще где угодно. А вот свип - может, т.к. он собирает мусор во всей базе.