|
|
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hi all В этом топеге буду складывать вопросы, появляющиеся по результатам сравнения - если увижу, что 3.0 в чем-то уступает 2.5. Запускаю на одной и той же машине старые тесты, сначала на WI-V2.5.3.26682 (SuperClassic), а затем на WI-T3.0.0.30567 (SuperServer). Данные по машине: Win-2003 Server SP2, CPU 2.4 GHz (2 core), RAM 1 Gb (увы, но только это). Пока что нарыл некоторое ухудшение скорости вставок в GTT. Исходный вопрос обсуждался тут: http://www.sql.ru/forum/860810-2/gtt-on-commit-delete-rows-nenulevye-writes-fetches-pri-commit-e-why Дано: 1) две пустые базы, для 2.5 и 3.0, на обеих pagesize=4K, FW = OFF и кеш = 65535 2) DDL: Код: sql 1. 2. 3. 3) выполняю на каждой базе по очереди следующие три серии запросов: Код: sql 1. 2. 3. 4. 5. (NB: для GTT, которая on commit PRESERVE rows, сразу после её заполнения и коммита делаю quit, дабы 2-й и последующий замеры снова начинались с нулевого состояния этой таблицы). Результаты: 1) время вставок в GTT'шки увеличилось в 3.0 по сравнению с 2.5, от 15% (для preserve rows) до 40% (для commit rows). 2) время вставок в fixed-таблицу увеличилось в 3.0 примерно на 10-15% Вот статистика по reads/writes/fetches (БЕЗ времени выполнения): Server versionВид таблицыСтатистикаЗатраты на insert 1'000'000 строкЗатраты на commit2.5.3.26682GTT on commit DELETE rowsReads11Writes2620445Fetches5237537204562.5.3.26682GTT on commit DELETE rowsReads381Writes2620444Fetches523783512.5.3.26682GTT on commit DELETE rowsReads11Writes4220446Fetches52375911xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3.0.0.30567GTT on commit DELETE rowsReads420Writes2820435Fetches5242686204583.0.0.30567GTT on commit DELETE rowsReads10Writes2220435Fetches524252313.0.0.30567GTT on commit DELETE rowsReads1840Writes8820439Fetches52914041 А вот статистика по времени выполнения: 1. для GTT on commit DELETE rows: среднее увеличение времени вставок ~40% Server versionОперацияизм_1изм_2изм_3изм_4изм_5изм_6изм_7изм_8изм_9изм_102.5.3.26682insert 1'000'000 rows3.193.193.183.193.213.193.213.193.193.213.0.0.30567""4.564.564.574.564.564.554.564.574.564.562.5.3.26682commit0.281.881.800.280.271.710.280.282.670.263.0.0.30567""1.750.290.300.300.320.301.860.310.300.29 2. для GTT on commit PRESERVE rows: среднее увеличение времени вставок ~15% Server versionОперацияизм_1изм_2изм_3изм_4изм_5изм_6изм_7изм_8изм_9изм_102.5.3.26682insert 1'000'000 rows5.025.115.135.275.215.275.705.065.315.173.0.0.30567""6.306.426.376.176.326.426.286.236.366.432.5.3.26682commit0.250.270.270.270.250.270.250.260.250.173.0.0.30567""0.260.280.270.280.280.280.280.260.280.26 3. для FIXED-таблицы: среднее увеличение времени вставок ~10-12% Server versionОперацияизм_1изм_2изм_3изм_4изм_5изм_6изм_7изм_8изм_9изм_102.5.3.26682insert 1'000'000 rows4.534.503.093.374.824.203.354.743.803.033.0.0.30567""5.474.494.434.474.414.414.394.544.414.412.5.3.26682commit2.231.971.661.771.751.981.832.011.762.033.0.0.30567""1.911.902.041.922.232.021.941.912.111.97 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 20:47:58 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
А сравни-ка всё то же самое, но с pagesize=16K, FW = ON Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 20:50:29 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамА сравни-ка всё то же самое, но с pagesize=16K, FW = ONпоясни, плз, что это даст ? FW = ON никак не должен повлиять на результаты GTT'шек. А увеличение pagesize должно обязательно привести к увеличению времени вставок/коммитов, но разве должны нарушиться их соотношения ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 20:54:21 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, Ты лучше свой тест с конкурентными вставками или апдейтами проверь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 20:58:31 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидПока что нарыл некоторое ухудшение скорости вставок в GTTВот как в двух операциях (select + insert) ты однозначно увидел замедление именно вставок ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:09:04 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидА увеличение pagesize должно обязательно привести к увеличению времени вставок/коммитовС чего бы это ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:09:29 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидЗапускаю на одной и той же машине старые тесты, сначала на WI-V2.5.3.26682 (SuperClassic), а затем на WI-T3.0.0.30567 (SuperServer).Ты сравниваешь апельсины с огурцами. Сделай им хотя бы кеши одинаковые. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:12:03 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисТы лучше свой тест с конкурентными вставками или апдейтами проверь.Это тоже будет, попозжее только. Сейчас надо простые штуки сравнить. Кстати: и в 2.5 и в 3.0 при commit'e в gtt on commit DELETE rows движок развивает бурную деятельность, смысл которой мне непонятен: Код: plaintext 1. 2. 3. 4. 5. 6. Тогда как в остальных двух случаях (gtt on commit PRESERVE и fixed-table) всё вполне пристойно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. (вроде бы я спрашивал уже про это, но найти не могу в ворохе своих же изысков ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:13:40 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидА увеличение pagesize должно обязательно привести к увеличению времени вставок/коммитовС чего бы это ?дык напарывался уже, в 2.1 еще... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:15:36 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидЗапускаю на одной и той же машине старые тесты, сначала на WI-V2.5.3.26682 (SuperClassic), а затем на WI-T3.0.0.30567 (SuperServer).Ты сравниваешь апельсины с огурцами. Сделай им хотя бы кеши одинаковые.Я с SS не работал, по 65000 выставил. Какой поставить-то в 3.0 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:16:22 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид3) выполняю на каждой базе по очереди следующие три серии запросов: Код: sql 1. 2. 3. Твои старые любимые грабли - первый запрос тратит время на расширение файла, второй запрос пользуется уже расширенным файлом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:16:32 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидПока что нарыл некоторое ухудшение скорости вставок в GTTВот как в двух операциях (select + insert) ты однозначно увидел замедление именно вставок ?гм... но селект-то идёт из одной и той же "бочки"! а вставки - по разным "флаконам" :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:17:50 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидКстати: и в 2.5 и в 3.0 при commit'e в gtt on commit DELETE rows движок развивает бурную деятельность, смысл которой мне непонятен: Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:18:32 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТвои старые любимые грабли - первый запрос тратит время на расширение файла, второй запрос пользуется уже расширенным файлом.йок. ибо: Код: sql 1. 2. 3. 4. ну, и в первом посте: автор(NB: для GTT, которая on commit PRESERVE rows, сразу после её заполнения и коммита делаю quit, дабы 2-й и последующий замеры снова начинались с нулевого состояния этой таб ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:20:05 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидйокТа ты шо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:21:48 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladПри освобождении страниц данных GTT помечает место в PIP, как свободноеДля чего это делать ? всё равно страницы GTT'шки с on commit delete rows никогда не будут видны даже транзакции "А", стартовавшей в одном коннекте с транзакцией "Б". Как только коммит будет - "ку-ку", вся таблица снова нулевая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:24:16 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидйокТа ты шо :)"Как же это так, кормилец ?!" (С) Если я сделал quit из единственного коннекта, а после - очередной коннект, то что... fb_temp_xxx разве НОВЫЙ не создастся ?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 21:25:53 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидhvladПри освобождении страниц данных GTT помечает место в PIP, как свободноеДля чего это делать ?А что такое PIP ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 22:35:28 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидЕсли я сделал quit из единственного коннекта...Ты сегодня в ударе :) Перечитай ещё раз: hvladпервый запрос тратит время на расширение файла, второй запрос пользуется уже расширенным файломи ещё разhvlad первый запрос тратит время на расширение файла, второй запрос пользуется уже расширенным файломи потом - ещё раз, контрольный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 22:37:36 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladПеречитай ещё раз <...> и потом - ещё раз, контрольныйПеречитал. Дошло, спасибо :-) Сделал заново для GTT'шек (без fixed-таблиц), добавил QUIT после каждого insert + commit. Ну, так вот: всё равно в ФБ-3 время больше. Вот "сырой" отчет, но надеюсь, в нём всё понятно: 1. для 2.5: Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 2. Для 3.0: Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. Но в ФБ 2.5 времени на это уходило меньше, отношение ~5/6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 23:41:24 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидпропущено... Для чего это делать ?А что такое PIP ? http://www.ibphoenix.com/resources/documents/design/doc_19 Page Inventory Page Page Type 2 is a page inventory page (PIP). PIPs map allocated and free pages. The header of a PIP includes the offset on this page of the bit that indicates the first available page on the PIP. The body of a PIP contains an array of single bits that reflect the state of pages in the database. If the bit is one, then the corresponding page is not in use. If the bit is zero, then the page is in use. PIPs occur at regular intervals through the database, starting at page 1. The last page allocated on each PIP is the next PIP. А это... как его... Что в эту самую PIP для GTT'шек пишется ? Раз их содержимое вообще вне базы хранится, то что будет содержать этот самый "array of single bits that reflect the state of pages in the database " для GTT'шек ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 23:51:01 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladкак в двух операциях (select + insert) ты однозначно увидел замедление именно вставок ?Проверил уже только вставки, никаких селектов - т.е. через execute block: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. - и аналогичный скрипт для таблицы gttsav. Результат: замедляются именно ВСТАВКИ. Затраты на выборку из rdb$fields были микронные. Замеры делал по 10 раз для каждого скрипта на каждой версии ФБ. Отчет: Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. Соотношение между временем вставок, КМК, осталось таким же: 5/6 в пользу ФБ 2.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 10:09:51 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, Стабильность курсора требует определённых затрат + nbackup (который теперь работает быстрее). Может быть ещё найдут способ ускорить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 10:24:10 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидЧто в эту самую PIP для GTT'шек пишется ? Раз их содержимое вообще вне базы хранится, то что будет содержать этот самый "array of single bits that reflect the state of pages in the database " для GTT'шек ?Ты не поверишь, но временный файл с данными GTT имеет такую же структуру, как и обычная БД. И я писал об этом, насколько я помню. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 10:44:37 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисСтабильность курсора требует определённых затрат + nbackup (который теперь работает быстрее).Хорошая попытка, но мимо, по крайней мере в данном тесте :) Новый общий кеш в однопоточных тестах работает несколько медленнее, чем раньше. Ибо синхронизация, которой раньше не было, требует жертв. Симонов ДенисМожет быть ещё найдут способ ускорить.Правильно, и этим тоже занимаемся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 10:47:08 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
я бы сказал, что в этой теме не стоит (пока что) кричать караул и вопрошать "а почему?", надо просто выкладывать тесты и цифры результатов. А потом сравнить с бетой или RC. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 11:36:04 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Наконец-то официальная альфа тройки вышла. Теперь можно релиз-ноты почитать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 12:25:15 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrя бы сказал, что в этой теме не стоит (пока что) кричать караул и вопрошать "а почему?", надо просто выкладывать тесты и цифры результатов. А потом сравнить с бетой или RC."караул" про GTT'шки я кричал больше двух лет взад, вот тут: 1. Лишние(?) телодвижения при заполнении GTT on commit DELETE rows и последующем ROLLBACK`e (started 28-feb-11) 2. GTT on commit DELETE rows: ненулевые writes & fetches при COMMIT'e. Why ? (started 22-jun-2011) Влад там сказал, что для GTT таки можно выполнить оптимизацию (см ниже под спойлером). Но в то время все силы отцов-основателей были брошены на ФБ-3 и лезть с этой хотелкой было бесполезно. Сейчас ФБ-3 уже высунул нос для тестирования, и он еще не забетонирован, насколько я понимаю. Можно ли сделать ту самую оптимизацию GTT, "о которой так долго говорили большевики" ? http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=860810&msg=10871916 hvlad, 24 июн 11, 18:15ТаблоидВОПРОС-2. Зачем при коммите для GTT-таблицы, созданной как on commit delete rows, выполнять какую-то запись ? В принципе, тут есть что оптимизировать для GTT с DELETE ROWS, согласен. http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=860810&msg=10873177 hvlad, 24 июн 11, 22:44ТаблоидЗачем вообще нужен сброс кеша для времянки любого рода а) Для DELETE освобождённые страницы можно вообще не писать на диск, сняв пометку о том, что они грязные б) Для всех GTT - прям по коммиту можно и не сбрасывать (кстати flush для GTT не делается, т.е. операция не тяжёлая), но грязные страницы всё равно когда-нить пойдут на диск - хотя бы при вытеснении их из кеша. http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=831889&msg=11592233 hvlad, 14 ноя 11, 12:41И - да - для GTT ON COMMIT DELETE ROWS можно не откатывать изменения по роллбеку. И это тоже здесь уже упоминалось. Там ещё кое-что можно не делать. Дойдут руки - сделаем (сделаю). Но что-то никто не жалуется (кроме тебя :)) на эти моменты - значит не так уж оно и критично :) http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=831889&msg=11593934 hvlad, 14 ноя 11, 15:35ТаблоидЗа каким лешим ФБ откатывает изменения в GTT после окончания сеанса, когда и так ясно, что данных никаких не будет и файл грохнется операционкой ? За таким, что всё делается одинаково и для GTT, и для обычных таблиц. Сколько раз я это должен повторять ? Далее. Роллбеку пофигу откуда он вызван - из детача, или по просьбе юзера. Далее. Сколько раз ещё я должен повторить, что роллбек для GTT\DELETE можно оптимизировать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 14:44:38 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Причём тут GTT. Вставка, обновление и удаление на тройке медленнее чем на 2.5 и для обычных таблицы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 15:20:11 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисПричём тут GTT. Вставка, обновление и удаление на тройке медленнее чем на 2.5 и для обычных таблицы1) то, что работу с GTT оптимизировать можно и, наверное , это будет сделано - об этом говорил Влад (см предыдущий мой пост). Про ускорение dml c fixed-таблицами он не говорил - ни прямо, ни намёками. По кр. мере, за последние 3 года я не видел этого :-) 2) я вчера тестил только вставки в fixed-таблицу, в моноконнекте. Сильного проседания не заметил. Давай свой тест "на погляд", плз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 15:34:08 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
чуть позже обязательно предоставлю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 16:24:46 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Кажется , есть хорошая новость. А может, и нет её вовсе, если это снова апельсины vs огурцы :-) Создал в WI-V2.5.3.26682 и WI-T3.0.0.30567 таблицу с 10 млн строк и тремя индексами, каждый - по одному полю: DDL Код: sql 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. Селективность индексов: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Коннект к обоим серверам делаю via ISQL Version: WI-V2.5.3.26661. Вижу устойчивое преимущество ФБ-3 по времени выполнения вот такого вида запросов, примерно на 30-40%. Например, ввожу: Код: plaintext 1. 2. 3. 4. 5. Вот типичный пример того, что получаю в 2.5: Код: plaintext 1. 2. 3. 4. 5. 6. 7. И вот что для такого же значения :p1 будет в 3.0: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Размер данных серверного процесса в байтах. На самом деле зависит от многих факторов, далеко не только от последнего запроса. Delta memory Насколько изменился предыдущий параметр между началом и концом обрабокти запроса. Не удивляйтесь, если увидите отрицательное число -- так тоже бывает. Просто сервер вдруг решил, что часть памяти ему сейчас не нужна и решил её освободить. Max memory Максимальный размер памяти, до которого доходило дело на каком-либо этапе обработки запроса. И как такое может быть, что ФБ 2.5, затащив в память аж 270 Мб данных, лопатил в полтора раза дольше, чем ФБ 3.0, которому понадобилось всего лишь Max memory = 1985560 = 1.9 Мб ?! Кажется, конфигурации 2.5 & 3.0 нуждаются в дальнейшем допиливании, дабы они действительно находились в равных условиях. Но что именно менять, дабы привести их в "равенство" ? Изменённые параметры firebird.conf в 3.0: Код: plaintext 1. 2. Изменённые параметры firebird.conf в 2.5: Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2013, 21:33:53 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Смотрю на старую тему : "Может ли FB не соединять при "очевидно ложном" условии соединения (on 1=0 etc)". Есть там фраза:dimitr 3.0 будет сам такие вещи понимать. - вопиющая о необходимости своей проверки :-) DDL: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Далее ввожу два варианта запроса, в котором источник, присоединяемый по left join, задушен константным условием "очевидная ложь": Код: 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. А теперь убираем комментарий с inner join'a таблиц thead & rdb$database: Код: plaintext 1. 2. 3. 4. Trace: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. output Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Вопрос-1. dimitrТаблоидсможет действительно распознавать "100% невыполнимые" условия ПРЕЖДЕ, чем начать делать выборку ? да, если они константны для запроса Почему ФБ-3 включил в план TDATA, если в запросе явно присутствует константное условие "ложь" ? Вопрос-2. Почему так повлияло inner-соединение thead с rdb$database ? PS. Делал на WI-T 3.0.0.30567 . На WI-V2.5.3.26682 ситуация с обоими вариантами точно такая же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2013, 10:37:25 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидвопиющая о необходимости своей проверки оптимизатор проверять еще рано, он в альфе практически не менялся. Всему свое время. ТаблоидНа WI-V2.5.3.26682 ситуация с обоими вариантами точно такая же ну и что тогда этот тест делает в этой ветке? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2013, 10:56:22 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидвопиющая о необходимости своей проверкиоптимизатор проверять еще рано, он в альфе практически не менялся. Всему свое время.А когда примерно проверять можно будет ? dimitrТаблоидНа WI-V2.5.3.26682 ситуация с обоими вариантами точно такая жену и что тогда этот тест делает в этой ветке?ну я же не знал, что оптимизатор проверять еще рано. Вот и сравнил с 2.5 Кста! Скажи мну, плз, вот по этому посту : я что-то неправильно назначил в конфиге ФБ-3, раз он так мало памяти жрёт по сравнению с 2.5 ? (и запросы быстрее на 30% фигачит) ? Как изменить конфиги, чтобы их (2.5 и 3.0, сидят на одной тачанке) поставить в равные условия ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2013, 11:16:05 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидА когда примерно проверять можно будет ? Beta 1 ТаблоидСкажи мну, плз, вот по этому посту : я что-то неправильно назначил в конфиге ФБ-3, раз он так мало памяти жрёт по сравнению с 2.5 ? (и запросы быстрее на 30% фигачит) ? про память - мне отсюда не видно. Есть же MON$MEMORY_USAGE, посмотри в счетчики (а) базы, (б) твоего аттача, (в) твоей транзакции сразу после выполнения запроса. Может станет понятнее. Но вообще-то в 3.0 менялся менеджер памяти, так что сравнивать их напрямую бессмысленно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2013, 11:44:05 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, По поводу потребления памяти тройкой. Рано радуешься. Взгляни в диспетчер задач. Там он рисует значение в сотни раз больше чем показывает в статистике. Вероятно из этой статистики исключена память занятая кэшем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2013, 23:56:25 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrпро память - мне отсюда не видно. Есть же MON$MEMORY_USAGE, посмотри в счетчики (а) базы, (б) твоего аттача, (в) твоей транзакции сразу после выполнения запроса.Посмотрел, понятного мало :( На обоих инстансах ФБ запустил "мониторные" isql, а с другой машины выполнял выполнял "основной запрос" вида: Код: sql 1. 2. 3. 4. 5. 6. Перед и сразу после выполнения этого запроса в "мониторных" isql вводил: Код: plaintext 1. 2. 3. 4. 1. Результат для 2.5: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 2. Результат для 3.0 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. MON$MAX_MEMORY_ALLOCATED (maximum number of bytes allocated from the operating system by this object ) Но лучше dimitr'a никто не объяснит, на что именно следует обратить внимание в этих двух фотоснимках mon$memory_usage. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 02:33:50 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
первое, что я вижу - что ты тестируешь 2.5 в архитектуре SC или CS. Вопрос - нафига, если тебе нужны равные условия? Во-вторых, статистика в 3.0 неисправна - в нее не попадает кеш и значения под 4GB явно левые, не соответствующие истине. Как поправим - отпишусь, надо будет повторить тест. ЗЫ. твой второй "мониторный" коннект только мешает смотреть, делай селект из MON$ в том же коннекте что и тест. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 09:12:11 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrпервое, что я вижу - что ты тестируешь 2.5 в архитектуре SC или CS. Вопрос - нафига, если тебе нужны равные условия?Потому что привык на автопилоте тыркать в install_superclassic.bat :-[ Но! Размазывать задачи по нескольким ядрам SS научился только в 3.0 RN 3.0, page 9 True SMP support for SuperServer In Superserver mode, the engine now makes use of multiple CPUs and cores when spawning connections. Tracker: CORE-775 Implemented by V. KhorsunСоотв-но, как только будет сравнение работы нескольких коннектов, надо будет вернуть 2.5 в режим SuperClassic'a. Я прав ? dimitrВо-вторых, статистика в 3.0 неисправна - в нее не попадает кеш и значения под 4GB явно левые, не соответствующие истине. Как поправим - отпишусь, надо будет повторить тест.OK, будем подождать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 10:05:18 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидкак только будет сравнение работы нескольких коннектов, надо будет вернуть 2.5 в режим SuperClassic'a. Я прав ? проверять надо будет на всех архитектурах, чтобы иметь отправную точку в виде "немасштабируемого" старого SS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 10:41:01 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Переставил арх-ру в 2.5, кеш оставил прежним, 65535 страниц. Повторил запрос, mon$-таблицу запрашивал из этого же isql-окна. Результат для 2.5 SuperServer: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 10:47:50 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, пытаюсь воспроизвести большие числа в allocated-счетчиках и не могу, у меня там все нормально. Для свежесозданной базы без данных у тебя такое же безобразие выдается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 11:04:49 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидПовторил запрос, mon$-таблицу запрашивал из этого же isql-окна признавайся, коммитился перед вторым MON$-запросом? Надо так: mon$-commit-test-mon$. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 11:06:53 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидПовторил запрос, mon$-таблицу запрашивал из этого же isql-окна признавайся, коммитился перед вторым MON$-запросом? Надо так: mon$-commit-test-mon$.я рестартовал ФБ_2.5 и выполнил вот это: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. В итоге: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 11:32:18 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrпытаюсь воспроизвести большие числа в allocated-счетчиках и не могу, у меня там все нормально. Для свежесозданной базы без данных у тебя такое же безобразие выдается?Сейчас попробую на отресторенной. Только не знаю, сколько этот b/r будет длиться, ибо .fdb весит под гиг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 11:33:22 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидя рестартовал ФБ_2.5 и выполнил вот это чем бы в тебя запустить отсюда? Я тебе говорю НЕ КОММИТИТЬ после выполнения тестового запроса, а ты опять за свое... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 11:39:47 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид.fdb весит под гиг какое слово во фразе "база БЕЗ ДАННЫХ " тебе непонятно? (с) DS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 11:40:53 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидя рестартовал ФБ_2.5 и выполнил вот это чем бы в тебя запустить отсюда? Я тебе говорю НЕ КОММИТИТЬ после выполнения тестового запроса, а ты опять за свое...ой... :-[ пардон муа... dimitrНадо так: mon$-commit-test-mon$. А впрочем, вот - ничего особо не поменялось (в 2.5): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 11:47:43 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоид.fdb весит под гигкакое слово во фразе "база БЕЗ ДАННЫХ " тебе непонятно? (с) DSпфф... не проснулся я еще: вчерась почти 600 км отмотал по дорогам "нечерноземья" :-/ сейчас проверю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 11:49:26 |
|
||
|
Сравнение производительности 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 11:54:38 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
PS. Еще раз напомню, что вижу это на: Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 11:55:47 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидPS. Еще раз напомню, что вижу это на иди спать лучше, а потом тестируй. У тебя 4 гига на 3.0 вылазило, а ты мне 2.5 пихаешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 12:01:52 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Не, я уже проснулся, теперь "маховик не остановить" :-) Вот для пустышки в WI-T3.0.0.30567: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 12:08:12 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
У меня тоже для тройки в таблице mon$memory_usage Код: plaintext 1. 2. 3. 4. 5. Правда там база не пустая. Но кроме собственно запроса select * from mon$memory_usage я ничего не выполнял. БД была наполнена так Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 12:20:53 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
На самом деле я немного ошибся. Если только подключиться и сделать запрос к таблице мониторинга то всё норм. а вот если сделать второй коннект, то статистика омается. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Теперь подключимся вторым isql Код: plaintext 1. 2. 3. Снова переходим в первый и вот Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 12:38:17 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
теперь вижу, спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 13:05:55 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
исправлено ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 13:40:55 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид Кажется , есть хорошая новость. А может, и нет её вовсе, если это снова апельсины vs огурцы :-)Нет, уже почти не кажется. Почти точно - она есть, эта хорошая новость :-) Ибо сейчас два ФБ в одной арх-ре (SS), на одной windows-машине, с одинаковым кешем баз - и вижу, что ФБ-3 явно выигрывает у 2.5 в выборках из вот этого теста трёхлетней давности: " INDEX scan vs NATURAL в случае плохой селект-сти: INDEX всегда лучше ?! ". DDL тот же, что в в первом посте этого теста. Подключение делал по ТСР. Запустил isql в 2.5, запустил трейс к нему. Выполнил 5 раз вот этот скрипт: Код: sql 1. 2. // 36681AD7-F44E-4E07-6AB1-96CF144A2082 = значение, записанное в 98% всех 10 млн записей таблицы Повторил затем то же самое для 3.0. Данные трейсов по 5 запускам в ФБ 2.5 vs 3.0:Firebird releaseQuery plan (NB: в таблице 98% строк - с одинаковым значением)timereadsfetches Firebird 2.5PLAN (TMPMEASURE NATURAL)486162129192042575548525212987479644823548376 Firebird 2.5PLAN (TMPMEASURE INDEX (IDX_TMPMSR_NAME))441532253851961239943870453284437143872timereadsfetches Firebird 3.0PLAN (TMPMEASURE NATURAL)197622129292027806218707182101840918248 Firebird 3.0PLAN (TMPMEASURE INDEX (IDX_TMPMSR_NAME))162192253411938705816193163791601116103 Повторил затем всё по-новой, опять делал по 5 запусков на двух ФБ - статистика подтвержилась. 18 сек против 45 - слишком серьёзное расхождение, чтобы его игнорировать. Это что-то новое в алгоритмах доступа к данным "сработало" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 17:01:41 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
навскидку, методы доступа тут не причем. Надо будет отпрофилировать на досуге :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 17:22:01 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrнавскидку, методы доступа тут не причем. Надо будет отпрофилировать на досуге :-)есть ощущение, что часть данных застревала в файловом кеше, а вытеснялась оттудова в 2.5 быстрее, чем в 3.0. Звучит маразматично, но вот что получилось в результате выполнения скрипта: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 18:22:06 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, статистику reads и fetches добавь, плс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 19:05:07 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоид, статистику reads и fetches добавь, плсВот (пустые ячейки означают повтор последнего значения, расположенного в этом столбце выше данной строки):FB versionQuery plantimereadsfetchesWI-V2.5.3.26682PLAN (TMPMEASURE NATURAL)1556121291920425755160112129873927548386484914853248519480994806348284WI-V2.5.3.26682PLAN (TMPMEASURE INDEX (IDX_TMPMSR_NAME))4402922538519612399439674377943977440034370343986439544416943803timeWI-T3.0.0.30567PLAN (TMPMEASURE NATURAL)186982129292027806220102202128391834018730184731879818370186891847218623WI-T3.0.0.30567PLAN (TMPMEASURE INDEX (IDX_TMPMSR_NAME))1573022534119387058162021576116020198684947849730498544983049813 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 20:27:16 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Что-то странность вижу: хрестоматийный подсчет числа счастливых билетов (вариант с обращениями к rdb$database) на 2.5 идёт быстрее, чем на 3.0 :( Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. FB 2.5: 3.8" Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. FB 3.0: ~4.4" Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 22:17:44 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, я же говорил уже, что работа с кешем в 3-ке чуть медленнее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 22:24:12 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladя же говорил уже, что работа с кешем в 3-ке чуть медленнееДа, я помню. Повторил тест, но уже по условию равенства сумм четырех цифр, а не трёх (т.е. джойн 8 таблиц вместо 6). Отличие примерно 16% - многовато, КМК. Вот результат для ФБ 3.0 : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. А вот для 2.5 : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 22:35:46 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladработа с кешем в 3-ке чуть медленнееВлад, а только ли с кешем ? Вот, смотри: я намеренно добавил в запрос lucky.sql "ошибку чайника": заменил 'union all' на "просто union": Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. И теперь получаю разницу в 2 раза, и не пользу ФБ-3 FB 3.0: Код: plaintext 1. 2. 3. 4. 5. 6. 7. FB 2.5: Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 22:48:49 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидИ теперь получаю разницу в 2 разаЗависимость для этого варианта (с union distinct), похоже, константная: старый 2.5 в два раза быстрее, чем новый 3.0 :( Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2013, 23:52:13 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Решил проверить для Oracle 11 XE вот это:ТаблоидПовторил тест, но уже по условию равенства сумм четырех цифр ... - но с отягощением:Таблоиднамеренно добавил в запрос lucky.sql "ошибку чайника": заменил 'union all' на "просто union"В общем, нам есть куда стремиться: этот гад всё утоптал за 2 минуты, выполнив 20 млн согласованных чтений (вместо 55 млн в ФБ, и то для случая union all ) и всего 2 (два) физических чтения :-) Ora 11 xe, на той же машине, в конфигурации его ничего не менял: Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 15:58:21 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Добрался до старого вопроса про кеш и вытеснение из него страниц: " Вытеснение страниц из кеша по принципу LRU" Дано: 0) ФБ-3, SS, и база с кешем = 65535 (размер страницы = 4К); 1) таблица TBIG, 10 млн записей: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 2) Запрос, "ходящий" по двум индексам и выполняющий примерно 3-4 тыс фетчей. Код: plaintext 1. 2. 3. Вот пример для трёх запусков запроса, когда соотв-щих записей *НЕТ* в кеше: reads ~1500...1700 Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. Идём дальше: открываем второе isql-окошко. Запускаем в нём: SQL> select * from tbig where id>=10000000; -- или просто select count(*) from tbig; Получаем план: PLAN (TBIG NATURAL) И результат: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Повторяем любой из вышеприведенных трех запросов и... получаем однозначное свидетельство, что огроменный NATURAL -скан второго окна вытолнул наши драгоценные записи из кеша. НЕ ВСЕ, но большую их часть: число reads равно 1000...1200 (в самом начале, до "закеширования", было 1500...1700) reads ~1000...1200 Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 18:41:04 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидогроменный NATURAL -скан второго окна вытолнул наши драгоценные записи из кешаBTW, на WI-V2.5.3.26682 этого нету! Записи остаются в кеше, время повторных выборок по индексам остается равным нулю. (База - аналогичная, арх-ра - такой же SS, кеш коннекта - такой же, 65535). Any comments ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 18:58:23 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, в 3-ке (пока ещё) сломана защита от большого натурального скана. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 19:08:18 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladв 3-ке (пока ещё) сломана защита от большого натурального скана.в трекер заносить надо или это было сознательно сделано и не забудется ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 19:10:56 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, пока не надо, я это помню ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 19:20:54 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Тут еще один вопрос полыхнул. По мотивам пьесы почти годовалой давности: "Через сколько времени выполняемый DML должен среагировать на delete from mon$attachments ?", только теперь вместо mon$attachments'a в главной роли mon$statements. Эмпирически выяснилось, что ЕСЛИ: 1) запустить в сеансе_1 какой-то "жуткий bulk insert" типа такого: Код: plaintext 1. 2. 3. 2) затем минут так через 10-15 в сеансе_2 ввести: Код: plaintext 1. 2. ТО: 1) сообщение вида: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Хотя в трейсе сообщение о завершении оператора delete from mon$statements появляется практически сразу же за его стартом: Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 2) ввод в сеансе_2 сразу после команды (1) команды (2) ни к чему не приводит - т.е. она просто висит без ответа. Опять таки до тех пор, пока ФБ не выполнит откат инсертов. И вот этого я уже не понимаю: что ему (мониторингу) мешает сразу вернуть Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Вот фрагмент трейса по п. "2)": Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. ИТОГО получил: ожидание результата выборки из mon$statements, причина которого связана как-то с завершением откатов "сбитой" массовой вставки записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 22:14:04 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид1) сообщение вида: Код: plaintext 1. 2. 3. Хотя в трейсе сообщение о завершении оператора delete from mon$statements появляется практически сразу же за его стартом:И это совершенно правильно Таблоид2) ввод в сеансе_2 сразу после команды (1) команды (2) ни к чему не приводит - т.е. она просто висит без ответа. Опять таки до тех пор, пока ФБ не выполнит откат инсертов.Откат - операция тонкая, она не отвлекается на мониторинг и прочий решедулинг. Насколько создание снапшота мониторинга во время отката действительно критично, нужно крепко подумать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 22:27:24 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladОткат - операция тонкая, она не отвлекается на мониторинг и прочий решедулинг. Насколько создание снапшота мониторинга во время отката действительно критично, нужно крепко подумать...Хм... Снапшот мониторинга делает ДБА, и в основном - не ради любопытства, а когда видит, что база тупит. Снапшот также может делать планировщик, если ДБА захочет понаблюдать за базой в течение NN дней. А откат массового DML может произойти ввиду срубания приложения на любой усеровской тачке. В любой момент. И что получается, ДБА (или задание крона :)) должен будет ждать 2-3-5-... минут результатов мониторинга, пока ФБ не выполнит откаты обрубленного bulk DML ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 22:37:03 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидВ общем, нам есть куда стремиться: этот гад всё утоптал за 2 минуты, выполнив 20 млн согласованных чтений (вместо 55 млн в ФБ, и то для случая union all ) и всего 2 (два) физических чтения :-) текущая версия из SVN "топчет" твой тест за 4 минуты с хвостиком против 17 минут на альфе 1 (при том же числе фетчей и чтений). А на своей сборке я сейчас вижу: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. но оно еще требует тестирования :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 22:43:33 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидпока ФБ не выполнит откаты обрубленного bulk DML ? откаты обрубленного будут ускорены, ты же сам об этом просил в трекере ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 22:46:36 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидИ что получается, ДБА (или задание крона :)) должен будет ждать 2-3-5-... минутнет, пусть лучше БД развалится на части - но зато мгновенно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 22:48:11 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидВ общем, нам есть куда стремиться: этот гад всё утоптал за 2 минуты, выполнив 20 млн согласованных чтений (вместо 55 млн в ФБ, и то для случая union all ) и всего 2 (два) физических чтения :-) текущая версия из SVN "топчет" твой тест за 4 минуты с хвостиком против 17 минут на альфе 1 (при том же числе фетчей и чтений).Вах!.. а в чём там дело было ? Такое ускорение выглядит как-то... подозрительно dimitrА на своей сборке я сейчас вижу: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. dimitrно оно еще требует тестирования :-)Наверное, ты прав... :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 22:51:58 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrоткаты обрубленного будут ускорены, ты же сам об этом просил в трекереДа, я помню этот 3809 Но после слов Алекса: Alexander PeshkovAlexander Peshkov added a comment - 09/Apr/12 05:24 AM It's very interesting point. Probably be we should change rollback method when shutdown is active . - и отсутствия на него твоей реакции почему-то подумалось, что "утопнет оно" :-) BTW, а когда это ускорение откатов случится, наверное, в Beta только ? hvladнет, пусть лучше БД развалится на части - но зато мгновенноА с какого это перепугу она "развалится мгновенно на части" ? Если bulk_DML-откат будет прерван шатдауном с -force 0 (что я делал не один десяток раз, да еще и на FW = OFF) - что, тоже развалится ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 23:00:50 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидВах!.. а в чём там дело было ? Такое ускорение выглядит как-то... подозрительно ничего сверхестественного, глянь в трекере . Оно давно напрашивалось, но руки дошли только сейчас. Правда, эффект несколько больше ожидаемого :-) но твои тесты вечно не от мира сего... Вот только былое отставание от 2.5 надо будет отдельно разбирать, это что-то другое. Таблоид Код: plaintext 1. а нафига больше для чтения таблицы с одной записью? Это свежесозданная БД, настройки "из коробки". Таблоид Код: plaintext 1. это нормально. Оракл тоже усердно все закешировал, но он в consistent gets считает и чтения из временной таблицы тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 23:02:30 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидА с какого это перепугу она "развалится мгновенно на части" ?Вот этот вопрос и надо изучить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 23:11:43 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидВах!.. а в чём там дело было ? Такое ускорение выглядит как-то... подозрительноничего сверхестественного, глянь в трекере . Оно давно напрашивалось, но руки дошли только сейчас.Круто, что тут говорить. Но! фраза: "However, even the former case could benefit from the "plain" execution, as it saves one union context thus avoiding redundant record copying" - не объясняет, почему не только юнион 8 строк, но и соединение 8 таблиц теперь будет выполняться быстрее прежнего на несколько порядков. dimitrПравда, эффект несколько больше ожидаемого :-) но твои тесты вечно не от мира сего...Дык у нас всё приложение тут такое (пока его 1с'ом не убили - есть неисчерпаемый источник для маразма вдохновения и соотв-щих тестов :)) dimitrТаблоид Код: plaintext а нафига больше для чтения таблицы с одной записью? Это свежесозданная БД, настройки "из коробки".Как это "с одной записью" ?? Там таблица в 10 строк создается и дальше идет self join 8 раз! dimitrТаблоид Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 23:15:45 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидничего сверхестественного, глянь в трекере .Там написано, что Fix Version/s: 3.0 Alpha 2 Если скачивать снапшот с обычного адреса - эта фича уже будет в нём, или на сайте только Alpha- 1 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2013, 23:22:41 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидне объясняет, почему не только юнион 8 строк, но и соединение 8 таблиц теперь будет выполняться быстрее прежнего на несколько порядков потому что это соединение юнионов методом nested loop, т.е. юнионы перевыполняются туеву хучу раз ТаблоидКак это "с одной записью" ?? Там таблица в 10 строк создается и дальше идет self join 8 раз! все твои выкрутасы с WITH и self join это лишь повторные фетчи из одной таблицы размером в одну страницу. Включи мозг. ТаблоидЭто на сборке, где ты уже подправил статистику ? (я про недавние траблы с ней) статистика с памятью уже давно в SVN исправлена, прочая статистка работает правильно ТаблоидЕсли скачивать снапшот с обычного адреса - эта фича уже будет в нём, или на сайте только Alpha-1 ? в снапшоте будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 06:36:18 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Посмотрел исправленную статистику. Очень интересно. Это на БД 716 Мб Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Это на БД 1 Мб Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Других запросов не выполнялось. Правильно ли я понимаю, что при подключении к БД Firebird пытается как можно больше засосать в кэш? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 07:19:01 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидстарый 2.5 в два раза быстрее, чем новый 3.0 правильнее будет - новый 2.5 (то бишь 2.5.3) был быстрее как нового 3.0, так и старого 2.5.2. Причина найдена, справедливость восстановлена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 13:40:37 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисПосмотрел исправленную статистику. Очень интересно небось размер страницы 16К в большой и 4К в маленькой? Я никаких странностей у себя не наблюдаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 13:49:49 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitr, Может быть. Посмотрю. Я просто думал, что пока кэш не заполнен и статистика должна быть небольшой. Выходит, что память сразу резервируется и независимо заполнен кэш или нет отображается таковой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 14:04:52 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисВыходит, что память сразу резервируется и независимо заполнен кэш или нет отображается таковой. конечно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 14:05:45 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисПравильно ли я понимаю, что при подключении к БД Firebird пытается как можно больше засосать в кэш?а вот у мну на сегодняшнем снапшоте нет такой разницы. Проверяю на 1) пустой базе и затем на 2) базе 5 Гб. Размер страниц в обеих базах одинаковый, 4К. Параметры firebird.conf оставил дефолтными. Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 14:31:02 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, dimitr уже ответил. Скорее всего так и есть. Размер страниц разный. После работы перепроверю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 14:33:30 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидВ общем, нам есть куда стремиться: этот гад всё утоптал за 2 минуты, выполнив 20 млн согласованных чтений (вместо 55 млн в ФБ, и то для случая union all ) и всего 2 (два) физических чтения :-)текущая версия из SVN "топчет" твой тест за 4 минуты с хвостиком против 17 минут на альфе 1 (при том же числе фетчей и чтений). Проверил на WI-T3.0.0. 30578 Firebird 3.0 Alpha 1/tcp, вариант подсчета числа счастливых билетов в 8-значных номерах, с union DISTINCT (вместо "обычного" union ALL). Улучшение по времени вып-я, конечно же, вижу: БЫЛО (см. тут , под спойлером): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. СТАЛО: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Но фетчей то осталось столько же, 55 лямов! Вот это волшебство:dimitrА на своей сборке я сейчас вижу: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 15:03:42 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидоно уже включено в снапшот или еще нет ? если внимательно читать мои посты, то очевидно что нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 15:52:40 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
В двух базах, одна из которых была создана под 2.5.3, а вторая под 3.0.0, присутствует таблица TBIG(id int, ... другие_поля ...), 10 млн строк. На таблицу был навешен ПК, а затем он был удален - таким обр., повторное его пересоздание по этой же таблице не вызовет увеличение диска. Соединяюсь по ТСР с каждой базой по очереди и повторно ввожу команду создание индекса ПК с отображением статистики. И вот что вижу. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. show version + database, 3.0.0 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. show version + database, 2.5.3 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 17:33:08 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, а файл сортировки в одном и том же месте создается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 17:37:57 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
kdvфайл сортировки в одном и том же месте создается?я не менял в .conf'e значение для TempDirs. Да и диск на этой машине всего один. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 17:44:59 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrСимонов ДенисПосмотрел исправленную статистику. Очень интересно небось размер страницы 16К в большой и 4К в маленькой? Я никаких странностей у себя не наблюдаю. Так и было. Извиняюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 20:50:06 |
|
||
|
Сравнение производительности 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 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
У нас в серверной куча убитых ssd валяется. Думали, на шару можно на обычных ssd взлететь. ... Сейчас, вроде, на коробочках с ширпотребовскими ssd прямо пишут: "Не для серверов". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 21:33:30 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
NickDeeТаблоиду нужно подарить SSD, вторым диском, для тестов проще ему подарить пиво. "серверные" SSD весьма дороги, и у них там все несколько иначе работает, чем у десктопных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 22:00:42 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
чччДУ нас в серверной куча убитых ssd валяется. Думали, на шару можно на обычных ssd взлететь. ... Сейчас, вроде, на коробочках с ширпотребовскими ssd прямо пишут: "Не для серверов". Вот серверный SSD от Intel: http://www.thg.ru/storage/obzor_intel_dc_s3700_test/index.html Цены на price.ru: http://price.ru/search/pc-components/ssd/offers/?query=Intel SSD DC S3700&auto=1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 22:01:12 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
чччДУ нас в серверной куча убитых ssd валяется. Думали, на шару можно на обычных ssd взлететь. дык. рассказывай. марка, модель, сколько проработало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 22:01:50 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
kdvчччДУ нас в серверной куча убитых ssd валяется. Думали, на шару можно на обычных ssd взлететь. дык. рассказывай. марка, модель, сколько проработало. На днях в офис загляну, расспрошу поподробнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 23:06:25 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
NickDee, чччД, kdv! товарищи! один мой топег уже успешно был засорён оффтопом. Если не затруднит, идите какать куда-нить в другое место, плз... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 23:42:33 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоиду, имхо, саперную лопатку подарить надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 23:47:58 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
чччДТаблоиду, имхо, саперную лопатку подарить надо.Их есть у меня: Диля внезапно выслал на Новый год, полтора года взад :-) Но какать оффтопить таки лучше идите все в Пятницу :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 23:59:00 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидто дождаться результата вот этого: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. ТаблоидДаже при кеше = 128К.Так ты ведь кеш файловой системы выкинул. Действительно - а зачем он нужен ? Он был бы не нужен, если бы ты сначала всю таблицу в кеш ФБ затянул, быстрым натуралом. Но ты не ищешь лёгких путей (я знаю) :) ТаблоидНаблюдение в ProcessExplorer'e за ФБ_3 (с момента старта запроса) показывает, что сначала он интенсивно читает диск, но затем диск ему становится нужным всё меньше и меньше, пока потребность эта не станет близкой к нулю. Тут по законам жанра должно расти использование CPU ("ведь кто-то же должен работать!") - ан нет!Наблюдать тоже надо знать как. Твой нижний график в PE (который IO), означает совсем не чтения с диска, а чтения из файлового кеша. Который, очевидно, не содержал в себе всей таблицы (про индекс я молчу) в начале выполнения запроса. Потому ты и наблюдаешь быстрые чтения из кеша в начале процесса и мало-мало потом, когда кеш не в состоянии обслужить твой запрос. А так как random'ность в твоём тесте дичайшая, то и получаешь ты честную сотню страниц в секунду... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 00:53:21 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladНу, как сказать, я смог выждать аж 70 сек :) <...> Buffers: 65 000 <...> ТаблоидДаже при кеше = 128К.Так ты ведь кеш файловой системы выкинул. Действительно - а зачем он нужен ? Почему это "выкинул" ? я отлично помню, что этот выкидыш будет только при установке DefaultDBCachePages > FileSystemCacheThreshold, налетал уже раньше на эти грабли :-) А потому сразу же вонзил в firebird.conf FileSystemCacheThreshold = 512K , что какбэ больше 128К :-) Или на этот параметр (FileSystemCacheThreshold) есть какое-то "скрытое ограничение сверху", при превышении которого файловый кеш всё таки будет игнорироваться ? hvladТвой нижний график в PE (который IO), означает совсем не чтения с диска, а чтения из файлового кеша. Который, очевидно, не содержал в себе всей таблицы (про индекс я молчу) в начале выполнения запроса. Потому ты и наблюдаешь быстрые чтения из кеша в начале процесса и мало-мало потом, когда кеш не в состоянии обслужить твой запрос. А так как random'ность в твоём тесте дичайшая, то и получаешь ты честную сотню страниц в секунду...ОК, я проверю попозжее следующее: перегружу этот сервак и запущу на нём скрипт со 100500 командами вида: Код: plaintext 1. 2. 3. Ну, и запущу также мониторинг, аналогичный: из mon$io_stats + mon$rec_stats. Надо будет сравнить "скорость полета". Пока же установил кеш базы = 65000 страниц, рестартовал ФБ и запустил запрос и мониторинг по-новой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 01:12:11 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидПока же установил кеш базы = 65000 страниц, рестартовал ФБ и запустил запрос и мониторинг по-новой.В общем, оставляю его летать одного в ночи с 64К буферами кеша. Ибо конца-краю этому кисляку не видно - см аттач, ЦПУ опять в нуле, диск еле-еле дёргается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 01:37:13 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидТаблоидПока же установил кеш базы = 65000 страниц, рестартовал ФБ и запустил запрос и мониторинг по-новой.В общем, оставляю его летать одного в ночи с 64К буферами кеша. Ибо конца-краю этому кисляку не видно - см аттач, ЦПУ опять в нуле, диск еле-еле дёргается.В общем, чудес не бывает: за ночь так ничего и не родилось, несмотря на кеш = 65000. Например, за три часа с 05:00 по 08:00 изменения в mon$io_stats - такие же нищенские, как и при кеше = 128К: DTSMON$STAT_IDMON$STAT_GROUPMON$PAGE_READSMON$PAGE_WRITESMON$PAGE_FETCHESMON$PAGE_MARKS05:00:45.576010382446490417825179113305:00:45.57602103656405:00:45.576032001005:00:45.5760430033005:00:45.5760513824984117679140205:00:45.5760623824943017678432005:00:45.5760733824772017678008005:00:45.576081002105:00:45.576091002108:00:12.0760105212878159624372225199808:00:12.07602103656408:00:12.076032001008:00:12.0760430033008:00:12.0760515213197124111577208:00:12.0760625213156024110869008:00:12.0760735212985024110445008:00:12.076081002108:00:12.0760910021differences:10 1 388 414 692 6 547 046 865 21 - - - - 32 - - - - 43 - - - - 51 1 388 213 - 6 432 437 - 62 1 388 213 - 6 432 437 - 73 1 388 213 - 6 432 437 - 81 - - - - 91 - - - - Ну, и по mon$record_stats дифференты тоже совсем не айс: DTSMON$STAT_IDMON$STAT_GROUPMON$RECORD_SEQ_READSMON$RECORD_IDX_READS05:00:48.59101049940714797605:00:48.5910212202605:00:48.5910320005:00:48.5910430805:00:48.591051220714308805:00:48.5910620714304905:00:48.5910730714304105:00:48.5910810005:00:48.5910910008:00:18.73201088000975866308:00:18.7320212202608:00:18.7320320008:00:18.7320430808:00:18.732051220974889308:00:18.7320620974885408:00:18.7320730974884608:00:18.7320810008:00:18.73209100difference:10 38 060 2 610 687 21 - - 32 - - 43 - - 51 - 2 605 805 62 - 2 605 805 73 - 2 605 805 81 - - 91 - - ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 08:41:36 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
То ли ФБ-3 именно на виндузе (2003 server sp2) так тупит, то ли диск на этой тачке совсем #%$$#&! Ибо на линухе всё просто взлетело, на тех же данных и кеше = 65000. И это было видно сразу - CPU был загружен по-взрослому: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. PS. Странно, впрочем, что у Влада был сильно другой результат по числу фетчей: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 09:09:28 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид240 idx_reads в секундуhvladА так как random'ность в твоём тесте дичайшая, то и получаешь ты честную сотню страниц в секунду...Ты до сих пор удивлён ? ТаблоидТо ли ФБ-3 именно на виндузе (2003 server sp2) так тупит, то ли диск на этой тачке совсем #%$$#&! Ибо на линухе всё просто взлетелоНет, там всё уже было в файловом кеше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 11:55:52 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladв 3-ке (пока ещё) сломана защита от большого натурального скана.Вроде починил, завтра сможешь проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 12:42:22 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоид240 idx_reads в секундуhvladА так как random'ность в твоём тесте дичайшая, то и получаешь ты честную сотню страниц в секунду...Ты до сих пор удивлён ?Уже нет. Запустил перфмон и вижу, что диск на эту машину был принесён с помойки: 1) средняя длина очереди диска = 1.12 (x 100.000) 2) средняя скорость чтения с диска, байт/сек, = 770000 (x 0.0001) 3) среднее время чтения с диска, сек, = 0.007 (x 1000.000). На этом навозе можно только детские тесты запускать :( Перейду-ка на линух снова. Там хоть и виртуалка с 4 гигами, но зато шевелится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 12:53:03 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladhvladв 3-ке (пока ещё) сломана защита от большого натурального скана.Вроде починил, завтра сможешь проверить.ОК, псип. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 12:53:12 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидЗапустил перфмон и вижу, что диск на эту машину был принесён с помойки: 1) средняя длина очереди диска = 1.12 (x 100.000) 2) средняя скорость чтения с диска, байт/сек, = 770000 (x 0.0001) 3) среднее время чтения с диска, сек, = 0.007 (x 1000.000).Совершенно обычный десктопный винт. Просто с пустым кешем тяжко получить с него нечто бОльшее. Сделай count(*) по таблице перед тестом, удивишься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 12:59:10 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladСовершенно обычный десктопный винт. Просто с пустым кешем тяжко получить с него нечто бОльшее. Сделай count(*) по таблице перед тестом, удивишься.Сделал, два раза для верности :-) Оба раза были reads = ~ 133500 страниц, при том что: Код: plaintext 1. 2. 3. Код: 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. 27. 28. И это выглядит как-то странно: что помешало содержимому таблицы "зацепиться посильнее" за кеш ?.. В общем, жду опять уже 20 в лишним минут. Срубаю к ЧМ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 13:45:31 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидВ общем, жду опять уже 20 в лишним минутА сколько у тебя там памяти всего ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 14:02:15 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Блин, прочухалась машина эта. И причина была простая: в разеделе "Свойства системы" / "Дополнительно" / "Быстродействие" / "Параметры", дальше в отдельном окне опять во вкладке "Дополнительно" кто-то из недоброжелателей ФБ установил радиокнопки на оптимизацию работы ПРОГРАММ, вместо служб, и использование памяти также было оптимизировано под программы, вместо системного кеша (см скриншот). В общем, после рестарта компа и удаления ненужных старых служб файловый кеш стал равен 450 мегов вместо прежних 140-150. Ну, и родилось наконец-то за 12 минут. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 14:35:03 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидВ общем, жду опять уже 20 в лишним минутА сколько у тебя там памяти всего ?1 Гб. Но проблема была не в этом нищенском размере, а в настройке быстрод-вия Win 2003 Server'a как простой рабочей станции. Кто это сделал - уже не выяснить. Но руки я бы им поотшибал непременно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 14:36:33 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladТаблоид240 idx_reads в секундуhvladА так как random'ность в твоём тесте дичайшая, то и получаешь ты честную сотню страниц в секунду...Ты до сих пор удивлён ? ТаблоидТо ли ФБ-3 именно на виндузе (2003 server sp2) так тупит, то ли диск на этой тачке совсем #%$$#&! Ибо на линухе всё просто взлетелоНет, там всё уже было в файловом кешеВернемся к нашим баранам. Дичайший рандом_io, как выясняется, не так уж страшен, если ФБ имеет б о льший процент попаданий при поиске в файловом кеше, чем некий "страшный порог". То число страниц, которые он вытряхнул с диска (Reads = 10'659'939), а не из кеша, НЕ говорит ничего о времени, потраченном на это. А диск - самое узкое место. Так вот, вопрос: можно ли завести доп. счетчик производительности (в трейсе или видимый только set stat on - пофигу), показывающий именно время , затраченное на вычитку данных с ДИСКА, а не из кеша операционки ? Грубо говоря, показать Reads * <среднее время на 1 reads в ms> - можно ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 14:49:11 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидТак вот, вопрос: можно ли завести доп. счетчик производительности (в трейсе или видимый только set stat on - пофигу), показывающий именно время , затраченное на вычитку данных с ДИСКА, а не из кеша операционки ? Грубо говоря, показать Reads * <среднее время на 1 reads в ms> - можно ?Программа понятия не имеет, откуда ОСь дала ей данные. Среднее время read\write вывести можно. Я только пока не уверен, что это будет бесплатно. Ну и за большой период времени это будет так же бесполезно, как и средняя тем-ра по больнице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 14:52:35 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladСреднее время read\write вывести можно. Я только пока не уверен, что это будет бесплатно. Ну и за большой период времени это будет так же бесполезно, как и средняя тем-ра по больнице.Если будет не только среднее, но еще и min/max время одного reads'a/writes'a, то будет ясен разброс значений и "степень доверия" к среднему. А что касается платы за это - всегда можно сравнить, если будет вкл/вЫкл в trace.conf'e ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 15:01:35 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
ТаблоидТак вот, вопрос: можно ли завести доп. счетчик производительности (в трейсе или видимый только set stat on - пофигу), показывающий именно время , затраченное на вычитку данных с ДИСКА, а не из кеша операционки ? это будет ближе к бете, но исключительно опционально, ибо дорого ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 15:49:21 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrэто будет ближе к бете, но исключительно опционально, ибо дорогов трекер нужно заносить, чтобы не забылось ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 16:00:34 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 16:37:36 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоидпосле рестарта компа и удаления ненужных старых служб файловый кеш стал равен 450 мегов вместо прежних 140-150. Ну, и родилось наконец-то за 12 минут.Рано я радовался. Рестартанул комп еще разок, проверил затем, что нет старых сервисов и файловый кеш снова около 450 Мб - да, всё ОК. Запустил isql, провел предварительную "вычитку" таблицы (select count(*) from ...). Запустил основной запрос - и он заклинил, гад, почти на 3 часа Код: 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. Что измениться могло по сравнению с неслыханной удачей, когда роды прошли за 12 минут - не понимаю. Однако, в ProcExplorer'e активность диска стала уже другой - см аттач: диск явно ожил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2013, 18:35:10 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
hvladв 3-ке (пока ещё) сломана защита от большого натурального скана.Проверил на WI-T3.0.0.30583 - починилось, работает :-) Natural больше не вытесняет результаты индексных поисков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2013, 18:27:53 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
2 dimitr: а будет ли в ФБ-3 что-то делаться вот по этому направлению ? dimitr http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=904994&msg=11800732 ... в 3-ке есть желание многое переделать во внутренностях мониторинга, как насчет изоляции, так и насчет алгоритмики. я проверил тест из того топика на скорость получения ID аттача и транзакции из mon$transactions vs current_connection + current_transaction - и вижу, что воз и ныне там. Различие в 6 с лишним раз. current_connection, current_transaction: 3.47" Код: 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. 27. 28. 29. 30. 31. 32. 33. mon$transactions: 22.7" Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 17:54:10 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
И еще пара вопросов. 1. В топеге про сортировку широких выборок было как-то сказано:dimitrв 3.0 будет мониторинг temp-хранилищаЭто будет в альфе или в бете ? И будет ли вообще ? 2. Примерно в то же время (не могу пока найти тынц) тут была приведена ссылка на спецбилд ФБ, в котором был реализован пересмотренный алгоритм сортировки. В алгоритме этом вместо сортировки всех кортежей (ключей + всех остальных полей) идет сортировка только ключей с последующим соединением со всеми остальными полями. Я тестировал ту сборку, вроде бы даже находил одну-две баги (отсылал в личку). Но хотелось бы "намять бока" этой сборку на линухе. Реально ли сиё ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 19:18:02 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, 1. будет в бете 2. собирать сам будешь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 20:43:03 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидпока ФБ не выполнит откаты обрубленного bulk DML ?откаты обрубленного будут ускорены, ты же сам об этом просил в трекереГлянул сегодня и... неужто дождались ?!.. http://svn.code.sf.net/p/firebird/code/firebird/trunk/ChangeLog Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 19:17:28 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
Таблоид, это другое (оно связано, но совсем чуть-чуть) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2013, 19:20:44 |
|
||
|
Сравнение производительности 2.5.3 vs 3.0 (перечитывая старые тесты)
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидВах!.. а в чём там дело было ? Такое ускорение выглядит как-то... подозрительно ничего сверхестественного, глянь в трекере . Оно давно напрашивалось, но руки дошли только сейчас. Правда, эффект несколько больше ожидаемого :-) но твои тесты вечно не от мира сего... Тут обнаружил что сломался рекурсивный запрос если он идёт по двум и более веткам. Код: sql 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. FB 2.5 Код: plaintext 1. 2. 3. 4. 5. 6. 7. FB 3.0 Код: plaintext 1. 2. 3. Это случано не связано с оптимизацией UNION? В трекере создал тикет CORE-4240 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2013, 19:09:18 |
|
||
|
|

start [/forum/topic.php?all=1&fid=40&tid=1564261]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
184ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
458ms |
get tp. blocked users: |
1ms |
| others: | 216ms |
| total: | 895ms |

| 0 / 0 |
