Лучше день потерять…

…потом за пять минут долететь.

В рамках тестирования следующей версии IBProvider v5.12 была создана пара UBER таблиц c 4096-ю колонок в каждой, которые добили прямолинейные алгоритмы тестирования схем метаданных «schema.002.*» основной тестовой системы.

Их там три штуки. Тот, который грузит схемы без кэширования, до последнего времени работал 6 часов. После появления вышеобозначенной сладкой парочки — 2 дня и 19 часов. То есть 67 часов.

Это означает, что после завершения всех остальных тестов, компьютер еще кучу времени тупил в одно ядро над одним тестом. 9 ядер простаивали.

Страшно думать, сколько бы оно тупило с отладочной сборкой провайдера. Сто пудов — не меньше недели …

Так что, после того как слона загнали в угол, началась оптимизация этого процесса.

Первое что было сделано — распараллеливание.

Для этого пришлось дорабатывать систему выполнения тестов и позволить тестам добавлять в общую очередь подзадачи.

Три теста, в общей сложности развалились на 363 штуки.

Это немного помогло. Основная часть бодро проезжает, но потом все возвращается на свои круги и тупит.

Тупит оно на схеме COLUMN_PRIVILEGES. Это я и раньше видел. И даже знал причину.

У этой схемы ограничения на колонки: TABLE_CATALOG(1), TABLE_SCHEMA(2), TABLE_NAME(4), COLUMN_NAME(8), GRANTOR(16), GRANTEE(32). В скобках — значение битовой маски, привязанной к ограничению.

Самый тупняк на ограничениях: 16, 32, 16+42=48. Потому что в колонках GRANTOR и GRANTEE очень мало уникальных значений: NULL, PUBLIC, GAMER.

Кстати, в колонках COLUMN_NAME тоже много дубликатов. А UBER-таблицы наплодили дубликатов в колонке TABLE_NAME.

И выборка по этим ограничениям заставляет провайдер вернуть практически все записи этой схемы.

Тут надо бы таки объяснить, что из себя представляет тест.

1. Получаем все записи схемы метаданных.
2. Перебираем эти записи.
3. Заставляем провайдер вернуть данные этой схемы для каждой поддерживаемой комбинации ограничений с указанием значений из текущей записи.
4. Проверяем полученные записи ограниченного множества.

В COLUMN_PRIVILEGES после появления UBER-таблиц стало 57274 записей.

И краем сознания ты осознаешь, что эти UBER-таблицы не последние в своем роде. Поэтому надо что-то делать.

А что делать, что делать? Не надо по 100500 раз проверять одну и ту же комбинацию значений ограничений. Достаточно трех раз. Второй и третий раз нужны для проверки работы всяких кэшей (данных и ресурсов) в провайдере.

В отличии от реализации распараллеливания — работы было на полчаса час (руки понятно откуда растут).

И пришла победа, Карл! 38 минут на десятиядерном 6950X.

[19.02.2020 11:06:58] Creation 10 thread(s)...
....
[19.02.2020 11:10:48] [Thread04] [STOP   ] schema.002.read_schema.schema_cache_2/reader_of_DBSCHEMA_COLUMN_PRIVILEGES/test_restrictions__44
[19.02.2020 11:10:50] [Thread03] [STOP   ] schema.002.read_schema.schema_cache_2/reader_of_DBSCHEMA_PROCEDURES/test_restrictions__12
[19.02.2020 11:10:58] [Thread08] [STOP   ] schema.002.read_schema.schema_cache_2/reader_of_DBSCHEMA_COLUMN_PRIVILEGES/test_restrictions__60
[19.02.2020 11:16:19] [Thread06] [STOP   ] schema.002.read_schema.schema_cache_0/reader_of_DBSCHEMA_PROCEDURE_PARAMETERS/test_restrictions__8
[19.02.2020 11:20:15] [Thread05] [STOP   ] schema.002.read_schema.schema_cache_0/reader_of_DBSCHEMA_COLUMNS/test_restrictions__12
[19.02.2020 11:40:08] [Thread07] [STOP   ] schema.002.read_schema.schema_cache_0/reader_of_DBSCHEMA_COLUMNS/test_restrictions__8
[19.02.2020 11:43:46] [Thread02] [STOP   ] schema.002.read_schema.schema_cache_0/reader_of_DBSCHEMA_COLUMN_PRIVILEGES/test_restrictions__8
[19.02.2020 11:43:54] [Thread09] [STOP   ] schema.002.read_schema.schema_cache_0/reader_of_DBSCHEMA_COLUMN_PRIVILEGES/test_restrictions__24
[19.02.2020 11:44:30] [Thread10] [STOP   ] schema.002.read_schema.schema_cache_0/reader_of_DBSCHEMA_COLUMN_PRIVILEGES/test_restrictions__40
[19.02.2020 11:44:42] [Thread01] [STOP   ] schema.002.read_schema.schema_cache_0/reader_of_DBSCHEMA_COLUMN_PRIVILEGES/test_restrictions__56
....
[19.02.2020 11:44:43] [summary] ------------------------------------------- [SUMMARY INFORMATION]
[19.02.2020 11:44:43] [summary] [TESTS]
[19.02.2020 11:44:43] [summary] EXECUTED      : 363
[19.02.2020 11:44:43] [summary] SUCCEEDED     : 363
[19.02.2020 11:44:43] [summary] FAILED        : 0
[19.02.2020 11:44:43] [summary] WITH WARNINGS : 0
[19.02.2020 11:44:43] [summary] 
[19.02.2020 11:44:43] [summary] - - - - - - - - - - - - - - - - - - - - - -
[19.02.2020 11:44:43] [summary] [TEST TIMES]
[19.02.2020 11:44:43] [summary] REAL          : 129878750456  [03:36:27.8750456]
[19.02.2020 11:44:43] [summary] USER          : 16520937500   [00:27:32.0937500]
[19.02.2020 11:44:43] [summary] KERNEL        : 2415312500    [00:04:01.5312500]
[19.02.2020 11:44:43] [summary] TOTAL         : 18936250000   [00:31:33.6250000]
[19.02.2020 11:44:43] 
[19.02.2020 11:44:43] [TEST HEAP] Test heap is empty
[19.02.2020 11:44:43] [TEST HEAP] Validate ... OK
[19.02.2020 11:44:43] [TEST HEAP] Destroy ... OK
[19.02.2020 11:44:43] 
[19.02.2020 11:44:43] [summary] ------------------------------------------- [PROCESS INFORMATION]
[19.02.2020 11:44:43] [summary] [VIRTUAL MEMORY]
[19.02.2020 11:44:43] [summary] 
[19.02.2020 11:44:43] [summary] PRIVATE BYTES      : 25732 KB       [25MB 132KB]
[19.02.2020 11:44:43] [summary] PEAK PRIVATE BYTES : 664464 KB      [648MB 912KB]
[19.02.2020 11:44:43] [summary] VIRTUAL SIZE       : 4999508 KB     [4GB 786MB 340KB]
[19.02.2020 11:44:43] [summary] PAGE FAULT COUNT   : 356063

Кстати видно, что последние пять тестов завершились через 20 минут после того, как закончились остальные тесты.

Ну, 20 минут это терпимо. В релизном наборе тестов после этой группы идут составы с другими тестами схем метаданных. Так что, полагаю, простоя не будет вообще.

Такие дела.

Можно пойти купить конверт для письма Деду Морозу по поводу 64-ядерного процессора 🙂

Leave a Comment