fbserver кушает 100% проца (думаю, это не сборка мусора)
fbserver кушает 100% проца (думаю, это не сборка мусора)
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(!), и сервер сам успокаивается. Прямо как после сборки мусора.
Самое интересное - со всех магазинов/АЗС все данные стекаются в филиальные/центральные базы, размеры которых достигают десятков Гб - проблем никаких, в т.ч. и этих.
Если есть хотябы какие-то мысли, почему такое происходит - говорите, пожалуйста - буду рад всему.
Ну а если подскажете, что можно сделать, чтобы избавиться от этой проблемы - тем более
Заранее всем спасибо.
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(!), и сервер сам успокаивается. Прямо как после сборки мусора.
Самое интересное - со всех магазинов/АЗС все данные стекаются в филиальные/центральные базы, размеры которых достигают десятков Гб - проблем никаких, в т.ч. и этих.
Если есть хотябы какие-то мысли, почему такое происходит - говорите, пожалуйста - буду рад всему.
Ну а если подскажете, что можно сделать, чтобы избавиться от этой проблемы - тем более
Заранее всем спасибо.
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
На этой базе как воспроизвести ?
Версию с кривым запросом проверяли ?
Версию с кривым запросом проверяли ?
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Зайти в нее, например, ч-з IBExpert, и зайти в любую непустую таблицу (например, SHIFTS)hvlad писал(а):На этой базе как воспроизвести ?
В смысле?hvlad писал(а):Версию с кривым запросом проверяли ?
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Так это у тебя свип работает, однозначноOldest transaction 99433782
Oldest active 125576893
Oldest snapshot 125576893
Next transaction 125576894
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
И почему расширение GDB ???
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Похоже, но:hvlad писал(а):Так это у тебя свип работает, однозначно
1. Разве sweep при GCPolicy=cooperative должен запускаться?
2. Почему же он работает часами на маленькой базе?
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
А какая разница? Так изначально было, зачем менять...hvlad писал(а):И почему расширение GDB ???
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Автор, во-первых, прочитай про GDB в Firebird FAQ. У тебя всё правильно сделано?
Во-вторых, каким образом тебе удаётся добиться дырки в 26 миллионов транзакций? При свип-интервале в 20000 к тому же...
Во-вторых, каким образом тебе удаётся добиться дырки в 26 миллионов транзакций? При свип-интервале в 20000 к тому же...
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Проблемы медленного коннекта на 2003 были пройдены много лет назад. Автоматическое обновления я отключаю ВСЕГДА, сразу после установки винды. Везде.WildSery писал(а):Автор, во-первых, прочитай про GDB в Firebird FAQ. У тебя всё правильно сделано?
Это я бы и сам хотел узнать...WildSery писал(а):Во-вторых, каким образом тебе удаётся добиться дырки в 26 миллионов транзакций? При свип-интервале в 20000 к тому же...
Да, забыл указать (может это важно): все программы работают через IBX из D6 с единственным моим изменением в ibsql.pas:
строка
FCursor := Name + RandomString(8);
заменена на
CoCreateGuid( guid );
FCursor := Name + GuidToString( guid );
Но это было уже очень давно... Гораздо раньше появления этой проблемы.
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Что ты знаешь о транзакциях и управлении ими?
Вне зависимости от административного решения проблемы (ночной свип делается?) стоит обратить внимание на то, как работают транзакции в программе.
Вне зависимости от административного решения проблемы (ночной свип делается?) стоит обратить внимание на то, как работают транзакции в программе.
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Затрудняюсь ответить. Что именно ты хочешь узнать?WildSery писал(а):Что ты знаешь о транзакциях и управлении ими?
Нет. Периодически (раз в 2-3 месяца) производится профилактика (полный бэкап-ресторе). В таком ключе система работала годы.Вне зависимости от административного решения проблемы (ночной свип делается?)
В основной программе все транзакции read commited. Создаются в 99% случаев для инсертов (1% - апдейтов), затем - commit или rollback.стоит обратить внимание на то, как работают транзакции в программе.
Но раз в 10 минут запускается программа, которая открывает snapshot и собирает накопившиеся изменения в базе, формирует из них особый пакет, удаляет эти "изменения" из особого места и закрывается. Длится это не молее минуты (обычно 3-5 секунд).
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
есть ряд пожеланий
- статистику выкладывайте запакованную в zip. Только так сохраняется дата файла статистики, и показания IBAnalyst будут более точными
- статистику надо собирать как gstat -a -r. Иначе она практически бесполезна. Хорошо что база есть, взял из нее.
и вопросов:
- что это за система такая, и сколько пользователей, что в базе в сутки стартует миллион транзакций? Причем на протяжении 118 дней, непрерывно. У вас в базе из 60 мегабайт - 31 мегабайт занимает Transaction Inventory Page.
- действительно, каким образом умудрились ни разу не запускать sweep и т.д., что Oldest застряла тридцать дней назад?
- почему в этом случае sweep interval = 20000, а не 0 ?
данных в базе практически нет. мусора (версий) тоже. А вот селективность индексов уехала от реальной процентов на 30-40. Значит данные в таблицах сильно часто обновляются. Но это фигня.
Еще в базе есть три либо битых либо "недоиндексированных" индекса
то есть ключей в индексах 14, а записей в таблице - 2965. причем видно, что одновременно в этой таблице 2951 версий, которые являются признаком удаления. Либо я в IBAnalyst неправ, либо что-то тут не то.
Виснет на открытии базы даже FBFirstAid. Причину пока не знаю, выясним.
Продолжение расследования следует
- статистику выкладывайте запакованную в zip. Только так сохраняется дата файла статистики, и показания IBAnalyst будут более точными
- статистику надо собирать как gstat -a -r. Иначе она практически бесполезна. Хорошо что база есть, взял из нее.
и вопросов:
- что это за система такая, и сколько пользователей, что в базе в сутки стартует миллион транзакций? Причем на протяжении 118 дней, непрерывно. У вас в базе из 60 мегабайт - 31 мегабайт занимает Transaction Inventory Page.
- действительно, каким образом умудрились ни разу не запускать sweep и т.д., что Oldest застряла тридцать дней назад?
- почему в этом случае sweep interval = 20000, а не 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
Виснет на открытии базы даже FBFirstAid. Причину пока не знаю, выясним.
Продолжение расследования следует
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
кстати, абсолютно зря, и автоматическое обновление и gdb не имеют никакой связи.Автоматическое обновления я отключаю ВСЕГДА, сразу после установки винды. Везде.
Необновляемая винда у клиента - источник потенциальной опасности в смысле вирусняков, троянов и т.п. Так что на лицензионной автообновление надо включать всегда и везде.
сколько пользователей одновременно работают с базой, и сколько часов в сутки? вот с этой, с конкретной m_pos. Она тестовая или реальная?В основной программе все транзакции read commited.
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Я прошу прощенья. Под "автоматическое обновление" я имел в виду "восстановление системы", конечно же. ОписАлся.kdv писал(а):кстати, абсолютно зря, и автоматическое обновление и gdb не имеют никакой связи.
Работа идет 24 часа в сутки.сколько пользователей одновременно работают с базой, и сколько часов в сутки? вот с этой, с конкретной m_pos. Она тестовая или реальная?
Из заголовка темы:
Работа с базой происходит следующим образом (в данном случае): один компьютер, коннект чз LOCALHOST:D:\...\m_pos.gdb,
с базой работает несколько приложений, каждое из которых может иметь с ней одновременно несколько соединений (из dll-плугинов и из основной проги).
В одной из программ идет одновременная работа с базой из двух потоков (ч-з 2-й коннект, всё "по науке").
В среднем одновременно получается не более 10 коннектов к этой базе.
Некоторые коннекты висят, пока работает система. Иногда неделями, иногда несколько дней - до перезагрузки компа. Некоторые - временные.
Т.е. пользователь 1 (человек), но коннектов минимум 2, в среднем - около 10. В данном конкретном случае (для именно этой базы) - постоянных (24 часа в сутки) 2, и еще один - запускается раз в 10 минут на несколько секунд (снапшот).
Это реальная база. Которая работала ~3 месяца до 1-го "такого" случая. Сразу же я эту базу забрал (до починки) и сюда выложил.
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Идет постоянное обновление (минимум раз в секунду) окошек топливораздаточных колонок. Некоторые данные, необходимые для этого, берутся из базы. Отсюда и много транзакций.kdv писал(а): - что это за система такая, и сколько пользователей, что в базе в сутки стартует миллион транзакций? Причем на протяжении 118 дней, непрерывно. У вас в базе из 60 мегабайт - 31 мегабайт занимает Transaction Inventory Page.
Это, конечно, может и плохо(что постоянно новые транзакции для этого создаются), но так работало ГОДЫ без единой проблемы.
Чес. говоря, никогда не использовал sweep (специально, вручную). Ну просто не надо было - никаких тормозов не было при любых размерах. Пока не начались такие проблемы 2 года назад. Сейчас приходится регулярно делать бэкап/ресторе.- действительно, каким образом умудрились ни разу не запускать sweep и т.д., что Oldest застряла тридцать дней назад?
- почему в этом случае sweep interval = 20000, а не 0 ?
А на счет почему sweep interval не 0 - надо поставить. Но корень проблемы это вряд ли решит.
Вот как раз после появления в нашей системе этой таблицы (MGT$LOGS) - и начали по-тихотьку появляться такие "зависания". В эту таблицу попадают с помощью триггеров все изменения большинства таблиц (айдишники), которые затем, с поимощью как раз той проги, которая запускается раз в 10 минут и через снапшот делает из этих айдишников пакет изменений и удаляет в ней все записи. После чего закрывает транзакцию и закрывается сама.данных в базе практически нет. мусора (версий) тоже. А вот селективность индексов уехала от реальной процентов на 30-40. Значит данные в таблицах сильно часто обновляются. Но это фигня.
Еще в базе есть три либо битых либо "недоиндексированных" индексато есть ключей в индексах 14, а записей в таблице - 2965. причем видно, что одновременно в этой таблице 2951 версий, которые являются признаком удаления. Либо я в IBAnalyst неправ, либо что-то тут не то.Код: Выделить всё
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
Я и раньше подозревал, что проблема в этом. Но что делать, блин.
У меня это расследование длится уже 3-й год, но только сейчас удалось впоймать такую базу за хвост...Виснет на открытии базы даже FBFirstAid. Причину пока не знаю, выясним.
Продолжение расследования следует
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Свип состоит из нескольких действий.
Собственно сборка мусора пролетает достаточно быстро, меньше минуты точно (я не засекал, лень мне).
Но вот потом свип должен подвинуть OIT. При этом он определяет состояние каждой тр-ции из интервала [OIT - Next] в поисках limbo р-ций.
В данной БД это 26 млн тр-ций. Алгоритм, исползующийся при этом, очень не эффективен (в этой БД) т.к. подразумевает проход по связанному списку страниц TIP в поисках нужного transaction_id. Тут у нас > 1500 страниц. Умножаем это на 26М и делим на 2.
Мораль - делай свип вручную ежедневно.
Собственно сборка мусора пролетает достаточно быстро, меньше минуты точно (я не засекал, лень мне).
Но вот потом свип должен подвинуть OIT. При этом он определяет состояние каждой тр-ции из интервала [OIT - Next] в поисках limbo р-ций.
В данной БД это 26 млн тр-ций. Алгоритм, исползующийся при этом, очень не эффективен (в этой БД) т.к. подразумевает проход по связанному списку страниц TIP в поисках нужного transaction_id. Тут у нас > 1500 страниц. Умножаем это на 26М и делим на 2.
Мораль - делай свип вручную ежедневно.
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
ок. но про последствия застревания OIT при такой частоте транзакций все-таки знать надо.Отсюда и много транзакций.
частично - решит. при коннекте запускается свип, и на скане TIP, вот этой "дыры" в 26 миллионов транзакций, он и виснет. Отключение автосвипа уберет его запуск в случае застревания OIT.Но корень проблемы это вряд ли решит.
А B/R можно было бы делать и почаще, чем раз в 2-3 месяца, потому что он должен происходить пулей - данных-то в 60 метрах всего 4, и 2мб индексов. Заодно это исключит необходимость запуска свипа.
насчет MGT$LOGS - пока неясно, разберемся.
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Это понятно уберу. Ноkdv писал(а):Отключение автосвипа уберет его запуск в случае застревания OIT.
Сейчас виснет при коннекте - это из-за свипа?насчет MGT$LOGS - пока неясно, разберемся.
Еще раз подчеркиваю: это новая база. Изначально B/R не делался годами, и всё прекрасно работало. Только когда уже база была метров под 500-600 - начинало немного притормаживать (терпимо). Тогда делали B/R вместе с обрезкой ненужных данных на заправке.А B/R можно было бы делать и почаще, чем раз в 2-3 месяца, потому что он должен происходить пулей - данных-то в 60 метрах всего 4, и 2мб индексов. Заодно это исключит необходимость запуска свипа.
Просто обидно. Выбрали FB в 2002 году, когда разрабатывали систему, и в течении нескольких лет пришли к выводу, что не ошиблись - всё летало на немалых объемах и плохом железе. Но в последнее время из-за этой проблемы всё больше и больше проблем, аж в душе что-то скребет... И сделать толком ничего не получается...
Ну, если поможет отключение свипа - это будет уже хорошо...
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
разумеется! автосвип включен, разница между транзакциями для его срабатывания есть. Первый коннект - и опа, поехали.Сейчас виснет при коннекте - это из-за свипа?
слюшай, я может абидный вещ скажу, но за дизайном приложения, транзакций и т.п. надо же следить. А то 2-3 года все работало, т.е. разрабатывается давно, и вдруг "ой, а я не думал что автосвип надо отключить".Но в последнее время из-за этой проблемы всё больше и больше проблем, аж в душе что-то скребет...
я уже начинаю слегка злиться. Вы хоть раз свои базы IBAnalyst-ом смотрели?Ну, если поможет отключение свипа - это будет уже хорошо...
Re: fbserver кушает 100% проца (думаю, это не сборка мусора)
Так ведь не ошиблись, раз оно в таких условиях нормально работало столько времениYuRock писал(а):Просто обидно. Выбрали FB в 2002 году, когда разрабатывали систему, и в течении нескольких лет пришли к выводу, что не ошиблись - всё летало на немалых объемах и плохом железе. Но в последнее время из-за этой проблемы всё больше и больше проблем, аж в душе что-то скребет... И сделать толком ничего не получается...
Ну, если поможет отключение свипа - это будет уже хорошо...
OIT застрял и отстаёт от Next на 26млн, при не отключенном авто-свипе. Т.е. авто-свип ничего не мог сделать. А потом вдруг смог (с тормозами, есс-но).
Это означает только одно - приложение держало открытую тр-цию всё то время, пока стартовали эти 26 млн, а потом закрыло её.
Читайте о тр-циях и прочем. И начинать читать нужно было в том самом 2002 году