makhaon,

http://www.ibase.ru/devinfo/ibx.htm#servapi

makhaon2. как узнать параметры OIT, OAT, OST, Next с помощью компонент IBX?
можно разными способами получить. через mon$/tmp$, через IB API, и через TIBStatisticalService. В последнем случае надо парсить текст.

Собственно, более всего непонятно, зачем запускать sweep программно. Его надо запускать административно, и то в моменты, когда в системе наименьшее количество активных транзакций. А это надо мониторить, например утилитой IBTM.

Dimitry Sibiryakov,

у тебя совершенно противоположное моему мнение на запуск sweep. если мое мнение подкреплено практикой и минимум десятками тяжелых систем, где случайно застрявшая oit ВНЕЗАПНО приводит к автосвипу, и вызывает тормоза, то твое мнение я не помню чем подкреплено.
В промышленных БД никаких внезапностей быть не должно, поэтому там автосвип отключать нужно. разрешаю не отключать - на однопользовательских и чахлых системах разве что с десятком пользователей, не больше.

Dimitry Sibiryakov,

объясни мне, зачем в промышленной БД нужен включенный автосвип. Как раз чтобы он случайно сработал?
Или ты отрицаешь, что в базе могут происходить настоящие роллбэки?
И почему sweep нельзя запускать регламентно, если он действительно нужен? Я понимаю, разработчикам рубить пальцы-руки-ноги топором за плохие приложения. Но есть же и legacy, и сторонние.
Ты написал прекрасное приложение, и в результате существуешь в каком-то сферическом мире, который не допускает всего того, что я перечислил.

Гаджимурадов Рустамkdv> поэтому там автосвип отключать нужноА вот тут ты делаешь ровно такое же голословное заявление, как и он. Только с другого конца.
еще раз, для тебя и для тех, у кого не бывает систем больше чем с 10 пользователей. И для всех остальных.

Когда разработчик делает систему, он ее разрабатывает в монопольном режиме. Он имеет смутное представление, как это все будет работать в многопользовательском режиме. Поэтому он не уделяет особого внимания оптимизации запросов, управлению транзакциями, версиям, мусору и прочему на текущий момент для него бреду.
Потом система попадает в промышленную эксплуатацию. И бывают те, кому повезло - то есть, на 10-20 пользователях и хорошем железе система работает еще туда-сюда.
И вот на этих системах, включая нагруженные еще больше, периодически случается такая фигня - вдруг все начинает тормозить на 30 минут, 1 час, или даже 2 часа, а потом "отпускает". Происходить это может в понедельник, среду, или даже четверг, и установить причину этого бывает сложно (якобы).

Так вот эти внезапные и случайные тормоза, в 90% случаев, результат срабатывания АВТОСВИПА.
Я замечу, что мусор в этих системах собирается так или иначе. Например, появляющиеся тормоза в конце дня, или с утра - это все РЕГУЛЯРНЫЕ тормоза, которые людям (пользователям) вроде бы понятны, и которые они могут пережить.
Но вот автосвип, который срабатывает абы как, вносит в работу совершенно ненужную депрессию.

Отключение автосвипа приводит к чему? К тому, что где-то в базе может быть мусор. Еще к тому, что постепенно растет память, потребляемая транзакциями snapshot. И даже если свип не запускать вручную, ничего страшного не происходит.
Вот к примеру, header page от базы некоего казино.
Статистика снята 5 июня 2014 года. Т.е. с момента создания БД прошел год.
Транзакций в сутки тут примерно 300к, так что OIT застряла где-то на третий день, после чего, через год, транзакции snapshot при старте стали аллокировать аж по 27.5 мегабайт памяти под локальный TIP.
И что? И НИЧЕГО.

Что ты, что Сибиряков, никак не могут понять, что
- автосвип стартует в любой произвольный момент времени, как только OST-OIT стало >= 20000.
- свип это скан всей БД, то есть тормоза с момента его запуска до момента его окончания.
- при плохом управлении транзакциями (а я позволю себе заметить, что таких систем примерно 70% от всех систем на ИБ и ФБ, если не больше), автосвип имеет мало шансов успешно завершиться, т.к. активные транзакции могут ему препятствовать.

Таким образом, я делаю вывод, что автосвип - зло по определению для систем более чем с 7-10 пользователей. У кого меньше, могут положить на это дело болт. Или положить болт на все что я сейчас написал, как угодно.
Тем не менее, массу систем советом отключить автосвип мы избавили от этих "случайных тормозов". Разумеется, исправлять управление транзакциями - это дальше на совести разработчиков, но они не всегда исправляют, не всегда доступны, и т.д.
Пользователей систем - больше, чем разработчиков этих систем.

Ну теперь скажи мне, что мое заявление - голословное.

p.s. из вышеизложенного я могу сделать даже куда далее идущий вывод - ЛЮБОЙ процесс в СУБД, который стартует в непредсказуемый момент времени, является вредоносным.

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

kdvСтатистика снята 5 июня 2014 года
2004 года, конечно.

p.s. у меня собрано статистики разной, сейчас посчитал, как минимум по ~400 разным системам, на протяжении 15 лет. Поспорьте еще со мной.

Dimitry SibiryakovТо есть 9 из 10 твоих клиентов присылают тебе выдержку из firebird.log, где есть
совпадающие с точностью до минуты с началом и концом тормозов записи о запуске и окончании
свипа?..
сколько лет существует версия ФБ, в которой данные про свип пишутся в лог ФБ?

Dimitry SibiryakovИли же просто IBTM сообщает о успешном окончании свипа
все гораздо проще. есть тормоза, смотрим статистику, видим застревание OIT, и что автосвип включен. Отключаем автосвип, "внезапные тормоза" пропадают.
Как я уже сказал, про "регулярные тормоза" (с утра или вечером) речь не идет.

Гаджимурадов РустамВдуй щеки обратно. Твоё заявление голословное.
почему оно голословное?

Гаджимурадов РустамКак можно не понимать голословность и глупость утверждения
"В промышленных БД нужно отключать автосвип" ? Про твои
"10 юзеров" и разрешаю я уж и не говорю - смешно, не более.
Не "в большинстве", не "в таких-то условиях", не "рекомендуется",
а "нужно всегда" и всё тут. Тут вы с тёзкоё два брата-акробата.
давай я твой комментарий, как и все остальные, проигнорирую.
Ты уже и так себя зарекомендовал как профессионального демагога, регулярно наводящего тень на плетень.
"научись внимательно читать, что тебе пишут.", и прочая ахинея, вместо конкретного ответа.

К тому же, никому не известно, что Рустам делает на Firebird, какие системы, сколько там пользователей, и так далее. Предлагаю тебе с текущем стилем ответов и комментариев пойти обратно в раздел Дельфи, а тут больше не появляться.
Это просто предложение, ты его можешь проигнорировать, но ты для меня так и останешься "болтологом", не имеющим на свои комментарии никакого основания, абсолютно.

Гаджимурадов РустамСистемы бывают разные, жидкие и газообразные - есть на 15 юзеров с высоким оборотом и CS, а есть и на 70, в которых SS работает и никаких проблем.
да, бывают. Но ПРАКТИКА (которой у тебя нет, я утверждаю, ибо обратных подтверждений нет совсем) говорит о том, что в БОЛЬШИНСТВЕ случаев автосвип лучше все же выключить, и запускать свип регулярно, автоматизированно, в конкретные периоды времени.
Я думаю, что обратного ПРАКТИЧЕСКОГО примера от тебя я не получу, никогда. Поэтому все будущие дискуссии на этом предлагаю считать законченными.

makhaon пока не понятно, что не так на той системе. длинные пишущие транзакции вроде бы все вычищены
здесь вопрос про свип или автосвип вообще не возникал, пока.

Dimitry SibiryakovТанец дождя.
да, вот такой танец. Данные по четыремстам системам собери, а потом будем сравнивать. Согласен, грубовато, зато практично.

makhaonSweep is started by SWEEPER
OIT 2265655, OAT 2265656, OST 2265656, Next 2265657
нафига стартанули sweep, непонятно, потому что OST-OIT = 1

makhaon этот почему-то был относительно долго, и, видимо, очень не вовремя: 13 минут хватило, что бы сервис убили.
непонятно, почему долго. Next за это время выросло всего на 452 транзакции. Впрочем, об интенсивности операций внутри этих транзакций ничего не известно, может они там базу дрюкали. В результате и свип медленно отработал.

Впрочем, даже и по окончании свипа явно видно, что OIT не застревало (ибо и раньше было -1 от OAT и OST, и так же оно и стало), и sweep был запущен "от балды".

Еще раз. sweep нужен только для сборки потенциально присутствующего мусора в БД при застревании OIT, т.е. когда этот маркер не движется вместе с остальными "вверх". Причем, "потенциально присутствующего" - этот мусор может быть, а может и не быть.
Например, взяли, и убили процесс классика, который в базе ничего не менял. OIT застрянет на его транзакции, поскольку сервер не знает, менял этот процесс что-то или нет (вернее, память об изменениях погибла вместе с убитым процессом). В результате sweep если запустить, то он отработает впустую.

GallemarА как в таком случае продвинуть счетчик и собрать мусор?
во-первых, в данном случае никакого мусора нет. во-вторых, зачем продвигать OIT? 18516451