|
|
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Вопрос довольно абстрактный, но всё же... Есть ли смысл что-то фрагментировать в OLTP-системе, если dbspace находится на единственном RAID-е? Может быть, у кого-нибудь есть какой-то опыт... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2009, 17:29 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Leonid Vorontsov, Ответ довольно абстрактный .... :) Как известно, для OLTP наиболее систем, наиболее предпочтителен индексный метод доступа ISAM. Собственно и ответ - фрагметировать индексы. Стратегия фрагментации, зависит от природы данных (гистограммы распределение данных), частоте доступа и т.д. Надеюсь, что у Вас SMP-система и RAID не 5-го уровня. С уважением, Вадим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2009, 19:20 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Н-да, ответ тоже будет не прямой. 1. Фрагментация ради увеличения производительности. Года 2 назад, проанализировав свои индексы решил уменьшить количество levels с помощью фрагментации. Пересоздал индексы - уменьшил, правда токо на 1 уровень. Далее, теория теорией, но нужно как-то проверить. Составил тест для выборки нескольких миллионов единичных значений. В итоге, при сравнительном тесте на фрагментированном по выражению индексе и на индексе состоящему из 1 partnum пришел к одинаковым результатам по количеству ISAM вызовов, количеству чтений буферов и времени выполнения. Почему так получилось - не стал разбираться, это было на 9.40 и создавать кучу пространств для фрагментирования индексов не хотелось. М.б., есди бы levels уменьшился на 3 получился бы выигрыш, а может я не то сравнивал, давно это было Round robin для ускорения вставок не пробовал - не скажу. 2. Фрагментация для обхода ограничений сервера. Есть ограничения на размер partnum, количество в нем строк, количества экстентов. Для обхода эих ограничений можно воспользоваться фрагментацией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 10:07 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
И еще 1 момент касательно сжатия данных на 11.50. Уменьшая размер ОЛТП БД вы в некотом роде увеливаете доступность сервера. Большие таблицы можно фрагментировать а "старые" фрагменты сжимать, таким образом уменьшая размер БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 10:12 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Leonid VorontsovЗдравствуйте! Вопрос довольно абстрактный, но всё же... Есть ли смысл что-то фрагментировать в OLTP-системе, если dbspace находится на единственном RAID-е? Собственно, zaiets уже затронул контекст - "для чего" или "какая цель ?" Варианты наших ответов могут быть разными в зависимости от твоего ответа: - появилось свободное время и можно попробовать поиграться - начальство ставит задачу разобраться - нужно улучшить производительность, ищу способы - приближаются некоторые ограничения (критичный размер tablespace), которые надо обходить то ли сменой версии то ли фрагментацией - захотелось поговорить/пообщаться на форуме, а то активность народа упала :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 13:58 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Система - SMP, RAID - 10-й. То, что приходится обходить ограничения фрагментированием - ясно. Задача - быстродействие. zaiets, конечно, огорчил :-( Хотя Performance Guide утверждает, что быстродействие можно улучшить! За счёт исключения сервером фрагментов при выполнении запроса, а также за счёт снижения конкуренции запросов на фрагмент... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 16:26 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Leonid VorontsovСистема - SMP, RAID - 10-й. То, что приходится обходить ограничения фрагментированием - ясно. Задача - быстродействие. zaiets, конечно, огорчил :-( Хотя Performance Guide утверждает, что быстродействие можно улучшить! За счёт исключения сервером фрагментов при выполнении запроса, а также за счёт снижения конкуренции запросов на фрагмент...Ну так можно и ухудшить также, и оптимизатору сложнее планы выдумывать и полный обход всех фрагментов дороже чем обход одного. Производительность увеличивают анализом и устранением узких мест, а не фрагментированием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 16:36 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Leonid VorontsovСистема - SMP, RAID - 10-й. То, что приходится обходить ограничения фрагментированием - ясно. Задача - быстродействие. zaiets, конечно, огорчил :-( Хотя Performance Guide утверждает, что быстродействие можно улучшить! За счёт исключения сервером фрагментов при выполнении запроса, а также за счёт снижения конкуренции запросов на фрагмент... мы используем фрагментацию для исключения сервером фрагментов при выполнении запроса. никто не жаловался, что медленнее стало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 17:04 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Производительность увеличивают анализом и устранением узких мест, а не фрагментированием. +1. Для OLTP может быть критичным не сколько глубина индекса, как быстрое его вытеснение из буферного пула. Банальная нехватака буферов. Помимо увеличения буферов, Уменьшить параметры упреждающего чтения , индексы зачитываются в память через RA_ при этом могут выбивать из буферов нужные данные(другие индексы). можно рассмотреть возможность уменьшения индексного ключа( для сложных индексов), использование сурогатных ключей Ревизия планов запросов, удаление лишних индексов. Ревизия и разбиение таблиц, для установки связей 1 к 1 и дальнейшей пакетной подготовкой данных для последующей обработки. Фрагментирование может быть полезно с точки зрения удаления старых данных. Если эту операцию рассматривать как критичную по времени. Иногда ради быстрого удаления старых данных можно пойти на легкую просадку в опертивной производительности , если речь идет о системе 24 /7/365. Ответ такой же общий как и вопрос. Первое, на что нужно смотреть onstat -P . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 17:44 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
авторРевизия и разбиение таблиц, для установки связей 1 к 1 и дальнейшей пакетной подготовкой данных для последующей обработки. Эта штука очень хорошо повышает производительность, но возможна только как рефакторинг. При учете жизненных циклов данных и циклов обработки в системе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 18:22 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис... и полный обход всех фрагментов дороже чем обход одного. А как же фулл скан и параллельное сканирование фрагментов (и последующая параллельная сортировка) ? Журавлев ДенисПроизводительность увеличивают анализом и устранением узких мест, а не фрагментированием. Полностью согласен. Но постоянно встречались ситуации. когда люди понимая, что анализ это очень трудозатратно и долго, просят некие средства для быстрого (сиюминутного) решения проблем производительности. А так как нормально измерить результат нечем (в лучшем случае некий долгоиграющий отчет, который к производительности OLTP-запросов не имеет никакого отношения), то главное (что то сделать) достигается фрагментированием и включением PDQ на некоторых тяжелых отчетах :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 18:45 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Leonid VorontsovСистема - SMP, RAID - 10-й. То, что приходится обходить ограничения фрагментированием - ясно. Задача - быстродействие. zaiets, конечно, огорчил :-( Хотя Performance Guide утверждает, что быстродействие можно улучшить! За счёт исключения сервером фрагментов при выполнении запроса, а также за счёт снижения конкуренции запросов на фрагмент... Прошу прощения, с утра я был в глубоком расстройстве по поводу проигрыша ДК. К вечеру вроде как немного отошел. Сейчас призадумался, и точно сказать не могу что именно я тестировал. помню, что задачу поставил - уменьшение количества чтений индексных страниц за счет уменьшения levels. И, как оказывается. хватил меня склероз. Точно как решал - не скажу. Мог как фрагментированием так и увеличением размера странницы. Но, результат был негативный. поэтому отзываю свои слова назад. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 19:32 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
vasilis А так как нормально измерить результат нечем (в лучшем случае некий долгоиграющий отчет, который к производительности OLTP-запросов не имеет никакого отношения), то главное (что то сделать) достигается фрагментированием и включением PDQ на некоторых тяжелых отчетах :) Я наблюдал картину, когда включение PDQ для отчетов, уменьшало производительность OLTP раза ~3 OLTP Сессии толклись на коротких сортировках вокруг PDQ памяти и не могли ее поделить. Уменьшение PDQPRIORITY увеличивало производительнсть OLTP и уменьшало скорость отчетов. Тут нужно искать либо компромис, либо чем то жертовать . Как привило в жертву приностился админ, который по звонку дергает onmode -D в ту или иную сторону, если есть лишняя память. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 19:40 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
На 11.50 с разным окружением вроде как не проблема. В пределах 1го хоста делаете PRI и SDS. SDS настраиваете на PDQ и вперед. либо на HDR. Если конечно позволяет логика приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 19:54 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
onstat- Как привило в жертву приностился админ, который по звонку дергает onmode -D в ту или иную сторону, если есть лишняя память. Дергать нужно до запуска отчета. Могут быть проблемы с подготовленными запросами ( prepare), они продолжают жить своей жизнью. В конечном итоге отчеты , длинные транзакции и OLTP нужно разносить по разным серверам. Плохо они дружатся, не любят друг друга. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 20:00 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
zaiets Если конечно позволяет логика приложения. А если не позволяет , то обсновывать затраты на рефакторинг. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 20:03 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
vasilis А как же фулл скан и параллельное сканирование фрагментов (и последующая параллельная сортировка) ?речь была про oltp, они просто будут стоять в очереди за pdq ресурсом. vasilis Полностью согласен. Но постоянно встречались ситуации. когда люди понимая, что анализ это очень трудозатратно и долго, просят некие средства для быстрого (сиюминутного) решения проблем производительности. А так как нормально измерить результат нечем (в лучшем случае некий долгоиграющий отчет, который к производительности OLTP-запросов не имеет никакого отношения), то главное (что то сделать) достигается фрагментированием и включением PDQ на некоторых тяжелых отчетах :)В общем все еще хуже. Теоретически надо выяснить самые критичные для бизнеса места и если они "узкие" начать ими заниматься. Мой опыт показывает что имеет смысл разбираться в планах запросов, и точить , точить их. Фрагментировать огромные таблицы (скорее даже индексы) можно только если в запросах к ним участвует ключ фрагментации, ну или чтобы избежать максимального кол-ва экстентов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 22:02 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
В oltp системе pdq можно включать только для долгоиграющих (dss) запросов. Причем порядок работы такой, включаем pdq, делаем select, close его курсор, выключаем pdq ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2009, 22:09 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис включаем pdq ... выключаем pdq Это как? В смысле какими командами? Мне казалось, что PDQpriority настраивается только через onconfig. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2009, 21:17 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
bk0010Журавлев Денис включаем pdq ... выключаем pdq Это как? В смысле какими командами? Мне казалось, что PDQpriority настраивается только через onconfig. Как всё плохо. onconfig только ограничивает эти ресурсы сверху. SET PDQPRIORITY сессии - вот нижний уровень управления.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2009, 21:54 |
|
||
|
Фрагментация
|
|||
|---|---|---|---|
|
#18+
bk0010, да я пользовался и всем "своим" программерам рекомендовал включать вручную sql запросом set pqdp.... только там где надо. Причем в onconfig ставил типа pqdqueries =2, Иначе банальные insert одной строки с включенным pqd будет занимать ресурс (типа памяти 200 мб), и все будут стоять в очереди. Примерно из-за всего этого большим достижением считаю параметр nonpqdmem... Осталось дождаться умного общего буфера типа ораклячьего pga_aggregate_target ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2009, 09:23 |
|
||
|
|
start [/forum/moderation_log.php?user_name=Sapfeer]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 446ms |
| total: | 618ms |
| 0 / 0 |
