Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
PG8.2.5 Ubuntu. Памяти 4Гб, raid5 5x15K таблицы, связанны FK на INT4, все поля, по которым происходит объединение имеют индексы. Откуда берутся такие ошибки в планировщике: start-up cost =570 total cost = 6000 ? После facuum full, analyze, reindex. Без изменений Код: plaintext 1. 2. 3. 4. 5. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2008, 17:10 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
Что-то я не понял где Вы увидели ошибки планировщика. ИМХО план соответсвует тому что Вы запросили у Постгреса. PLI (80К) стыкуется с 2 мелкими справочниками и одной толстой таблицы. Оптять же 72683 строк по 62юайта - это ~4М результата. А первую строчку Вы получите практически мгновенно 65мсек. Можете попробовать отключить seq_scan, но не думаю, чтоэто поможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2008, 17:46 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
за секунду перемолотил 70 тыс строк - наверное это ок? в чем ошибка - в том что выбрал seqscan? или ошибка в подсчете cost=570.63..5157.34? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2008, 22:02 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat в чем ошибка - в том что выбрал seqscan? или ошибка в подсчете cost=570.63..5157.34? Ошибка, IMHO, в подсчете. Никогда не видел такой большой разницы. Я неверно тему сформулировал. Именно SeqScan и должен быть, раз берут всю таблицу. Верно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2008, 23:21 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
tadmin LeXa NalBat в чем ошибка - в том что выбрал seqscan? или ошибка в подсчете cost=570.63..5157.34? Ошибка, IMHO, в подсчете. Никогда не видел такой большой разницы. 570 - это время первой строки, оно действительно небольшое, но потом нужно "поднять" всю таблицу на 70 тыс строк, а закончится это нескоро. tadmin Я неверно тему сформулировал. Именно SeqScan и должен быть, раз берут всю таблицу. Верно? По крайней мере очень похоже на правду. :) PS Может меня LeXa NalBat поправит и дополнит, но бывают две ошибки оптимизатора: 1. Ошибка оценки количества строк. Это выглядит как большая разница между строками explain и строками explain analyze. Как следствие - неправильный план выполнения запроса. 2. Просто неправильно выбранный план. Это сложно диагностируемая ошибка, обычно обнаруживатеся по тому, что запрос "тормозит", и вроде как есть представление о том, как по другому можно написать план выполнения запроса. И есть еще несколько распространённых случаев: 1. Ошибка разработчика SQL, когда он пишет, мягко скажем, неоптимальный запрос, который СУБД не может переколбасить его во что-то более приличное. 2. Отсутствие в СУБД некторых "фич" (обычно идёт вопрос "А у меня в ххх работает в 100 раз быстрее!" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2008, 09:40 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
всем спасибо, похоже все в порядке, я лишь неверно интерпертирую план запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2008, 10:17 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
Andrey Daeron tadminОшибка, IMHO, в подсчете. Никогда не видел такой большой разницы.570 - это время первой строки, оно действительно небольшое, но потом нужно "поднять" всю таблицу на 70 тыс строк, а закончится это нескоро.да. причем время выдачи первой строки 570 не близко к нулю, потому что перед выдачей первой строки надо полностью построить хэш в 16 тыс строк salearticles Andrey Daeron tadminЯ неверно тему сформулировал. Именно SeqScan и должен быть, раз берут всю таблицу. Верно?По крайней мере очень похоже на правду. :)да, план хороший PS по оценкам планировщика не все понятно. может кто-нибудь объяснит? Код: plaintext 1. 2. 3. почему планировщик считает, что на построение hash вообще не тратися времени по сравнению с seqscan: cost 369.21 == 369.21? хотя на самом деле таблица сканируется за time 31.127, а хэш строится за 65.132. почему планировщик считает, что первая строка от Hash Join будет возвращена через cost 570.63, должно быть наверное: цена построения хэша cost 369.21 плюс еще чуть-чуть - откуда разница в 200? в реальном времени наблюдаем: time 65.132 ~= 65.336. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2008, 10:25 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat почему планировщик считает, что на построение hash вообще не тратися времени по сравнению с seqscan: cost 369.21 == 369.21? хотя на самом деле таблица сканируется за time 31.127, а хэш строится за 65.132. cpu_operator_cost такого поведения нельзя "добиться"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2008, 12:47 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
Gold_ cpu_operator_cost такого поведения нельзя "добиться"? Был не прав. Параметры влияющие на стоимость запрооса не трогал. Стоимость на hash не считается. постгрес 7.4.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2008, 13:32 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
Не поясните ли, в чем измеряется "cost" ? Вероятно эти попугаи сложно связаны связаны с реальным временем через доступные IOPS для подъема страниц, циклы CPU и т.д. PGDOCS, по-моему, никак не трактуют их размерность Есть где-нибудь рассуждения на эту тему в общем смысле? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2008, 13:57 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
tadminНе поясните ли, в чем измеряется "cost" ? 14.1. Using EXPLAIN The costs are measured in arbitrary units determined by the planner's cost parameters (see Section 18.6.2). Traditional practice is to measure the costs in units of disk page fetches; that is, seq_page_cost is conventionally set to 1.0 and the other cost parameters are set relative to that. tadminВероятно эти попугаи сложно связаны связаны с реальным временем через доступные IOPS для подъема страниц, циклы CPU и т.д.наоборот. вы сами можете провести тестирование производительности своего железа на операциях аналогичных seq_page, random_page, cpu_tuple, cpu_index_tuple, cpu_operator, и установить в конфиге значения random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost в соответствии с результатами ваших экспериментов, например приняв за единицу seq_page_cost=1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2008, 14:28 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat tadminВероятно эти попугаи сложно связаны связаны с реальным временем через доступные IOPS для подъема страниц, циклы CPU и т.д.наоборот. вы сами можете провести тестирование производительности своего железа на операциях аналогичных seq_page, random_page, cpu_tuple, cpu_index_tuple, cpu_operator, и установить в конфиге значения random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost в соответствии с результатами ваших экспериментов, например приняв за единицу seq_page_cost=1. А как это сделать на практике? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2008, 14:39 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
Andrey Daeron LeXa NalBatвы сами можете провести тестирование производительности своего железа на операциях аналогичных seq_page, random_page, cpu_tuple, cpu_index_tuple, cpu_operator, и установить в конфиге значения random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost в соответствии с результатами ваших экспериментовА как это сделать на практике?имхо, если бы кто-нибудь это знал, то в постгрес добавили бы утилитку для бенчмарка железа, автоматически подстраивающую эти параметры в конфиге. я примерно год назад читал, что разработчики хотели сделать такую утилиту, но видимо пока не сделали. наверное эти настройки надо выбирать не только основываясь на технических характеристиках компа, но и на задачах, которые будут решаться. например мы пытались тюнить эти параметры учитывая, что в нашей задаче часто используемые данные влезают в кэш оперативной памяти, запросы только на выборку, то есть жесткий диск почти не дергается. изменяя эти параметры, мы пытались добиться того, чтобы для типичных в нашей задаче запросов постгрес правильно оценивал cost, то есть чтобы cost было пропорционально real time. в итоге выбрали значение random_page_cost=2, остальные оставили по дефолту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 10:48 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat Andrey Daeron LeXa NalBatвы сами можете провести тестирование производительности своего железа на операциях аналогичных seq_page, random_page, cpu_tuple, cpu_index_tuple, cpu_operator, и установить в конфиге значения random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost в соответствии с результатами ваших экспериментовА как это сделать на практике?имхо, если бы кто-нибудь это знал, то в постгрес добавили бы утилитку для бенчмарка железа, автоматически подстраивающую эти параметры в конфиге. я примерно год назад читал, что разработчики хотели сделать такую утилиту, но видимо пока не сделали. Т.е. на практике обычным сметрным провести тестирование производительности своего железа - нереально, можно только методом псевдонаучного тыка, по критерию приближения стоимости cost к реал-тайм (с каким-то коэффициентом-множителем) на большинстве запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 12:14 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
Andrey DaeronТ.е. на практике обычным сметрным провести тестирование производительности своего железа - нереально, можно только методом псевдонаучного тыканаверное да, нам, "обычным сметрным", остается или методом тыка, или превращаться в "бессмертных" :-) и курить сорцы, придумывать тесты для железа и софта, и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 16:21 |
|
||
|
почему seqscan?
|
|||
|---|---|---|---|
|
#18+
Мне кажется (теоретизирую), что на уровнях: - CPU cache - file block - RAID block должен быть заметный эффект от настройки этих параметров. Мешает делу то, что на всех этих уровнях есть либо прямые помехи для таких измерений (CPU cache - многозадачность), либо сглаживающие факторы (RAID cache, OS FS cache). В результате, если крутить эти параметры без реального представления об их смысле, то железо будет в широких пределах исправлять дурость экспериментатора. Подкрутили вниз, скажем, параметр цены подъема страницы с диска, а скорость не упала, оценка планировщика тоже в порядке. Не факт, что вы не на что не повлияли. Если RAID хранилище имеет большой кеш и read-ahead настройку, то железо уже зафетчило данные и оттранслировать их в OS кеш копейки стоит. Т.е. на мощном железе приходится крутить настройки слишком далеко, прежде чем увидишь результат. А при таких перекосах уже непонятно, во что ты уперся. Темный лес. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 17:53 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=35124675&tid=2004621]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
68ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 218ms |
| total: | 404ms |

| 0 / 0 |
