문제

나는 간단한 웹 앱을 작성하기 위해 SBCL+Hunchentoot를 사용하여 Common Lisp 개발에 사용하려고 하는 메모리(256Mb)가 많지 않은 VPS를 가지고 있습니다.많은 양의 메모리가 특별히 복잡한 작업을 수행하지 않은 채 사용되고 있는 것으로 보이며, 페이지를 제공한 후 잠시 후에 메모리가 부족해지고 모든 스왑을 사용하여 미쳐버리거나 (스왑이 없는 경우) 그냥 죽습니다.

그래서 다음과 같은 일을 하려면 도움이 필요합니다.

  • 모든 메모리를 사용하고 있는 것이 무엇인지 알아보세요(특히 라이브러리나 제가 있는 경우).
  • 대량의 스와핑을 방지하기 위해 SBCL에서 사용할 수 있는 메모리 양을 제한합니다.
  • 메모리가 부족할 때 충돌이 발생하지 않고 깔끔하게 처리하십시오(웹 앱이기 때문에 계속해서 정리하려고 합니다).

나는 처음 두 가지가 합리적으로 간단하다고 생각하지만 세 번째도 가능합니까?사람들은 Lisp에서 메모리 부족 또는 제한된 메모리 조건을 어떻게 처리합니까?

(또한 64비트 SBCL은 32비트에 비해 문자 그대로 두 배의 메모리를 사용하는 것으로 보입니다.이것이 예상되는가?메모리를 많이 절약한다면 32비트 버전을 실행할 수 있습니다)

도움이 되었습니까?

해결책

SBCL의 메모리 사용을 제한하려면-dynamic-space size 옵션을 사용하십시오 (예 :sbcl --dynamic-space-size 128 메모리 사용량을 128m로 제한합니다).

누가 메모리를 사용하고 있는지 알아 보려면 (room) (사용중인 메모리를 알려주는 기능) 다른 시간에 : 시작시, 모든 라이브러리가로드 된 후 작업 중에 (코스, (sb-ext:gc :full t) 아직 수집되지 않은 쓰레기를 측정하지 않기 전에).

또한 SBCL 프로파일 러를 사용하여 메모리 할당을 측정 할 수 있습니다.

다른 팁

모든 메모리를 사용하는 것이 무엇인지 알아보십시오 (라이브러리 또는 나, 특히)

Attila Lendvai에는 할당 된 객체의 출처를 찾기위한 SBCL 별 코드가 있습니다. 인용하다 http://article.gmane.org/gmane.lisp.steel-bank.devel/12903 필요한 경우 개인 메일을 작성하십시오.

구현 별 누출이 아닌지 확인하기 위해 정확한 GC (Clozure CL과 같은)를 사용하여 다른 구현을 시도하십시오.

SBCL이 사용할 수있는 메모리의 양을 제한하고 대량의 스와핑을 피하기 위해

이미 다른 사람들이 대답했습니다.

추락하지 않고 메모리가 다 떨어질 때 깨끗하게 처리하십시오 (웹 앱이기 때문에 계속하고 정리하려고합니다).

256MB는 빡빡하지만 어쨌든 : 나머지 여유 공간을 점검하는 반복 (아마도 1S) 타임 스레드를 예약하십시오. 여유 공간이 X보다 작은 경우 exec ()을 사용하여 현재 SBCL 프로세스 이미지를 새 것으로 바꾸십시오.

유형 선언이 없다면 64 비트 LISP가 32 비트 공간의 두 배를 차지할 것으로 기대합니다. 평범한 (작은) int조차도 64 비트의 메모리 덩어리를 사용합니다. 나는 그것이 당신이 그것을 선언하지 않는 한 그것이 기계 단어보다 적게 사용할 것이라고 생각하지 않습니다.

#2와 #3을 도울 수는 없지만 #1을 알아 내면 문제가되지 않을 것 같습니다. SBCL/Hunchentoot 인스턴스가 오랫동안 실행되는 것을 보았습니다. 엄청난 양의 기억을 사용하고 있다면 보통 내 잘못입니다. :-)

아마도 32비트 셀이 아닌 64비트 셀을 사용할 것이므로 두 배의 메모리를 사용하는 64비트 SBCL에 놀라지 않을 것입니다. 그러나 실제로 확인하지 않고는 확실히 말할 수 없습니다.

예상보다 오랫동안 메모리를 유지하는 일반적인 요인은 여전히 ​​루트 할당 세트에 대한 경로가 있는 더 이상 유용하지 않은 참조입니다(해시 테이블은 이러한 항목을 유지하는 좋은 방법입니다).코드에 GC에 대한 명시적인 호출을 삽입하고 (가능한 한) 전역 변수에 항목을 저장하지 않도록 할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top