다음과 같은 구성이 있습니다.
- 3 개의 도커 컨테이너를 실행하는 호스트 시스템 :
- 몽고 DB
- 레디 스
- 이전 두 컨테이너를 사용하여 데이터를 저장하는 프로그램
Redis와 MongoDB는 모두 대량의 데이터를 저장하는 데 사용됩니다. Redis는 모든 데이터를 RAM에 보관해야한다는 것을 알고 있으며 이것으로 괜찮습니다. 불행히도 몽고는 많은 RAM을 차지하기 시작하고 호스트 RAM이 가득 차면 (여기서 32GB 이야기) 몽고 또는 Redis가 충돌합니다.
이에 대한 다음과 같은 이전 질문을 읽었습니다.
- MongoDB RAM 사용 제한 : 분명히 대부분의 RAM은 WiredTiger 캐시에서 사용됩니다.
- MongoDB 제한 메모리 : 분명히 문제는 로그 데이터였습니다.
- MongoDB의 RAM 메모리 사용량 제한 : 몽고의 메모리를 제한하여 캐시 / 로그 / 데이터에 더 적은 양의 메모리를 사용하도록 제안합니다.
- 너무 많은 메모리를 사용하는 MongoDB : 여기에서는 WiredTiger 캐싱 시스템이라고 말하며 가능한 한 많은 RAM을 사용하여 더 빠른 액세스를 제공합니다. 그들은 또한 진술
it's completely okay to limit the WiredTiger cache size, since it handles I/O operations pretty efficiently - mongodb 메모리 사용을 제한하는 옵션이 있습니까? : 다시 캐싱, 그들은 또한 추가
MongoDB uses the LRU (Least Recently Used) cache algorithm to determine which "pages" to release, you will find some more information in these two questions - MongoDB 인덱스 / RAM 관계 : 인용문 :
MongoDB keeps what it can of the indexes in RAM. They'll be swaped out on an LRU basis. You'll often see documentation that suggests you should keep your "working set" in memory: if the portions of index you're actually accessing fit in memory, you'll be fine. - MongoDB에서 사용하는 캐싱을 해제하는 방법은 무엇입니까? : 5에서와 동일한 답변.
이제이 모든 대답에서 내가 이해하는 것처럼 보입니다.
- 빠른 액세스를 위해서는 mongo가 RAM의 모든 인덱스에 맞는 것이 좋습니다. 그러나 필자의 경우 SSD가 매우 빠르기 때문에 디스크에 부분적으로 인덱스가있는 것이 좋습니다.
- RAM은 주로 몽고에 의한 캐싱에 사용됩니다.
이것을 고려할 때 mongo는 가능한 한 많은 RAM 공간을 사용하려고 시도했지만 RAM 공간이 거의 없어도 기능을 수행하고 디스크에서 대부분의 것을 가져옵니다. 그러나, 나는 사용하여 (예를 들어 8 기가 바이트) 몽고 부두 노동자 컨테이너의 메모리를 제한 --memory하고 --memory-swap, 대신 디스크에서 물건을 가져 오는 중, 단지 즉시 메모리 부족으로 추락 몽고.
mongo가 사용 가능한 메모리 만 사용하도록하고 메모리에 맞지 않는 모든 것을 디스크에서 가져 오려면 어떻게해야합니까?
OOM 킬러라고합니다. MongoDB는 상용 하드웨어에서 실행되도록 설계되었습니다. 인위적으로 제한된 리소스에서는 절대로 실행하지 않습니다. 작은 데이터베이스 만있는 경우 MongoDB가 이상적인 선택이 아닙니다. 데이터베이스가 크면 (3 억 ~ 10 억 개 항목) 자원을 제한하는 것은 좋지 않은 선택입니다. 당신의 문제에 따라 : 당신은 케이크를 가지고 그것을 먹을 수 없습니다. 고르다.
—
Markus W Mahlberg
올바르게 구성되면 메모리 부족시 MongoDB가 충돌하지 않아야합니다. 사용중인 특정 버전의 MongoDB 서버 및 O / S를 확인하고 충돌을보다 자세히 설명 할 수 있습니까? 예를 들어, MongoDB 로그에 메시지가 있거나
—
Stennie
dmesg예기치 않은 종료와 관련이 있습니까? Docker의 가능성은 컨테이너의 프로세스가 컨테이너 제한이 아닌 사용 가능한 전체 RAM을 감지한다는 것입니다.
MongoDB 프로덕션 노트에 따르면 : 시스템에서 사용 가능한 모든 RAM에 액세스 할 수 없는
—
Stennie
mongod 컨테이너 ( lxc,, cgroupsDocker 등) 에서 실행하는 경우 사용 가능한 RAM 양보다 작은 값으로 설정해야합니다 컨테이너. 정확한 양은 컨테이너에서 실행중인 다른 프로세스에 따라 다르지만 일반적으로 RAM의 50 %-1GB를 넘지 않아야합니다. storage.wiredTiger.engineConfig.cacheSizeGB