iBase.ru Forum

Win 2000, XP Pro, Home...
SS (на CS такой проблемы нет (хотя тестов было мало), но CS и не совсем подходит)
FB 1.5.*, 2.0.*, 2.1.*
Dialect 1
EVENT'ов нет
foreign key'ев нет
Антивирусов нет
Фаерволов нет

Немного предистории.
Программа работает с 2003 года. Сотни мазазинов и АЗС в Украине.
Изначально работала на FB 1.0.* - подобных проблем не возникало.
В 2007 году появились первые "ласточки". Но тогда я думал, что это из-за
уже довольно большого размера баз (за несколько лет базы выросли до 400-600Мб).
Но сейчас такие проблемы начали встречаться все чаще, и даже на только что созданных
базах, которые работают около месяца (размером в 30-50Мб).

Итак: ни с того, ни с сего fbserver.exe начинает жрать 100% проца при коннекте к базе (любом - в т.ч. из IBExpert, gbak...).
Иногда - не сразу при коннекте, а при попытке просмотреть данные любой не пустой таблицы(как в данном примере).

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

Вот база:
http://www.utncard.com/bugs/M_POS_100p.rar
(архив 10Мб)

Вот статистика:
http://www.utncard.com/bugs/stat_100p.txt

Работа с базой происходит следующим образом (в данном случае): один компьютер, коннект чз LOCALHOST:D:\...\m_pos.gdb,
с базой работает несколько приложений, каждое из которых может иметь с ней одновременно несколько соединений (из dll-плугинов и из основной проги).
В одной из программ идет одновременная работа с базой из двух потоков (ч-з 2-й коннект, всё "по науке").
В среднем одновременно получается не более 10 коннектов к этой базе.
Некоторые коннекты висят, пока работает система. Иногда неделями, иногда несколько дней - до перезагрузки компа. Некоторые - временные.

С появлением FB 2.0 я экспериментировал с GCPolicy - ставил любые варианты - всё безуспешно.
Заметил: если такое с базой произошло - то будет происходить и позже примерно раз в месяц. Но есть базы, огромные, с которыми за многие годы такого не было и нет.

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

Да, совсем забыл сказать. Лечится это с помощью бубна: иногда помогает перезапустить компьютер (раз 5 или 8 ), иногда - бэкап/рестор (если удастся).
Чаще всего - подождать минут 40-240(!), и сервер сам успокаивается. Прямо как после сборки мусора.

Самое интересное - со всех магазинов/АЗС все данные стекаются в филиальные/центральные базы, размеры которых достигают десятков Гб - проблем никаких, в т.ч. и этих.

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

Заранее всем спасибо.

На этой базе как воспроизвести ?
Версию с кривым запросом проверяли ?

hvlad писал(а):На этой базе как воспроизвести ?

Зайти в нее, например, ч-з IBExpert, и зайти в любую непустую таблицу (например, SHIFTS)

hvlad писал(а):Версию с кривым запросом проверяли ?

В смысле?

Oldest transaction 99433782
Oldest active 125576893
Oldest snapshot 125576893
Next transaction 125576894

Так это у тебя свип работает, однозначно

И почему расширение GDB ???

hvlad писал(а):Так это у тебя свип работает, однозначно

Похоже, но:
1. Разве sweep при GCPolicy=cooperative должен запускаться?
2. Почему же он работает часами на маленькой базе?

hvlad писал(а):И почему расширение GDB ???

А какая разница? Так изначально было, зачем менять...

Автор, во-первых, прочитай про GDB в Firebird FAQ. У тебя всё правильно сделано?
Во-вторых, каким образом тебе удаётся добиться дырки в 26 миллионов транзакций? При свип-интервале в 20000 к тому же...

WildSery писал(а):Автор, во-первых, прочитай про GDB в Firebird FAQ. У тебя всё правильно сделано?

Проблемы медленного коннекта на 2003 были пройдены много лет назад. Автоматическое обновления я отключаю ВСЕГДА, сразу после установки винды. Везде.

WildSery писал(а):Во-вторых, каким образом тебе удаётся добиться дырки в 26 миллионов транзакций? При свип-интервале в 20000 к тому же...

Это я бы и сам хотел узнать...

Да, забыл указать (может это важно): все программы работают через IBX из D6 с единственным моим изменением в ibsql.pas:
строка
FCursor := Name + RandomString(8);
заменена на
CoCreateGuid( guid );
FCursor := Name + GuidToString( guid );

Но это было уже очень давно... Гораздо раньше появления этой проблемы.

Что ты знаешь о транзакциях и управлении ими?
Вне зависимости от административного решения проблемы (ночной свип делается?) стоит обратить внимание на то, как работают транзакции в программе.

WildSery писал(а):Что ты знаешь о транзакциях и управлении ими?

Затрудняюсь ответить. Что именно ты хочешь узнать?

Вне зависимости от административного решения проблемы (ночной свип делается?)

Нет. Периодически (раз в 2-3 месяца) производится профилактика (полный бэкап-ресторе). В таком ключе система работала годы.

стоит обратить внимание на то, как работают транзакции в программе.

В основной программе все транзакции read commited. Создаются в 99% случаев для инсертов (1% - апдейтов), затем - commit или rollback.
Но раз в 10 минут запускается программа, которая открывает snapshot и собирает накопившиеся изменения в базе, формирует из них особый пакет, удаляет эти "изменения" из особого места и закрывается. Длится это не молее минуты (обычно 3-5 секунд).

есть ряд пожеланий
- статистику выкладывайте запакованную в zip. Только так сохраняется дата файла статистики, и показания IBAnalyst будут более точными
- статистику надо собирать как gstat -a -r. Иначе она практически бесполезна. Хорошо что база есть, взял из нее.

и вопросов:
- что это за система такая, и сколько пользователей, что в базе в сутки стартует миллион транзакций? Причем на протяжении 118 дней, непрерывно. У вас в базе из 60 мегабайт - 31 мегабайт занимает Transaction Inventory Page.
- действительно, каким образом умудрились ни разу не запускать sweep и т.д., что Oldest застряла тридцать дней назад?
- почему в этом случае sweep interval = 20000, а не 0 ?

данных в базе практически нет. мусора (версий) тоже. А вот селективность индексов уехала от реальной процентов на 30-40. Значит данные в таблицах сильно часто обновляются. Но это фигня.

Еще в базе есть три либо битых либо "недоиндексированных" индекса то есть ключей в индексах 14, а записей в таблице - 2965. причем видно, что одновременно в этой таблице 2951 версий, которые являются признаком удаления. Либо я в IBAnalyst неправ, либо что-то тут не то.

Виснет на открытии базы даже FBFirstAid. Причину пока не знаю, выясним.

Продолжение расследования следует

Автоматическое обновления я отключаю ВСЕГДА, сразу после установки винды. Везде.

кстати, абсолютно зря, и автоматическое обновление и gdb не имеют никакой связи.
Необновляемая винда у клиента - источник потенциальной опасности в смысле вирусняков, троянов и т.п. Так что на лицензионной автообновление надо включать всегда и везде.

В основной программе все транзакции read commited.

сколько пользователей одновременно работают с базой, и сколько часов в сутки? вот с этой, с конкретной m_pos. Она тестовая или реальная?

kdv писал(а):кстати, абсолютно зря, и автоматическое обновление и gdb не имеют никакой связи.

Я прошу прощенья. Под "автоматическое обновление" я имел в виду "восстановление системы", конечно же. ОписАлся.

сколько пользователей одновременно работают с базой, и сколько часов в сутки? вот с этой, с конкретной m_pos. Она тестовая или реальная?

Работа идет 24 часа в сутки.
Из заголовка темы:
Работа с базой происходит следующим образом (в данном случае): один компьютер, коннект чз LOCALHOST:D:\...\m_pos.gdb,
с базой работает несколько приложений, каждое из которых может иметь с ней одновременно несколько соединений (из dll-плугинов и из основной проги).
В одной из программ идет одновременная работа с базой из двух потоков (ч-з 2-й коннект, всё "по науке").
В среднем одновременно получается не более 10 коннектов к этой базе.
Некоторые коннекты висят, пока работает система. Иногда неделями, иногда несколько дней - до перезагрузки компа. Некоторые - временные.

Т.е. пользователь 1 (человек), но коннектов минимум 2, в среднем - около 10. В данном конкретном случае (для именно этой базы) - постоянных (24 часа в сутки) 2, и еще один - запускается раз в 10 минут на несколько секунд (снапшот).

Это реальная база. Которая работала ~3 месяца до 1-го "такого" случая. Сразу же я эту базу забрал (до починки) и сюда выложил.

kdv писал(а): - что это за система такая, и сколько пользователей, что в базе в сутки стартует миллион транзакций? Причем на протяжении 118 дней, непрерывно. У вас в базе из 60 мегабайт - 31 мегабайт занимает Transaction Inventory Page.

Идет постоянное обновление (минимум раз в секунду) окошек топливораздаточных колонок. Некоторые данные, необходимые для этого, берутся из базы. Отсюда и много транзакций.
Это, конечно, может и плохо(что постоянно новые транзакции для этого создаются), но так работало ГОДЫ без единой проблемы.

- действительно, каким образом умудрились ни разу не запускать sweep и т.д., что Oldest застряла тридцать дней назад?
- почему в этом случае sweep interval = 20000, а не 0 ?

Чес. говоря, никогда не использовал sweep (специально, вручную). Ну просто не надо было - никаких тормозов не было при любых размерах. Пока не начались такие проблемы 2 года назад. Сейчас приходится регулярно делать бэкап/ресторе.
А на счет почему sweep interval не 0 - надо поставить. Но корень проблемы это вряд ли решит.

данных в базе практически нет. мусора (версий) тоже. А вот селективность индексов уехала от реальной процентов на 30-40. Значит данные в таблицах сильно часто обновляются. Но это фигня.

Еще в базе есть три либо битых либо "недоиндексированных" индекса

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

	IDX_MGT$LOGS_STATUS (MGT$LOGS)	Records: 2965, Keys: 14, Difference - 2951
	IDX_MGT$LOGS_TABLE (MGT$LOGS)	Records: 2965, Keys: 14, Difference - 2951
	PK_MGT$LOGS (MGT$LOGS)	Records: 2965, Keys: 14, Difference - 2951

то есть ключей в индексах 14, а записей в таблице - 2965. причем видно, что одновременно в этой таблице 2951 версий, которые являются признаком удаления. Либо я в IBAnalyst неправ, либо что-то тут не то.

Вот как раз после появления в нашей системе этой таблицы (MGT$LOGS) - и начали по-тихотьку появляться такие "зависания". В эту таблицу попадают с помощью триггеров все изменения большинства таблиц (айдишники), которые затем, с поимощью как раз той проги, которая запускается раз в 10 минут и через снапшот делает из этих айдишников пакет изменений и удаляет в ней все записи. После чего закрывает транзакцию и закрывается сама.

Я и раньше подозревал, что проблема в этом. Но что делать, блин.

Виснет на открытии базы даже FBFirstAid. Причину пока не знаю, выясним.
Продолжение расследования следует

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

Свип состоит из нескольких действий.

Собственно сборка мусора пролетает достаточно быстро, меньше минуты точно (я не засекал, лень мне).

Но вот потом свип должен подвинуть OIT. При этом он определяет состояние каждой тр-ции из интервала [OIT - Next] в поисках limbo р-ций.
В данной БД это 26 млн тр-ций. Алгоритм, исползующийся при этом, очень не эффективен (в этой БД) т.к. подразумевает проход по связанному списку страниц TIP в поисках нужного transaction_id. Тут у нас > 1500 страниц. Умножаем это на 26М и делим на 2.

Мораль - делай свип вручную ежедневно.

Отсюда и много транзакций.

ок. но про последствия застревания OIT при такой частоте транзакций все-таки знать надо.

Но корень проблемы это вряд ли решит.

частично - решит. при коннекте запускается свип, и на скане TIP, вот этой "дыры" в 26 миллионов транзакций, он и виснет. Отключение автосвипа уберет его запуск в случае застревания OIT.
А B/R можно было бы делать и почаще, чем раз в 2-3 месяца, потому что он должен происходить пулей - данных-то в 60 метрах всего 4, и 2мб индексов. Заодно это исключит необходимость запуска свипа.

насчет MGT$LOGS - пока неясно, разберемся.

kdv писал(а):Отключение автосвипа уберет его запуск в случае застревания OIT.

Это понятно уберу. Но

насчет MGT$LOGS - пока неясно, разберемся.

Сейчас виснет при коннекте - это из-за свипа?

А B/R можно было бы делать и почаще, чем раз в 2-3 месяца, потому что он должен происходить пулей - данных-то в 60 метрах всего 4, и 2мб индексов. Заодно это исключит необходимость запуска свипа.

Еще раз подчеркиваю: это новая база. Изначально B/R не делался годами, и всё прекрасно работало. Только когда уже база была метров под 500-600 - начинало немного притормаживать (терпимо). Тогда делали B/R вместе с обрезкой ненужных данных на заправке.

Просто обидно. Выбрали FB в 2002 году, когда разрабатывали систему, и в течении нескольких лет пришли к выводу, что не ошиблись - всё летало на немалых объемах и плохом железе. Но в последнее время из-за этой проблемы всё больше и больше проблем, аж в душе что-то скребет... И сделать толком ничего не получается...
Ну, если поможет отключение свипа - это будет уже хорошо...

Сейчас виснет при коннекте - это из-за свипа?

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

Но в последнее время из-за этой проблемы всё больше и больше проблем, аж в душе что-то скребет...

слюшай, я может абидный вещ скажу, но за дизайном приложения, транзакций и т.п. надо же следить. А то 2-3 года все работало, т.е. разрабатывается давно, и вдруг "ой, а я не думал что автосвип надо отключить".

Ну, если поможет отключение свипа - это будет уже хорошо...

я уже начинаю слегка злиться. Вы хоть раз свои базы IBAnalyst-ом смотрели?

YuRock писал(а):Просто обидно. Выбрали FB в 2002 году, когда разрабатывали систему, и в течении нескольких лет пришли к выводу, что не ошиблись - всё летало на немалых объемах и плохом железе. Но в последнее время из-за этой проблемы всё больше и больше проблем, аж в душе что-то скребет... И сделать толком ничего не получается...
Ну, если поможет отключение свипа - это будет уже хорошо...

Так ведь не ошиблись, раз оно в таких условиях нормально работало столько времени
OIT застрял и отстаёт от Next на 26млн, при не отключенном авто-свипе. Т.е. авто-свип ничего не мог сделать. А потом вдруг смог (с тормозами, есс-но).
Это означает только одно - приложение держало открытую тр-цию всё то время, пока стартовали эти 26 млн, а потом закрыло её.
Читайте о тр-циях и прочем. И начинать читать нужно было в том самом 2002 году