Sentry.Sources keeps the decoded source-code map on its heap after loading it into ETS

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#1,259 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
76/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
elixir
Lĩnh vực
backend

Hướng nghiên cứu

Bắt đầu bằng cách đọc Sentry.Sources.handle_continue/2, đặc biệt là nhánh :load_source_code_map, nơi giải mã bản đồ được đóng gói và chèn các mục vào ETS. Kiểm tra các bài kiểm thử callback của GenServer và xác minh rằng tiến trình giải phóng bản đồ đã giải mã sau khi tải, trong khi các mục ETS vẫn có thể được truy cập. Issue không nêu tên tệp kiểm thử, vì vậy hãy tìm các bài kiểm thử liên quan trong repository.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Environment
  • sentry 13.4.2, Elixir 1.20.4 / OTP 29.1.1, enable_source_code_context: true
  • Release with a packaged source-code map (mix sentry.package_source_code)
What happens

Sentry.Sources.handle_continue(:load_source_code_map, state) decodes the whole map (:erlang.binary_to_term/1 on the packaged file), inserts each entry into the :sentry_source_code_map ETS table and returns {:noreply, state}. The process then receives no further messages, so it never triggers a garbage collection. The decoded term, which ETS has already copied, stays on the process heap for the life of the node.

On a ~6,400-module app this was about 57 MB per node, on top of the ~54 MB the ETS table needs:

pid = Process.whereis(Sentry.Sources)
Process.info(pid, :total_heap_size)   # ~7.1M words ≈ 57 MB
:erlang.garbage_collect(pid)
Process.info(pid, :total_heap_size)   # near zero

This matters on small machines: on a 1 GB container, this one process held ~6% of RAM for nothing.

Suggested fix

Shrink the heap once the load is done, for example:

{:noreply, state, :hibernate}

or an explicit :erlang.garbage_collect() before returning from handle_continue/2. :hibernate is enough because the process is idle afterwards. Decoding the map outside the GenServer (in a short-lived task) would also avoid it.

Workaround

After the application starts, we wait for the load to finish with :sys.get_state(Sentry.Sources) and then call :erlang.garbage_collect/1 on the process.

Ngôn ngữ chính
Elixir
Star
692
Fork
219
Merge trung bình
2 ngày 19 giờ
Pull request đã merge (30 ngày)
16

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của getsentry/sentry-elixir

Tất cả issue của getsentry/sentry-elixir

Issue tương tự

Thêm issue về Elixir

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.