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

[Maks_f]

Собственно конфиг

Firebird 1.5
два проца 3.2 ксеона
2гига оперативки
5 raid
100 гигов логическом диске где база
база 11 гиг

работаем под супером так как под классиком нет возможности нормально шотдаун делать

свободного места лигическом диске где база 24 гига

тормоза бешенные - планы, запросы все выверенно. Раз в неделю делаем бекап рестор, раз вдень свип.

Так вот с какого-то момента, появились тормоза, т.е. свип идет по 5 часов вместо 40 минут.
Может кто подскажет влияет ли на общую производитеольность наличие на этом же винте большого ко-ва мелких файлов к которым обращаются но очень редко. Может у кого есть подобный опыт. Нет ли жестких рекомендаций по поводу наличия на одном логическом винте с базой других файлов.

[CyberMax]

Тут найдешь статьи по настройке:http://www.ibase.ru/develop.htm
Если есть проблемы с какими-то определенными запросами, тогда тебе в раздел "Общие проблемы". Прочитаешь прилепленную тему про доп. информацию и создавай свою тему по конкретному запросу. А там, глядишь, и с другими разрешится.

[Merlin]

40 минут свип на такой базе-железе - норма? Застрелиться и не жить... Всё выверено, говоришь... Ну-ну. IBAnalyst тебе в руки. Насоздавал поди индексов по полям типа да/нет и апдейтишь эти поля раз в минуту без коммитов часами.

[kdv]

для сравнения по железу.
на базе 2.5 гиг на обычном SATA-диске sweep в "монопольном" режиме выполняется примерно 1 минуту, на любой версии IB/FB (как минимум на FB 1.5/IB 7.x.
вот "вернут" мне новый диск из ремонта, я вам скажу, сколько sweep на 11-гиговой базе будет занимать.

А пока замечание такое - если диски SCSI, крутите параметры контроллера. Сейчас ситуация такая, что в базовой конфигурации или вообще SCSI медленнее SATA. При некоторых настройках - может быть в 2-10 раз хуже.

[Merlin]

вот "вернут" мне новый диск из ремонта, я вам скажу, сколько sweep на 11-гиговой базе будет занимать.

Да я тебе прям щас скажу - не больше 5 в базарный день при 100 тыщах транзакций в день и вечернем гапе тыщи в три.

[Tchamlay_Oleg]

Собственно конфиг

Firebird 1.5
два проца 3.2 ксеона
2гига оперативки
5 raid
100 гигов логическом диске где база
база 11 гиг

Наша конфигурация:
Firebird 1.5.1
4 двухядерных Intel(R) Xeon(TM) CPU 2.66GHz
16 гиг оперативки
10raid аппаратный LSI Logic / Symbios Logic MegaRAID
60 гигов логическом диске где база
база 24 гиг

работаем под супером так как под классиком нет возможности нормально шотдаун делать

У нас classic. шутдаун делаем так: killall fb_inet_server

свободного места лигическом диске где база 24 гига

свободного места логическом диске где база 31 гиг

тормоза бешенные - планы, запросы все выверенно.

Тормоза временами сильные и возникают по какому-то "скрытому" от нас сценарию.
Коннектов около 60-100
Запросы и планы не выверены.

Раз в неделю делаем бекап рестор, раз вдень свип.

Так вот с какого-то момента, появились тормоза, т.е. свип идет по 5 часов вместо 40 минут.

У нас свип идет порядка 9-12 минут вечером и около 50 минут днем

Информация отранзакциях перед свипом
starting at Thu Dec 14 20:10:01 VLAT 2006
-------------------------------------
Oldest transaction: 32516877
Oldest active: 33998300
Snapshot: 33998300
Next transaction: 33998303

и после свипа
starting at Thu Dec 14 20:19:01 VLAT 2006
-------------------------------------
Oldest transaction: 34010893
Oldest active: 34010894
Snapshot: 34010872
Next transaction: 34011044
.....................................

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

По идее наличие большого количества файлов на этом же винте не должно влиять на производительность. (Особенно если эти файлы лежат в другом каталоге).
(Сам не проверял - не было много маленьких файлов. Хотя проблема с долгим свипом была)

У нас были такие проблемы на предыдущем сервере
(долгий свип - после массового изменения/удаления+добавление не успевал отрабатывать с часу ночи до 9 утра,
во время дневной работы процессы fb_inet_server временами ждали данных с диска) .

Конфигурация,
2 процессора по 2.4 Гигагерц
6 Гигабайт памяти
10 аппаратный раид

Долгий свип и ожидание данных поличилось увеличением оперативки.

Падение производительности - пока для нас не разрешимая проблема
даже на новом сервере

[Dimitry Sibiryakov]

шутдаун делаем так: killall fb_inet_server

На серверах до двойки это небезопасно. Как минимум получите как раз "висячие" транзакции. И вполне возможно потерянные страницы, версии записей. Или даже битые индексы.

Oldest transaction: 32516877
Oldest active: 33998300
Snapshot: 33998300
Next transaction: 33998303

Возможно я опять путаю, но в любом случае миллион транзакций в непонятном состоянии это круто.

[Tchamlay_Oleg]

шутдаун делаем так: killall fb_inet_server

На серверах до двойки это небезопасно. Как минимум получите как раз "висячие" транзакции. И вполне возможно потерянные страницы, версии записей. Или даже битые индексы.

Oldest transaction: 32516877
Oldest active: 33998300
Snapshot: 33998300
Next transaction: 33998303

Возможно я опять путаю, но в любом случае миллион транзакций в непонятном состоянии это круто.

Да транзакций ОЧЕНЬ много (временами доходит до 2 милиионов) (программа работает через БДЕ )
(у разработчиков есть планы по переводу на FIB+)
Но даже при таком количестве транзакций sweep делается намного быстрее, чем было ранее
( Автор справшивал про долгий свип. У нас вип временами был тоже очень долгий - доходил до 7 часов).

[kdv]

1. ibanalyst в руки
2. в случае bde, похоже, без запуска sweep действительно не обойтись, если днем начинаются тормоза.

[Tchamlay_Oleg]

1. ibanalyst в руки
2. в случае bde, похоже, без запуска sweep действительно не обойтись, если днем начинаются тормоза.

Я вообще отвечал на вопрос по поводу долгого свип
( как нам удалось получить приемлемое время его выполнения )
Но все равно спасибо!

[WildSery]

2. в случае bde, похоже, без запуска sweep действительно не обойтись, если днем начинаются тормоза.

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

[dimitr]

Так вот с какого-то момента, появились тормоза, т.е. свип идет по 5 часов вместо 40 минут.

тормоза только в свипе или вообще? Или напрягает именно свип? Или он ради красного словца тут?

[Merlin]

2. в случае bde, похоже, без запуска sweep действительно не обойтись, если днем начинаются тормоза.

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

Под сборкой мусора имеешь в виду именно сборку, или по инерции вопрошающих свип? Если первое, то я бы не сказал, что тормозов не будет.

[Tchamlay_Oleg]

Так вот с какого-то момента, появились тормоза, т.е. свип идет по 5 часов вместо 40 минут.

тормоза только в свипе или вообще? Или напрягает именно свип? Или он ради красного словца тут?

Я наверное не совсем удачно делился опытом как нам удалось уменьшить время свипа с 3-5 часов (ночью после бакупа) до приемлемых 9-30 минут (во время работы предприятия).
Началось примерно так-же как и у автора вопроса.
Два процессора по 1.8 Xeon 4гига оперативки 5RAID (программный) на трех SCSI дисках по 36Гиг на 10.000 оборотов и база 6Гиг.
После полутора лет эксплуатации начались тормоза и поиск причин. Приложение работает с БД через БДЕ. На вопрос, что делать? Ответ примерно один - много поколений и чаще делать свип. Настроили свип после ночного бакупа. В один из дней в 9:00 оказалось, что менеджеры не могу нормально отпускать товар - все запросы работают очень медленно. Выяснилось - не закончил работать свип стартанувший в час ночи. Ситуация стала повторятся чаще. В результате увеличения оперативной памяти до 16 Гиг при БД размером 30Гиг свип стал отрабатывать в приемлемое время днем. И при работающем свипе менеджеры могут работать.
Проблема с переодическими тормозами осталась. Но четкой взаимосвязи тормозов и свипа не прослеживается. Свип запускаем из скрипта по расписанию если средняя загрузка за минуту меньше 1.0. (Информацию о загрузке берем из /proc/loadavg). Бывают дни когда народ не жалуется на тормоза и статистика выполнения тестовых запросов тоже показывает отсутсвие падения производительности.

[Merlin]

Перебить индексы с селективностью 0.5, добиться, посредством управления транзакциями в приложении (taAutoCommit фтопку) суточного разрыва транзакций oldest - next хотя бы тысяч 20-30, уйти от технологий типа "всё удалить - вставить всё то же самое и ещё две записи и одну изменённую", "вставить пустую запись и апдейтить отдельными транзакциями при редактировании каждого поля в отдельности" и свип будет выполняться минут за 5 на 2х гигах оперативки.

[Tchamlay_Oleg]

Так вот с какого-то момента, появились тормоза, т.е. свип идет по 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-ка толстых запросах общая скорость немного выше, чем скорость одного запроса.

Теперь ищем как настрить ядро (или что там ещё "нароем")
Вот такая проблема.

[WildSery]

[quote="Merlin"][/quote]Именно сборку мусора.
Но это конечно сугубая имха, потому как реальные замеры относятся к серверу 1.0.3. Я знаю, что в двойке на порядок быстрее, но пока не перешли, не все сложности решены.
У нас в особо активных подразделениях, если автоматическая сборка мусора идёт, то к обеду примерно сервер становится колом, и простые запросы выполняются по несколько минут.
А вот запущенный с утра снэпшот - помогает, держит мусор, и база до вечера никаких тормозов не кажет. Ночью - бэкап-рестор.

[Merlin]

Осталось сменить БДЕ на FIB+ и если это не поможет - тихо ползти в сторону канадской границы

А на канадской границе вас ждёт IBAnalyst, который, к бабке не ходи, скажет что половину индексов (а то и поболе) надо отправить в помойку. Там же пребывает изучение планов ваших запросов на оставшейся половине индексов и расставление хинтов и прописывание явных планов в некоторых из них. После чего толстые запросы стремительно похудеют. Если же худобы таки не хватит, то за канадской границей вас ждёт концепция он-лайн (на триггерах) или ночного сбора хранимых агрегатов - полуфабрикатов для толстых запросов или даже готовых результатов вместо них.

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

Ещё бы. База-то на одном диске, вот они дружно в очередь к нему и выстраиваются. Я честно говоря не помню что есть 10 - простое зеркалирование вроде?

[Merlin]

Именно сборку мусора.
Но это конечно сугубая имха, потому как реальные замеры относятся к серверу 1.0.3. Я знаю, что в двойке на порядок быстрее, но пока не перешли, не все сложности решены.
У нас в особо активных подразделениях, если автоматическая сборка мусора идёт, то к обеду примерно сервер становится колом, и простые запросы выполняются по несколько минут.
А вот запущенный с утра снэпшот - помогает, держит мусор, и база до вечера никаких тормозов не кажет. Ночью - бэкап-рестор.

Чудно чего-то. У вас супер что ли? Там да, бывают проблемки при очень длинных цепочках версий. Что на эту тему говорит аналист у вас? Однако это игра с огнём - можно его накопить столько, что обычное чтение начнёт застревать.

[Merlin]

А вот запущенный с утра снэпшот - помогает, держит мусор

Кстати, если тебе уж так действительно необходимо блокировать сборку мусора, то висячий снапшот - не лучший вариант. Он ещё и TIP ведь раздувает. Есть более цивилизованный способ, только вслух при мальчонках говорить не хочу, тут же задействуют где надо и не надо. Намекну, ты-то разберёшься Вспомни один из параметров сервиса бакап и пошарь у kdv поиском похожие слова