Падает скорость работы Firebird
Модераторы: kdv, Alexey Kovyazin
-
- Сообщения: 23
- Зарегистрирован: 27 апр 2005, 12:40
Падает скорость работы Firebird
Есть проблема с производительностью сервера 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 и по не горящим лампочкам винчестеров)
Что делать не знаю.
Железо:
Четыре 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 и по не горящим лампочкам винчестеров)
Что делать не знаю.
-
- Сообщения: 23
- Зарегистрирован: 27 апр 2005, 12:40
Крутим тестовые запросы на чтение. (ведем статистику когда томозит система)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 и более общая скорость запросов/сек падает до скорости одного запроса
Стакивался кто нибудь с такой проблемой?
Есть у кого возможность поделиться опытом эксплуатации/администрирования/настройки быстродействия БД такого размера?
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
-
- Сообщения: 23
- Зарегистрирован: 27 апр 2005, 12:40
Firebird 1.5.1, Centos Linux 2.6Dimitry Sibiryakov писал(а):А может, ты нам предоставишь немного больше данных? Размер страницы БД, параметры транзакции, вывод gstat -h... Побалуешься с fb_lock_print... Как крайний вариант, постучишься в мыло Алексу Пешкову.
Транзакция стандартная БДЕшная.
Размер страницы 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
-
- Сообщения: 23
- Зарегистрирован: 27 апр 2005, 12:40
У нас стоит Classik. Он должен (судя по описаниям) увеличивать при необходимости размер памяти для блокировок начиная с размера указанного в LockMemSize.dimitr писал(а):увеличивать в конфиге LockMemSize, а также возможно LockSemCount и LockHashSlots
Параметр LockSemCount увеличивали - появляются предупреждения в журнале firebird.log Нужно увеличивать в настройках ядра. Реально ошибку нехватки семафоров получаем только в тестовой программе при массовом параллельном insert
LockHashSlots увеличили до 257 - как узнать результат?
Притормаживания остались
(время выполнения тестового запроса увеличивается с 0.4 секунд до 4-7 секунд)
это правда для виндов и для некоторых posix. Я бы посоветовал выставить вручную по формуле: <пиковое число коннектов> * <размер кеша в страницах> * 100.Tchamlay_Oleg писал(а):У нас стоит Classik. Он должен (судя по описаниям) увеличивать при необходимости размер памяти для блокировок начиная с размера указанного в LockMemSize.
он виден на выводе fb_lock_printTchamlay_Oleg писал(а):LockHashSlots увеличили до 257 - как узнать результат?
т.е. тормоза настают не сразу после запуска теста, а через некоторое время? Или я чего-то не понял?Tchamlay_Oleg писал(а):время выполнения тестового запроса увеличивается с 0.4 секунд до 4-7 секунд
А ты послушай хорошего совета. Не факт что в яблочко, но по порядку величины похоже. Я увеличил в своё время до 70Мб сразу и непонятные неповторяющиеся притормаживания в произвольные моменты почти исчезли. Отхватывать 100 раз по 1 байту в 100 раз накладней, чем 1 раз 100 Кстати, с DefaultDbCachePages не баловались? 75 умолчательных маловато будет вообще-то, в мохнатые времена умолчание делалось. А если перебрать, то тоже тормозит, индивидуальная подгонка нужна, под базу-задачу.Tchamlay_Oleg писал(а): У нас стоит Classik. Он должен (судя по описаниям) увеличивать при необходимости размер памяти для блокировок начиная с размера указанного в LockMemSize.
[skip]
Притормаживания остались
(время выполнения тестового запроса увеличивается с 0.4 секунд до 4-7 секунд)
-
- Сообщения: 23
- Зарегистрирован: 27 апр 2005, 12:40
Хорошо - поставмим. Спасибоdimitr писал(а):это правда для виндов и для некоторых posix. Я бы посоветовал выставить вручную по формуле: <пиковое число коннектов> * <размер кеша в страницах> * 100.Tchamlay_Oleg писал(а):У нас стоит Classik. Он должен (судя по описаниям) увеличивать при необходимости размер памяти для блокировок начиная с размера указанного в LockMemSize.
Сразу посмотрели (Сначала поменяли, всех от базы отключили - смотрим в fb_lock_print, а там все равно 101 стоитон виден на выводе fb_lock_printTchamlay_Oleg писал(а):LockHashSlots увеличили до 257 - как узнать результат?
Потом догадались остановить fb_lock_mgr
Я имею в виду - есть положительный результат?
Мы крутим тестовый запрос раз в две минуты. Статистика вызовов копится в файле. Жалобы отдела продаж на уменьшение скорости работы совпадает с увеличением времени работы запроса.т.е. тормоза настают не сразу после запуска теста, а через некоторое время? Или я чего-то не понял?Tchamlay_Oleg писал(а):время выполнения тестового запроса увеличивается с 0.4 секунд до 4-7 секунд
-
- Сообщения: 23
- Зарегистрирован: 27 апр 2005, 12:40
Спасибо поставимMerlin писал(а):А ты послушай хорошего совета. Не факт что в яблочко, но по порядку величины похоже. Я увеличил в своё время до 70Мб сразу и непонятные неповторяющиеся притормаживания в произвольные моменты почти исчезли. Отхватывать 100 раз по 1 байту в 100 раз накладней, чем 1 раз 100 Кстати, с DefaultDbCachePages не баловались? 75 умолчательных маловато будет вообще-то, в мохнатые времена умолчание делалось. А если перебрать, то тоже тормозит, индивидуальная подгонка нужна, под базу-задачу.Tchamlay_Oleg писал(а): У нас стоит Classik. Он должен (судя по описаниям) увеличивать при необходимости размер памяти для блокировок начиная с размера указанного в LockMemSize.
[skip]
Притормаживания остались
(время выполнения тестового запроса увеличивается с 0.4 секунд до 4-7 секунд)
LockMemSize увеличить до 20МБ, т.к. сейчас пользуется 14Tchamlay_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
LockHashSlots увеличивать до тех пор, пока Hash lengths c 3-4х сотен не снизится до единиц или хотя бы десятков. Я бы начал с 1027 (числа простые выбирать)
OIT (32078313) застряла. Значит был "большой" роллбек и\или свип не делается. Постоянно есть разрыв около 100К между OAT и Next - это долгоиграющие тр-ции. Например в 11:00 и в 11:30 OAT не менялась - что она полчаса делает ???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
За час стартовали 220К тр-ций - не многовато ли ?
%acqwait подозрительно высок. Не могу сказать точно,что это значит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
-
- Сообщения: 23
- Зарегистрирован: 27 апр 2005, 12:40
Спасибо! Попробуем.hvlad писал(а): LockMemSize увеличить до 20МБ, т.к. сейчас пользуется 14
LockHashSlots увеличивать до тех пор, пока Hash lengths c 3-4х сотен не снизится до единиц или хотя бы десятков. Я бы начал с 1027 (числа простые выбирать)
Прогорамма работает на БДЕ. Явный start/commit делается только при сохранении операций прихода/расхода товара. Отчеты (например печать счетов-фактур) никак не управляют транзакцией.hvlad писал(а): OIT (32078313) застряла. Значит был "большой" роллбек и\или свип не делается. Постоянно есть разрыв около 100К между OAT и Next - это долгоиграющие тр-ции. Например в 11:00 и в 11:30 OAT не менялась - что она полчаса делает ???
За час стартовали 220К тр-ций - не многовато ли ?
А какое количество транзакций в единицу времени приемлем?
Есть планы по преходу на FIB+.
Но нет "оценки" практического результата. Вроде всем понятно, что будет лучше. Уменьшится количество транзакций. Но на сколько это улучшит быстродействие?
Поменям настройки для LockMemSize и LockHashSlots может и процент %acqwait понизитсяhvlad писал(а): %acqwait подозрительно высок. Не могу сказать точно,что это значит
BDE тут не при чём. Ищите проколы в приложениях - кто-то забывает коммитить тр-ции. Есть SQL Monitor в конце-концов.Tchamlay_Oleg писал(а):Прогорамма работает на БДЕ. Явный start/commit делается только при сохранении операций прихода/расхода товара. Отчеты (например печать счетов-фактур) никак не управляют транзакцией.hvlad писал(а): OIT (32078313) застряла. Значит был "большой" роллбек и\или свип не делается. Постоянно есть разрыв около 100К между OAT и Next - это долгоиграющие тр-ции. Например в 11:00 и в 11:30 OAT не менялась - что она полчаса делает ???
За час стартовали 220К тр-ций - не многовато ли ?
Может у вас вообще кто-то открыл ИБЕ, выполнил запрос и пошёл гулять - а тр-ция висит
Столько, сколько нужно. Т.е. стоит подумать о необходимости явного управления тр-циями и как это делать в вашем случае.Tchamlay_Oleg писал(а):А какое количество транзакций в единицу времени приемлем?
Кол-во тр-ций быстродействию вредит слабо. Вредят долгоиграющие тр-ции. С FIB+ вы сможете настроить некоторые нюансы, но сама собой проблема не рассосётся. Нужно тщательно анализировать приложенияTchamlay_Oleg писал(а):Есть планы по преходу на FIB+.
Но нет "оценки" практического результата. Вроде всем понятно, что будет лучше. Уменьшится количество транзакций. Но на сколько это улучшит быстродействие?
-
- Сообщения: 23
- Зарегистрирован: 27 апр 2005, 12:40
Приложение не статично. Имеется возможность расширять функциональность. Приходится искать конкретный модуль для указания разработчикам на необходимость "поправить".hvlad писал(а):BDE тут не при чём. Ищите проколы в приложениях - кто-то забывает коммитить тр-ции. Есть SQL Monitor в конце-концов.Tchamlay_Oleg писал(а):Прогорамма работает на БДЕ. Явный start/commit делается только при сохранении операций прихода/расхода товара. Отчеты (например печать счетов-фактур) никак не управляют транзакцией.hvlad писал(а): OIT (32078313) застряла. Значит был "большой" роллбек и\или свип не делается. Постоянно есть разрыв около 100К между OAT и Next - это долгоиграющие тр-ции. Например в 11:00 и в 11:30 OAT не менялась - что она полчаса делает ???
За час стартовали 220К тр-ций - не многовато ли ?
Может у вас вообще кто-то открыл ИБЕ, выполнил запрос и пошёл гулять - а тр-ция висит
Столько, сколько нужно. Т.е. стоит подумать о необходимости явного управления тр-циями и как это делать в вашем случае.Tchamlay_Oleg писал(а):А какое количество транзакций в единицу времени приемлем?
Кол-во тр-ций быстродействию вредит слабо. Вредят долгоиграющие тр-ции. С FIB+ вы сможете настроить некоторые нюансы, но сама собой проблема не рассосётся. Нужно тщательно анализировать приложенияTchamlay_Oleg писал(а):Есть планы по преходу на FIB+.
Но нет "оценки" практического результата. Вроде всем понятно, что будет лучше. Уменьшится количество транзакций. Но на сколько это улучшит быстродействие?
Часть PID процессов держащих транзакции удалось выявить с помощью серии звонков пользователям с просьбой выйти из программы. Если при выходе пользователя транзакции "передвигались" то делалось предположение о "вине" модуля.
Есть ли практические рекомендации по поиску в результатах выводимых утилитой fb_lock_print PID-ов процессов чьи транзакции сейчас активны (или долго живут) ?
-
- Сообщения: 23
- Зарегистрирован: 27 апр 2005, 12:40
hvlad писал(а):И как успехи ?
Нашли "дополнительное" приложение работающее через ODBC.
Сначала повыходили из всех копий программы которые запустились раньше времени "остановки" OAT и OIT.
Остались соединения из "дополнительного" приложения, и соединения IBExpert программистов.
Попросили программистов выйти - часть транзакций "подвинулась".
Остановили "дополнительное" приложение - транзакции стали "совсем хорошими"
(Разница около 300 )
Затратили на все около 4 часов. Не все пользователи могли прекратить работу, некоторых небыло на рабочем месте.
Приложение работающее через ODBC починили.
Теперь сначала звоним программистам.
Первое время разница между транзакциями была в пределах 30000.
Потом ситуация стала ухудшаться.
Если бы была возможность найти тот процесс который в ответе за застрявшую транзакцию - то задание на оптимизацию быстрее нашло адресата
запускаешь с ключом -l. Смотришь на записи LOCK BLOCK. Те, у которых Series = 4, это транзакции. Идентификатор транзакции смотришь в поле Key. Запоминаешь значение поля Owner, скроллируешь вывод вверх и ищешь OWNER BLOCK с запомненным номером. Там смотришь Process ID.Tchamlay_Oleg писал(а):Есть ли практические рекомендации по поиску в результатах выводимых утилитой fb_lock_print PID-ов процессов чьи транзакции сейчас активны (или долго живут) ?
пример:
...
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
...