Trong quá trình vận hành và mở rộng (scale) các ứng dụng .NET Core trên môi trường IIS, hiện tượng Worker Process (w3wp.exe) tiêu thụ tài nguyên RAM vượt mức kiểm soát là một rủi ro kiến trúc phổ biến.

Tài liệu này nhằm làm rõ bản chất của hiện tượng tiêu thụ bộ nhớ bất thường, phân định vai trò của các thành phần hệ thống, và thiết lập các tiêu chuẩn chuẩn đoán cũng như tối ưu hóa mã nguồn cho đội ngũ kỹ sư.

1. Bản chất vấn đề: Phân mảnh vùng nhớ (Fragmentation) vs. Rò rỉ bộ nhớ (Leak)

Việc định nghĩa sai nguyên nhân sẽ dẫn đến việc sử dụng sai công cụ profile bộ nhớ. Cần phân định rõ hai khái niệm sau trong hệ sinh thái .NET:

1.1. Managed Memory Leak (Rò rỉ vùng nhớ có quản lý)

• Định nghĩa: Là trạng thái các đối tượng (objects) không còn giá trị sử dụng nhưng vẫn bị giữ lại bởi một chuỗi tham chiếu (reference tree) đang hoạt động (GC Root).
• Đặc điểm: Garbage Collector (GC) nhận diện các đối tượng này là “đang sống” (alive) và từ chối thu hồi.
• Nguyên nhân phổ biến: Quên hủy đăng ký sự kiện (Event handlers), lạm dụng static collections, lưu trữ object vào Cache mà không có chính sách Eviction.

1.2. LOH Memory Fragmentation (Phân mảnh Large Object Heap)

• Định nghĩa: Là trạng thái các đối tượng đã được giải phóng đúng cách, GC đã thu hồi vùng nhớ, nhưng bộ nhớ bị chia cắt thành nhiều khối nhỏ rải rác không liền mạch.
• Đặc điểm: GC thực hiện dọn dẹp LOH bằng cơ chế Sweep (chỉ xóa đối tượng, đánh dấu vùng nhớ trống) mà không Compact (gom mảnh) do chi phí CPU cho việc dịch chuyển dữ liệu lớn rất cao. Khi hệ thống yêu cầu một mảng dữ liệu liền mạch lớn hơn các khối trống hiện tại, CLR buộc phải yêu cầu hệ điều hành cấp phát thêm bộ nhớ vật lý mới.
• Nguyên nhân phổ biến:
  • Thay đổi kích thước mảng động (Dynamic Array Resizing): Sử dụng List<T>, Dictionary<K, V> chứa dữ liệu lớn mà không thiết lập Capacity.
  • Cấp phát bộ đệm tạm thời (I/O Buffer & Strings): Lạm dụng từ khóa new khởi tạo các mảng byte[] lớn cho luồng xử lý file/network thay vì sử dụng ArrayPool.
  • Đặc tính trì hoãn của Server GC: Cơ chế Server GC ưu tiên thông lượng sẽ trì hoãn tối đa các đợt dọn dẹp toàn cục (Gen 2 / Full GC), khiến LOH không kịp được quét và tái sử dụng.

2. Kiến trúc cấp phát: Mối quan hệ giữa IIS, CLR và LOH

Để xác định ranh giới trách nhiệm khi sự cố bộ nhớ xảy ra, cần hiểu mô hình In-Process Hosting:

1. Hệ điều hành (Windows): Quản lý bộ nhớ vật lý. Cấp phát bộ nhớ cho tiến trình theo yêu cầu.
2. IIS (Internet Information Services): Sinh ra tiến trình w3wp.exe. IIS không can thiệp vào logic quản lý bộ nhớ bên trong của ứng dụng.
3. .NET CLR (Common Language Runtime): Nằm trực tiếp bên trong w3wp.exe. Lượng RAM tiến trình này yêu cầu phản ánh trực tiếp cấu trúc cấp phát bên dưới.

Quy tắc phân bổ vùng nhớ của CLR:

• Đối tượng < 85,000 bytes (~83KB): Lưu trữ tại SOH (Small Object Heap). Trải qua quá trình dọn dẹp và gom mảnh qua các thế hệ Gen 0, 1, 2.
• Đối tượng >= 85,000 bytes: Cấp phát trực tiếp tại LOH (Large Object Heap), thuộc Gen 2.

Khi các đối tượng lớn được tạo và hủy liên tục, LOH xuất hiện nhiều khoảng trống nhỏ rải rác. Do cơ chế không gom mảnh (như đã đề cập ở mục 1.2), hệ thống liên tục xin RAM mới, dẫn đến hiện tượng tiến trình phình to lên hàng chục GB bất chấp tổng dung lượng trống thực tế rất nhiều.

3. Phân tích kỹ thuật: Các nhóm tác nhân chính gây phân mảnh LOH

Hiện tượng LOH Fragmentation thường xuyên xuất hiện và trở nên nghiêm trọng trong các dịch vụ backend phải tải và xử lý khối lượng dữ liệu lớn trực tiếp trên bộ nhớ (In-memory Data Processing). Dưới góc độ mã nguồn, có 3 nhóm cấu trúc dữ liệu là tác nhân chính xả rác vào LOH.

3.1. Dynamic Collections (List<T>, Dictionary<K, V>)

Các cấu trúc dữ liệu động này sử dụng mảng (Array) nội bộ để lưu trữ. Trên kiến trúc 64-bit, mỗi tham chiếu (reference) chiếm 8 bytes. Một collection chứa từ 10,625 phần tử trở lên sẽ có mảng nội bộ vượt 85,000 bytes và tự động bị đẩy thẳng vào LOH.

• Cơ chế thay đổi kích thước (Resizing): Khi thêm phần tử vượt quá Capacity hiện tại, collection tự động cấp phát một mảng mới với kích thước gấp đôi trên LOH, sao chép dữ liệu sang và loại bỏ mảng cũ. Quá trình này liên tục tạo ra các vùng nhớ rác với kích thước tăng dần (ví dụ: 131KB, 262KB, 524KB).
• Hệ quả: Mỗi lần tải dữ liệu lớn, hàng loạt mảng tham chiếu cũ bị vứt bỏ, băm nát vùng nhớ LOH thành vô số các hố hổng phân mảnh.

3.2. I/O Buffers (byte[], char[])

Trong các tác vụ xử lý tài liệu, đọc file, hoặc phân tích tải trọng (payload) mạng (JSON/XML khổng lồ), hệ thống bắt buộc phải khởi tạo các bộ đệm (buffer) để chứa dữ liệu thô.

• Nếu thư viện hoặc đoạn code xử lý liên tục sử dụng từ khóa new byte[100000] để đọc từng phần (chunk) của file, mỗi mảng byte này sẽ đi thẳng vào LOH.
• Vòng đời của các buffer này thường rất ngắn (đọc xong là bỏ). Việc khởi tạo và hủy liên tục hàng ngàn buffer kích thước lớn sẽ bào mòn không gian LOH nhanh chóng trước khi GC kịp can thiệp.

3.3. Thao tác chuỗi dữ liệu lớn (Large Strings)

Trong .NET, chuỗi (string) là kiểu dữ liệu bất biến (immutable) và sử dụng bảng mã UTF-16 (2 bytes cho mỗi ký tự). Bất kỳ chuỗi nào dài hơn 42,500 ký tự sẽ tự động được xếp vào LOH.

• Việc ghép chuỗi (concatenation), cắt chuỗi (substring) trên các tập văn bản lớn sẽ liên tục sinh ra các đối tượng chuỗi mới trong LOH và biến chuỗi cũ thành rác.
• Ngay cả khi sử dụng StringBuilder để tối ưu, nếu không định cỡ sức chứa (Capacity) từ đầu, mảng ký tự ngầm của StringBuilder vẫn sẽ bị nhân đôi và xả rác y hệt như cơ chế của List<T>.

4. Giải pháp cô lập sự cố: Cấu hình RuntimeConfig.json

Trước khi tối ưu mã nguồn, cần thiết lập giới hạn tài nguyên cấp phát, ngăn chặn tình trạng cạn kiệt bộ nhớ hệ điều hành (OS) làm gián đoạn các dịch vụ khác trên máy chủ.

• "System.GC.HeapHardLimit": 17179869184 (16GB): Giới hạn bộ nhớ tối đa cho managed heap. Khi chạm ngưỡng này, ứng dụng sẽ throw OutOfMemoryException và dừng tiến trình (fail-fast) thay vì tiếp tục mở rộng.
• "System.GC.Server": true: Kích hoạt Server GC (mặc định cho ASP.NET Core). Tối ưu hóa throughput cho môi trường đa luồng, cấp phát bộ nhớ theo các segment lớn.
• "System.GC.ConserveMemory": 5: Cấu hình ưu tiên thu hồi bộ nhớ. Ép GC dọn dẹp thường xuyên hơn, giảm thiểu lượng RAM giữ lại, đánh đổi bằng việc tăng mức sử dụng CPU.

5. Chiến lược Chuẩn đoán (Diagnostics) và Giám sát

Khi tiến trình tiến sát các giới hạn tài nguyên, đội ngũ kỹ sư cần áp dụng các bước chuẩn đoán sau:

5.1. Giám sát Telemetry (Observability)

Thiết lập thu thập metric của .NET GC thông qua OpenTelemetry và kết xuất lên các hệ thống giám sát tập trung (như hệ sinh thái LGTM: Loki, Grafana, Tempo, Mimir).

• dotnet_gc_heap_size_bytes (Gen 0, 1, 2, LOH): Đánh giá tỷ lệ phình to của LOH.
• dotnet_gc_fragmentation_ratio: Tỷ lệ phần trăm vùng nhớ trống trên tổng bộ nhớ đã cấp phát. Tỷ lệ này cao xác nhận lỗi Fragmentation chứ không phải Leak.

5.2. Trích xuất và Phân tích Memory Dump

Sử dụng lệnh dotnet-dump collect -p <w3wp_PID> để tạo snapshot bộ nhớ. Dùng công cụ phân tích chạy các lệnh:

• dumpheap -stat: Xem tổng quan số lượng và kích thước các đối tượng. (Dung lượng LOH tăng nhưng số lượng đối tượng không tăng tương xứng -> Xác nhận phân mảnh).
• dumpheap -type System.Collections.Generic.List: Truy vết các mảng kích thước lớn đang bị giữ lại.

6. Tiêu chuẩn tối ưu hóa mã nguồn (Action Items)

Để giải quyết triệt để sự cố ở tầng ứng dụng, toàn bộ mã nguồn cần tuân thủ:

6.1. Cấp phát trước kích thước (Pre-sizing) Luôn xác định hoặc ước lượng Capacity khi khởi tạo collection đối với các tập dữ liệu lớn để chặn đứng cơ chế Resizing.

• Khuyên dùng: var records = new List<OrderRecord>(20000); (Chỉ cấp phát vùng nhớ một lần duy nhất trong LOH).

6.2. Tái sử dụng đối tượng (Object Reuse) Trong các vòng lặp xử lý liên tục (ví dụ: background worker, message queue consumer), tuyệt đối tránh khởi tạo lại collection.

• Khởi tạo collection bên ngoài vòng lặp.
• Sau mỗi chu kỳ xử lý, sử dụng phương thức .Clear(). Hàm này chỉ đặt lại chỉ số Count = 0 mà không giải phóng hoặc thu hẹp mảng nội bộ, cho phép luồng tiếp theo tái sử dụng vùng nhớ sẵn có trong LOH.

6.3. Sử dụng ArrayPool cho dữ liệu I/O Đối với các tác vụ cường độ cao yêu cầu mảng byte lớn (đọc/ghi luồng file Excel, PDF):

• Sử dụng ArrayPool<byte>.Shared.Rent(size) để mượn bộ đệm từ pool thay vì dùng new byte[].
• Đảm bảo hoàn trả bằng ArrayPool<byte>.Shared.Return() trong khối finally.

6.4. Kích hoạt gom mảnh LOH chủ động (Compaction on Demand) Sử dụng một cách có kiểm soát sau các tiến trình batch processing quy mô lớn để dồn vùng nhớ, giảm phân mảnh:

1
2

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();