|
|
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
И еще тут вопросик. На тему: что быстрее выполнится, новый hash join в Firebird 3.x или старина-merge в 2.5. Вот есть таблица в 3 млн строк, два int-поля, одно из них проиндексировано. DDL: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Задача: 1) сгруппировать по f1 записи и вычислить по каждому f1 агрегат count(*)' 2) вытащить далее только такие f1, по которым count(*) будет либо наибольшим из всех остальных (т.е. "золотой призёр" по частоте встречаемости), либо следующим за наибольшим ("серебрянный призёр"). Например, вот для такого варианта: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Код: plaintext 1. 2. 3. 4. Установил на обоих ФБ (2.5.3 и 3.0.0) максимально возможный в 32-битном варианте кеш страниц - 128К. Вводил по 5 раз запрос: Код: plaintext 1. 2. 3. 4. 5. 6. Планы выполнения и статистика оказались следующими. 1. ФБ 3.0.0 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 2. ФБ 2.5.3 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Затем повторил на кеше = 65535 - результаты практически не поменялись: Код: plaintext 1. 2. Итого: hash join проигрывает 20% (если в нём, конечно, дело). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 21:01:56 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
PS. Да, и еще. Когда ФБ выполняет сортировки, то в task manager'e чётко виден рост потребляемой памяти. По окончании сортировки ФБ *не* отдает эту память системе уже до переконнекта (возможно, это только в SS так). Например, вот такой запрос (таблицу см в DDL предыдущего поста): Код: sql 1. 2. 3. 4. - приводит к изъятию сразу ~150 мегов памяти, хотя сортировать ему тут надо всего 1 тыс строк int-значений. И после выдачи результата + коммита память эта так и остается "зарезервированной". Системе она вернется только после переконнекта. Заметив это, я делал замеры с непременным дисконнектом isql после окончания последнего запуска. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 21:10:27 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Самое интересное, что заставить объединять два потока методом MERGE невозможно, даже если это явно указать в плане. То ли это временно сделано для отладки HASH JOIN, то ли его полностью решили заменить. Вроде бы с статье по методам доступа было сказано, что HASH JOIN не всегда быстрее MERGE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 21:32:35 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Есть и еще одна печалька: если заменить 3 ляма на 10: DDL Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Код: plaintext 1. 2. 3. 4. 5. 6. 7. Наблюдение в ProcessExplorer'e за ФБ_3 (с момента старта запроса) показывает, что сначала он интенсивно читает диск, но затем диск ему становится нужным всё меньше и меньше, пока потребность эта не станет близкой к нулю. Тут по законам жанра должно расти использование CPU ("ведь кто-то же должен работать!") - ан нет! ЦПУ так и застрял в нуле! Я срубил этот запрос по прошествии не менее 15 минут ожидания (трейс при этом не запускал). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 21:46:40 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Вот пример Код: sql 1. 2. 3. 4. 5. 6. В тройке даёт план Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. В 2.5 PLAN MERGE (SORT (TMP NATURAL), SORT (T TMP NATURAL)) Теперь пробуем подставить план от 2.5 в тройку Код: sql 1. 2. 3. 4. 5. 6. 7. Снова получаем Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 21:47:05 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисТо ли это временно сделано для отладки HASH JOIN именно так ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 21:57:45 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидЕсть и еще одна печалька: если заменить 3 ляма на 10 это ожидаемый результат на текущий момент. Сейчас есть смысл тестировать hash join на относительно небольших таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 21:59:28 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидпамять эта так и остается "зарезервированной" в виртуалку же смотришь, а надо в используемую физическую память ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 22:02:07 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидЕсть и еще одна печалька: если заменить 3 ляма на 10 это ожидаемый результат на текущий момент. Сейчас есть смысл тестировать hash join на относительно небольших таблицах.Кхм... у мну и на 2.5.3 этот запрос потух, тихо само собою. Запустил его 2.5 часа взад, получил PLAN MERGE (SORT (SORT (X X ORDER TMP_F1)), SORT (A A ORDER TMP_F1)) - и всё, больше ничего. В PE вижу кардиограмму мертвеца - см аттач. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 00:26:38 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Что-то ночер перестаёт быть томным... :-/ Провалилась скорость вложенных циклов. На мизерных таблицах в 1'000 и 10'000 строк. Пока проверил БЕЗ индексов: DDL. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. FB 3.0: ~14.2 sec Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. FB 2.5.3: ~10.2 sec Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 00:57:37 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидКхм... у мну и на 2.5.3 этот запрос потух, тихо само собою. Запустил его 2.5 часа взад, получил PLAN MERGE (SORT (SORT (X X ORDER TMP_F1)), SORT (A A ORDER TMP_F1)) - и всё, больше ничего. ты индекс специально создал, чтобы похерить скорость этого запроса? Ибо никакой пользы от него я не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 07:15:45 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrты индекс специально создал, чтобы похерить скорость этого запроса? Ибо никакой пользы от него я не вижу.Ну, подумалось что-то, что с ним будет лучше... :-[ Оказалось "как всегда" - надо было меньше думать. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 2.5 выдал в трейсе: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 3.0 на таком же скрипте выдал: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Ладно, время выполнения пока не смотрим - ДЕ сказал, что HJ пока несильно рулит на больших таблицах (кстати: это сколько страниц/строк в них должно быть, чтобы они стали считаться "большими" ?) Но вот я вижу в ProcessExplorer'e, что диск интенсивно юзался на запись. Почему это не отражается в writes, пусть даже это были "вспомогательные структуры" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 10:45:14 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидНо вот я вижу в ProcessExplorer'e, что диск интенсивно юзался на запись. Почему это не отражается в writes, пусть даже это были "вспомогательные структуры" ? reads/writes/fetches/marks - это счетчики страничного кеша, который используется для работы с файлом БД. Активность временных файлов к кешу не относится и ими не фиксируется. Для этого будут вводиться отдельные счетчики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 12:35:47 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидкстати: это сколько страниц/строк в них должно быть, чтобы они стали считаться "большими" более 100К строк примерно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 12:36:57 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидНо вот я вижу в ProcessExplorer'e, что диск интенсивно юзался на запись. Почему это не отражается в writes, пусть даже это были "вспомогательные структуры" ? reads/writes/fetches/marks - это счетчики страничного кеша, который используется для работы с файлом БД. Активность временных файлов к кешу не относится и ими не фиксируется. Для этого будут вводиться отдельные счетчики.Теперь понятно, спасибо. Это будет тоже в 3.х введено ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 13:43:16 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, надеюсь да ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 13:48:47 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидты индекс специально создал, чтобы похерить скорость этого запроса? Ибо никакой пользы от него я не вижуПользы от него нет, но получается, что ФБ при его наличии.... фактически перестаёт работать с единственным запросом, который ему передан. Это видно и в ProcessExplorere'e (нулевые как ЦПУ, так и очередь к диску), и в mon$-таблицах. В аттаче - лог результатов запросов к mon$io_stats и mon$record_stats, с интервалом ~ в одну минуту. Видно же невоор. глазом, что ФБ почти ничего не делает! ПОЧЕМУ ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 16:28:33 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидПОЧЕМУ ?Потому что RANDOM IO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 17:43:29 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladПотому что RANDOM IOНу, и ? вот идёт ФБ себе по индексу, видит ключ_1. Дальше он вытаскивает соотв-щий rdb$db_key и прыгает в DP. Дальше делает "прыг" по индексу на ключ_2, и опять лезет в DP. Я должен видеть эту его активность в mon$-таблицах. И там какая-то активность действительно есть. Призрачная только - см аттаченный файл, в который статистика собиралась 1 раз в минуту несколько раз. Такой "немощи" никогда не бывает, например, при обычном select * from t order by <indexed_field>. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 17:57:24 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, я уже 15 минут пытаюсь найти посты, относящиеся только к этому вопросу - это невозможно. ЗАДАВАЙ ОДИН ВОПРОС В ОДНОЙ ТЕМЕ или я буду этот бардак игнорировать не читая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 19:12:31 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladя уже 15 минут пытаюсь найти посты, относящиеся только к этому вопросу - это невозможно. ЗАДАВАЙ ОДИН ВОПРОС В ОДНОЙ ТЕМЕ или я буду этот бардак игнорировать не читая.А как ты искал, по " Всем темам автора " ? Так это не правильно, там уже давно трудно искать Я обычно пытаюсь "возвращаться в топег", если сам могу его найти и если это не приведёт к его "перепрыгиванию" на совсем другой вопрос. А про random_io - это мы в личке обсуждали, см прения от 00:11:35 17/09/2011 (key phrase: random io творит "чудеса"). Но то касалось валидации базы gfix'ом, я даже CORE-3602 завел в трекере тогда. Но валидация - это совсем другая тема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 19:30:00 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидА как ты искалЯ искал глазами, в одной этой теме. Я не буду выворачиваться наизнанку, для того, чтобы фильтровать 10 потоков сознания в одной теме в поисках одного из них. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 19:38:32 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидА как ты искалЯ искал глазами, в одной этой теме. Я не буду выворачиваться наизнанку, для того, чтобы фильтровать 10 потоков сознания в одной теме в поисках одного из них.Ну так я специально запихивал разные вопросы в одну тему, т.к. речь в них идет всё равно об одном, а именно: о сравнении производительности 2.5 и 3.0. пару лет взад я также по трейсу натолкал много разных вопросов, но все они касались общего - трейса. Ладно, если это не удобно для поиска, буду ваять по-старому: 1 вопрос = 1 топег. Лишь бы в помойку, как тут , не превратилось :-) Но всё-таки прошу вопрос про отсутствие жизнедеятельности ФБ при выполнении конкретного запроса, указанного выше в этом топеге, добить здесь же . Запрос этот молотит уже 4 часа. Я логирую отдельным "мониторным окном" 1 раз в 1 минуту значения в двух таблицах: mon$io_stats & mon$record_stats. Лог накапливается в виде текста, и два результата из него: на 16:07 и на 19:07, я вытряхнул в эксель, расположил их "попарно вместе" (io к io, rec к rec) и вычел из значений на 19:07 значения на 16:07 - см. аттач. Так вот, вопросик у мну. Как такое может быть, что за ТРИ ЧАСА: 1) прочиталось всего ~113000 страниц (см лист "MON$IO_STATS_1607_vs_1907", группа ячеек выделена желтым цветом) ? 2) было совершено 48'700 seq_reads и "аж" 4'4 млн idx_reads ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 20:09:53 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидПОЧЕМУ ?Потому что RANDOM IO Таблоиду нужно подарить SSD, вторым диском, для тестов (или дать погонять). Я не сомневаюсь что у него получится раскрыть настоящую правду про Firebird+SSD :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 21:02:17 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
NickDeeу него получится раскрыть настоящую правду про Firebird+SSD :)дык это... что мешает почтеннейшим посетителям нашего кабачка, а также его завсегдатаям, повторить эти несложные тесты "у себя дома" ? Авось, и новое чего нароете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 21:26:18 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38358800&tid=1564261]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
193ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
| others: | 188ms |
| total: | 488ms |

| 0 / 0 |
