iBase.ru Forum

Есть проблема с производительностью сервера Firebird 1.5
Железо:
Четыре 2-х ядерных Xeon 2.66 Гигагерц
16Гигабайт памяти
Аппаратный RAID 10 (LSI Megaraid)
Операционка: Linuux 2.6 (Centos)
Firebird 1.5.1 (Пробовали 1.5.3 и 2.0)

Проблема:
Когда выполняются одновременно несколько (от 4-х и выше) не очень тяжелых запросов (при не загруженном сервере в IBExpert один запрос выполняется секуд 10-15) общая загрузка сервера падает (в top видно что увеличивается общий idle). И соответственно падает производительность (запросов в единицу времени).
Еще в top в колонке S видно, что процессы fb_inet_server ожидают в функции semtimedo (наверное функция semtimedop).
При этом очень мелкие запросы (типа выбрать одну запись по первичному ключу) работают быстро.
Дисковой активности нет (судя по vmstat -p sda1 и по не горящим лампочкам винчестеров)
Что делать не знаю.

Запросы на чтение или на запись ?

hvlad писал(а):Запросы на чтение или на запись ?

Крутим тестовые запросы на чтение. (ведем статистику когда томозит система)
Забыл сказать - размер базы 30 Гиг
Проводили тестирование на старом сервере
CPU 2 Intel(R) XEON(TM) CPU 1.80GHz
RAM 4Gig

запускали одновременно от 1 до 200 запросов (читающих).
1-2 запроса - нет semtimedo - общий idle 20%
Общая производительность (Всего запросов/Время тестирования)
растет
3-4 запроса - semtimedo пояляются у 2-3 процессов - общий idle 40%
Общая производительность (Всего запросов/Время тестирования)
падает

При 8 и более общая скорость запросов/сек падает до скорости одного запроса

Стакивался кто нибудь с такой проблемой?
Есть у кого возможность поделиться опытом эксплуатации/администрирования/настройки быстродействия БД такого размера?

А может, ты нам предоставишь немного больше данных? Размер страницы БД, параметры транзакции, вывод gstat -h... Побалуешься с fb_lock_print... Как крайний вариант, постучишься в мыло Алексу Пешкову.

увеличивать в конфиге LockMemSize, а также возможно LockSemCount и LockHashSlots

Dimitry Sibiryakov писал(а):А может, ты нам предоставишь немного больше данных? Размер страницы БД, параметры транзакции, вывод gstat -h... Побалуешься с fb_lock_print... Как крайний вариант, постучишься в мыло Алексу Пешкову.

Firebird 1.5.1, Centos Linux 2.6
Транзакция стандартная БДЕшная.
Размер страницы 4096 ( раньше было 16К. Неделю назад делали бакуп/ресторе и оставили значение по умолчанию. На скорость работы принципиально не повлияло )
Увеличил LockHashSlots с 101 до 257
fb_lock_print
Результаты
в 10:30
LOCK_HEADER BLOCK
Version: 15, Active owner: 0, Length: 13533184, Used: 13516840
Semmask: 0x3154, Flags: 0x0001
Enqs: -1072670452, Converts: 23959685, Rejects: 8500420, Blocks: 18345125
Deadlock scans: 391, Deadlocks: 0, Scan interval: 10
Acquires: -25269358, Acquire blocks: 556937884, Spin count: 0
Mutex wait: 13.0%
Hash slots: 257, Hash lengths (min/avg/max): 135/ 151/ 181
...

в 11:00
LOCK_HEADER BLOCK
Version: 15, Active owner: 0, Length: 13533184, Used: 13516840
Enqs: -1047743070, Converts: 23976289, Rejects: 8504930, Blocks: 18389126
Deadlock scans: 392, Deadlocks: 0, Scan interval: 10
Acquires: 487043, Acquire blocks: 570910595, Spin count: 0
Mutex wait: 117219.8%
Hash slots: 257, Hash lengths (min/avg/max): 150/ 170/ 202
...

в 11:30
LOCK_HEADER BLOCK
Version: 15, Active owner: 4280916, Length: 14221312, Used: 14212340
Lock manager pid: 2293
Semmask: 0x3154, Flags: 0x0001
Enqs: -1028946813, Converts: 23986621, Rejects: 8509753, Blocks: 18434861
Deadlock scans: 394, Deadlocks: 0, Scan interval: 10
Acquires: 20057611, Acquire blocks: 581600204, Spin count: 0
Mutex wait: 2899.6%
Hash slots: 257, Hash lengths (min/avg/max): 326/ 359/ 396
---------
Результаты gstat -h по транзакциям
starting at Thu Dec 14 10:30:01 VLAT 2006
-------------------------------------
Oldest transaction: 32078313
Oldest active: 32096170
Snapshot: 32067486
Next transaction: 32175226

starting at Thu Dec 14 11:00:01 VLAT 2006
-------------------------------------
Oldest transaction: 32078313
Oldest active: 32111217
Snapshot: 32096170
Next transaction: 32290912

starting at Thu Dec 14 11:30:01 VLAT 2006
-------------------------------------
Oldest transaction: 32078313
Oldest active: 32111217
Snapshot: 32096170
Next transaction: 32394771

fb_lock_print -ia
10:30:06 acquire/s acqwait/s %acqwait acqrtry/s rtrysuc/s
10:31:06 14820 8681 58 0 0

Average: 14820 8681 58 0 0

11:00:03 acquire/s acqwait/s %acqwait acqrtry/s rtrysuc/s
11:01:03 9053 2171 23 0 0

Average: 9053 2171 23 0 0

11:30:04 acquire/s acqwait/s %acqwait acqrtry/s rtrysuc/s
11:31:04 9829 6814 69 0 0

Average: 9829 6814 69 0 0

dimitr писал(а):увеличивать в конфиге LockMemSize, а также возможно LockSemCount и LockHashSlots

У нас стоит Classik. Он должен (судя по описаниям) увеличивать при необходимости размер памяти для блокировок начиная с размера указанного в LockMemSize.
Параметр LockSemCount увеличивали - появляются предупреждения в журнале firebird.log Нужно увеличивать в настройках ядра. Реально ошибку нехватки семафоров получаем только в тестовой программе при массовом параллельном insert
LockHashSlots увеличили до 257 - как узнать результат?
Притормаживания остались
(время выполнения тестового запроса увеличивается с 0.4 секунд до 4-7 секунд)

Tchamlay_Oleg писал(а):У нас стоит Classik. Он должен (судя по описаниям) увеличивать при необходимости размер памяти для блокировок начиная с размера указанного в LockMemSize.

это правда для виндов и для некоторых posix. Я бы посоветовал выставить вручную по формуле: <пиковое число коннектов> * <размер кеша в страницах> * 100.

Tchamlay_Oleg писал(а):LockHashSlots увеличили до 257 - как узнать результат?

он виден на выводе fb_lock_print

Tchamlay_Oleg писал(а):время выполнения тестового запроса увеличивается с 0.4 секунд до 4-7 секунд

т.е. тормоза настают не сразу после запуска теста, а через некоторое время? Или я чего-то не понял?

Tchamlay_Oleg писал(а): У нас стоит Classik. Он должен (судя по описаниям) увеличивать при необходимости размер памяти для блокировок начиная с размера указанного в LockMemSize.
[skip]
Притормаживания остались
(время выполнения тестового запроса увеличивается с 0.4 секунд до 4-7 секунд)

А ты послушай хорошего совета. Не факт что в яблочко, но по порядку величины похоже. Я увеличил в своё время до 70Мб сразу и непонятные неповторяющиеся притормаживания в произвольные моменты почти исчезли. Отхватывать 100 раз по 1 байту в 100 раз накладней, чем 1 раз 100 Кстати, с DefaultDbCachePages не баловались? 75 умолчательных маловато будет вообще-то, в мохнатые времена умолчание делалось. А если перебрать, то тоже тормозит, индивидуальная подгонка нужна, под базу-задачу.

dimitr писал(а):

Tchamlay_Oleg писал(а):У нас стоит Classik. Он должен (судя по описаниям) увеличивать при необходимости размер памяти для блокировок начиная с размера указанного в LockMemSize.

это правда для виндов и для некоторых posix. Я бы посоветовал выставить вручную по формуле: <пиковое число коннектов> * <размер кеша в страницах> * 100.

Хорошо - поставмим. Спасибо

Tchamlay_Oleg писал(а):LockHashSlots увеличили до 257 - как узнать результат?

он виден на выводе fb_lock_print

Сразу посмотрели (Сначала поменяли, всех от базы отключили - смотрим в fb_lock_print, а там все равно 101 стоит
Потом догадались остановить fb_lock_mgr
Я имею в виду - есть положительный результат?

Tchamlay_Oleg писал(а):время выполнения тестового запроса увеличивается с 0.4 секунд до 4-7 секунд

т.е. тормоза настают не сразу после запуска теста, а через некоторое время? Или я чего-то не понял?

Мы крутим тестовый запрос раз в две минуты. Статистика вызовов копится в файле. Жалобы отдела продаж на уменьшение скорости работы совпадает с увеличением времени работы запроса.

Merlin писал(а):

Tchamlay_Oleg писал(а): У нас стоит Classik. Он должен (судя по описаниям) увеличивать при необходимости размер памяти для блокировок начиная с размера указанного в LockMemSize.
[skip]
Притормаживания остались
(время выполнения тестового запроса увеличивается с 0.4 секунд до 4-7 секунд)

А ты послушай хорошего совета. Не факт что в яблочко, но по порядку величины похоже. Я увеличил в своё время до 70Мб сразу и непонятные неповторяющиеся притормаживания в произвольные моменты почти исчезли. Отхватывать 100 раз по 1 байту в 100 раз накладней, чем 1 раз 100 Кстати, с DefaultDbCachePages не баловались? 75 умолчательных маловато будет вообще-то, в мохнатые времена умолчание делалось. А если перебрать, то тоже тормозит, индивидуальная подгонка нужна, под базу-задачу.

Спасибо поставим

Tchamlay_Oleg писал(а):fb_lock_print
Результаты
в 10:30
LOCK_HEADER BLOCK
Version: 15, Active owner: 0, Length: 13533184, Used: 13516840
Semmask: 0x3154, Flags: 0x0001
Enqs: -1072670452, Converts: 23959685, Rejects: 8500420, Blocks: 18345125
Deadlock scans: 391, Deadlocks: 0, Scan interval: 10
Acquires: -25269358, Acquire blocks: 556937884, Spin count: 0
Mutex wait: 13.0%
Hash slots: 257, Hash lengths (min/avg/max): 135/ 151/ 181
...

в 11:00
LOCK_HEADER BLOCK
Version: 15, Active owner: 0, Length: 13533184, Used: 13516840
Enqs: -1047743070, Converts: 23976289, Rejects: 8504930, Blocks: 18389126
Deadlock scans: 392, Deadlocks: 0, Scan interval: 10
Acquires: 487043, Acquire blocks: 570910595, Spin count: 0
Mutex wait: 117219.8%
Hash slots: 257, Hash lengths (min/avg/max): 150/ 170/ 202
...

в 11:30
LOCK_HEADER BLOCK
Version: 15, Active owner: 4280916, Length: 14221312, Used: 14212340
Lock manager pid: 2293
Semmask: 0x3154, Flags: 0x0001
Enqs: -1028946813, Converts: 23986621, Rejects: 8509753, Blocks: 18434861
Deadlock scans: 394, Deadlocks: 0, Scan interval: 10
Acquires: 20057611, Acquire blocks: 581600204, Spin count: 0
Mutex wait: 2899.6%
Hash slots: 257, Hash lengths (min/avg/max): 326/ 359/ 396

LockMemSize увеличить до 20МБ, т.к. сейчас пользуется 14
LockHashSlots увеличивать до тех пор, пока Hash lengths c 3-4х сотен не снизится до единиц или хотя бы десятков. Я бы начал с 1027 (числа простые выбирать)

Tchamlay_Oleg писал(а):Результаты gstat -h по транзакциям
starting at Thu Dec 14 10:30:01 VLAT 2006
-------------------------------------
Oldest transaction: 32078313
Oldest active: 32096170
Snapshot: 32067486
Next transaction: 32175226

starting at Thu Dec 14 11:00:01 VLAT 2006
-------------------------------------
Oldest transaction: 32078313
Oldest active: 32111217
Snapshot: 32096170
Next transaction: 32290912

starting at Thu Dec 14 11:30:01 VLAT 2006
-------------------------------------
Oldest transaction: 32078313
Oldest active: 32111217
Snapshot: 32096170
Next transaction: 32394771

OIT (32078313) застряла. Значит был "большой" роллбек и\или свип не делается. Постоянно есть разрыв около 100К между OAT и Next - это долгоиграющие тр-ции. Например в 11:00 и в 11:30 OAT не менялась - что она полчаса делает ???
За час стартовали 220К тр-ций - не многовато ли ?

Tchamlay_Oleg писал(а):fb_lock_print -ia
10:30:06 acquire/s acqwait/s %acqwait acqrtry/s rtrysuc/s
10:31:06 14820 8681 58 0 0

Average: 14820 8681 58 0 0

11:00:03 acquire/s acqwait/s %acqwait acqrtry/s rtrysuc/s
11:01:03 9053 2171 23 0 0

Average: 9053 2171 23 0 0

11:30:04 acquire/s acqwait/s %acqwait acqrtry/s rtrysuc/s
11:31:04 9829 6814 69 0 0

Average: 9829 6814 69 0 0

%acqwait подозрительно высок. Не могу сказать точно,что это значит

hvlad писал(а): LockMemSize увеличить до 20МБ, т.к. сейчас пользуется 14
LockHashSlots увеличивать до тех пор, пока Hash lengths c 3-4х сотен не снизится до единиц или хотя бы десятков. Я бы начал с 1027 (числа простые выбирать)

Спасибо! Попробуем.

hvlad писал(а): OIT (32078313) застряла. Значит был "большой" роллбек и\или свип не делается. Постоянно есть разрыв около 100К между OAT и Next - это долгоиграющие тр-ции. Например в 11:00 и в 11:30 OAT не менялась - что она полчаса делает ???
За час стартовали 220К тр-ций - не многовато ли ?

Прогорамма работает на БДЕ. Явный start/commit делается только при сохранении операций прихода/расхода товара. Отчеты (например печать счетов-фактур) никак не управляют транзакцией.
А какое количество транзакций в единицу времени приемлем?
Есть планы по преходу на FIB+.
Но нет "оценки" практического результата. Вроде всем понятно, что будет лучше. Уменьшится количество транзакций. Но на сколько это улучшит быстродействие?

hvlad писал(а): %acqwait подозрительно высок. Не могу сказать точно,что это значит

Поменям настройки для LockMemSize и LockHashSlots может и процент %acqwait понизится

Tchamlay_Oleg писал(а):

hvlad писал(а): OIT (32078313) застряла. Значит был "большой" роллбек и\или свип не делается. Постоянно есть разрыв около 100К между OAT и Next - это долгоиграющие тр-ции. Например в 11:00 и в 11:30 OAT не менялась - что она полчаса делает ???
За час стартовали 220К тр-ций - не многовато ли ?

Прогорамма работает на БДЕ. Явный start/commit делается только при сохранении операций прихода/расхода товара. Отчеты (например печать счетов-фактур) никак не управляют транзакцией.

BDE тут не при чём. Ищите проколы в приложениях - кто-то забывает коммитить тр-ции. Есть SQL Monitor в конце-концов.
Может у вас вообще кто-то открыл ИБЕ, выполнил запрос и пошёл гулять - а тр-ция висит

Tchamlay_Oleg писал(а):А какое количество транзакций в единицу времени приемлем?

Столько, сколько нужно. Т.е. стоит подумать о необходимости явного управления тр-циями и как это делать в вашем случае.

Tchamlay_Oleg писал(а):Есть планы по преходу на FIB+.
Но нет "оценки" практического результата. Вроде всем понятно, что будет лучше. Уменьшится количество транзакций. Но на сколько это улучшит быстродействие?

Кол-во тр-ций быстродействию вредит слабо. Вредят долгоиграющие тр-ции. С FIB+ вы сможете настроить некоторые нюансы, но сама собой проблема не рассосётся. Нужно тщательно анализировать приложения

hvlad писал(а):

Tchamlay_Oleg писал(а):

hvlad писал(а): OIT (32078313) застряла. Значит был "большой" роллбек и\или свип не делается. Постоянно есть разрыв около 100К между OAT и Next - это долгоиграющие тр-ции. Например в 11:00 и в 11:30 OAT не менялась - что она полчаса делает ???
За час стартовали 220К тр-ций - не многовато ли ?

Прогорамма работает на БДЕ. Явный start/commit делается только при сохранении операций прихода/расхода товара. Отчеты (например печать счетов-фактур) никак не управляют транзакцией.

BDE тут не при чём. Ищите проколы в приложениях - кто-то забывает коммитить тр-ции. Есть SQL Monitor в конце-концов.
Может у вас вообще кто-то открыл ИБЕ, выполнил запрос и пошёл гулять - а тр-ция висит

Tchamlay_Oleg писал(а):А какое количество транзакций в единицу времени приемлем?

Столько, сколько нужно. Т.е. стоит подумать о необходимости явного управления тр-циями и как это делать в вашем случае.

Tchamlay_Oleg писал(а):Есть планы по преходу на FIB+.
Но нет "оценки" практического результата. Вроде всем понятно, что будет лучше. Уменьшится количество транзакций. Но на сколько это улучшит быстродействие?

Кол-во тр-ций быстродействию вредит слабо. Вредят долгоиграющие тр-ции. С FIB+ вы сможете настроить некоторые нюансы, но сама собой проблема не рассосётся. Нужно тщательно анализировать приложения

Приложение не статично. Имеется возможность расширять функциональность. Приходится искать конкретный модуль для указания разработчикам на необходимость "поправить".
Часть PID процессов держащих транзакции удалось выявить с помощью серии звонков пользователям с просьбой выйти из программы. Если при выходе пользователя транзакции "передвигались" то делалось предположение о "вине" модуля.
Есть ли практические рекомендации по поиску в результатах выводимых утилитой fb_lock_print PID-ов процессов чьи транзакции сейчас активны (или долго живут) ?

И как успехи ?

hvlad писал(а):И как успехи ?

Нашли "дополнительное" приложение работающее через ODBC.
Сначала повыходили из всех копий программы которые запустились раньше времени "остановки" OAT и OIT.
Остались соединения из "дополнительного" приложения, и соединения IBExpert программистов.
Попросили программистов выйти - часть транзакций "подвинулась".
Остановили "дополнительное" приложение - транзакции стали "совсем хорошими"
(Разница около 300 )
Затратили на все около 4 часов. Не все пользователи могли прекратить работу, некоторых небыло на рабочем месте.
Приложение работающее через ODBC починили.
Теперь сначала звоним программистам.
Первое время разница между транзакциями была в пределах 30000.
Потом ситуация стала ухудшаться.
Если бы была возможность найти тот процесс который в ответе за застрявшую транзакцию - то задание на оптимизацию быстрее нашло адресата

Tchamlay_Oleg писал(а):Есть ли практические рекомендации по поиску в результатах выводимых утилитой fb_lock_print PID-ов процессов чьи транзакции сейчас активны (или долго живут) ?

запускаешь с ключом -l. Смотришь на записи LOCK BLOCK. Те, у которых Series = 4, это транзакции. Идентификатор транзакции смотришь в поле Key. Запоминаешь значение поля Owner, скроллируешь вывод вверх и ищешь OWNER BLOCK с запомненным номером. Там смотришь Process ID.

пример:

...
OWNER BLOCK 11500
Owner id: 51502756, type: 3, flags: 0x00, pending: 0, semid: 11796
Process id: 3020, UID: 0x0 Alive
Flags: 0x00
Requests (1): forward: 12860, backward: 12860
Blocks: *empty*
...
LOCK BLOCK 12912
Series: 4, Parent: 11712, State: 6, size: 4 length: 4 data: 112857
Key: 112857, Flags: 0x00, Pending request count: 0
Hash que (1): forward: 692, backward: 692
Requests (1): forward: 12860, backward: 12860
Request 12860, Owner: 11500, State: 6 (6), Flags: 0x00
...

Спасибо!