Kỹ sư Pinterest loại bỏ "CPU Zombies" để giải quyết nút thắt hiệu suất trong môi trường sản xuất

Pinterest đã công bố một báo cáo kỹ thuật chi tiết về cách đội ngũ kỹ sư của họ theo dõi và khắc phục tình trạng thiếu hụt CPU ngắt quãn, vốn đang gây ra sự cố cho các công việc đào tạo máy học (machine learning). Bằng cách xác định những gì nhóm gọi là "zombies" (các bộ nhớ cgroup bị rò rỉ do một tác nhân mặc định bị crash liên tục), các kỹ sư đã khôi phục lại sự ổn định cho nền tảng điện toán phân tán của mình.

Vấn đề biểu hiện dưới dạng các lỗi mạng và sự cố sập công việc trên PinCompute, nền tảng dựa trên Kubernetes nơi Pinterest chạy hơn một nửa khối lượng công việc máy học ngoại tuyến (offline). Hàng chục nghìn cụm Ray được cung cấp hàng tháng cho các nhiệm vụ này, và một số trường hợp sử dụng đã thấy tỷ lệ thành công của công việc đào tạo giảm hơn 25% do các thiết bị Elastic Network Adapter (ENA) bị đặt lại và gói tin bị loại bỏ. Các cuộc điều tra ban đầu gặp khó khăn vì việc sử dụng CPU tổng thể trông có vẻ ổn định, che giấu các lỗi bên dưới.

Buộc phải bỏ qua các bảng điều khiển cấp cao, đội ngũ hạ tầng đã chuyển sang phân tích từng lõi CPU bằng công cụ mpstat. Cuộc điều tra cho thấy các lõi riêng lẻ đạt 100% CPU hệ thống trong vài giây tại một thời điểm. Hành vi này đặc biệt gây hại vì nếu một lõi xử lý ngắt mạng ENA bị bão hòa, luồng thăm dò NAPI của trình điều khiển có thể bị thiếu chu kỳ, kích hoạt cơ chế tự phục hồi là đặt lại thiết bị ENA (khi hoàn thành Tx bị đình trệ hơn năm giây), dẫn đến mất kết nối và làm sập các công việc Ray.

Để xác định chính xác nguồn gốc của sự bão hòa lõi này, nhóm đã sử dụng các bản ghi perf liên tục trong hai phút chạy trong cửa sổ tái tạo 12 giờ. Khi trực quan hóa bằng Flamescope của Netflix, các bản ghi này cho phép kỹ sư phóng to vào các thời điểm chính xác khi đặt lại mạng xảy ra. Họ phát hiện ra rằng tiến trình kubelet, thường tiêu thụ ít hơn 1% CPU, đã tăng vọt lên khoảng 6,5%. Phần lớn thời gian này được dành cho hàm kernel mem_cgroup_nr_lru_pages.

Cuối cùng, cuộc điều tra đã truy nguyên vấn đề về ảnh AMI Deep Learning của AWS được sử dụng cho các nút của họ. Ảnh cơ bản này bao gồm một tác nhân Amazon ECS được bật theo mặc định nhưng không được Pinterest sử dụng. Tác nhân này bị crashlooping (vòng lặp sự cố) và rò rỉ bộ nhớ cgroup (memcgs) mỗi lần khởi động lại. Với gần 70.000 "zombie" memcgs tích tụ so với chỉ 240 cái đang hoạt động, kubelet phải duyệt qua danh sách phình to này mỗi lần đồng bộ thống kê cgroup, chiếm dụng một lõi duy nhất trong vài giây.

Giải pháp tương đối đơn giản nhưng đòi hỏi sự hiểu biết sâu sắc về ngăn xếp hệ thống. Pinterest đã giải quyết nút thắt bằng cách vô hiệu hóa đơn vị systemd của tác nhân ECS trong ảnh cơ bản của họ và khởi động lại các máy bị ảnh hưởng để xóa sạch các cgroup tích tụ. Kể từ thay đổi này, số lượng bộ nhớ cgroup vẫn ổn định và các sự cố đặt lại mạng đã chấm dứt. Trải nghiệm này nhấn mạnh rằng các lớp trừu tượng giữa ứng dụng, bộ điều phối và kernel thường có thể che khuất nguyên nhân gốc rễ thực sự: trong trường hợp này là một daemon không gian người dùng thừa thãi làm rò rỉ trạng thái kernel.

Mặc dù Pinterest sử dụng lập hồ sơ thủ công để giải quyết trường hợp cụ thể này, nhóm đã lưu ý giá trị của việc lập hồ sơ liên tục, được lập chỉ mục theo thời gian để quan sát khả năng quan sát trong sản xuất. Các công cụ như gProfiler, mà Pinterest đang triển khai hợp tác với Intel, và các nền tảng dựa trên eBPF như Parca và Grafana Pyroscope, cung cấp khả năng hiển thị trên toàn đội tàu có thể rút ngắn con đường từ triệu chứng đến nguyên nhân gốc rễ.

Bằng cách chia sẻ phát hiện của mình, đội ngũ kỹ thuật Pinterest nhấn mạnh rằng hiệu suất ở quy mô thường được quyết định bởi các cấu hình mặc định của ảnh cơ bản cũng như mã ứng dụng. Hành trình của họ đóng vai trò như một lời nhắc nhở quan trọng đối với các kỹ sư phần mềm: hãy luôn hoài nghi về các mặc định của hệ thống và làm chủ các công cụ chẩn đoán cấp thấp.