Swap
Модераторы: kdv, Alexey Kovyazin
Swap
Добрый день.
Никогда не занимался администрированием FB. Использовал его только для маленьких задач на несколько пользователей с небольшим объёмом данных (в основном работаю с Oracle). Но так случилось что одно приложение написанное 6ть лет назад выросло до "большого" размер - база весит 600Мб, количество пользователей перевалило за 10, ну и отдельный сервачёк появился под win2003.
но это призказка. Далее сказка.
Сервак откровенно стоит курит - нагрузка на проц только в моменты бекапа или тяжёлых отчётов. памяти жрёт 100-150М... но запросы немного медленне работать стали чем раньше.
Решил поотимизировать базу, например в память всю запихать:
gfix -buffers 20000
и правдвда Fb сожрал больше памяти 8к*20000 (размер блока у меня 8к, архитектура сервера - супер). Но почему-то не оперативной, а виртуальной.
Проверил так ли это сказав
gfix -buffers 80000 (640М) - fb сожрал 640M, но опять же в свопе...
И тормоза усилились.
Наверное я что-то не так делаю?
Никогда не занимался администрированием FB. Использовал его только для маленьких задач на несколько пользователей с небольшим объёмом данных (в основном работаю с Oracle). Но так случилось что одно приложение написанное 6ть лет назад выросло до "большого" размер - база весит 600Мб, количество пользователей перевалило за 10, ну и отдельный сервачёк появился под win2003.
но это призказка. Далее сказка.
Сервак откровенно стоит курит - нагрузка на проц только в моменты бекапа или тяжёлых отчётов. памяти жрёт 100-150М... но запросы немного медленне работать стали чем раньше.
Решил поотимизировать базу, например в память всю запихать:
gfix -buffers 20000
и правдвда Fb сожрал больше памяти 8к*20000 (размер блока у меня 8к, архитектура сервера - супер). Но почему-то не оперативной, а виртуальной.
Проверил так ли это сказав
gfix -buffers 80000 (640М) - fb сожрал 640M, но опять же в свопе...
И тормоза усилились.
Наверное я что-то не так делаю?
Последний раз редактировалось xvv 23 май 2008, 14:28, всего редактировалось 1 раз.
это мелочь. хотя запросами можно убить и 100мб при двух пользователях.база весит 600Мб, количество пользователей перевалило за 10
ключевая фраза - что сменен сервак и ос win2003. А это значит, что на новом сервакенемного медленне работать стали чем раньше
а) или хреновые диски
б) или не те драйвера для дисков
а почему не в конфиге? и какой именно FB, мы должны догадываться?Решил поотимизировать базу
оперативную он будет использовать только когда надо.fb сожрал 640M, но опять же в свопе
Сейчас Fb 2.0.3.
Сборка мусора была автоматом - переделал на ежедневно ночью (как и бекап 2-3 раза в день перенёс только на ночь).
Это помогло избавится от резкого замедленияпри их запуске автоматом.
Сервер появился тем летом, до этого был ПК пользователя.
Про диски подумаю чем померить (если есть советы - буду благодарен).
Но ощущение такое что просто растёт база и нагрузка, падает скорость.
И 3-4 активных пользователей стало минимум 10. Справочники выросли на порядки. Попробовал половить "плохие запросы" щёлкая по кнопочкам - но вроде пока только один нашёл мерзкий (думаю как переписать). В остальном - просто работает медленнее чем хотелось бы. Везде.
Приложение на Fib+, транзакциями управляю ручками (там где они на запись), остальное в длинной читающей (+несколько справочников на авто через третью короткую пишущую).
Начинают просить разобраться - знакомлюсь с тем что могу сделать и не могу.
Про размер - было когда-то и 13Мб, но я уже не помню когда Для моих баз на Fb - это Размер.
Кстати, я так и не могу себя заставить отказаться от супера в пользу классика (на серваке 2а проца, один из них соответствено всегда курит). Зря боюсь проэксперементировать? (ЗЫ на живой базе не буду - придумаю как замучать свой ноут в качестве сервера и эмулятора нагрузки).
Сборка мусора была автоматом - переделал на ежедневно ночью (как и бекап 2-3 раза в день перенёс только на ночь).
Это помогло избавится от резкого замедленияпри их запуске автоматом.
Сервер появился тем летом, до этого был ПК пользователя.
Про диски подумаю чем померить (если есть советы - буду благодарен).
Но ощущение такое что просто растёт база и нагрузка, падает скорость.
И 3-4 активных пользователей стало минимум 10. Справочники выросли на порядки. Попробовал половить "плохие запросы" щёлкая по кнопочкам - но вроде пока только один нашёл мерзкий (думаю как переписать). В остальном - просто работает медленнее чем хотелось бы. Везде.
Приложение на Fib+, транзакциями управляю ручками (там где они на запись), остальное в длинной читающей (+несколько справочников на авто через третью короткую пишущую).
Начинают просить разобраться - знакомлюсь с тем что могу сделать и не могу.
Про размер - было когда-то и 13Мб, но я уже не помню когда Для моих баз на Fb - это Размер.
там же база для тестов и обучения. Я на ней размер и увеличивал. Конфиг же на все базы действует.а почему не в конфиге?
Т.е. и не надо пытаться заставить сервак ВСЮ базу загнать в оперативку?оперативную он будет использовать только когда надо.
Кстати, я так и не могу себя заставить отказаться от супера в пользу классика (на серваке 2а проца, один из них соответствено всегда курит). Зря боюсь проэксперементировать? (ЗЫ на живой базе не буду - придумаю как замучать свой ноут в качестве сервера и эмулятора нагрузки).
2-ка отлично справляется с мусором и во время работы.xvv писал(а):Сейчас Fb 2.0.3.
Сборка мусора была автоматом - переделал на ежедневно ночью
Конечно, если предпринять специальные шаги в приложении для препятствования этому - можно и замедлить.
IOMeter ?xvv писал(а):Про диски подумаю чем померить (если есть советы - буду благодарен).
А у меня ощущение (при таком смехотворном размере БД) что база криво спроектирована или запросы кривые.xvv писал(а):Но ощущение такое что просто растёт база и нагрузка, падает скорость.
С какими параметрами? Не снэпшот случаем?xvv писал(а):остальное в длинной читающей
А отчёты?
Про кривость запросов - может быть. Писалось давно и левой пяткой, но над этим понятно как работать. Чтоб не сильно напирали на это - вставлю фразу "под ораклом мной спроектированные базы в несколько терабайт работают на отлично".
Диски проверю в понедельник и отпишусь.
Про мусор - я и говорю что всё отлично.
Про транзакции и отчёты - посмотрю ещё раз. но вроде я там тоже всё выверял.
Я так понял что зря начал дефаултные параметры крутить?
Диски проверю в понедельник и отпишусь.
Про мусор - я и говорю что всё отлично.
Про транзакции и отчёты - посмотрю ещё раз. но вроде я там тоже всё выверял.
Я так понял что зря начал дефаултные параметры крутить?
Такого размера я видел только хранилища, в которых собственно никакой другой работы кроме складирования туда данных не ведётсяxvv писал(а):вставлю фразу "под ораклом мной спроектированные базы в несколько терабайт работают на отлично".
Те, которые начал - имхо зря.xvv писал(а):Я так понял что зря начал дефаултные параметры крутить?
По умолчанию там всё неплохо стоит, а крутить надо, когда уже ясно узкое место, особенность твоей работы с БД.
Наиболее вероятная причина - медленный обмен данными с диском.
Ты бы поглядел диагностику во время работы, тот же Perfomance Monitor, а именно дисковые операции.
да боже мой. HDTune, HDTach...Про диски подумаю чем померить
тогда откуда мусор и проблемы с авто-свипом??? Да еще на 2.03.Приложение на Fib+, транзакциями управляю ручками (там где они на запись), остальное в длинной читающей (+несколько справочников на авто через третью короткую пишущую).
если отчеты частые, и именно в них напряг - тогда явно зря.Зря боюсь проэксперементировать?
каким образом для живой базы можеть иметь значение супер или классик?на живой базе не буду
кстати, вдул ты кэш в БД, это хорошо для супера, и если баз несколько.
не забудь обнулить, когда переведешь на классик.
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Автор, ты б определился, как оптимизировать железом или программу нормально напишешь?
Вообще-то десяток юзеров+полгига БД нагрузка плевая, чтоб начало валиться надо написать изрядно криво. У меня такую нагрузку легко ворочает древний сервачек с полугигом памяти и парой винтов в зеркале. По хорошему надо править исходники своей приклады до получения нормальной скорости, иначе потом и десяток сказевых винтов захлебнется, когда базулька еще подрастет. Направление уже дали - параметры транзакций.
Если ж железо, то вероятней всего упор идет в диски, поставь вменяемый рэйд адаптор(адаптек например) и пару САС винтов в зеркало, да и не забыть батарейку(bbu) и включить кэш на запись. Если не хватит пары дисков, то добить еще. Хотя чтоб их утилизировать написать надо совсем уж левой ногой программу. Критерий оптимальности для дисковой очередь к диску в моменты максимальной нагрузки, смотреть perfmon.exe. Если хронически выше 2, то наращивать мускулы дисковой подсистемы.
Да и для супера на двухголовой машинке на сделать привязку (аффинити) к одному процу.
Вообще-то десяток юзеров+полгига БД нагрузка плевая, чтоб начало валиться надо написать изрядно криво. У меня такую нагрузку легко ворочает древний сервачек с полугигом памяти и парой винтов в зеркале. По хорошему надо править исходники своей приклады до получения нормальной скорости, иначе потом и десяток сказевых винтов захлебнется, когда базулька еще подрастет. Направление уже дали - параметры транзакций.
Если ж железо, то вероятней всего упор идет в диски, поставь вменяемый рэйд адаптор(адаптек например) и пару САС винтов в зеркало, да и не забыть батарейку(bbu) и включить кэш на запись. Если не хватит пары дисков, то добить еще. Хотя чтоб их утилизировать написать надо совсем уж левой ногой программу. Критерий оптимальности для дисковой очередь к диску в моменты максимальной нагрузки, смотреть perfmon.exe. Если хронически выше 2, то наращивать мускулы дисковой подсистемы.
Да и для супера на двухголовой машинке на сделать привязку (аффинити) к одному процу.
Запустил монитор - смотрю. нагрузки на сервак почти нет. Спит. То что идёт на запись - вообще копейки - даже не заметно. На чтение - пики проц + диск. краткосрочные. отдельные (2-3 сек, загрузка 100% одного ядра, + активное чтение диска той же продолжительности). Явно какой-то запрос читается не по индексу.
Что хочу сделать:
1. Загнять всю базу в память. чтоб исключить дисковые чтения
2. Привязать ко второму процу процес FB
3. Монитором отловить этот запрос и оптимизировать.
Про первое - придумал пока только увеличить размер буфера и уменьшить до минимума размер свопа.
Про третье - в oracle есть em, который эти запросы сам отловит и пальчиком покажет (ну или те что дольше 10 сек висят можно и так поймать). Чем смотреть в FB выполняющиеся запросы и как ловить те, что висят 2-3 секунды?
И ещё - спасибо за советы, пусть и столь критичные.
Что хочу сделать:
1. Загнять всю базу в память. чтоб исключить дисковые чтения
2. Привязать ко второму процу процес FB
3. Монитором отловить этот запрос и оптимизировать.
Про первое - придумал пока только увеличить размер буфера и уменьшить до минимума размер свопа.
Про третье - в oracle есть em, который эти запросы сам отловит и пальчиком покажет (ну или те что дольше 10 сек висят можно и так поймать). Чем смотреть в FB выполняющиеся запросы и как ловить те, что висят 2-3 секунды?
И ещё - спасибо за советы, пусть и столь критичные.
увеличить размер кэша - это да, а вот своп уменьшать-то зачем???только увеличить размер буфера и уменьшить до минимума размер свопа.
Своп должен на 32 битной ОС быть например если памяти 2 гига, своп 2 гига. памяти 3 гига - своп 1 гиг. памяти 1 гиг - своп 3 гига. причем фиксированного размера, а не динамический.
FBScanner-ом.Монитором отловить этот запрос и оптимизировать.
только если FB Classic.Привязать ко второму процу процес FB
Я эту тему и начал с вопроса про своп. Увеличение кеша привело к тому что вырос своп и увеличились тормоза, а в оперативке сколько было Fb, столько и осталось.
И про привязку к процу.
Что-то я запутался. Класик прекрасно работает с кучей процов, а супер пока умеет работать только с одним. Так почему такой коментарий? (ЗЫ превязывать через конфиг или прочими утилитами?)
И ещё маленькая просьба - если указываете утилиту кидайте ссылку (если утилиты нет в разделе утилит).
Спасибо за ответ
И про привязку к процу.
Что-то я запутался. Класик прекрасно работает с кучей процов, а супер пока умеет работать только с одним. Так почему такой коментарий? (ЗЫ превязывать через конфиг или прочими утилитами?)
И ещё маленькая просьба - если указываете утилиту кидайте ссылку (если утилиты нет в разделе утилит).
Спасибо за ответ
дык. далеко ходить не надо. у нас все схвачено, мы монополистыгугл нашёл и пояснил про FBScaner.
так ты постоянно хочешь разного. то тебе своп мешает, то кэш увеличиваешь, то супер на 1 проц пристебать, то мусор у тебя какой-то, то запросы тормозящие ищешь. Все это разные вещи. Может у тебя вообще - или диски фиговые или дрова к контроллеру дисков. А ты мучаешься.Но ощущение от общения - как будто на разных языках говорим.
p.s. может тебе к нам на курсы? чего зря метаться...
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Что-то идет какая-то путаница... классик никуда ведь привязывать не надо, есть 2 камня, замечательно, он задействует оба, а вот супер дело другое, чтоб он не метался от одного камня к другому ему и надо задать аффинити.kdv писал(а):только если FB Classic.Привязать ко второму процу процес FB
Или я вдруг все перепутал?
Да и если есть исходники программы, зачем ловить запросы сторонним монитором? Банально спросить юзера в каком конкретно месте тормозить, поднять исходник и поправить.
По крайней меря я так борюсь с тормозами, вродь вполне успешно.
Были б курсы в ёбурге - попробовал бы от работы оторваться.
А так... не в этом году. И так дочку не вижу.
Можно я тогда по порядку помучаю?
Начинаю мучать
Читая форум и статьи на ibase пришёл к выводам, что в тормозах виновато:
1. Кривость приложения.
2. Мусор.
3. Дисковая подсистема.
4. настройки конфига.
Пункт 1 - слишком большой и оставим его за рамками обсуждения. Что делать, как ловить и как править сам могу рассказать.
Пункт 2. Написано много, что делать понятно, как проверить наличие проблемы всё понятно. И главное - в данном случае проблемы нет.
Пункт 3. Вот здесь и начинается интересное:
(когда я начал писать этот топик, то об этом и думал)
предпосылки:
- дисковая подсистема всегда самое узкое звено. Иначе смотри пункт 1.
- минимизация дисковых операций приводит к ускорению приложения.
- операции чтения с диска можно свести к 0 при наличии ОЗУ большего, чем объём базы данных.
Способ решения (тот который я решил применить):
- Увеличить кеш базы данных чтоб туда попало 90% постоянно используемых данных. а лучше все 100% даных . В Oracle - возможность первого - грамотное проектирования. Здесь даже если считать что первое не получилось, при смехотворном объеме должно получится второе. И ещё место под сортировки хватит.
Результат:
FB действительно сожрал памяти под кеш. но вся память оказалась из свопа. В итоге дисковые чтения не уменьшились, а увеличились. Скорость упала.
Способ решения модифицированный:
Минимизировать своп, чтоб не дать туда засовывать FB.
Результат:
Мониторю. Пока не понятно.
Способ решения услышаный мной здесь, но пока до конце не понятый/проработаный (читаю про измерения скорости чтения дисков и утилиты. Для меня это очень далеко.):
Померить скорость дисковой подсистемы, поискать проблемы. Проблемы возможны в драйверах, дисках, настройках, железе.
Выявленные проблемы решить.
Результат:
Пытаюсь понять и сформировать конкретный план.
Что хочу обсудить:
1. неверность уменьшения свопа на системе. Как можно это сделать подругому.
2. Где смотреть конкретику про тестирование дисков (статьи, доки, желательно примитивный подход, а не теория. Или (и даже лучше) теория + пошаговая инструкция "как сделать").
А так... не в этом году. И так дочку не вижу.
Можно я тогда по порядку помучаю?
Начинаю мучать
Читая форум и статьи на ibase пришёл к выводам, что в тормозах виновато:
1. Кривость приложения.
2. Мусор.
3. Дисковая подсистема.
4. настройки конфига.
Пункт 1 - слишком большой и оставим его за рамками обсуждения. Что делать, как ловить и как править сам могу рассказать.
Пункт 2. Написано много, что делать понятно, как проверить наличие проблемы всё понятно. И главное - в данном случае проблемы нет.
Пункт 3. Вот здесь и начинается интересное:
(когда я начал писать этот топик, то об этом и думал)
предпосылки:
- дисковая подсистема всегда самое узкое звено. Иначе смотри пункт 1.
- минимизация дисковых операций приводит к ускорению приложения.
- операции чтения с диска можно свести к 0 при наличии ОЗУ большего, чем объём базы данных.
Способ решения (тот который я решил применить):
- Увеличить кеш базы данных чтоб туда попало 90% постоянно используемых данных. а лучше все 100% даных . В Oracle - возможность первого - грамотное проектирования. Здесь даже если считать что первое не получилось, при смехотворном объеме должно получится второе. И ещё место под сортировки хватит.
Результат:
FB действительно сожрал памяти под кеш. но вся память оказалась из свопа. В итоге дисковые чтения не уменьшились, а увеличились. Скорость упала.
Способ решения модифицированный:
Минимизировать своп, чтоб не дать туда засовывать FB.
Результат:
Мониторю. Пока не понятно.
Способ решения услышаный мной здесь, но пока до конце не понятый/проработаный (читаю про измерения скорости чтения дисков и утилиты. Для меня это очень далеко.):
Померить скорость дисковой подсистемы, поискать проблемы. Проблемы возможны в драйверах, дисках, настройках, железе.
Выявленные проблемы решить.
Результат:
Пытаюсь понять и сформировать конкретный план.
Что хочу обсудить:
1. неверность уменьшения свопа на системе. Как можно это сделать подругому.
2. Где смотреть конкретику про тестирование дисков (статьи, доки, желательно примитивный подход, а не теория. Или (и даже лучше) теория + пошаговая инструкция "как сделать").
все сразу - это вряд-ли. Кроме того, пункт 2 обычно относится к пункту 1.Читая форум и статьи на ibase пришёл к выводам, что в тормозах виновато:
1. Кривость приложения.
2. Мусор.
3. Дисковая подсистема.
4. настройки конфига.
то есть, в моменты торможений была собрана полная статистика, и мусора не обнаружено? Также нет застревания (долгих активных) транзакций?И главное - в данном случае проблемы нет.
по такому пути идут все кривописатели. медленно работает - мы поставим больше памяти и круче проц. Экстенсивное программирование?В 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. хватит теоретизировать, давай практические результаты.
Сервер выделяет виртуалку при открытии БД, а наполняет её данными (потребляет физ. память) по мере чтения страниц из БД.kdv писал(а):попахивает бредом. если я указываю большой кэш серверу, то у меня не только растет размер занятой виртуалки, но и размер занимаемой сервером памяти. Если размер занимаемой сервером памяти мал по сравнению с виртуалкой, значит серверу не хватает физической памяти. Т.е. нечто вытесняет его в виртуал. Это, как бы, элементарные вещи, вообще.FB действительно сожрал памяти под кеш. но вся память оказалась из свопа. В итоге дисковые чтения не уменьшились, а увеличились. Скорость упала.
Так что никто никого никуда не вытесняет, просто кеш ещё пуст.