2010-01-20 5 views
2

SQL FILESTREAM을 사용하여 이미지를 저장하는 응용 프로그램이 있습니다. LOT 개의 이미지 (일 수천만 개의 이미지)를 삽입합니다.SQL FileStream을 사용하여 메모리 누수

잠시 후 컴퓨터가 응답을 멈추고 메모리가 부족한 것 같습니다 ... PC의 메모리 사용량을 살펴보면 많은 메모리를 차지하는 프로세스가 없습니다 (SQL 또는 응용 프로그램이 아님) . 우리는 프로세스를 죽이려고 시도했지만 시스템을 복원하지 못했습니다. 그런 다음 SQL 서비스를 중단하고 시스템에 복원하지 않았습니다. 최후의 수단으로, 우리는 심지어 모든 프로세스 (시스템 것들을 제외하고)를 죽였고 메모리는 여전히 높게 유지되었습니다 (우리는 작업 관리자의 성능 탭을보고 있습니다). 그 시점에서 재부팅 만이 작업을 수행합니다. 우리는 Win7, WinXP, Win2K3 서버에서 항상 동일한 결과를 시도했습니다.

불행히도, 이것은 일회성 계약이 아니며 매번 발생합니다.

이전에 그런 종류의 행동을 본 사람이 있습니까? SQL FILESTREAMS를 사용하여 뭔가 잘못하고 있습니까?

+0

내 생각에 파일 시스템이나 파일 핸들 일 것입니다. 하루에 수백만 개의 이미지가 많이 있습니다. 그들은 어떤 크기입니까? –

+0

두 종류의 이미지가 있습니다. 1kb와 2kb 사이의 미리보기 이미지입니다. "전체 해상도"는 50kb보다 약간 작습니다. – mdarsigny

답변

4

하루에 많은 이미지를 삽입한다고합니다. 이미지로 무엇을 더합니까? 당신이 그들을 업데이트합니까, 많은 독서인가?

파일 시스템이 FILESTREAM에 최적화되어 있습니까?

어떻게 이미지를 읽습니까?

많은 업데이트를 수행하는 경우 SQL Server는 파일 스트림 개체를 수정하지 않지만 새 파일을 만들고 가비지 수집기에서 삭제하도록 이전 파일을 표시한다는 점을 기억하십시오. GC가 트리거되어 오래된 엉망을 제거하기 시작합니다. FILESTREAM의 문제점은 트랜잭션 로그에 많은 양을 기록하지 않아 GC가 심각하게 지연 될 수 있다는 것입니다. 이것이 문제가된다면 GC가보다 자주 반응을 유지하도록 강요함으로써 해결 될 수 있습니다. 이것은 CHECKPOINT 문을 사용하여 수행 할 수 있습니다.

업데이트 : 작은 파일 (1MB 미만)에는 FILESTREAM을 사용하지 마십시오. 수백만 개의 작은 파일은 파일 시스템과 마스터 파일 테이블에 문제를 일으킬 수 있습니다. 대신 varbinary를 사용하십시오. 저장에 대한 FILESTREAM (당신이 작은 파일의 많은 양을 위해 안), 최소한 그에 따라 파일 시스템을 구성해야합니다 사용에 여전히 주장하는 경우 : Designing and implementing FILESTREAM storage

UPDATE에게도 2를 참조하십시오.

는 (작은 파일의 많은 양의 (팁 이러한를 사용하고 당신이 당신이 적용하기 전에 그들이 무엇을 이해하기)

  • 변경 마스터 파일 테이블 레지스트리의 최대 예약 FSUTIL을 파일 시스템을 최적화 .EXE 동작 4)
  • 사용 안 함 8.3 파일 이름 (fsutil.exe 동작 disable8dot3 1)
  • 비활성화 마지막 액세스 업데이트를 설정 (fsutil.exe 동작 설정 disablelastaccess 1)
  • 재부팅을 mftzone를 설정하고 새 파티션을 만들
  • 블록 파일 크기 (대부분 이미지 파일에 따라 2k 또는 4k)를 사용하여 저장소 볼륨을 포맷합니다.
+0

INSERT, 읽지 않음, 업데이트가 없으므로이 문제를 재현 할 수 있습니다. 관리되는 메모리 문제가 아닌 것 같습니다 ... 우리는 가비지 컬렉터를 강제하고 도움이되지 않았습니다. 프로세스의 메모리가 높아 보이지 않기 때문에 OS 문제 일 수 있습니다. CHECKPOINT 문은 FILESTREAM에서 참조하지 않는 파일을 정리하므로 파일을 참조하고 싶기 때문에 도움이되지 않습니다. – mdarsigny

+0

업데이트 # 1에 대한 응답 : 우리는 작은 파일에 filestream을 사용합니다. 거대한 데이터베이스 파일이 필요합니다. 우리는 DB가 아닌 디스크에서 스토리지를 가져오고 싶습니다 ... varbinary를 사용하는 것이 더 효율적이라는 것을 이해합니다. 그러나 우리는 거대한 DB 파일을 원하지 않습니다 ... – mdarsigny

+0

업데이트 # 2에 대한 응답 : 우리는 이미 시도했습니다. 당신이 언급 한 조언. 우리가 알아챈 점은 파일 삽입 시간이 향상되어 문제가 더 빠르게 발생한다는 것입니다. ( 파일 시스템이 처리하기에 너무 빠르게 파일을 생성하고 있다고 생각합니다. 업데이트 # 1) – mdarsigny