GIÁM SÁT HIỆU NĂNG VÀ GỠ LỖI (MONITORING & DEBUGGING) CHO CỤM DGX SPARK
GIÁM SÁT HIỆU NĂNG VÀ GỠ LỖI (MONITORING & DEBUGGING) CHO CỤM DGX SPARK
Trong môi trường tính toán hiệu năng cao (HPC), một lỗi cấu hình nhỏ có thể khiến GPU rơi vào trạng thái "Idle" (nghỉ ngơi), lãng phí hàng nghìn USD mỗi giờ. Giám sát hệ thống NVIDIA DGX Spark không chỉ là xem biểu đồ CPU/RAM thông thường, mà là phân tích sâu vào sự phối hợp giữa nhân CUDA, băng thông NVLink và các Executor của Spark. Bài viết này sẽ hướng dẫn bạn cách xây dựng một hệ thống giám sát toàn diện và các kỹ thuật gỡ lỗi chuyên sâu.
1. Hệ sinh thái Giám sát "Ba lớp" trên DGX
Để quản lý hiệu quả, chúng ta cần chia việc giám sát thành ba tầng dữ liệu tách biệt nhưng liên kết chặt chẽ:
1.1. Tầng Phần cứng: NVIDIA DCGM (Data Center GPU Manager)
DCGM là trái tim của việc giám sát GPU. Nó cung cấp các thông số mà các trình giám sát thông thường không thấy được:
GPU Utilization: Tỷ lệ phần trăm nhân CUDA đang tính toán.
Memory Copy Utilization: Tốc độ dữ liệu di chuyển vào/ra VRAM.
NVLink Throughput: Băng thông trao đổi dữ liệu giữa các GPU.
XID Errors: Các lỗi phần cứng hoặc driver nghiêm trọng cần can thiệp ngay.
1.2. Tầng Điều phối: Prometheus & Grafana
Dữ liệu từ DCGM và Spark Metrics được đẩy về Prometheus để lưu trữ và hiển thị trên Grafana.
Dashboard: Tạo các biểu đồ trực quan để theo dõi sức khỏe của 8 GPU cùng lúc trên một màn hình duy nhất.
1.3. Tầng Ứng dụng: Spark UI & RAPIDS Dashboard
Spark UI cung cấp cái nhìn về các Stage và Task, trong khi RAPIDS Dashboard (mở rộng của Spark UI) cho biết chính xác phần nào của câu lệnh SQL đang được GPU xử lý và phần nào đang bị đẩy về CPU.
2. Các chỉ số "Sinh tử" cần theo dõi
Để biết hệ thống DGX Spark có đang tối ưu hay không, bạn phải chú ý 3 chỉ số sau:
2.1. GPU Sm Active (Streaming Multiprocessor)
Nếu chỉ số này thấp (< 50%) trong khi Job Spark đang chạy, nghĩa là mã nguồn của bạn chưa đủ độ song song hoặc dữ liệu nạp vào quá chậm (nghẽn I/O).
2.2. GPU Memory Max Used
GPU H100 có 80GB VRAM. Nếu Job Spark thường xuyên chạm ngưỡng 75-78GB, rủi ro lỗi Out of Memory (OOM) là rất cao. Bạn cần điều chỉnh kích thước Batch hoặc phân vùng lại dữ liệu.
2.3. PCIe/NVLink Traffic
Nếu bạn thấy lưu lượng trên PCIe rất cao nhưng NVLink lại thấp, có nghĩa là dữ liệu đang bị luân chuyển giữa CPU và GPU quá nhiều (hiện tượng Fallback). Đây là dấu hiệu cần phải tối ưu lại Code (xem lại Bài 16).
3. Kỹ thuật Gỡ lỗi (Debugging) chuyên sâu trên DGX
Khi Job Spark bị lỗi hoặc chạy chậm bất thường, hãy thực hiện quy trình gỡ lỗi sau:
3.1. Phân tích Stack Trace từ CUDA
Khác với lỗi Python thông thường, lỗi GPU thường xuất hiện dưới dạng hoặc .
Kỹ thuật: Sử dụng biến môi trường
để bắt buộc GPU chạy tuần tự, giúp xác định chính xác dòng code nào gây ra lỗi.CUDA_LAUNCH_BLOCKING=1
3.2. Kiểm tra "GpuPlan" trong Spark SQL
Mở Spark UI, vào tab SQL và kiểm tra sơ đồ thực thi (Execution Plan).
Dấu hiệu đỏ: Nếu thấy các nút "RowToColumnar" và "ColumnarToRow" xuất hiện liên tục xen kẽ, đó là bằng chứng của việc dữ liệu bị "nhảy" qua lại giữa RAM và VRAM, gây lãng phí thời gian khủng khiếp.
3.3. Sử dụng NVIDIA Nsight Systems
Đây là công cụ "X-quang" cho hệ thống DGX. Nsight Systems cho phép bạn xem dòng thời gian (Timeline) cực kỳ chi tiết: khi nào GPU tính toán, khi nào nó đợi dữ liệu từ ổ cứng, và khi nào nó đợi đồng bộ hóa qua mạng.
4. Xử lý các lỗi phổ biến (Troubleshooting)
4.1. Lỗi "GPU Out of Memory"
Nguyên nhân: Kích thước phân vùng (Partition size) quá lớn hoặc dùng quá nhiều Broadcast Join.
Khắc phục: Giảm
và kiểm soát chặt chẽspark.sql.files.maxPartitionBytes .spark.rapids.memory.gpu.allocFraction
4.2. Job Spark chạy chậm hơn CPU
Nguyên nhân: Dữ liệu quá nhỏ (Small files) khiến chi phí khởi tạo GPU (Overhead) lớn hơn thời gian tính toán.
Khắc phục: Gom các file nhỏ thành file lớn (Coalesce) trước khi xử lý trên GPU.
5. Tự động hóa cảnh báo (Alerting)
Đừng đợi đến khi hệ thống treo mới kiểm tra. Hãy thiết lập cảnh báo tự động:
Nhiệt độ GPU: Cảnh báo nếu vượt quá 85°C (Dấu hiệu hệ thống làm mát có vấn đề).
GPU Throttle: Cảnh báo nếu GPU tự giảm xung nhịp do quá nhiệt hoặc quá công suất.
XID Error: Gửi tin nhắn Telegram/Slack ngay lập tức cho đội ngũ IT nếu có lỗi phần cứng.
6. Bảng kiểm soát hiệu năng (Performance Checklist)
| Thành phần | Trạng thái Tốt | Trạng thái Tệ | Hành động |
|---|---|---|---|
| GPU Utilization | > 70% | < 20% | Tăng số lượng Partition |
| VRAM Usage | 60% - 85% | < 10% hoặc > 95% | Điều chỉnh Batch Size |
| SQL Plan | Toàn bộ là GpuOperator | Nhiều bước RowToColumnar | Tối ưu hóa Code PySpark |
| NVLink Traffic | Cao (GB/s) | Thấp hoặc bằng 0 | Kiểm tra cấu hình NCCL |
7. Kết luận
Giám sát và gỡ lỗi trên NVIDIA DGX Spark là một nghệ thuật cân bằng. Một hệ thống được giám sát tốt không chỉ giúp bạn tránh được các sự cố bất ngờ mà còn cung cấp dữ liệu quý giá để tối ưu hóa chi phí đầu tư. Hãy nhớ: "Bạn không thể tối ưu hóa những gì bạn không thể đo lường."