Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
27.11.2016, 17:00
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
Всем привет. Периодически, раз в пару недель, происходит следующее: нагрузка на процессор возрастает до максимальных значений, что не дает работать с БД Firebird 2.5.1 (нет возможности подключиться через IbExpert и через клиентские приложения). Вот как это выглядит через top (см. аттач) Дополнительная информация: Firebird 2.5.1 CentOS Sweep interval 0 housekeeping 0 Несколько раз делали рестарт службы firebird, не помогало, рестарт сервера также не помог. Служба запускается, но подключиться к БД не удается. Через два часа «танцев с бубнами» закрыли порт 3050, рестартанули субд, проблема ушла, открыли порт, подключились. Любым советам и рекомендациям по устранению причины внезапной утилизации CPU на сервере с субд (или сервера в целом) буду благодарен. Может клиенты массово стали запрашивать соединение и субд не могла стартануть (мне честно, говоря, это предположение не очень нравиться)? Бывало у кого-нибудь такое? Что делали? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
27.11.2016, 17:07
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
May12Firebird 2.5.1А должен быть - 2.5.6 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
27.11.2016, 17:10
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
May12, для начала попробовать обновиться до 2.5.7 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
27.11.2016, 17:11
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
Симонов Денис, ой 2.5.6. 2.5.7 не вышел ещё ... |
|||
:
Нравится:
Не нравится:
|
|||
|
27.11.2016, 17:17
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
May12Sweep interval 0 housekeeping 0 это одно и то же. Насчет 2.5.1 посоветовали верно. Кстати, почему суперклассик, а не классик? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
27.11.2016, 17:54
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
May12Может клиенты массово стали запрашивать соединение и субд не могла стартануть (мне честно, говоря, это предположение не очень нравиться)? Скорее начал чиститься мусор на табличке с плохим индексом, который там накопился в том числе и из-за отключенного autosweep. Снимай периодически и анализируй полную статистику базы с помощью gstat. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.11.2016, 19:27
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
Dimitry Sibiryakov, выгрузил статистику IbAnalyst'ом. Active transactions подсвечены красным. Клиентское приложение долго не закрывает транзакции, как я понимаю. К чему это может привести? Нашел это: Если же количество "действий" велико, то критическим признаком является количество транзакций в сутки начиная от 100 тысяч. Если есть шанс обрыва коннекта, или вдруг появится долго работающая транзакция , то в такой системе моментально накопится мусор и увеличится transaction inventory page, что может привести к неожиданной деградации производительности. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.11.2016, 19:45
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
May12Dimitry Sibiryakov, выгрузил статистику IbAnalyst'ом В кaком месте моего сообщения ты нашёл буквы "IBAnalyst"? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.11.2016, 19:52
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
Dimitry Sibiryakov, да, действительно, таких букв там нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.11.2016, 20:21
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
May12Если есть шанс обрыва коннекта, или вдруг появится долго работающая транзакция, то в такой системе моментально накопится мусор и увеличится transaction inventory page (господи, у меня написано прямо так? ага, надо будет пофиксить). не так. - долго работающая транзакция приводит к накоплению версий, и постепенным тормозам - когда долго работающая транзакция завершается, это приводит к превращению части накопленных версий в мусор, соответственно, другие транзакции могут этот мусор собрать, и когда запрос читает "замусоренные" данные, опять начинаются тормоза - обрыв коннекта обычно не приводит к "повисанию транзакции", сервер или сама сеть такие обрывы детектирует, и завершает коннект на стороне сервера (роллбэком транзакции). У вас там скорее всего или "программист уснул в IBExpert", или в приложениях управление транзакциями такое, что read-write транзакции существуют по пол-дня. полтора гига версий - это не хухры-мухры, где-то 8% от всех данных. Если там еще был мусор от массового удаления, и суперклассик напоролся на их вычистку, то тогда конечно один из коннектов заткнется на этой вычистке. И кстати, принудительное убиение сервера ФБ в этот момент дает вероятность получить поврежденную БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.11.2016, 20:22
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
May12, кстати, 8млн транзакций в сутки - что вы там делаете, и сколько пользователей одновременно работают с базой? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.11.2016, 20:23
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
Dimitry Sibiryakovты нашёл буквы "IBAnalyst"? правильно сделал человек, чего ругаешься? Ты ему еще посоветуй sweep interval включить - то-то он порадуется. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.11.2016, 21:08
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
kdvправильно сделал человек, чего ругаешься? Аналист может сэкономить время для того, кто знает как интерпретировать его выхлоп. В данном случае ему было бы лучше разобраться в первоисточнике - gstat. Просто чтобы понять какая из таблиц скорее всего и привела к затыку сервера до полной невменяемости. PS: Я не знаю, у тебя там есть табличка распределения мусора по таблицам? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.11.2016, 23:11
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
PS: Это один из последних топиков в fiebird-support: накопление мусора и его сборка классиком 2.5 в таблице с первичным ключом на текстовых GUID-ах приводит к впаданию сервера в ступор вплоть до неприёма новых коннектов. Симптомы, как видишь, один к одному. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.11.2016, 23:19
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
И, кстати, там тоже ЦентОС: https://groups.yahoo.com/neo/groups/firebird-support/conversations/topics/129936 Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2016, 00:05
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
Dimitry Sibiryakovу тебя там есть табличка распределения мусора по таблицам? конечно есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2016, 09:51
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
автор8млн транзакций в сутки - что вы там делаете, и сколько пользователей одновременно работают с базой? kdv, автор8млн транзакций в сутки - что вы там делаете учет ведем =) авторсколько пользователей одновременно работают с базой? до 40. Спасибо за Ваши комментарии. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2016, 09:56
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
May12, получается каждый пользователь стартует 200000 транзакций в сутки. Это подозрительно. Такое ощущение что присутствует какой-то массовый импорт, который работает с автоподтверждением транзакции на каждый стейтмент. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2016, 10:27
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
kdv- обрыв коннекта обычно не приводит к "повисанию транзакции", сервер или сама сеть такие обрывы детектирует, и завершает коннект на стороне сервера (роллбэком транзакции).по дефолту 2 часа, пока система сообразит, что все пропало. Собственно вменяемая статья про keepalive у тебя на сайте есть. К прочтению рекомендуется. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2016, 11:39
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
авторприсутствует какой-то массовый импорт, Симонов Денис, да, Вы правы - таких массовых импортов несколько. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2016, 11:41
|
|||
---|---|---|---|
100% утилизация CPU процессом fb_smp_server |
|||
#18+
Ivan_Pisarevskyпо дефолту 2 часа, пока система сообразит, что все пропало. очень похоже на наш случай. Через два часа работа системы возобновляется.... Как избежать такой ситуации? "Рубить" подключения по которым открыты "долгоживущие" транзакции? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2016, 11:49
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
May12, эти массовые импорты надо переделать так чтобы они использовали одну транзакцию, а не по транзакции на запрос. Оно так и работать быстрее будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2016, 12:25
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
May12Как избежать такой ситуации?собственно начать с прочтения статьи, далее решать ваш это случай или не ваш. http://www.ibase.ru/keepalive/ ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2016, 12:28
|
|||
---|---|---|---|
|
|||
100% утилизация CPU процессом fb_smp_server |
|||
#18+
Симонов Денисэти массовые импорты надо переделать так чтобы они использовали одну транзакцию, а не по транзакции на запрос.тут тоже надо не пережать, коммитить каждую строку это аццкийАдЪ, один коммит на ~10 000 записей самое оно, цифирь определить экспериментально на своей системе. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=40&tablet=1&tid=1561825]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 163ms |
0 / 0 |