Gallemarон не поможет, пока висят транзакции.
какие еще транзакции? свип что, не сможет убрать мусор от Oldest до Oldest snapshot? Ну да активные транзакции есть, ну и фиг с ними. Или со свипом.
Gallemarкто попадал в аналогичную ситуацию?
в какую?
застревание Oldest transaction это всего-лишь
-увеличение TIP, но это линейный список, так что пофиг. Разве что транзакции snapshot кушают все больше памяти - в данной статистике уже по 5 мегабайт почти.

И ВСЁ! Мусора-шмусора при этом вообще может не быть. Например, я тестировал когда срабатывает авто-свип в свежих ИБ и ФБ. И что, я мусор плодил? Нет, я принудительные роллбэки делал.

Почему у некоторых людей при застревании OT (или OIT) просто паника начинается?

Gallemarразрыв oldest-activ в 20 млн
и што? нет такого "разрыва". Есть
Next - OAT, это самая давняя активная
и
OST -OIT, это разрыв для авто-свипа.

Все остальное фигня. OAT - OIT это вообще фигня какая-то, потому что если OIT застревает, то он остается на месте, а все остальные маркеры едут вперед. Так же как и Next, и OST.
И это просто значит, что транзакция, номер которой был OIT, завершилась роллбэком. А она могла вообще ничего не менять в базе.
Дегтярев Евгенийа синхронизация этого хозяйства в классике не вызывает проблем, или меня память подводит?
синхронизация чего?
Я потрясен. Или никто ничего не читает, или эти знания бесследно выпадают из головы.
TIP, Transaction Inventory Pages, в базе. С ним работают "онлайн" только RC транзакции. Транзакции Snapshot читают TIP при старте, и дальше они клали болт на "синхронизацию" и глобальный TIP.

hvladТак штааа...
на память да, влияет. У меня был пример когда Next-OIT было 28 мегабайт.
Но в целом на производительность это толком не влияет, а если и влияет, то никто не замечал, потому что куда большее влияние оказывают версии, мусор, сборка мусора, и т.д.

Откуда появилось пугало про OIT я так и не понимаю. OAT при нынешней сборке мусора - да, ахтунг. При будущей - надеюсь что будет гораздо лучше, чем сейчас (с твоих слов).

Dimitry SibiryakovДля этого её пришлось бы запускать с отключенным сейфпоинтом, а такое мало кто умеет.
у ИБ и ФБ это делается по разному, но вполне делается в FIBPlus и IBX.

Дегтярев Евгенийне силен в терминах, RC это read committed?
http://www.ibase.ru/ibtrans/

Работать с БД и только догадываться что такое RC, это как-то ... сильно.
Тем более что уровней изолированности в стандарте 4 - dirty read, read committed, repeatable read, serializable,
плюс "типа нестандартный" snapshot.

Дегтярев Евгенийа разве по умолчанию транзакция не rc?
при чем тут умолчания? я обрисовал как с TIP работают транзакции read committed и snapshot. Других транзакций в ИБ и ФБ нет.
У ИБ и ФБ по умолчанию транзакция Snapshot (сюрприз).
У IBX - тоже snapshot.
У FIBPlus - read committed.

Как у других компонентов - до лампочки, потому что я давно говорю, что "по умолчанию" транзакции использовать нельзя, надо явно задавать уровень изолированности, потому что он х.з. какой по умолчанию в каких компонентах.
К примеру, RC "по умолчанию" в ИБ и ФБ no_rec_version (см. статью выше).

Vlad F,
я про "улучшенную сборку мусора" в 4. И все. А вообще про 4 тут
https://www.firebirdsql.org/en/planning-board/

Vlad F,

посередь минорных версий? Не, сейчас такое только у Интербэйза.

Vlad FЕсли ты про новую сборку
"новая сборка" - это 3.0.4, 3.0.5, 3.0.6...
4.0 - это не сборка, это версия.

Дегтярев Евгенийя правильно понимаю, что каждый процесс классика хранит это состояние и синхронизирует при изменениях?
хранит - да, но "синхронизирует" - нет. Нечего там синхронизировать. При snapshot читается TIP от OIT до Next, и дальше всё - транзакция сама никак TIP не меняет, никакая.
Еще раз - RC обращается к глобальному TIP, периодически, при проверке состояния транзакций у читаемых версий, на то она и read committed. Поэтому RC хранить у себя копию TIP незачем.
А Snapshot делает себе "личную копию TIP" именно для того, чтобы не видеть ничьих чужих изменений, и "перечитывать TIP" ей без надобности.
Так что, в общем, и у snapshot, да и у RC нет никакой "синхронизации TIP".
А глобальный TIP (в базе) меняется только когда какая-то транзакция завершилась.

кроме того, не "каждый процесс классика", а просто каждый коннект в любой архитектуре - CS, SC, SS. По потреблению памяти этот самый TIP влияет одинаково. Разница тут только в раздельном кэше БД у CS-SC и SS.

p.s. либо объясните, что имеете в виду под "синхронизацией". Лично я тут её не усматриваю.

Дегтярев ЕвгенийВлад выше сказал обратное.
ничего он обратного не сказал, см. его ответ ниже.

Я специально умолчал про кэш, потому что этот механизм несколько сбоку в отношении пресловутой мифической "синхронизации TIP". Достаточно понять, что я именно написал, и прочитать хоть чуть-чуть как транзакции меняют свое состояние, и как отслеживают состояния других транзакций, чтобы перестать говорить про "синхронизацию".
Может я нагнетаю, но мне кажется, что вы под синхронизацией представляете нечто другое, чем происходит на самом деле.

Дегтярев Евгенийможет быть миллион и чтобы это эффективно работало, надо чтобы эти данные были в памяти процесса.
за это отвечает КЭШ. Точно так же как и за синхронизацию изменений на страницах данных. Движок же в процессе работы транзакций и чтения версий ПРОВЕРЯЕТ состояния транзакций, либо из копии snapshot, либо из tip базы.

Дегтярев Евгенийя говорил про процессы
процессы дофига чего синхронизируют между собой через lock manager, например. Модификацию одной и той же страницы из разных транзакций, и т.д. Без "синхронизации" мульти-юзер доступ просто бы не работал.
Дегтярев Евгенийполучается при каждом комите надо TIP синхронизировать в 4к процессов.
вот не получается. При коммите движок записывает в TIP изменение состояния конкретной транзакции.
Если другим RC-транзакциям надо проверить версию этой транзакции, то они прочитают измененную страницу с этим куском с диска. Snapshot транзакции будут проверять состояния других транзакций только в локальной копии, никто никуда лазить не будет, и синхронизировать тоже.
авторно достаточно чтобы одна кривая апликуха, держащая OIT, поставила всю систему на колени.
извините, но это полная ерунда.
Во-первых, никакая аппликуха не держит OIT. OIT, в отличие от OAT, это давно завершившаяся роллбэком транзакция.
Во-вторых, чем она "поставит систему на колени"?

Если же тут перепутано, и имелось в виду OAT, так
- надо для читающих использовать read read committed. Тогда никаких длинных OAT не будет.
- не надо держать долго read write read committed в приложениях.
Собственно, опять же, "на колени" - это когда дофига версий и старая OAT. Нет версий - нет тормозов.

Vlad FЯ про новую сборку мусора.
сборка мусора - это сборка мусора. А просто сборка - это не сборка мусора. :-)

Дегтярев Евгений,

на всякий случай - мне к последнему ответу hvlad добавить нечего.

Vlad F,

я не словоблуд. Это проблема русского языка, что слово build - сборка и фраза "garbage collection" - сборка мусора -
начинаются в русском языке с одного и того же слова. Поэтому для меня "сборка" не является "сборкой мусора", даже при разнице в одно сообщение. К тому же, речь шла в том числе про новую фичу ФБ 4, которую тоже можно назвать "сборкой".
А насчет - "меня не спрашивали" - ну ок, не буду отвечать тогда.

Дегтярев Евгенийв чем будут тормоза? по IO или по CPU?
много версий, значит много читать, больше IO.
разбираться с версиями, проверять - CPU
сборка мусора - то же самое, только в другую сторону.
То есть, длительная OAT может вызвать накопление версий, а ее завершение - вызовет начало сборки мусора конкурирующими запросами.