SQLRU.net
Разработка приложений баз данных
Начало » Использование СУБД » Firebird, HQbird, InterBase » Потеря производительности сервера FB 2.5.9
Потеря производительности сервера FB 2.5.9 [сообщение #170] Tue, 12 July 2022 09:41 Переход к следующему сообщению
H.e.l.p в настоящее время не в онлайне  H.e.l.p
Сообщений: 9
Зарегистрирован: July 2022
Junior Member
Добрый день!

Сервер FireBird 2.5.9, CS
размер БД 0.9Т, кол-во одновременно работающих сессий до 200, кол-во транзакций в сутки порядка 2 млн.

текущая конфигурация
DefaultDbCachePages = 512
TempBlockSize = 2048576
TempCacheLimit = 67108864
LockMemSize = 31457280
LockHashSlots = 30011
DatabaseAccess = None
RemoteServicePort = 3050
RemoteAuxPort = 3052
TempDirectories = e:\temp
FileSystemCacheSize = 50

Появилась проблема потери производительности сервера (операции, которые выполняются в среднем 3-4 минуты начинают выполняться 20-25 минут). После рестарта сервера все работает штатно, однако через некоторый промежуток времени проблема повторяется (15-17 дней) и приходится перегружать сервер опять (уже 2 раза была такая ситуация, раньше сервер работал месяцами и перегружался разве что для обновления винды).

По памяти показатели в норме. По ПЦ -падает утилизация до 30-50 %, кривая графика утилизации становится пилообразной с резкими провалами и взлетами (в штатном режиме такого не наблюдается)

Подскажите, на что обратить внимание.

Известить модератора

Re: Потеря производительности сервера FB 2.5.9 [сообщение #172 является ответом на сообщение #170] Wed, 13 July 2022 12:17 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 330
Зарегистрирован: June 2022
Senior Member
Автосвип?

Известить модератора

Re: Потеря производительности сервера FB 2.5.9 [сообщение #183 является ответом на сообщение #172] Thu, 14 July 2022 12:14 Переход к предыдущему сообщениюПереход к следующему сообщению
H.e.l.p в настоящее время не в онлайне  H.e.l.p
Сообщений: 9
Зарегистрирован: July 2022
Junior Member
Отключен. Выполняется по расписанию на ежедневной основе

Известить модератора

Re: Потеря производительности сервера FB 2.5.9 [сообщение #186 является ответом на сообщение #183] Thu, 14 July 2022 14:38 Переход к предыдущему сообщениюПереход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
Застревают транзакции?
select min(MON$TIMESTAMP), current_timestamp from MON$TRANSACTIONS where MON$READ_ONLY=0
Если отставание больше 5 минут, стоит задуматься.

Известить модератора

Re: Потеря производительности сервера FB 2.5.9 [сообщение #188 является ответом на сообщение #186] Fri, 15 July 2022 07:57 Переход к предыдущему сообщениюПереход к следующему сообщению
H.e.l.p в настоящее время не в онлайне  H.e.l.p
Сообщений: 9
Зарегистрирован: July 2022
Junior Member
MIN CURRENT_TIMESTAMP
15.07.2022 07:11:19 15.07.2022 07:56:22

Известить модератора

Re: Потеря производительности сервера FB 2.5.9 [сообщение #194 является ответом на сообщение #188] Mon, 18 July 2022 04:28 Переход к предыдущему сообщениюПереход к следующему сообщению
fraks в настоящее время не в онлайне  fraks
Сообщений: 139
Зарегистрирован: June 2022
Географическое положение: Новосибирск
Senior Member
Активная транзакция длительностью 45 минут.
Может накапливать версии записей, которые могут вызвать торможение.


Можно:
1. Через таблицы мониторинга выяснить в каком коннекте эта транзакция, и посмотреть что за программа и что там происходит.
2. Рестартовать - транзация завешится, версии отпустятся.

Повторить цикл пока разрыв времени у транзакций не сократится до реальных значений.

Проверить, есть ли торможения. Если нет - то типа нашли причину, и можно начинать борьбу с длинными транзакциями (исправлять исходники).

Известить модератора

Re: Потеря производительности сервера FB 2.5.9 [сообщение #207 является ответом на сообщение #194] Tue, 19 July 2022 14:55 Переход к предыдущему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
Да, как выше написали, делаем выборку
select first 10 a.MON$ATTACHMENT_ID, t.MON$TIMESTAMP, a.MON$REMOTE_HOST, a.MON$REMOTE_OS_USER, a.MON$REMOTE_PROCESS, a.MON$REMOTE_PID
from MON$TRANSACTIONS t
join MON$ATTACHMENTS a on a.MON$ATTACHMENT_ID=t.MON$ATTACHMENT_ID
where t.MON$READ_ONLY=0
order by t.MON$TIMESTAMP
Идём разбираться с зависшими программами (есть столбец с PID, можно на клиентской машине убить процесс через диспетчер задач, если нормально не завершается).
Затем повторяем запрос, убеждаемся что проблема с долго висяшей транзакцией исчезла.

Известить модератора

Предыдущая тема: Update or insert, оптимизация записи
Следующая тема: Kubuntu: непонятки с правами
Переход к форуму:
  

[ Сформировать XML ] [ RSS ] [ PDF ]

Текущее время: Tue Dec 03 20:17:44 GMT+3 2024

Общее время, затраченное на создание страницы: 0.00735 секунд
.:: Обратная связь :: Начало ::.

При поддержке: FUDforum 3.1.3.
© 2001-2022 FUDforum Bulletin Board Software