Running Low-Latency Analytical Workloads with GPU-Accelerated Presto on NVIDIA GB200 NVL72

Presto is an open source, distributed SQL engine for running fast, interactive queries on very large datasets. On NVIDIA GPUs, Presto delivers peak performance for analytical query workloads and provides low latency for users and agents. GPU-accelerated Presto brings low latency to your analytical workloads, keeping you and your agents unblocked and iterating as fast as possible. 

This post demonstrates efficient multi-GPU Presto execution on scaled analytical benchmarks using both single-node NVIDIA DGX B200 and multinode NVIDIA GB200 NVL72. We also highlight the importance of NVIDIA GPUDirect Storage (GDS) for high I/O throughput on NVIDIA GB200 NVL72 when paired with an IBM Storage Scale System data source.

For more details about GPU-accelerated Presto and the importance of UcxExchange for high performance communications between GPU workers, see Accelerating Large-Scale Data Analytics with GPU-Native Velox and NVIDIA cuDF.

How does GPU-accelerated Presto deliver peak performance?

GPU-accelerated Presto uses NVIDIA cuDF algorithms for peak performance and NVIDIA NVLink for the fastest GPU-to-GPU communication. A single DGX B200 node with eight GPUs supports eight Presto GPU workers, all connected over NVLink 5.0 with 1,800 GB/s bidirectional bandwidth. GPU-accelerated Presto on DGX B200 shows clear performance advantages over Presto CPU running on 8-10 nodes of Intel Xeon 6642Y servers. 

This post focuses on benchmarks derived from TPC-H, which include 22 analytical queries, use parquet file data sources, and replace decimal types with float types for this demonstration. The measured query runtime includes SQL parsing, plan optimization, worker execution, and returning final results. Runtimes were measured by running each query five times and averaging the last four values. Benchmarking data were collected using source builds of Presto, Velox and cuDF. For comprehensive build, deployment, and benchmarking scripts, see the rapidsai/velox-testing GitHub repo.

Figure 1 compares the query runtime for multinode CPU Presto and single-node multi-GPU Presto. The Presto CPU configuration for scale factor 1K used Presto C++ workers, eight nodes of two-socket Intel Xeon 6642Y servers with 250 GiB system memory, and a Lustre data source containing parquet files. At scale factor 3K, the Presto CPU configuration used 10 nodes of the same servers. The Presto CPU configuration ran the benchmarks hot, with the workers using Velox async data cache, and the coordinator using soft affinity to increase cache utilization. The Presto GPU configuration used one NVIDIA DGX B200 with varying number of active GPUs, and hot cache parquet data source. 

At scale factor 1K (~1 TB data set), GPU-accelerated Presto delivered 2.5x-8x lower latency depending on the number of active GPUs. Presto GPU running with one B200 GPU showed 2.5x faster runtime compared to an eight-node Presto CPU cluster, and Presto GPU running with eight B200 GPUs showed 8.2x faster runtimes compared to an eight-node Presto CPU cluster. At scale factor 3K (~3 TB data set), Presto GPU delivered 3x-8x lower latency. Presto GPU running with three B200 GPUs showed 3.6x faster runtimes compared to a 10-node Presto CPU cluster, and Presto GPU running with eight B200 GPUs showed 7.8x faster runtime than a 10-node Presto CPU cluster. 

How does GPU-accelerated Presto scale out on GB200 NVL72? 

GPU-accelerated Presto also scales out to multiple nodes with excellent observed performance on NVLink-connected systems such as NVIDIA GB200 NVL72. The NVIDIA GB200 NVL72 system includes a total of 18 nodes, where each node includes two Grace CPUs, four B200 GPUs, and four ConnectX-7 (CX7) 400 Gbps network interface cards. The GPUs in the cluster are all connected by NVLink, opening the network for traffic between compute and storage.

For GPU-accelerated Presto benchmarking, the NVL72 cluster was paired with IBM Storage Scale, a data storage system with 20 storage nodes, 10 PB capacity and peak bandwidth of ~4.5 TiB/s. IBM Storage Scale, formerly IBM Spectrum Scale or General Parallel File System (GPFS), is a clustered, POSIX-compliant parallel file system, providing native remote direct memory access (RDMA) transport over InfiniBand/RoCE. Together, NVIDIA GDS and IBM Storage Scale allow file data to move directly from storage device to GPU memory, bypassing host CPU and system-memory bounce buffers.

Figure 2 compares the total query runtime for TPC-H-derived scale factors 10K and 30K for the NVL72 GB200 cluster, highlighting the most significant I/O and communication optimizations during cluster bring up. The query runtime data shown in Figure 2 used eight active nodes out of 18 total nodes, corresponding to 32 Presto GPU workers participating in the analytical workloads. 

The first-run condition used POSIX reads to IBM Storage Scale, unoptimized I/O parameters, and untuned UcxExchange configuration. The next condition–device reads and 16 MiB I/O tasks–delivered ~30% faster runtime by enabling GDS and increasing I/O task size from 4 MiB to 16 MiB, the recommended size for IBM Storage Scale. 

The next condition–plus 16 I/O threads–brought a further ~17% faster runtime due to better NVLink saturation when using 16 I/O threads instead of four I/O threads. The final condition–plus rebatching and Q11 rewrite–reduced runtime another 35% due to large exchange batch sizes and less GPU idle time. Overall the I/O and communication optimizations yielded 64% faster query runtimes.

Q11 rewrite modified the SELECT statement to an INSERT INTO statement, which reduced runtime on Q11 from 50 seconds to 2 seconds. We observed that Q11 as a SELECT statement resulted in <5% GPU utilization time in the cluster, due to a bottleneck in sending query results from a GPU worker to the coordinator over the default HttpExchange. Running Q11 as an INSERT INTO statement used the GPU-based parquet writer to efficiently store results in IBM Storage Scale. 

Moving forward, we plan to improve the throughput of sending results in Presto from worker to coordinator, keeping high GPU utilization without adjusting queries. 

How to achieve faster, lightweight I/O with GDS

On the NVL72 cluster with IBM Storage Scale, GDS is a critical tool for reaching peak performance and cost performance. IBM Storage Scale enables two main data paths: POSIX reads that stage data in a client page pool before copying to GPU memory, and GDS reads that populate GPU memory using RMDA. GDS is topology-aware, and ensures that the data path from the CX7 network card to GPU memory remains within the same NUMA node. The version of IBM Storage Scale in this study was not topology-aware for POSIX reads, so these reads incur both the extra staging buffer copy as well as penalties from NUMA boundary crossing.

We analyzed TPC-H-derived 10K performance in two I/O configurations: POSIX cold with a nominal page pool size of 50 GiB, and GDS cold, which bypasses caching. Running scale factor 10K with two nodes (eight GPUs), we observed that GDS reads demonstrate significant advantages over POSIX reads. At two nodes and eight GPUs, GDS cold reads showed ~2x faster runtimes than POSIX cold reads due to POSIX slowdowns from bounce buffer copying and NUMA boundary crossing. Due to the efficient data path and reduced consumption of host resources, we expect GDS reads to be the preferred approach for performance and cost-performance on NVL72 with IBM Storage Scale.

Get started with GPU-accelerated Presto

Whether you’re running interactive dashboards or nightly jobs, GPU-accelerated Presto provides your analytical workloads with low latency and high throughput.

With integration in the IBM watsonx.data platform, GPU-accelerated Presto is now ready for testing on your production workloads. Register for access to the technical preview of GPU-accelerated Presto on watsonx.data. 

For developers and engineers interested in Presto testing and deployment, refer to the Presto Native gpu-nightly tag on the Presto DockerHub. To learn more, see Getting Started with GPU-Accelerated Presto C++.