Cấp phát và giải phóng lặp đi lặp lại làm vùng trống bị chia vụn, khiến tiến trình chiếm nhiều bộ nhớ hơn hẳn lượng thực sự dùng.
Vì sao Nhiều thread cấp phát và giải phóng các vùng nhớ đủ mọi kích thước trong thời gian dài → Dẫn đến Vùng trống vụn rải rác nên không trả lại được cho OS, mức dùng cứ tăng như bị rò rỉ → Trên màn hình Càng chạy lâu càng chậm vì swap hoặc thiếu bộ nhớ, rồi bị buộc kết thúc
Phụ trách chính Phát triển server (Đội phát triển game)
Việc cần làm (Đội phát triển game)
Memory pool theo kích thước, bộ cấp phát (allocator) chống phân mảnh tốt (jemalloc, mimalloc, v.v.).
Trên đồ thị
Tăng dần · Bộ nhớ tiến trình (RSS)
Chỗ cần xem
Chạy hai server cùng bản build; ở một server, giảm số arena của glibc bằng biến môi trường MALLOC_ARENA_MAX hoặc đổi sang bộ cấp phát khác như jemalloc, rồi so sánh RSS trong pidstat -r của hai server trong vài ngày
Đúng nếu
số người và số đối tượng tương đương nhau mà chỉ server đã đổi là RSS ngừng tăng hoặc mức tăng giảm hẳn
Loại trừ nếu
đổi bộ cấp phát mà RSS vẫn tăng y như cũ → bộ nhớ không được giải phóng (mem-leak)
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm
Dấu hiệu giống hệt rò rỉ nên phân tích heap cũng không thấy chỗ rò. Bộ cấp phát mặc định của Linux (glibc) bị phân mảnh đặc biệt nặng ở server có nhiều thread, nên chỉ cần đổi bộ cấp phát là mức dùng bộ nhớ có thể giảm đáng kể.
Nguồn
mallopt(3) — Linux manual pageLinux man-pages Để giảm tranh chấp giữa các thread, glibc malloc tạo arena tới bội số của số CPU, và càng nhiều arena thì mức dùng bộ nhớ càng tăng (giới hạn bằng M_ARENA_MAX, cũng đặt được qua biến môi trường MALLOC_ARENA_MAX)
jemalloc memory allocatorjemalloc Bản cài đặt malloc đa dụng, chú trọng tránh phân mảnh và mở rộng tốt khi chạy đồng thời