Почему IB7.01 жрет память и помирает?

[Leon]

Ситуация: Сервер(4 CPU, HyperThreading - выкл.) - ОС Win2000 Adv. Server (SP4)

InterBase 7.01
База данных ~ 4Гб. Размер страницы - 8к. Кэш - 8000 страниц.
С базой активно работают ~ 100 пользователей.
После перезагрузки все приложения летают.
В течении 2-3 часов IB сжирает память (Working Set ~ 450 Mb, Virtual bytes ~ 700Mb), все начинает жутко тормозить, спасает перезагрузка.
Мусора в базе почти нет, sweep interval=0, с транзакциями все OK.

С чем это м.б. связано? Где копать?
Может операционка глючит?
Достаточно активно используется FreeUDFLib.dll (для обработки Blob),
как проверить, м.б. это она?

Уже просто руки опускаются!

[Merlin]

Достаточно активно используется FreeUDFLib.dll (для обработки Blob),
как проверить, м.б. это она?

Это действительно первое подозрение. Проверить так - сделать маленькую апликушку, вызывающую в цикле используемую UDF так же, как основной программе, погнать её и следить за памятью. Повторить со всеми используемыми. Ну и ещё одна общая рекомендация - не держать сутками открытых запросов с большим объёмом данных, особенно извлекаемых процедурами, особенно рекурсивными.

[Leon]

UDF-ку проверил, вроде все нормально.
Больших открытых запросов не держу, процедур не много.
Много тригеров...простеньких.

Че делать то? Где копать?

[Merlin]

С IB7 и с супером вообще в плане ужора памяти я тебе не помощник, извини. Вот kdv проснётся, может скажет чего. Уверен, что именно IB отжирает, а не кеш файловой системы? Forced Writes у IB установлено On?

[kdv]

InterBase 7.01 или 7.1? Надо 7.1 SP2, то есть версию 7.1.0.189.

В течении 2-3 часов IB сжирает память (Working Set ~ 450 Mb, Virtual bytes ~ 700Mb), все начинает жутко тормозить, спасает перезагрузка.

у IB7 есть замечательная вещь - temporary system tables. в которых все про текущее состояние сервера понаписано. для начала можно взять ibanalyst, и посмотреть статистику базы в начале торможения, и через 1 час и через 2 (и прислать нам на support)

Есть у меня ощущение, что ты напоролся на ситуацию, описанную в www.ibase.ru/devinfo/test3.htm, хотя и не факт. Но вообще-то, как показывает практика - IB 7.1 SP2 очень стабильная версия, которая замечательно работает.

[Leon]

Че то я уже окончательно запутываюсь...
temporary system tables (InterBase 7.0.1)- смотрю постоянно, пользуюсь в основном IB PerformanceMonitor 1.1.0(IBAnalist-ом посмотрю сегодня). Используемая IB память постепенно растет, до опред. предела, потом остается на примерно одном уровне. Прямой связи с торможением найти не могу.
Начинаю думать опять на мусор в базе, вот ситуация...
Обед, пользователи не работают, но конекции к базе висят,
идет BACKUP - мои контрольные запросы вып-ся более менее нормально. Заканчивается BACKUP и последующий за ним SWEEP, пользователи не работают - контрольные запросы начинают грузить сервер на 100% и вып-ются но неск. минут. В планах кроме "Execute time = 6m 9s 234ms" ничего не меняется. Вот 2 плана одного запроса по таблице с ~20000 записей:
Plan
PLAN JOIN (A NATURAL,SN INDEX (RDB$PRIMARY34),SS INDEX (RDB$PRIMARY1),SR INDEX (RDB$PRIMARY36),SC INDEX (RDB$PRIMARY33))

Adapted Plan
PLAN JOIN (A NATURAL,SN INDEX (INTEG_68),SS INDEX (INTEG_2),SR INDEX (INTEG_72),SC INDEX (INTEG_66))

------ Performance info ------
Prepare time = 31ms
Execute time = 5s 485ms
Current memory = 285 071 237
Max memory = 344 399 761
Memory buffers = 8 000
Reads from disk to cache = 1 045
Writes from cache to disk = 0
Fetches from cache = 60 420

Plan
PLAN JOIN (A NATURAL,SN INDEX (RDB$PRIMARY34),SS INDEX (RDB$PRIMARY1),SR INDEX (RDB$PRIMARY36),SC INDEX (RDB$PRIMARY33))

Adapted Plan
PLAN JOIN (A NATURAL,SN INDEX (INTEG_68),SS INDEX (INTEG_2),SR INDEX (INTEG_72),SC INDEX (INTEG_66))

------ Performance info ------
Prepare time = 32ms
Execute time = 6m 9s 234ms
Current memory = 275 079 517
Max memory = 344 399 761
Memory buffers = 8 000
Reads from disk to cache = 1 129
Writes from cache to disk = 0
Fetches from cache = 60 420

Первый выполнен во время BACKUP, второй после.
Почему это происходит? Мусор?
Но судя по полям TMP$Record_Purges, TMP$Record_Expunges, TMP$Record_BackOuts темповых таблиц, пользовательские запросы мусор почти не убирают.
А что обозначают TMP$Record_Expunges, TMP$Record_BackOuts ?

[Leon]

Так ни кто, ни чего и не подскажет?
ibanalyst - ничего не прояснил, кроме того, что мусора в базе почти нет.
В "режиме торможения" ib грузит процы на 100% даже если запрос к TMP$STATEMENTS не показывает ни одного выполняющегося в данный момент запроса, пользовательские приложения не ворочаются(как будто это ib5.6 без поддержки SMP). Помогает только полная перезагрузка сервера.

Это м.б. связано с сетью?

[Merlin]

Эвенты и отвалившийся клиент?

[Leon]

Эвенты - не используем.

[kdv]

Используемая IB память постепенно растет

какая именно память? если ты заботишься о памяти - смотри именно за расходом памяти запросов, транзакций и коннектов.
IBPerfMon 1.1 - в общем устаревшее г. надо перфмон из IBConsole смотреть, или новый, но Крэйг его кажись так и не опубликовал.
Поэтому рекомендую написать самописных запросов пусть даже в IBExpert, и следить за сервером именно ими. Обычный перфмон много всякой ненужной дряни показывает, которая только замусоривает глаза.

Это как смотреть живую статистику БД без IBAnalyst.

[Leon]

В принципе, о памяти заботиться смысла нет... На сервере 6Гб оперативки, кроме IB ничего не крутится. W2k Adv.Serv. - по идее, должен давать IB - 2 гига для работы, остальное под кэш. Но больше 600Mб(если DB cache=30000 pages) IB ни разу не съедал.
Почему IB не использует больше памяти?

Судя по TMP$-ным таблицам самые большие POOL-ы:
REQ, TRA ~ max по 110Мб, PRC ~ 11Мб.
Прямой связи между занимаемой IB памятью и "постоянным торможением" не могу найти(при max потреблении памяти IB может и нормально работать, но когда тормозит - то память всегда исп-ся им max). Торможение - больше всего зависит от времени непрерывной работы, 5 часов - предел. Похоже, где то или что то у него или у системы перемыкает, но найти не могу.
Где можно почитать по подробнее, что обозначают названия полей в TMP$POOLS и TMP$POOL_BLOCKS?

Виндовый PerfMon показывает, что на сетевой карте сервера собирается очередь для отправки пакетов(Output Queue Length доходит со временем до ~300-400 пакетов),замена карты и драйверов ничего не изменила. Сет.карта - 1000Мб/с.
Это м.б. причиной замедления работы IB?
Хочу попробовать уменьшить TCP_REMOTE_BUFFER до 4096 в ibconfig...

[Ivan_Pisarevsky]

Виндовый PerfMon показывает, что на сетевой карте сервера собирается очередь для отправки пакетов(Output Queue Length доходит со временем до ~300-400 пакетов),замена карты и драйверов ничего не изменила. Сет.карта - 1000Мб/с.
Это м.б. причиной замедления работы IB?

Мне кажется зависает коммутатор, попробуй в момент тормозов передернуть питание свичу, не трогая сервер, клиенты правда послетают все.
Попробуй другой патчкорд сервер-свич, другую дырку в свиче, зажать скорость до сотки, поменять на время сам свич.
300-400 пакетов в очереди это может быть только при НЕХИЛО нагруженом файл-сервере с быстрой дисковой, для эскуэль сервера явно непорядок.

[Leon]

Это уже 2-й switch, к кот. подключен сервер(любой др. switch в сети может давать такой эфект? как его вычислить?). Патчкорды у сервера меняли, на сотке работали, очередь все равно остается.
М.б. операционка глючит?

Кхм.. Сглазил, только что вылетел гигабитный свитч, опять переходим на 100-ку!

[kdv]

ты результат-то скажи, замены свича на 100мбит. я такую проблему, с жутким замедлением, встречал в одной конторе года три назад. поменяли интел на 3ком, и все начало умирать. Вернули обратно - без проблем. Но - зависит от сетки целиком, то есть от сетевых карт и других "запчастей".

насчет памяти под транзакции и т.п. - ты так и не дал статистику (даже header page) от IBAnalyst в момент хреновой работы

[Ivan_Pisarevsky]

Начни с проверки заземления и электропроводки
Свич вумный? мож намудрил чего с вланами, приоритетами и прочими умностями...

Попробуй воткнуть тупейшую 8139 и присоединить к не менее тупому д-линку, хотя пихать в сервер всякую фигню, может и вредный совет...

[Leon]

куда бросить статистику от IBAnalyst?

Результат замены свитча - НИКАКОЙ! Output Queue length через час уже 542.
(правда я еще дополнительно драйвер на сетевухе поменял, м.б. косячный? Вечером поставлю старый.)

Свич вумный? мож намудрил чего с вланами, приоритетами и прочими умностями...
Попробуй воткнуть тупейшую 8139 и присоединить к не менее тупому д-линку, хотя пихать в сервер всякую фигню, может и вредный совет...

Свитч - умный, но там все по умолчанию... У нас вообще все свитчи умные, кроме одного, и еще одного глупого хаба!
Сейчас в серваке работает встроенная сетевуха, наверное попробую поставить что-нибудь другое.

[Ivan_Pisarevsky]

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

Интеловые сетевухи имеют массу тонких настроек, и если что-то накосячено могут вполне давать такие выкрутасы, поэтому я и говорил про тупую сетевуху ака 8139.

Так, скорее мысли вслух... Не может ИБ ссориться с режимом работы с памятью свыше 4-х гиг, попробовать добавить строчку в бут.ини, чтоб винда не видела свыше 4-х гиг?

Нагни электриков прозвонить электропроводку, у меня пяток хабов сгореть успело пока я начальство дожал на нормальную проводку, колбасило так, что мама не горюй.

[kdv]

куда бросить статистику от IBAnalyst?

я сейчас скажу куда... в IBA есть help, это во-первых. А во-вторых, есть прямо в меню хелп соответствующий пункт "написать нам письмо".

p.s. извините конечно за излишнюю нервозность, но подобные вопросы меня иногда просто бесят...

[Leon]

я сейчас скажу куда... в IBA есть help, это во-первых. А во-вторых, есть прямо в меню хелп соответствующий пункт "написать нам письмо".

Спасибо! Сейчас сброшу(ох, не до хелпов мне сейчас!)...

p.s. извините конечно за излишнюю нервозность, но подобные вопросы меня иногда просто бесят...

Ничего страшного! Я сам в последнее время нервным стал(постоянные перезагрузки сервера и крики руководства, спокойствия не добавляют).

Так, скорее мысли вслух... Не может ИБ ссориться с режимом работы с памятью свыше 4-х гиг, попробовать добавить строчку в бут.ини, чтоб винда не видела свыше 4-х гиг?

Уже пробовал.Не помогает.

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

Интеловые сетевухи имеют массу тонких настроек, и если что-то накосячено могут вполне давать такие выкрутасы, поэтому я и говорил про тупую сетевуху ака 8139.

Кажется вопрос с очередью на сет.карте - решился!
Уже прошел час после перезагрузки, output queue length=0.

[Ivan_Pisarevsky]

Поделись попозже как полет проходит, ну и как проблему одолел, а то ить интересно