Фб 3.0.4
Суперсервер
База большая, бэкап рестор в вс выполнен. Размер файла 170 гб
На сервере 512 гб озу, 56 физических ядер
Кэш настроен на 20 000 000 страниц по 8192 байт
Одновременных подключений до 250

Все работало ок до вчерашнего дня.

С сегодняшнено дня фб зависает, все процессы фб показывают 100% загрузку процессора.

Подскажите, что это может быть?

Сейчас попытаемся выполнить gfix на проверку файла.

В темп папке все файлы сортировки имеют нулевую длину.

hvlad,

сорри, ошибся. там супер сервер, один процесс забивает 56 ядер под 100%

параметры сейчас сюда скинут.

проблема в том, что с такими цифрами сервер отлично работал с марта прошлого года. без перезагрузок и даже без бэкап/рестора.

зависание началось РЕЗКО с сегодняшнего дня.

пока не можем сделать gfix. через пару часов появится возможность

идея настройки сервера простая:

1) кэш фб, чтобы влезла ВСЯ база
2) 64 гб под буффер сортировки фб
3) ВКЛЮЧЕННЫЙ кэш ОС, чтобы сортировки, которые не влезли в буфер фб, кэшировались на уровне ОС. Благо для этого осиается еще 256 Гб ОЗУ. Еще раз повторюсь, до вчерашнего дня такая конфигурация отработала почти год. И работала шустро.

dimitr,

будем знать.

полезно было бы такую инфу закинуть в дефолтный firebird.conf.

dimitrsysdba223) ВКЛЮЧЕННЫЙ кэш ОС, чтобы сортировки, которые не влезли в буфер фб, кэшировались на уровне ОС
FileSystemCacheThreshold влияет только на файл базы, временные файлы сортировки кешируются всегда

тогда да, можно ставить 0. чтение все равно всегда из кэша бд будет, а на запись там forced writes on.

Симонов Денис,

так исторически сложилось с конца девяностых )) тогда не было еще databases.conf

Итак, ситуация безрадостная. Лучше бы была явная ошибка, по крайней мере ясно было бы что исправлять.

Диспозиция:

1. конфигурация техники и размер БД см. выше.
2. всё работало как часы с марта прошлого года. сервер был или 3.0.2 или 3.0.3
сейчас трудно установить.

Что делали в последнее время:

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

2. в вс сделали бэкап/рестор бд. занимает весь процесс в районе 8 часов.

3. в среду могли обновить большое количество записей. точное количество
трудно установить. возможно, до миллиона.

До утра четверга система работала без нареканий.

1. Утром в четверг предприятие стало. База "зависла". На сервере в диспетчере задач
процесс fbserver показывал 100% загрузку процессора (там два процессора по 28 ядер
каждый, итого 56 ядер).

2. Местный сисадмин подождав некоторое время (20-30 минут) остановил процесс сервера
(не срубил жестко, а именно остановил) и перегрузил сервер. По мере подключения
пользователей к базе картина повторилась.

3. Опять остановили сервер и обновили до ФБ 3.0.4. Перегрузили. Не помогло.

4. обнаружили что при ресторе бд был выставлен кэш 2 000 000 страниц (16 Гб) вместо
20 000 000 (160 Гб). Остановили сервер и утилитой gfix увеличили кэш. Перезапустили.
Не помогло.

5. Запретили пользователям входить в систему. Оставили только 20-30 самых критичных
конектов для отгрузки продукции. С огромным трудом и паузами система ворочалась.
На сервере по прежнему 100% загрузка.

6. обнаружили что тригер на дисконнект внутри кидает ошибку (см. выше). Удалили триггер
и опять аккуратно перезагрузили сервер. Не помогло.

7. Начали искать в логах операционной системы, в логах RAID контроллера. Никакой подозрительной
информации не обнаружено.

8. через несколько часов сисема самостоятельно пришла в нормальное состояние.


Что это было?

Сборка мусора? Но sweep interval в header page установлен в 0. Хотя mon$attachment и содержит информацию
о сборщике.

Массированные обновления происходили и раньше, но никогда не приводили к таким последствиям.

1. Заходят в сервисы. Находят сервис Firebird. Вызывают для него команду остановить.

2. Disabling Automatic Sweeping

If you set the sweep interval to zero then automatic sweeping will be disabled. This implies that there will be no automatic housekeeping done so your database performance will not suffer as a result of the processing requirements of the automatic sweep.

If you disable sweeping you are advised to run a manual sweep at regular intervals when the database is quiet. Alternatively, simply make sure that you take regular backups of the database and as this is something you should be doing anyway, it shouldn't be a problem.

я не говорю что знаю всё. я вообще знаю мало. объясните, буду рад узнать новую информацию. заранее спасибо.

DmSerОчень интересно, как вообще удалось загрузить все 56 ядер? :)

обычное количество одновременных пользователей ~250. На пике может и 300 быть.

сервер FB SuperServer 3.

так вот ядра и грузятся...

Dimitry Sibiryakov Sweep interval никак со сборкой мусора не связан.


несколько противоречит хотя бы этой странице:

http://www.ibase.ru/garbage/

авторСамый известный момент сборки мусора – это sweep, автоматический (sweep interval > 0) или ручной (gfix -sweep db.gdb).

почему возникла тема свипа. потому что это был обычный день, с обычной работой пользователей. ничего не предвещало...
одна из гипотез была, что при бэкапе/ресторе как-то установили sweep interval больше 0 и запустилась автоматическая сборка.

почему ставим sweep 0? Это еще с девяностых тянется, с IB 5.6, с которого мы начинали. предпочитаем контролировать
процессы вручную через бэкап/рестор. это вообще привычка выработанная годами. потому что только успешный бэкап/рестор
на ранних версиях ib/yaffil/fb давал уверенность, что база целая и в ней не начало чего сыпаться.

я вообще был в 600 км от этого предприятия и только с телефонной связью, так что дебагер оперативно запустить
не мог, к сожалению.

квалификация людей такая, какая она есть. я не думаю, что файреберду в нынешних условиях стоит щеголять
требованием обязательного наличия системного программиста с++ высокого уровня в штате предприятия, да еще и
с сертификатом MSCE. Как то это будет уж очень невыгодно, относительно конкурентов.

знаю ли я что мусор убирается не только при свипе, но и при чтении записи, например? да знаю. но в момент "зависания"
в mon$statements не было никаких подозрительных запросов на массовое чтение, которые можно было бы в чем-то подозревать.
как, впрочем, и на массовое удаление или обновление.

да, был на предприятии массовый update до этого. но такие апдейты там регулярно происходили и раньше, но не приводили
к особым проблемам. по крайней мере таких "зависаний" вообще за 12 лет эксплуатации системы не было ни разу.

не хочется, чтобы это была какая скрытая ошибка в фб. будем надеяться просто на неудачную сборку мусора. еще
раз повторюсь, я был не на месте и не могу за всё ручаться.

на будущее будем наблюдать, будем смотреть.

огромное спасибо за помощь и советы.

и остается еще маленькая наводка с тригером на дисконект от бд, в котором кидалась ошибка на вставку записи в таблицу. при его удалении проблема вроде как не решилась, но всё же.

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

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