hi all

в узких кругах широко известно следующее:
http://www.ibase.ru/devinfo/utl.htm Когда транзакция стартует она получает копию TIP от Oldest Interesting Transaction (OIT). Однако, транзакции read committed используют одну и ту же копию TIP. Транзакции snapshot работают каждая со своей копией. Поэтому, когда застревает OIT, старт транзакций snapshot копирует все больше памяти, чем если бы OIT не застревал.


Сейчас ваяю большой тест, имитирующий ОЛТП-нагрузку, в котором присутствует несколько мест, где нужно менять таблицы неким хитрым образом. Трабл в том, что алгоритм должен быть стопудово железным в смысле правильности: ошибки в нём отражаются не в момент его работы, а на "следующих" фазах бытия. Например, на том, что общее кол-во расходов по какому-либо изделию > 0, а стоимость этих расходов "вдруг" оказалась нулевой.
Причина расхождений в том, что нельзя сразу (одним DML-оператором) поменять данные во всех таблицах. Кроме того, в некоторых таблицах новые значения должны быть рассчитаны по if-else принципу на основе других "новых значений".

Ну так вот. Даже при средней нагрузке (30-40 молотилок) ввиду отсутствия согласовванности данных в режиме read committed быстро наступает фаза, когда постоянно срабатывают сторожевые check'и, что однозначно говорит: алгоритм брал в разных своих точках несогласованные на момент своего старта данные. То какие-то строки "пропали" в середине его вып-я, то данные в нх поменялись чьим-то коммитом, то появились новые строки.

Первой судорожной попыткой решить этот трабл было "двухфазное" выполнение такого рода алгоритмов:
1) на фазе-1 выясняем rdb$db_key записей, которые участвуют в процессе, и лочим их (select ... for update + update ... set id = id where rdb$db_key = ...). Облом при select for update по таймауту, равно как и последующий update conflicts (если запись таки удалось залочить, но она уже изменена) - неизбежность, но зато данные в базе не портятся.
2) на фазе-2 пробегаем тем же курсором по залоченным записям и:
2.1) ПЕРЕЧИТЫВАЕМ ЗАНОВО значения некоторых полей (ибо они запросто могли поменяться при ожидании на select for update!)
2.2) если новые (перечитанные в п 2.1) значения по-прежнему удовлетворяют условиям - проводим требуемые изменения.

Но:
1) код стал более громоздким;
2) запросто можно забыть перечитать по-новой все требуемые для алгоритма поля. Это означает, что алгоритм будет продолжать опираться на значения, которых уже нет в базе. Т.е. алгоритм так и останется неправильным;
3) главное: это не уберегает от "фантомов" - появления в базе новых строк и попадания их в курсор на фазе-2. Ибо RC!

Вот сижу теперь и думку думаю: то ли городить и дальше всё в RC, ибо "так у всех делается, и надо чтобы было как у всех", то ли просто делать проверку на til = snapshot + lock timeout >0, и обламывать, если til ниже.

Кто что думает ?

ЗЫ. Однажды , ДС мне подкинул реплику: "а ты мерял ?" - в ответ на процитированное выше про копирование TIP и затраты. Сейчас сильно жалею, что не провёл тогда эксперимент.

У кого-нить есть реальный опыт работы усеров в SNAPSHOT'e ?

kdvпохоже, ты в попытке уйти от снапшота перегнул все что можно.ну так мантра какая-то в ФБ-мире есть: самое лучшее с т.зр. производительности - rc. Вот и поддался на провокацию... ;-)

Симонов Денискак по мне, так если транзакция довольно короткая то пофиг. Затратами на копирования TIP можно пренебречь.Хронометрёж (да и трейс) безжалостны: на ожидание высвобождения строк часто требуется 5-10, а иногда доходит до.... 20 сек! Но это при включенном логировании и когда на каждую ошибку надо строить стек вызовов (для записи в лог), а это обращение к mon$-таблицам.
Без такого обращения всё гораздо шустрее, но мне стек вызовов часто позарез нужен!

Можно, конечно, запускать и с no wait, но тогда и обломы будут постоянными, да и в базу будет записано гораздо меньше инфы. На устойчивость к постоянным обломам типа "deadlock" или update conslicts ФБ вроде как проверять не нужно, у него с этим всё в порядке :-)

Симонов ДенисИначе у тебя система с течением времени колом встанет. Так что 20 сек, по мне очень даже не короткая транзакцияНе встанет: они (транзакции) с разными "объемами" должны работать, у одной задание на 1000 строк, а у другой - на 10 тыс.

Денис, ты мне про сабж что сказать можешь ? ты пробовал snapshot no wait / lock timeout на каком-нибудь своём тестовом стенде или на живых машинорылах ?

Dimitry SibiryakovУ сам-знаешь-какого репликатора основная рабочая транзакция имеет параметры concurrency nowait. Жалоб о том, что она является источником тормозов или тормозит сама (именно как следствие уровня изоляции) я не слышал.Тут поправочку надо сделать. Репликатор один работает с til = snapshot, остальные же - в RC (по кр мере, у мну и, насколько могу понять, у почтеннейшей публики точно так же ?). Кроме того, репликатор ни с кем не дерётся за записи в repl$log'e: "они там пусть добавляют, а я - и только я - перенесу очередную пачку записей и грохну их". Так что у него вообще причин к тормозам нет...

Dimitry SibiryakovУ остальных - есть, но копирование TIP там не играет рояля.Тогда почему столь широко распространён именно RC ? Или я пребываю в иллюзиях и все молотят в snapshot'ах ?

0xFF. 2 DS: ты бы добавил таки в repl$log поле с номером транзакции... вряд ли тормозов прибавит, а про одну бяку можно будет забыть.

Гаджимурадов РустамТаблоид> Тогда почему столь широко распространён именно RC ?

А откуда у тебя вообще сведения о распространённости?Да это не то, чтобы "сведения". Какая-то смутная догадка, вот я и решил спросить у народа.

Гаджимурадов РустамУ меня их нет. И сомневаюсь, что они вообще у кого-то есть.Ну, вот у нас как бэ... есть.... :-)

Гаджимурадов РустамЕсть рекомендации, да. RC read - для чтения, concurrency
nowait - для записи.Тогда вопрос! Вот прочёл ты данные в RC, дальше твой алгоритм начинает опираться на них. А если они, пока читались, оказались противоречивыми ? Ну, то есть пока шло чтение, часть данных успела поменяться, - что тогда ? Или у тебя нету такого гемора ?

Гаджимурадов РустамВо втором случае есть варианты.В каком "втором" случае, про что речь ?

Dimitry Sibiryakovя подумываю выкинуть repl$log как таковой.Интересно... Но это я в личке тогда спрошу, а то оффтоп уже идёт.

Гаджимурадов Рустам> Ну, вот у нас как бэ... есть.... :-)

Сведения или догадки?я про то, что у нас в продакшене используется именноTIL = RC - и он там единственный используемый уровень. И кто там принимал решение, что надо именно RC - хрен знает, "иных уж нет, а те далече".

Гаджимурадов Рустам> Вот прочёл ты данные в RC

Основных вариантов немного - два, по сути.
И это совсем другой вопрос, отдельный, ибо чтение данных к обновлению отношения не имеетПогодь!! При таких операциях, как "проведение документа", некоторое предварительное чтение данных, НЕ относящихся к данному документу, - что не нужно разве ? Или я неправильно понимаю тутошний контекст слова "чтение" ?..

Гаджимурадов Рустамна изменение данных ты можешь открывать снапшот хоть сразу, хоть на подтверждение (у меня с Дедом на этот счёт мнения были разные, IIRC).Ты про что-то типа формы с полями для ввода говоришь ?

Гаджимурадов РустамТаблоид> я про то, что у нас

У кого-то может быть что угодно (тем более у вас), но это не означает распространенность, правильность,
рекомендованность и пр. подхода.ОК. Хотелось бы послушать остальных завсегдатаев нашего кабачка.
Что там у вас, какой TIL в продакшенах ?