Использование IB7.5

_so_ · Сообщение **_so_** » 15 апр 2005, 10:58

Решился я все таки запустить IB7.5 на серваке в своей фирме (отчасти чтобы дать клиентам рекомендации) локально уже тестирую с января и не каких проблем не использовал. На нашем серваке и нагрузка-то небольшая ну максимум пользователей 25.

Код: Выделить всё

CONSBASE (Server)	Wed Apr 13 09:01:15 2005
	Server: setting SWEEP_QUANTUM to 250, USER_QUANTUM to 1000,
                SWEEP_YIELD_TIME to 1 ms, and MAX_THREADS to 1000000
                SQL_COMPILER_RECURSION to 2000


CONSBASE (Client)	Wed Apr 13 09:01:16 2005
	Guardian starting: F:\IB75\bin\ibserver.exe


CONSBASE (Client)	Thu Apr 14 16:01:54 2005
	INET/inet_error: read errno = 10053 client host = UNKNOWN connection name = localhost user name = UNKNOWN

CONSBASE (Client)	Thu Apr 14 16:26:42 2005
	REMOTE INTERFACE/gds__detach: Unsuccessful detach from database. 
	Uncommitted work may have been lost

К даному времни он уже сожрал 600 Мб памяти.
Через IBConsole монитор показал что больше всего сожрал память на:
TRA: Transaction Manager 554 814 КВ
Может для него что-нибудь нужно делать в настройках дополнительно или еще чего-нибудь.
При использовании 7.1 SP2 этого не было. Были утечки памяти в ХП конешно. Но блил они написали что их исправили.
Наверное придется откатываться.

Сообщение **kdv** » 15 апр 2005, 22:48

IBAnalyst. смотреть, что там с транзакциями. Небось, CommitRetaining пользуете?

_so_ · Сообщение **_so_** » 16 апр 2005, 09:41

CommitRetaining пользуем. Но потранзакциям смотрел вроде ничего страшного не увидел. В понедельник получу статистику.

_so_ · Сообщение **_so_** » 18 апр 2005, 16:25

Параметр Значение
Дата создания 13.04.2005
Дата получения статистики 18.04.2005
Page size 16384
Forced Write OFF
Диалект 1
OnDiskStructure 11.2
Sweep interval 20000
Oldest transaction 22227
Oldest snapshot 24344
Oldest active 24344
Next transaction 27171
Sweep gap (active - oldest) 2117
Размер TIP для Snapshot 4944 транзакций, 17 килобайт
Active transactions 2827, 62% от ежедневных
Транзакций в день 4528, за 6 дней
Процент версий данных 0.05% - записей: 218 mb, версий: 0 mb, страниц 343 mb

Вот статистика.
Я не помню по чему когда-то перешли на CommitRetaining.
Это было когда использовали толь Ib5.5 или IB 5.6 или Ib6.0 (точно не помню) и там была проблема если очень часто открывать закрывать транзакции (легкие), то текли ресурсы по ниткам. Решение прогблемы было перейти на CommitRetaining.

Сообщение **kdv** » 18 апр 2005, 17:05

перешли на CommitRetaining.
Это было когда использовали толь Ib5.5 или IB 5.6 или Ib6.0 (точно не помню) и там была проблема если очень часто открывать закрывать транзакции

гм. не помню таких проблем. тем более что вы-то сейчас 7.5 пользуете. По статистике IBA подозрительное только вот:

Active transactions 2827, 62% от ежедневных
Транзакций в день 4528, за 6 дней

похоже на ваш CommitRetaining. Транзакции очень длинные, накапливается дикое количество savepoints. Точнее можно посмотреть только в IBPerfMon. Кстати, меня несколько удивляет, что люди никак не могут истолковать его показания (данные врем. системных таблиц).
Такое впечатление, что придется еще один вариант IBAnalyst писать специально для 7.1/7.5.

то текли ресурсы по ниткам

в смысле?

_so_ · Сообщение **_so_** » 18 апр 2005, 19:13

.

Транзакции очень длинные, накапливается дикое количество savepoints

Не понял. savepoints не используется.

в смысле?

Количество ниток используемых IB увеличалось постояно и IB их не отдавал. А потом система начинала безбожно тормозить.
На каких задачах это точно проявлялось не помню (это было лет 6 назад). И тогда за работу с БД я не отвечал.

Уйти CommitRetaining можно попробовать. Завтра займусь.

Но от длиных транзаций на чтение не избавишься. Человек открыл запрос прокачал часть данных и ушел гулять

Merlin · Сообщение **Merlin** » 18 апр 2005, 19:25

_so_ писал(а):.
Транзакции очень длинные, накапливается дикое количество savepoints
Не понял. savepoints не используется.

Сервер тебя не спрашивает, как ему их использовать

А явное управление ими в последних версиях - просто вытянутая наружу рукоятка к низкоуровневому механизму, который внутри работал с рождества Джимова. Атомарность оператора, транзакции, конструкции when, suspend - всё они, родимые, savepoints. А поскольку retaining сохраняет контекст транзакции, то и их за собой тянет.

_so_ писал(а): Но от длиных транзаций на чтение не избавишься. Человек открыл запрос прокачал часть данных и ушел гулять

А read_commited read транзакции на что нам дадены? Вот для этого самого и дадены. И никаких ресурсов за собой не тянут.

Сообщение **kdv** » 18 апр 2005, 19:27

на тему длинных транзакций - если у вас там ВСЕГО за сутки 4 тысячи транзакций, а oldest active на 2 тыщи меньше Next, то IBA об этом и говорит - что есть какая то длинная с точки зрения данных цифр транзакция (или несколько). Длинные там они или не длинные в другом понимании - это дело десятое.

Количество ниток используемых IB увеличалось постояно и IB их не отдавал.

вот не помню такого, в упор. если только своими хитрыми udf не баловались. IB суперсервер вообще всегда кол-во ниток уменьшал (с момента пика числа коннектов).

Уйти CommitRetaining можно попробовать.

я пишу про мониторинг в IBPerfmon или ibconsole. То есть, мы его смотреть не будем, сразу рубанем код топором?

Но от длиных транзаций на чтение не избавишься. Человек открыл запрос прокачал часть данных и ушел гулять

я из лесу вышел.... про read read_committed не в курсе?

Сообщение **kdv** » 18 апр 2005, 19:33

и еще. я лично наблюдал систему с 7.1 SP2 вживую которая 4 тыщи активных транзакций нагенерила за 1.5 часа двумя клиентскими местами. И серверу хоть бы что (да в общем я и сам как то в порядке эксперимента в приложении открыл 5 тысяч транзакций, потом надоело). Там к концу дня просто вылет был с клиента по нехватке хэндлов. Поэтому чем там у вас 2000 транзакций 600 мег отъедают - это надо разбираться, дотошно. через tmp$transactions и др.

_so_ · Сообщение **_so_** » 18 апр 2005, 23:40

Блин что мне про 7.1 sp2 говорить, на нем этой проблемы не было.
На нем текли хранимые процедуры это факт. В 7.5 обещали исправить, но видно добавили что-то новое. Я конечно сомневаюсь, что поможет, если уйти от CommitRetaining.

_so_ · Сообщение **_so_** » 18 апр 2005, 23:48

Насчет read_commited все я в курсе. раньше он и использавлся. Я не могу знать и не помню почему бывший работник перешел на CommitRetaining.

Сообщение **kdv** » 19 апр 2005, 10:49

в таком ключе дальше продолжать бессмысленно. Если хочется понять проблему, то надо мониторить сервер, включая tmp$heaps. Если не хочется - откатываемся молча на 7.1 SP2.

_so_ · Сообщение **_so_** » 19 апр 2005, 13:25

Согласен. Попробую выяснить на каких пользователях течет и что они делают.
Проверил насчет утечек памятив хранимых проц. По моему стало еще хуже.

Код: Выделить всё

Type                         Pools  Total      Free      Extend amt.  Free stack nodes  Free bitmap buckets  Free bitmap segments  
CCH: Cache mgr/page buffers  1      33842176   1136      16384        0                 0                    0                     
DYN: Internal DDL            27     114688     22960     1024         198               21                   49                    
IRQ: Int. metadata queries   55     279552     57200     1024         413               58                   98                    
PRC: Procedure requests      520    482694144  53098800  1024         7450              -23223               2679658               
PRM: Metadata structures     1      1228800    75392     16384        5                 4                    16                    
REQ: Compiled user queries   21     147456     20864     1024         325               32                   39                    
SQL: SQL interface           9      56320      4664      1024         0                 0                    0                     
SRT: Sort memory             2      2097000    0         0            0                 0                    0                     
TRA: Transaction manager     3      1418240    100532    1024         8                 18                   96                    
TRG: Trigger requests        92     326656     113684    1024         169               70                   77                    
                                    522205032  53495232

Это за три минуиы работы одним конектом. После того как за 10 минут сожрал 1 Гб памяти срубил. Ждать освободит или нет не смог все встало.
Алгоритм простой создается хранимая процедура в ней делается один запрос агрегация и вставляются данные в другую таблицу. Потом ХП удаляется. И алгоритм повторяется многократно для разных видов агрегаций. Если без хранимых процедур, то все живет замечательно, как и с ними до 7.1.
Так-что в ReleaseNotes.pdf либо наврали либо они исправили, но не то (А я им поверил).
С тем поразбираюсь еще денек, не получиться откачусь.

Сообщение **kdv** » 19 апр 2005, 13:31

пример для воспроизведения на support кинь, если можешь изготовить.

Merlin · Сообщение **Merlin** » 19 апр 2005, 13:43

_so_ писал(а): Алгоритм простой создается хранимая процедура в ней делается один запрос агрегация и вставляются данные в другую таблицу. Потом ХП удаляется. И алгоритм повторяется многократно для разных видов агрегаций.

Для полноты картины надо бы указать моменты старта транзакций и коммитов. И hard они или или всё-таки retaining. А то сразу возникают грубые подозрения

Ivan_Pisarevsky

Алгоритм простой создается хранимая процедура в ней делается один запрос агрегация и вставляются данные в другую таблицу. Потом ХП удаляется. И алгоритм повторяется многократно для разных видов агрегаций.

Это в процессе работы постоянно передергиваются метаданные? Ну и гемор... На параметрах не получается сделать?

_so_ · Сообщение **_so_** » 19 апр 2005, 15:56

На параметрах не реально. Слишком разные запросы агрегации.

Ivan_Pisarevsky

Как насчет вопроса Мерлина про транзакции, после каждого телодвижения с метаданными должон быть коммит. Он есть?

_so_ · Сообщение **_so_** » 19 апр 2005, 16:57

Есть. Но CommitRetaining

Merlin · Сообщение **Merlin** » 19 апр 2005, 17:38

_so_ писал(а):Есть. Но CommitRetaining

Честно говоря, даже не знаю, как оператор DDL ведёт себя с этим извратом. Они ведь на самом деле выполняются на коммите, а до того просто параметры для выполнения пишутся в системные таблицы. А тут - изменения вроде бы и подтверждены, но весь контекст с областью видимого должен сохраниться... Эту хрень придумали, насколько я понимаю, для обеспечения автокоммитного режима BDE, чтоб открытые датасеты не схлопывались. То есть, для упрощения программирования на клиенте ввели полухак в сервер. А потом естественным образом, вместо акцентирования вовремя внимания на кеширующих датасетах типа TClientDataSet (где это допустимо по условиям применения) и внедрения второй транзакции в обычный датасет, потащили этот изврат во все остальные либы. Так что ну его нафик, есть большая вероятность, что всё станет на место если перейдёшь на хард коммит.