wyjątek scbl Sterty wyczerpane podczas zbierania śmieci

Gdy nasza aplikacja działa przez pewien czas, na przykład, działa przez wiele godzin, sbcl rzuci wyjątek wyczerpania stosu.wyjątek scbl Sterty wyczerpane podczas zbierania śmieci

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>

Jakieś sugestie?

Źródło

2015-08-05 Amitabha

Sugestia: nie wyczerpuj sterty. Wygląda na to, że masz wyciek pamięci, ja. mi. trzymają się rzeczy, aby nie można ich było zbierać. – Svante

Od czasu do czasu wpadałem na ten sam problem i nie było to deterministyczne, dlatego nie mogłem (jeszcze) złożyć zgłoszenia błędu lub znaleźć błędu z mojej strony. Ale wspólny wzorzec, jaki napotkałem, polegał na tym, że przeznaczyłem dużo pamięci na krótkotrwałe użytkowanie. Ponieważ SBCL używa [generation garbage collection] {http://www.sbcl.org/manual/#History-and-Implementation-of-SBCL} może to być spowodowane złym usuwaniem wyższych pokoleń. W ten sposób możesz wymusić krótkie operacje z użyciem wysokiej mem do oddzielnych wątków, ponieważ rozwiązało to problem, ponieważ po tym, jak wątek umrze, pamięć zostanie zwolniona. – Sim

innym rozwiązaniem może być 'sbcl --dynamic-space-size ' – Sim

SBCL nie pozwala przydzielić więcej niż (sb-ext:dynamic-space-size) bajtów na stercie. Tutaj masz domyślny rozmiar 512 MB (536870912 bajtów), a program Lisp już prawie używał tej ilości, gdy próbował wykonać inną alokację.

Można podwoić ilość dostępnej przestrzeni sterty do 1024 MB, uruchamiając SBCL z --dynamic-space-size 1024. Jednak, jak wskazano w kilku komentarzach, może wystąpić przeciek pamięci, w którym obiekty są w pewnym sensie proporcjonalne do czas, w którym system działa, więc będzie to tylko tymczasowe wytchnienie.

Standardowe wywołanie funkcji Common Lisp może pomóc w debugowaniu tego, jeśli wywoływane jest okresowo.

Bardziej zaawansowany kod taki jak ten http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.debug;a=headblob;f=/source/path-to-root.lisp#l42, który zagłębia się w wewnętrzną mapę alokacji SB-VM, może rzucić więcej światła, a SBCL ma profiler statystyczny, http://www.sbcl.org/manual/#Statistical-Profiler, który obsługuje również raportowanie o alokacjach.

Źródło

2016-02-07 23:11:05

Czy możesz wskazać na działające przykłady użycia profilera SBCL? Wydaje mi się, że nie mogę uzyskać z tego żadnych znaczących wyników. Używam Fiveam i CLOS i napotkam podobny problem, jak pytający. –

wyjątek scbl Sterty wyczerpane podczas zbierania śmieci

Odpowiedz

Powiązane problemy