Khi ứng dụng của chúng tôi chạy trong một thời gian, ví dụ, chạy hàng giờ, sbcl sẽ ném ngoại lệ đã cạn kiệt heap.scbl ngoại lệ Heap cạn kiệt trong quá trình thu gom rác
Heap exhausted during garbage collection: 1968 bytes available, 2128 requested.
Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB LUB !move Alloc Waste Trig WP GCs Mem-age
0: 0 0 0 0 0 0 0 0 0 0 0 5368709 0 0 0.0000
1: 0 0 0 0 0 0 0 0 0 0 0 5368709 0 0 0.0000
2: 0 0 0 0 0 0 0 0 0 0 0 5368709 0 0 0.0000
3: 101912 101913 0 0 19362 20536 0 0 0 162867456 554752 102714709 0 1 1.4405
4: 130984 131071 0 0 29240 18868 0 0 25 191196152 5854216 128537781 14785 1 0.6442
5: 75511 81013 0 0 16567 17127 92 99 36 132974568 5818392 2000000 16565 0 0.0000
6: 0 0 0 0 7949 1232 0 0 0 37605376 0 2000000 7766 0 0.0000
Total bytes allocated = 524643552
Dynamic-space-size bytes = 536870912
GC control variables:
*GC-INHIBIT* = true
*GC-PENDING* = true
*STOP-FOR-GC-PENDING* = false
fatal error encountered in SBCL pid 3281(tid 3067845440):
Heap exhausted, game over.
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>
Bất kỳ đề xuất nào?
Gợi ý: không xả hết đống. Dường như bạn có một số rò rỉ bộ nhớ, i. e. đang nắm giữ những thứ để chúng không thể được thu gom rác. – Svante
Tôi thỉnh thoảng chạy vào cùng một vấn đề và nó không phải là xác định do đó tôi đã (chưa) không thể gửi một lỗi báo cáo hoặc tìm lỗi trên một phần của tôi. Nhưng mô hình phổ biến mà tôi gặp phải là tôi phân bổ rất nhiều bộ nhớ để sử dụng trong thời gian ngắn. Vì SBCL sử dụng [thu gom rác thế hệ] {http://www.sbcl.org/manual/#History-and-Implementation-of-SBCL}, điều này có thể là do thanh toán bù trừ kém của các thế hệ cao hơn. Vì vậy, bạn có thể muốn buộc các hàm shortliving với việc sử dụng mem cao vào các chủ đề riêng biệt vì điều này giải quyết được vấn đề cho tôi như sau khi một luồng chết mem sẽ được giải phóng. – Sim
một giải pháp khác có thể là 'sbcl --dynamic-space-size' –
Sim