Hai lỗi cấu hình gây ra sự cố hết bộ nhớ (OOM) của Spark trên Kubernetes

Trang chủ InfoQ Bài viết Hai lỗi cấu hình gây ra sự cố OOM của Spark trên Kubernetes Điện toán đám mây Hai lỗi cấu hình gây ra sự cố OOM của Spark trên Kubernetes Ngày 03/6/2026 14 phút đọc Bởi Pranav Bhasker Được đánh giá bởi Steef-Jan Wiggers Viết bài cho InfoQ Thỏa mãn sự tò mò của bạn. Giúp hơn 550.000 nhà phát triển cấp cao toàn cầu mỗi tháng luôn dẫn đầu. Liên hệ Nghe bài viết này - 0:00 Âm thanh sẵn sàng phát Trình duyệt của bạn không hỗ trợ phần tử âm thanh. 0:00 0:00 Bình thường 1.25x 1.5x Thích Danh sách đọc Những điểm chính Việc đặt spark.kubernetes.local.dirs.tmpfs=true sẽ sao lưu tất cả các thư mục tạm thời bằng RAM của nút, bao gồm cả shuffle spill, có thể làm cạn kiệt bộ nhớ nút trong vài giây trong các giai đoạn nặng về shuffle. Một quy tắc podAffinity cứng buộc các executor cùng vị trí sẽ tập trung áp lực bộ nhớ trong thời gian shuffle vào một nút duy nhất, điều này có thể gây ra lỗi hết bộ nhớ (OOM) nghiêm trọng trong các giai đoạn nặng về shuffle. Giới hạn dung lượng scratch volume một gibibyte (1Gi) là không đủ cho bất kỳ tác vụ nặng về shuffle nào: hãy điều chỉnh kích thước tmp-volume và workdir theo hồ sơ dữ liệu shuffle sản xuất thực tế của bạn. Các lỗi cấu hình cơ sở hạ tầng phức tạp thường chỉ xuất hiện dưới tải trọng quy mô sản xuất và dễ bị chẩn đoán sai là các vấn đề điều chỉnh Spark như thiếu bộ nhớ heap hoặc lệch dữ liệu. Việc di chuyển lên đám mây làm thay đổi hợp đồng cơ sở hạ tầng mà khối lượng công việc của bạn phụ thuộc vào; hãy xác thực rõ ràng ngữ nghĩa lưu trữ và hành vi lập lịch trước khi đưa vào sản xuất. Giới thiệu Ngay sau khi di chuyển một số đường ống xử lý hàng loạt Spark từ cơ sở hạ tầng tại chỗ sang Azure Kubernetes Service (AKS), chúng tôi bắt đầu thấy các lỗi OOM executor lặp đi lặp lại trong một trong những tác vụ lớn hơn của mình. Các lỗi xuất hiện trong các giai đoạn shuffle và ban đầu trông giống như một vấn đề điều chỉnh bộ nhớ Spark điển hình. Bộ nhớ executor được tăng lên, số lượng executor được điều chỉnh và tác vụ được khởi động lại nhiều lần. Không có thay đổi nào trong số này giúp ích. Điều khó hiểu là đường ống đã ổn định trong nhiều năm trước khi di chuyển. Nguyên nhân gốc rễ cuối cùng không phải là vấn đề cấu hình Spark. Thay vào đó, hai cài đặt cấp cơ sở hạ tầng được đưa vào trong quá trình di chuyển đã tương tác theo một cách không mong muốn: các thư mục tạm thời cục bộ được hỗ trợ bởi RAM (spark.kubernetes.local.dirs.tmpfs=true) và một quy tắc podAffinity cứng buộc tất cả các executor vào cùng một nút. Cùng với nhau, các cài đặt này đã khiến shuffle spill tiêu thụ bộ nhớ nút thay vì đĩa, dẫn đến các lỗi OOM lặp đi lặp lại. Bài viết này ghi lại quá trình điều tra, nguyên nhân gốc rễ và các thay đổi cấu hình đã giải quyết vấn đề. Bối cảnh hệ thống và nền tảng di chuyển Môi trường đường ống Nền tảng dữ liệu của chúng tôi quản lý các quy trình xử lý hàng loạt (batch pipelines) hỗ trợ tổng hợp và chuyển đổi dữ liệu giao dịch quy mô lớn tại một tổ chức tài chính lớn của Hoa Kỳ. Các tác vụ này xử lý một tệp phẳng (flat file) có độ rộng cố định, dung lượng khoảng 3 gigabyte mỗi ngày. Tệp này chứa nhiều bố cục bản ghi xen kẽ, đòi hỏi nhiều lần phân tích cú pháp và hợp nhất, khiến công việc tốn nhiều tài nguyên xáo trộn (shuffle-intensive) hơn so với kích thước đầu vào 3 gigabyte của nó. Tại chỗ (on-premises), các quy trình này đã chạy ổn định trong hơn 3 năm với hồ sơ thực thi ổn định và không có mô hình lỗi hết bộ nhớ (OOM) tương tự. Cấu hình cụm AKS Tổng quan về môi trường nơi sự cố xảy ra: | Tham số | Trước (lỗi) | Sau (đã sửa) | |---|---|---| | RAM nút | 64GB | 64GB | | Trình thực thi mỗi tác vụ | 4 | 4 | | Bộ nhớ trình thực thi | 8g → 10g trong quá trình chẩn đoán | 10g | | Cấp phát động | Đã tắt | Đã tắt | | Phiên bản Spark | 3.4.0 | 3.4.0 | | Ngôn ngữ | Scala | Scala | | spark.kubernetes.local.dirs.tmpfs | true ❌ | false ✅ | | spark.sql.shuffle.partitions | chưa đặt (mặc định 200) | 200 (đặt rõ ràng) | | Kích thước tmp-volume | 1Gi (dựa trên RAM) ❌ | 10Gi (dựa trên đĩa) ✅ | | Kích thước workdir | 1Gi (dựa trên RAM) ❌ | 10Gi (dựa trên đĩa) ✅ | | Quy tắc đặt Pod | podAffinity bắt buộc ❌ | podAntiAffinity ưu tiên ✅ | Bối cảnh di chuyển Việc di chuyển sang AKS là một phần của nỗ lực hiện đại hóa đám mây rộng lớn hơn. Các tác vụ này được coi là ứng cử viên "nâng và chuyển" (lift-and-shift), với giả định rằng việc khớp CPU và RAM sẽ duy trì hành vi thời gian chạy mà không cần thay đổi ứng dụng. Giả định đó đã sai: hai cài đặt cơ sở hạ tầng được đưa vào trong quá trình di chuyển đã thay đổi cách Kubernetes xử lý việc đặt trình thực thi và lưu trữ cục bộ, và cả hai đều không được gắn cờ trong quá trình xem xét. Dòng thời gian sự cố Tuần đầu tiên sau di chuyển Các lần chạy ban đầu có vẻ ổn định. Các tác vụ nhỏ hơn hoàn thành mà không gặp vấn đề gì. Các lỗi OOM đầu tiên xuất hiện trong tác vụ hàng loạt nhiều bố cục có độ rộng cố định trong các giai đoạn hợp nhất tốn nhiều tài nguyên xáo trộn của nó. Tác vụ này đọc cùng một tệp 3 gigabyte nhiều lần với các trình phân tích cú pháp bố cục khác nhau trước khi hợp nhất kết quả. Ngày thứ hai đến thứ ba Các lỗi OOM ban đầu được coi là tạm thời. Các tác vụ được khởi động lại thủ công và tạm thời phục hồi. Vấn đề được ghi nhận là không liên tục và được cho là do tranh chấp tài nguyên có thể xảy ra ở cấp cụm. Ngày thứ ba đến thứ tư: Giả thuyết đầu tiên và cấu hình heap sai Chẩn đoán ban đầu tập trung vào kích thước heap của trình thực thi. Chúng tôi đã tăng spark.executor.memory từ 8 gigabyte (8g) lên 10 gigabyte (10g). Các lỗi vẫn tiếp diễn dưới tải, loại trừ việc thiếu kích thước heap đơn giản là nguyên nhân gốc rễ. Ngày thứ tư: Giả thuyết thứ hai và số lượng trình thực thi Chúng tôi đã tăng số lượng trình thực thi để phân phối khối lượng công việc hơn.