Возникновение тормозов на больших базах

Администирование клиентской и серверной части InterBase, Firebird, Yaffil. Настройка файла конфигурации и т.п.

Модераторы: kdv, Alexey Kovyazin

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 15 дек 2006, 18:49

Merlin писал(а):Намекну, ты-то разберёшься :)
К сожалению, никто мне помочь не может (пока?).
У меня основной фейс на BDE, ещё ансофтом писанный. Это уже наши модули на FIB работают, переписку основного (исходников нет, конечно же) мы пока не осилим.
Принудительного отключения со стороны сервера гарбаджколлекта нет, а в DBE ты знаешь, куда его сувать? Я не раскопал.

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 15 дек 2006, 18:53

Ндя, что собой представляет TDataBase, я уже не то что смутно, а почти вообще никак не помню...

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 15 дек 2006, 19:38

И нет, не супер, классик на линухе.
Статистики в момент "тормозов" не осталось - мы снэпшотом проблему уже с полгода гасим.

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 15 дек 2006, 19:45

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

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 15 дек 2006, 19:51

Merlin писал(а):Тогда совсем странно. В классике напоровшийся коннект и должен тормозить, остальным по барабану практически.
Вот на двойку всё переведу - тогда и вернусь к проблеме. А сейчас пока забил на это дело, все силы на миграцию брошены.

Tchamlay_Oleg
Сообщения: 23
Зарегистрирован: 27 апр 2005, 12:40

Re: Возникновение тормозов на больших базах

Сообщение Tchamlay_Oleg » 15 дек 2006, 19:55

Merlin писал(а):
Tchamlay_Oleg писал(а): Осталось сменить БДЕ на FIB+ и если это не поможет - тихо ползти в сторону канадской границы :)
А на канадской границе вас ждёт IBAnalyst, который, к бабке не ходи, скажет что половину индексов (а то и поболе) надо отправить в помойку. Там же пребывает изучение планов ваших запросов на оставшейся половине индексов и расставление хинтов и прописывание явных планов в некоторых из них. После чего толстые запросы стремительно похудеют. Если же худобы таки не хватит, то за канадской границей вас ждёт концепция он-лайн (на триггерах) или ночного сбора хранимых агрегатов - полуфабрикатов для толстых запросов или даже готовых результатов вместо них.
Сбор агрегатов это возможный вариант. Совсем "мертвые запросы" (аналитика за год) были переведены на "полуфабрикаты"
Tchamlay_Oleg писал(а): Оказалось, что Linux при запуске более 4-х толстых читающих запросов на тестовой базе увеличивает простой процессоров и соответственно уменьшает общую скорость выполнения запросов. 8-мь толстых параллельных запросов работают в целом как 2-а толстых параллельных запроса :(
А при 10-ти - 40-ка толстых запросах общая скорость немного выше, чем скорость одного запроса.
Ещё бы. База-то на одном диске, вот они дружно в очередь к нему и выстраиваются.
Я честно говоря не помню что есть 10 - простое зеркалирование вроде?
Да (1) Зеркало (для дублирования) + (0) Стрип (для увеличения скорости)
НО! При тестировании мы подобрали параметры тестового запроса так, чтобы 16Гиг памяти хватало для хранения скешированных данных с диска.
Во время тестирования (судя по статистике) обращений к дискам нет. Когда увеличиваем количество данных обрабатываемых запросом так, что не хватает кэша и идет обращение к дискам (видно по лампочкам на корзинах, по данным vmstat) то скорость выполнения падает.
Может конечно очередь выстраивается к кешу файловой системы?
:(
На моем домашнем компьютере firebird-ы честно жрут (в целом) 100% процессора и при 1 запросе и при 40. И idle практически равен нулю (правда процессор один пришлось включить гипертридинг, памяти 512 и база 6Гиг)

Lyas
Сообщения: 7
Зарегистрирован: 14 мар 2007, 10:07

Re: Возникновение тормозов на больших базах

Сообщение Lyas » 19 мар 2007, 10:37

Tchamlay_Oleg писал(а):
dimitr писал(а):
Maks_f писал(а):Так вот с какого-то момента, появились тормоза, т.е. свип идет по 5 часов вместо 40 минут.
тормоза только в свипе или вообще? Или напрягает именно свип? Или он ради красного словца тут?
У нас проблемы с производительностью базы данных под Firebird. Переходить на другой сервер БД мы не хотим. Есть желание разобраться с проблемой. В свое время мы перешли с IB5.6 под Windows на firebird 0.9 на Linux из-за тормозов при одновременной работе бухгалтерии (крутивших "толстые" отчеты) и отдела продаж. Classic сервер решил наши проблемы на несколько лет. Для проверки скорости ставили разные размеры страниц при очередном бакуп/ресторе (один раз в 3 или 12 месяцев) Каждую ночью делали бакуп. И все работало замечательно пока не накопились данные.
А когда база стала тормозить - вот тогда и пришли лихорадочные поиски решения. Собственно говоря кроме изменения размера страницы, изменения количества буферов и перевода приложения с БДЕ на другую библиотеку мы никаких вариантов ускорения взаимодействия Приложения+СерверБД+БазаДанных не нашли. Пол года ждали новый 8-ми процессорный сервер, 16Гиг памяти, Аппаратный раид 1+0 с 10 SCSI дисками на 15000 оборотов в двух корзинах. Установили Linux 2.6, Ну теперь-то тормозов быть недолжно ???
Теперь процессы не "падали в swap", не ждали данных с диска.
Но тормоза всё равно посещают нашу базу данных :(
Сделали бакуп+ресторе (минус 4-ре часа ночной жизни). Ситуация не улучшилась.
Осталось сменить БДЕ на FIB+ и если это не поможет - тихо ползти в сторону канадской границы :)
Написали тестовую программу на FIB+ которая должна была показать преимущества FIB+ при работе с Firebird и мощь Firebird на 8-ми процессорном сервере.

Оказалось, что Linux при запуске более 4-х толстых читающих запросов на тестовой базе увеличивает простой процессоров и соответственно уменьшает общую скорость выполнения запросов. 8-мь толстых параллельных запросов работают в целом как 2-а толстых параллельных запроса :(
А при 10-ти - 40-ка толстых запросах общая скорость немного выше, чем скорость одного запроса.

Теперь ищем как настрить ядро (или что там ещё "нароем")
Вот такая проблема.
Вам удалось решить проблему? если да отпишитесь плиз.
Сталкнулись точно с такимже диагнозом. Ядро 2.6 както криво понижает приоритеты процессов Firebirda CS, толстые процессы вешают все запросы на серваке, перешли на старое ядро 2.4 ситуация кардинально изменилась, толстые процессы сразу падают в приоритет 25 и живут там себе спокойно, никому не мешая. Новый планироыщик ядра появившийся в 2.6 рыли, манипуляция noop,cqf, deadline... не дала нужного результата, вот и думаем может на 2.4 остаться?

Tchamlay_Oleg
Сообщения: 23
Зарегистрирован: 27 апр 2005, 12:40

Re: Возникновение тормозов на больших базах

Сообщение Tchamlay_Oleg » 19 мар 2007, 17:10

Lyas писал(а): Вам удалось решить проблему? если да отпишитесь плиз.
Сталкнулись точно с такимже диагнозом. Ядро 2.6 както криво понижает приоритеты процессов Firebirda CS, толстые процессы вешают все запросы на серваке, перешли на старое ядро 2.4 ситуация кардинально изменилась, толстые процессы сразу падают в приоритет 25 и живут там себе спокойно, никому не мешая. Новый планироыщик ядра появившийся в 2.6 рыли, манипуляция noop,cqf, deadline... не дала нужного результата, вот и думаем может на 2.4 остаться?
У нас проблема обнаружилась в конфигурации менеджера блокировок fb_lock_mngr.
По результатам полученным утилитой fb_lock_print (следили за процентом ожидающий блокировок) сделали вывод, что не хватает "слотов". Увеличили параметр LockHashSlots в файле конфигурации до 1027 (написано, что это должно быть простое число. Долго "упрашивали" менеджер блокировок использовать новое значение - потом просто перегрузили сервер ;) ).
В результате процент ожидающих запросов с снизился 40%-90% до 5%-25% .
Пользователи перестали жаловаться. Мониторинг скорости выполнения тестовых запросов показывает отсутствие падения производительности.

barsuk
Сообщения: 8
Зарегистрирован: 09 авг 2005, 10:28

Сообщение barsuk » 12 апр 2007, 11:50

аналогичная ситуация
LockHashSlots не помог
думаю дело в ядре, создал отдельную тему о не совместимости 2.6 и firebird

Ответить