Firebird 2.0.2 SuperServer
GCPolicy combined
На клиентских местах транзакции на чтение "READ ONLY READ COMMITTED
RECORD_VERSION"
на update, delete "READ WRITE WAIT READ COMMITTED RECORD_VERSION".
Снимали статистику раз в час gstat -h, если посчитать количество
транзакций, то явных всплесков нет. Около 35000 транзакций в час.
Статистика gstat -a -r полученная непосредственно в момент проблемы:
"Отчет IBAnalyst 1.9.5.1, 25.06.2009 14:32:05
База данных: /opt/storage/DATABASE.fdb

· Forced Write (синхронное обновление) выключено (OFF). Это может
быть опасным, в особенности на ОС Windows. Будьте осторожны и
используйте UPS для защиты питания сервера. FW OFF сильно увеличивает
вероятность повреждения базы данных в случае сбоя. Если произойдет
сбой операционной системы или оборудования, либо сбой по питанию,то
база данных будет повреждена. Мы рекомендуем установить Forced Write
в ON (gfix -write sync).

· Ваша база данных работает 749 дней, и среднее число транзакций в
день - 471381.

· Текущий размер страницы базы данных = 16384 байт.

--------------------------------------------------------
Фрагментированных таблиц: 2.
Фрагментация таблиц может ухудшить производительность. Вам нужно
следить за перечисленными таблицами - если фрагментация будет
усиливаться  с течением времени, то нужно сделать backup/restore. Вот
список таблиц размером более 200 килобайт и средней фрагментацией
менее 60%.

 TABLE_1                      : 36%, Записей       999, Страниц     17
 TABLE_2                     : 57%, Записей      1403, Страниц     17

--------------------------------------------------------"
В момент проблемы резко возрастает нагрузка на процессор, и как
следствие более медленное выполнение всех запросов. Никаких особенных
запросов не запускалось. Характер запросов к базе идентичный весь
день, нет каких то особенных периодов закачки/обработки данных.
Вообщем то решили перезапуском одного из рабочих мест, т.е.
предположительно оно генерировало некие запросы влиявшие на общую
картину, но не можем понять как именно и какие запросы. В принципе
именно у него характер запросов несколько отличный от остальных, в
частности там регулярно перечитывается одна и та же таблица. После
перезапуска всё стало абсолютно нормально. Причем это был именно
перезапуск, т.е. оно продолжило делать те же запросы с той же частотой
и на те же данные.
Sweep interval 0, и в этот момент gfix -sweep не запускался. Также не
было запущенно ни одного процесса через cron и вообще на сервер
выполнялся стандартный набор процессов.
Почему резко возросла нагрузка на процессор ? Запросы от этого
рабочего места "попадали" на сборку мусора ? На что еще нужно обратить
внимание ?

Reply via email to