Bộ nhớ ECS Fargate tăng mãi: tách mức nền và đỉnh tải để điều tra (メモリ調査)

✍️ Tác giả nguồn: tm-onishi, thuộc 株式会社Shizen Connect trên Qiita.
🔗 Tiêu đề gốc: ECS Fargateでメモリ使用率が単調増加していた話 ――「床」と「ピーク」は別の原因だった
🌐 Bài gốc: Qiita · c403750dc2be843c0968, đăng ngày 15/10/2026, đọc ngày 17/10/2026.
📝 Biên soạn: Tóm lược ngắn kết hợp phân tích và ví dụ riêng của BrSE.vn. Các câu Nhật bên dưới là câu luyện tập tự soạn.

📌 Điểm nhấn cốt lõi (Key Takeaways)

• Đỉnh bộ nhớ khi chạy batch và mức nền sau batch cần hai tiêu chí theo dõi riêng.
• flush() và commit() giải quyết hai việc khác nhau; chia lô vẫn cần xét các tham chiếu còn giữ đối tượng.
• Chỉ số cấp service cần được đối chiếu với từng task, worker và thời điểm deploy trước khi kết luận nguyên nhân.

1. Ca thực tế gợi ra câu hỏi gì?

Trong ca của tm-onishi, một API có cả đỉnh tải theo lô lẫn mức nền tăng dần. Tác giả dùng chia lô và ổn định câu SQL, sau đó bổ sung tái tạo worker để xử lý phần tăng còn lại. Đây là kết quả trong môi trường của tác giả, chưa chứng minh cấu hình đó phù hợp với mọi ứng dụng.

Từ đây, nhóm dự án có thể đặt câu hỏi cụ thể hơn: “Sau khi xử lý cùng một khối lượng dữ liệu, bộ nhớ lúc nhàn rỗi có quay về cùng khoảng cũ không?” Câu hỏi này giúp bản báo cáo phân biệt được giảm tải tức thời với cải thiện vận hành dài hạn.

Nghĩa: Chúng tôi sẽ tiếp tục kiểm tra xem lượng bộ nhớ sau xử lý có trở về mức ban đầu hay không.

2. Đọc chỉ số trước khi quy lỗi cho code

Theo tài liệu ECS về service utilization, Average phản ánh tổng mức sử dụng so với tổng tài nguyên cấu hình của các task. Minimum và Maximum phản ánh task sử dụng ít và nhiều nhất. Vì thế, minimum theo ngày của service không phải phép đo trực tiếp lượng bộ nhớ còn giữ của một worker.

Khi task được thay thế hoặc autoscale, đường biểu diễn cũng có thể đổi. Hãy ghi lại task count, revision, thời điểm restart và khung chạy batch bên cạnh biểu đồ. Khi cần xác định tiến trình nào tăng RSS, bổ sung số đo theo task/process. Chỉ từ một đường phần trăm chưa thể khẳng định memory leak.

Minh họa do BrSE.vn tự vẽ, phát hành theo CC0 1.0. Đây là sơ đồ khái niệm, không phải ảnh CloudWatch hay dữ liệu của bài nguồn.

Một bảng điều tra tự lập có thể bắt đầu như sau:

Câu hỏi	Bằng chứng cần thu	Quyết định tiếp theo
Đỉnh có đi cùng số bản ghi?	Số bản ghi, peak RSS, thời lượng cùng một lần chạy	Thử giảm lượng dữ liệu đồng thời
Sau thời gian nghỉ, nền có tăng?	RSS cùng worker ở các mốc tương đương	Kiểm tra vòng đời đối tượng và cache
Đường giảm có trùng deploy?	Task ID, revision, nhật ký khởi động	Phân biệt thay process với code tự giải phóng
Task nào tạo đỉnh?	Metric theo task và log correlation ID	Khoanh vùng thay vì suy từ trung bình

3. Ví dụ riêng: chia lô nhưng giữ một transaction

Giả sử đội phát triển cần nhập danh sách mã thiết bị. Mẫu dưới đây tự tạo dữ liệu, chạy được với SQLite trong bộ nhớ và SQLAlchemy 2.x; nó minh họa ranh giới transaction, không phải bản tái hiện hay benchmark hệ thống Qiita.

from sqlalchemy import String, create_engine, func, select
from sqlalchemy.orm import DeclarativeBase, Mapped, Session, mapped_column

class Base(DeclarativeBase):
    pass

class Device(Base):
    __tablename__ = "device_demo"
    id: Mapped[int] = mapped_column(primary_key=True)
    code: Mapped[str] = mapped_column(String(40), unique=True)

engine = create_engine("sqlite:///:memory:")
Base.metadata.create_all(engine)

with Session(engine) as session:
    with session.begin():
        for start in range(0, 12, 4):
            session.add_all(
                Device(code=f"demo-{i}") for i in range(start, start + 4)
            )
            session.flush()
        # Thoát begin thành công: commit một lần; lỗi: rollback.
    print(session.scalar(select(func.count()).select_from(Device)))
    # Kết quả mong đợi: 12

SQLAlchemy Session Basics giải thích rằng flush gửi thay đổi đang chờ vào transaction; flush chưa phải commit. Với yêu cầu “thành công toàn bộ hoặc không ghi gì”, commit từng lô sẽ thay đổi hành vi nghiệp vụ.

Về bộ nhớ, Session State Management nêu ngoại lệ giữ tham chiếu mạnh cho đối tượng pending, deleted hoặc có thay đổi. Sau full flush, đối tượng persistent trở về cơ chế tham chiếu yếu thông thường. Nếu ứng dụng vẫn gom chúng vào một list bên ngoài, flush() không xóa danh sách đó và không bảo đảm RSS giảm ngay.

Trong dự án thật, hãy so sánh hai lần chạy cùng đầu vào, cùng worker count và cùng cách lấy số đo. Nếu chỉ giảm batch size nhưng vẫn đọc toàn bộ payload vào RAM trước vòng lặp, phạm vi cải thiện sẽ bị giới hạn.

4. Worker recycling cần một kế hoạch nghiệm thu

Uvicorn có --limit-max-requests để giới hạn số request một process xử lý. Chọn ngưỡng cần dựa trên tải đo được và thời gian khởi động ứng dụng. Health check cũng có thể ảnh hưởng chu kỳ thay worker; số request không tương đương số lần chạy batch.

Trước khi dùng cơ chế này, nhóm nên diễn tập lúc đang có request dài: quan sát lỗi HTTP, request bị ngắt, tác vụ nền, số worker khả dụng và thời gian shutdown. Nếu thao tác có tác dụng phụ, cần xác nhận cách tránh thực hiện hai lần khi phía gọi thử lại. Recycling là biện pháp vận hành; nó chưa cung cấp bằng chứng rằng nguyên nhân giữ bộ nhớ đã được sửa.

Gợi ý tiêu chí nghiệm thu tự soạn cho BrSE: “Với bộ dữ liệu và mức đồng thời đã thống nhất, ghi nhận peak, RSS lúc nghỉ của cùng worker và tỷ lệ lỗi qua nhiều chu kỳ batch. Báo cáo riêng các lần deploy/restart.” Chốt khoảng quan sát và ngưỡng với khách hàng trước khi chạy, thay vì dùng một ảnh chụp dashboard làm kết luận.

Nghĩa: Chỉ giảm đỉnh tải chưa chắc đã giải quyết vấn đề. Cần kiểm chứng lại trong cùng điều kiện.

5. Sổ tay thuật ngữ Hán Việt

Thuật ngữ Nhật	Furigana	Hán Việt	Nghĩa trong kỹ thuật
使用量	しようりょう	Sử dụng lượng	Lượng tài nguyên đang dùng
単調増加	たんちょうぞうか	Đơn điệu tăng gia	Xu hướng tăng không giảm
解放	かいほう	Giải phóng	Nhả tài nguyên hoặc tham chiếu
参照	さんしょう	Tham chiếu	Reference tới đối tượng
閾値	しきいち	Vực trị	Ngưỡng để đánh giá hoặc cảnh báo
再検証	さいけんしょう	Tái kiểm chứng	Kiểm tra lại giả thuyết/kết quả

Cột Hán Việt giúp nhớ mặt chữ; khi làm việc nên dùng nghĩa kỹ thuật ở cột cuối.

6. Ngữ pháp Nhật dùng trong báo cáo sự cố

Mẫu	Ý nghĩa	Ví dụ tự soạn và bản dịch
～かどうか	Có… hay không	増ふえるかどうかを調しらべます。— Kiểm tra xem có tăng hay không.
～とは限らない	Không nhất thiết	原因げんいんが一ひとつとは限かぎらない。— Nguyên nhân không nhất thiết chỉ có một.
～た上で	Sau khi đã…	条件じょうけんをそろえた上うえで比較ひかくします。— So sánh sau khi thống nhất điều kiện.

Khi bàn giao điều tra, hãy ghi rõ đâu là quan sát, đâu là giả thuyết và phép thử nào còn thiếu. Cách viết này giúp khách hàng đánh giá được mức chắc chắn của kết luận.