запрос omnisci регулируется в NVIDIA GPU + CUDA

Question

Я пытался сравнить несколько своих запросов в omnisci на сервере GPU. Но у меня возникают запросы удушья. Затем я попытался поэкспериментировать с примерами данных, предоставленными самим omnisci flights набор данных.

Ниже приведены мои наблюдения (я использую разъем JDBC)

1.PreparedStatement pstmt2 = conn.prepareStatement("select * from flights_2008_7M natural join omnisci_countries");
    pstmt2.execute(); # with 8 parallel threads 
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 410.104      Driver Version: 410.104      CUDA Version: 10.0     
|
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla P100-SXM2...  On   | 00000000:18:00.0 Off |                    0 |
| N/A   43C    P0    45W / 300W |   2343MiB / 16280MiB |     10%      Default |
+-------------------------------+----------------------+----------------------+
|   1  Tesla P100-SXM2...  On   | 00000000:3B:00.0 Off |                    0 |
| N/A   35C    P0    42W / 300W |   2343MiB / 16280MiB |     15%      Default |
+-------------------------------+----------------------+----------------------+
|   2  Tesla P100-SXM2...  On   | 00000000:86:00.0 Off |                    0 |
| N/A   33C    P0    42W / 300W |   2343MiB / 16280MiB |     14%      Default |
+-------------------------------+----------------------+----------------------+
|   3  Tesla P100-SXM2...  On   | 00000000:AF:00.0 Off |                    0 |
| N/A   38C    P0    42W / 300W |   2343MiB / 16280MiB |     10%      Default |
+-------------------------------+----------------------+----------------------+


2.PreparedStatement pstmt2 = conn.prepareStatement(
    "select * from flights_2008_7M where dest = 'TPA' limit 100000");
    pstmt2.execute(); # with 8 threads

Скрипт завис и ничего не движется, фактически не используется GPU. Просто хотел проверить, нет ли проблем с его конфигурацией. Как я могу максимизировать использование GPU и выполнить некоторые сложные запросы с большим набором данных.

Answer 1

вы уверены, что запрос не падает для выполнения процессора; Я использовал оптимизированные DDL, чтобы столбцы, используемые запросом, помещались в память VRAM.

Чтобы убедиться, что запрос не загружается в CPU для выполнения, перейдите в mapd_log / omnisci_server.INFO и после запуска запроса убедитесь, что вы не получаете подобные сообщения.

Запрос не может быть запущен в режиме графического процессора, повторная попытка на процессоре.

Я сделал небольшую попытку, используя не оптимизированную таблицу 1.2B + на сервере AWS с графическими процессорами 4xV100, и мне пришлось изменить параметр GPU-input-mem-limit = 4 из-за ошибки (вы можете изменить, добавив это в файл omnisci.conf, а затем перезапустите экземпляр) с размером фрагмента по умолчанию 32M.

Вы изменили размер фрагмента на столе вашего полета? Потому что тот, что в flight_7m очень низкий. Если нет, воссоздайте таблицу с размером фрагмента по умолчанию 32000000 или более.

время выполнения в одном потоке составляет около 290 мс

78 %, 84 %, 1530 MHz, 16130 MiB, 6748 MiB, 9382 MiB
81 %, 88 %, 1530 MHz, 16130 MiB, 6924 MiB, 9206 MiB
77 %, 84 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
76 %, 83 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
79 %, 85 %, 1530 MHz, 16130 MiB, 6748 MiB, 9382 MiB
73 %, 80 %, 1530 MHz, 16130 MiB, 6924 MiB, 9206 MiB
91 %, 99 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
77 %, 84 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
95 %, 100 %, 1530 MHz, 16130 MiB, 6748 MiB, 9382 MiB
76 %, 82 %, 1530 MHz, 16130 MiB, 6924 MiB, 9206 MiB
94 %, 100 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
93 %, 100 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
82 %, 88 %, 1530 MHz, 16130 MiB, 6748 MiB, 9382 MiB
95 %, 100 %, 1530 MHz, 16130 MiB, 6924 MiB, 9206 MiB
75 %, 82 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
94 %, 100 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
77 %, 83 %, 1530 MHz, 16130 MiB, 6748 MiB, 9382 MiB
78 %, 85 %, 1530 MHz, 16130 MiB, 6924 MiB, 9206 MiB
76 %, 83 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
75 %, 82 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
90 %, 97 %, 1530 MHz, 16130 MiB, 6748 MiB, 9382 MiB
74 %, 80 %, 1530 MHz, 16130 MiB, 6924 MiB, 9206 MiB
94 %, 100 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
75 %, 82 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB

при работе с четырьмя потоками время отклика увеличивается примерно до 1100 мс с небольшим увеличением использования графического процессора

93 %, 100 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
85 %, 93 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
89 %, 95 %, 1530 MHz, 16130 MiB, 6748 MiB, 9382 MiB
95 %, 100 %, 1530 MHz, 16130 MiB, 6924 MiB, 9206 MiB
90 %, 98 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
94 %, 100 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
89 %, 96 %, 1530 MHz, 16130 MiB, 6748 MiB, 9382 MiB
84 %, 91 %, 1530 MHz, 16130 MiB, 6924 MiB, 9206 MiB
92 %, 100 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
87 %, 95 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
94 %, 100 %, 1530 MHz, 16130 MiB, 6748 MiB, 9382 MiB
94 %, 100 %, 1530 MHz, 16130 MiB, 6924 MiB, 9206 MiB
89 %, 98 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
94 %, 100 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB
89 %, 95 %, 1530 MHz, 16130 MiB, 6748 MiB, 9382 MiB
84 %, 91 %, 1530 MHz, 16130 MiB, 6924 MiB, 9206 MiB
88 %, 97 %, 1530 MHz, 16130 MiB, 8972 MiB, 7158 MiB

Некоторые графические процессоры менее загружены, чем другие, поскольку данные не сбалансированы; мы должны осколковать таблицу, чтобы получить равномерное распределение между графическими процессорами.

Время выполнения настолько велико, потому что при таком проекционном запросе сервер обрабатывает один фрагмент за раз (по умолчанию 32M, поэтому возникают некоторые издержки при передаче и передаче данных из ЦП и ГП и наоборот.

Answer 2

Omnisci спроектирован как аналитическая база данных, поэтому он не очень подходит для выполнения простых проекционных запросов с небольшой фильтрацией, возвращающей много столбцов;тем не менее, запрос, подобный тому, который вы выполняете, занимает всего 31 мс на моей рабочей станции, которая использует только два графических процессора игрового класса

select * from flights_2008_7m  natural join omnisci_countries where dest='DEN' ;
7 rows returned.
Execution time: 29 ms, Total time: 31 ms.

Как и ожидалось, процент использования графических процессоров колеблется около одного процента, потому что набор данныхмала, и операции, которые выполняются на GPU, представляют собой просто соединение и фильтрацию.Чтобы увидеть что-то запущенное в gpu, вы должны выполнить запросы с большим количеством прогнозируемых записей и меньшим количеством столбцов (именно тем, который вам нужен для ваших расчетов), так как этот

select so.name,sd.name,so.id,arrdelay, depdelay,st_area(so.omnisci_geo) 

из flight_b присоединяется к omnisci_states sd на dest_state = sd.abbrприсоединитесь к omnisci_states и т. д. origin_state = so.abbr
где dep_timestamp между '2007-04-05 00:00:00' и '2007-10-07 00:00:00' и depdelay между 10 и 30 и depdelay> arrdelaylimit 1000;

Я изменил условие соединения, потому что при использовании естественного соединения таблицы объединяются в псевдо-столбцах rowid, поэтому было невозможно получить больше строк, чем в таблице geo.

запрос выполняется на том же наборе данных, в то время как таблица flight_b содержит 1,2 миллиарда строк вместо 7 миллионов в примере. Поскольку я работаю на GPU игрового класса, функция st_area довольно обременительна, поэтому выполнение этого запроса занимает 917 мс;в системе с графическим процессором класса Tesla это займет гораздо меньше

Здесь вывод nvidia-smi при выполнении запроса 0%, 0%, 1920 МГц, 10989 МБ, 540 МБ, 10449 МБ 0%,0%, 1875 МГц, 10988 МБ, 538 МБ, 10450 МБ 88%, 71%, 1920 МГц, 10989 МБ, 540 МБ, 10449 МБ 85%, 74%, 1875 МГц, 10988 МБ, 538 МБ, 10450 МБ 0%, 0%, 1920 МГц, 10989 МБ, 540 МБ, 10449 МБ 0%, 0%, 1875 МГц, 10988 МБ, 538 МБ, 10450 МБ

Запуск из omnisql или Java-инструмента, такого как dbeaver, с использованием jdbcводитель такой же.

Вы пробовали свои запросы с помощью Java-инструмента, такого как dbeaver и / или tableau?(последний для параллелизма запросов)