iBase.ru Forum

Добрый день.
Никогда не занимался администрированием FB. Использовал его только для маленьких задач на несколько пользователей с небольшим объёмом данных (в основном работаю с Oracle). Но так случилось что одно приложение написанное 6ть лет назад выросло до "большого" размер - база весит 600Мб, количество пользователей перевалило за 10, ну и отдельный сервачёк появился под win2003.
но это призказка. Далее сказка.
Сервак откровенно стоит курит - нагрузка на проц только в моменты бекапа или тяжёлых отчётов. памяти жрёт 100-150М... но запросы немного медленне работать стали чем раньше.
Решил поотимизировать базу, например в память всю запихать:
gfix -buffers 20000
и правдвда Fb сожрал больше памяти 8к*20000 (размер блока у меня 8к, архитектура сервера - супер). Но почему-то не оперативной, а виртуальной.
Проверил так ли это сказав
gfix -buffers 80000 (640М) - fb сожрал 640M, но опять же в свопе...
И тормоза усилились.

Наверное я что-то не так делаю?

база весит 600Мб, количество пользователей перевалило за 10

это мелочь. хотя запросами можно убить и 100мб при двух пользователях.

немного медленне работать стали чем раньше

ключевая фраза - что сменен сервак и ос win2003. А это значит, что на новом серваке
а) или хреновые диски
б) или не те драйвера для дисков

Решил поотимизировать базу

а почему не в конфиге? и какой именно FB, мы должны догадываться?

fb сожрал 640M, но опять же в свопе

оперативную он будет использовать только когда надо.

Сейчас Fb 2.0.3.

Сборка мусора была автоматом - переделал на ежедневно ночью (как и бекап 2-3 раза в день перенёс только на ночь).
Это помогло избавится от резкого замедленияпри их запуске автоматом.

Сервер появился тем летом, до этого был ПК пользователя.
Про диски подумаю чем померить (если есть советы - буду благодарен).

Но ощущение такое что просто растёт база и нагрузка, падает скорость.
И 3-4 активных пользователей стало минимум 10. Справочники выросли на порядки. Попробовал половить "плохие запросы" щёлкая по кнопочкам - но вроде пока только один нашёл мерзкий (думаю как переписать). В остальном - просто работает медленнее чем хотелось бы. Везде.
Приложение на Fib+, транзакциями управляю ручками (там где они на запись), остальное в длинной читающей (+несколько справочников на авто через третью короткую пишущую).

Начинают просить разобраться - знакомлюсь с тем что могу сделать и не могу.

Про размер - было когда-то и 13Мб, но я уже не помню когда Для моих баз на Fb - это Размер.

а почему не в конфиге?

там же база для тестов и обучения. Я на ней размер и увеличивал. Конфиг же на все базы действует.

оперативную он будет использовать только когда надо.

Т.е. и не надо пытаться заставить сервак ВСЮ базу загнать в оперативку?

Кстати, я так и не могу себя заставить отказаться от супера в пользу классика (на серваке 2а проца, один из них соответствено всегда курит). Зря боюсь проэксперементировать? (ЗЫ на живой базе не буду - придумаю как замучать свой ноут в качестве сервера и эмулятора нагрузки).

xvv писал(а):Сейчас Fb 2.0.3.
Сборка мусора была автоматом - переделал на ежедневно ночью

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

xvv писал(а):Про диски подумаю чем померить (если есть советы - буду благодарен).

IOMeter ?

xvv писал(а):Но ощущение такое что просто растёт база и нагрузка, падает скорость.

А у меня ощущение (при таком смехотворном размере БД) что база криво спроектирована или запросы кривые.

xvv писал(а):остальное в длинной читающей

С какими параметрами? Не снэпшот случаем?
А отчёты?

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

Диски проверю в понедельник и отпишусь.

Про мусор - я и говорю что всё отлично.

Про транзакции и отчёты - посмотрю ещё раз. но вроде я там тоже всё выверял.

Я так понял что зря начал дефаултные параметры крутить?

xvv писал(а):вставлю фразу "под ораклом мной спроектированные базы в несколько терабайт работают на отлично".

Такого размера я видел только хранилища, в которых собственно никакой другой работы кроме складирования туда данных не ведётся

xvv писал(а):Я так понял что зря начал дефаултные параметры крутить?

Те, которые начал - имхо зря.
По умолчанию там всё неплохо стоит, а крутить надо, когда уже ясно узкое место, особенность твоей работы с БД.

Наиболее вероятная причина - медленный обмен данными с диском.
Ты бы поглядел диагностику во время работы, тот же Perfomance Monitor, а именно дисковые операции.

Про диски подумаю чем померить

да боже мой. HDTune, HDTach...

Приложение на Fib+, транзакциями управляю ручками (там где они на запись), остальное в длинной читающей (+несколько справочников на авто через третью короткую пишущую).

тогда откуда мусор и проблемы с авто-свипом??? Да еще на 2.03.

Зря боюсь проэксперементировать?

если отчеты частые, и именно в них напряг - тогда явно зря.

на живой базе не буду

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

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

Вообще-то десяток юзеров+полгига БД нагрузка плевая, чтоб начало валиться надо написать изрядно криво. У меня такую нагрузку легко ворочает древний сервачек с полугигом памяти и парой винтов в зеркале. По хорошему надо править исходники своей приклады до получения нормальной скорости, иначе потом и десяток сказевых винтов захлебнется, когда базулька еще подрастет. Направление уже дали - параметры транзакций.

Если ж железо, то вероятней всего упор идет в диски, поставь вменяемый рэйд адаптор(адаптек например) и пару САС винтов в зеркало, да и не забыть батарейку(bbu) и включить кэш на запись. Если не хватит пары дисков, то добить еще. Хотя чтоб их утилизировать написать надо совсем уж левой ногой программу. Критерий оптимальности для дисковой очередь к диску в моменты максимальной нагрузки, смотреть perfmon.exe. Если хронически выше 2, то наращивать мускулы дисковой подсистемы.

Да и для супера на двухголовой машинке на сделать привязку (аффинити) к одному процу.

Запустил монитор - смотрю. нагрузки на сервак почти нет. Спит. То что идёт на запись - вообще копейки - даже не заметно. На чтение - пики проц + диск. краткосрочные. отдельные (2-3 сек, загрузка 100% одного ядра, + активное чтение диска той же продолжительности). Явно какой-то запрос читается не по индексу.
Что хочу сделать:
1. Загнять всю базу в память. чтоб исключить дисковые чтения
2. Привязать ко второму процу процес FB
3. Монитором отловить этот запрос и оптимизировать.

Про первое - придумал пока только увеличить размер буфера и уменьшить до минимума размер свопа.

Про третье - в oracle есть em, который эти запросы сам отловит и пальчиком покажет (ну или те что дольше 10 сек висят можно и так поймать). Чем смотреть в FB выполняющиеся запросы и как ловить те, что висят 2-3 секунды?

И ещё - спасибо за советы, пусть и столь критичные.

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

увеличить размер кэша - это да, а вот своп уменьшать-то зачем???
Своп должен на 32 битной ОС быть например если памяти 2 гига, своп 2 гига. памяти 3 гига - своп 1 гиг. памяти 1 гиг - своп 3 гига. причем фиксированного размера, а не динамический.

Монитором отловить этот запрос и оптимизировать.

FBScanner-ом.

Привязать ко второму процу процес FB

только если FB Classic.

Я эту тему и начал с вопроса про своп. Увеличение кеша привело к тому что вырос своп и увеличились тормоза, а в оперативке сколько было Fb, столько и осталось.

И про привязку к процу.
Что-то я запутался. Класик прекрасно работает с кучей процов, а супер пока умеет работать только с одним. Так почему такой коментарий? (ЗЫ превязывать через конфиг или прочими утилитами?)

И ещё маленькая просьба - если указываете утилиту кидайте ссылку (если утилиты нет в разделе утилит).

Спасибо за ответ

Так почему такой коментарий?

именно потому.

превязывать через конфиг или прочими утилитами?

супер к одному процу (ядру) ? не пойму я, чего тебе надо. Вроде по поводу классика и супера все объяснили...

если указываете утилиту кидайте ссылку

где утилиты, какие утилиты... все в download

гугл нашёл и пояснил про FBScanner.

Но ощущение от общения - как будто на разных языках говорим.

гугл нашёл и пояснил про FBScaner.

дык. далеко ходить не надо. у нас все схвачено, мы монополисты

Но ощущение от общения - как будто на разных языках говорим.

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

p.s. может тебе к нам на курсы? чего зря метаться...

kdv писал(а):

Привязать ко второму процу процес FB

только если FB Classic.

Что-то идет какая-то путаница... классик никуда ведь привязывать не надо, есть 2 камня, замечательно, он задействует оба, а вот супер дело другое, чтоб он не метался от одного камня к другому ему и надо задать аффинити.
Или я вдруг все перепутал?

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

Или я вдруг все перепутал?

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

Были б курсы в ёбурге - попробовал бы от работы оторваться.
А так... не в этом году. И так дочку не вижу.

Можно я тогда по порядку помучаю?

Начинаю мучать
Читая форум и статьи на ibase пришёл к выводам, что в тормозах виновато:
1. Кривость приложения.
2. Мусор.
3. Дисковая подсистема.
4. настройки конфига.

Пункт 1 - слишком большой и оставим его за рамками обсуждения. Что делать, как ловить и как править сам могу рассказать.
Пункт 2. Написано много, что делать понятно, как проверить наличие проблемы всё понятно. И главное - в данном случае проблемы нет.
Пункт 3. Вот здесь и начинается интересное:
(когда я начал писать этот топик, то об этом и думал)

предпосылки:
- дисковая подсистема всегда самое узкое звено. Иначе смотри пункт 1.
- минимизация дисковых операций приводит к ускорению приложения.
- операции чтения с диска можно свести к 0 при наличии ОЗУ большего, чем объём базы данных.

Способ решения (тот который я решил применить):
- Увеличить кеш базы данных чтоб туда попало 90% постоянно используемых данных. а лучше все 100% даных . В Oracle - возможность первого - грамотное проектирования. Здесь даже если считать что первое не получилось, при смехотворном объеме должно получится второе. И ещё место под сортировки хватит.

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

Способ решения модифицированный:
Минимизировать своп, чтоб не дать туда засовывать FB.

Результат:
Мониторю. Пока не понятно.

Способ решения услышаный мной здесь, но пока до конце не понятый/проработаный (читаю про измерения скорости чтения дисков и утилиты. Для меня это очень далеко.):
Померить скорость дисковой подсистемы, поискать проблемы. Проблемы возможны в драйверах, дисках, настройках, железе.
Выявленные проблемы решить.

Результат:
Пытаюсь понять и сформировать конкретный план.

Что хочу обсудить:
1. неверность уменьшения свопа на системе. Как можно это сделать подругому.
2. Где смотреть конкретику про тестирование дисков (статьи, доки, желательно примитивный подход, а не теория. Или (и даже лучше) теория + пошаговая инструкция "как сделать").

Читая форум и статьи на ibase пришёл к выводам, что в тормозах виновато:
1. Кривость приложения.
2. Мусор.
3. Дисковая подсистема.
4. настройки конфига.

все сразу - это вряд-ли. Кроме того, пункт 2 обычно относится к пункту 1.

И главное - в данном случае проблемы нет.

то есть, в моменты торможений была собрана полная статистика, и мусора не обнаружено? Также нет застревания (долгих активных) транзакций?

В Oracle - возможность первого - грамотное проектирования.

по такому пути идут все кривописатели. медленно работает - мы поставим больше памяти и круче проц. Экстенсивное программирование?

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

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

Минимизировать своп, чтоб не дать туда засовывать FB.

бред.

читаю про измерения скорости чтения дисков и утилиты. Для меня это очень далеко.

что там далекого? элементарщина. чем один диск отличается от другого? Ценой? Это взгляд менеджера по закупкам. Любой любознательный человек знает, что у диска есть
а) скорость позиционирования
б) скорость передачи данных (transfer rate)

указанными софтинами transfer rate меряется и показывается на графике, который понятен даже детям.

Где смотреть конкретику про тестирование дисков

какая блин конкретика? стандартный sata диск должен обеспечивать трансфер в среднем 40-50 мегабайт в секунду (ноутбучные - 20-30). Тебе непонятен график hdtune?
тогда глянь сюда:
http://interbase.livejournal.com/558.html
там в конце три картинки.
если твои диски хуже - можешь выбрасывать их на помойку (или материнскую плату). Потому что это тест, проведенный 2 года назад, на дисках, которые уже не выпускают.
Кстати, если график transfer rate получится линейным, и ниже 30-40 мб в секунду - то это однозначно проблемы настроек драйверов или биоса.

p.s. хватит теоретизировать, давай практические результаты.

еще один вариант "дерьма" - "все на диске C:\".

kdv писал(а):

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

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

Сервер выделяет виртуалку при открытии БД, а наполняет её данными (потребляет физ. память) по мере чтения страниц из БД.
Так что никто никого никуда не вытесняет, просто кеш ещё пуст.