AlloyDB Omni를 시작할 때 공유 버퍼의 상한을 결정할 수 있습니다. 상한을 설정하지 않으면 AlloyDB Omni에서 공유 버퍼 백업 크기를 시스템 메모리의 80%로 자동 설정합니다. 공유 버퍼의 초기 백업 크기는 상한과 다를 수 있습니다.
AlloyDB Omni는 메모리 상태를 지속적으로 모니터링하고 데이터를 캐싱할 때 최적의 성능을 위해 공유 버퍼 백업 크기를 조정하는 지능형 메모리 작업자로 구성됩니다.
기본적으로 shared_buffers 파라미터는 0으로 설정됩니다. 이는 shared buffers 캐시 크기의 상한을 시스템 메모리의 80%로 설정하는 특수 값입니다. AlloyDB Omni는 shared_buffers 상한의 10%에서 시작합니다. shared_buffers가 커스텀 값으로 재정의되면 AlloyDB Omni는 해당 값을 shared_buffers 크기의 상한으로 간주하고 지정된 커스텀 크기로 시작합니다.
커스텀 크기를 지정하려면 postgresql.conf 구성 파일을 수정합니다. 예를 들어 다음 중 하나를 사용하여 shared_buffers를 1GB로 설정할 수 있습니다.
docker run --name CONTAINER_NAME -e INITDB_ARGS="-c shared_buffers=1GB" $image
docker run --name CONTAINER_NAME $image -c shared_buffers=1GB
CONTAINER_NAME을 AlloyDB Omni 컨테이너를 설치할 때 할당한 이름으로 바꿉니다.
쿼리 성능 최적화
shared_buffers 파라미터의 기본값은 일반적인 시나리오에서 작동합니다.
하지만 최적의 성능을 위해 값을 조정할 수 있습니다.
shared_buffers의 기본값을 사용하여 공유 버퍼 상한을 추론하는 경우 cgroup memory.max 값을 사용하여 계산에 영향을 줍니다.
열 기반 엔진 메모리
동적 shared_buffers는 열 기반 엔진 메모리와 독립적입니다. 열 기반 엔진이 사용 설정된 경우 동적 shared_buffers 크기는 시스템 또는 cgroup에서 사용할 수 있는 총 메모리의 80%에서 열 기반 엔진이 사용한 메모리 양을 빼서 구할 수 있습니다.
Huge Page
Huge Page는 데이터베이스 성능을 개선합니다. AlloyDB Omni는 가능하면 명시적으로 Huge Page를 관리하고, 그렇지 않은 경우 운영체제의 Transparent Huge Page(THP) 기능을 사용합니다. 지원되는 Huge Page 유형이 없는 경우 AlloyDB Omni가 4k 페이지로 되돌아가고 Docker 컨테이너 로그 docker logs $container_name에 Huge Page를 설정하는 구체적인 안내와 함께 경고가 출력됩니다. 컨테이너를 시작하는 방법은 AlloyDB Omni 시작을 참조하세요.
경고는 다음과 유사합니다.
HINT: Please either execute the all-in-one setup script:
docker run --rm --privileged $image setup-host
OR manually execute:
echo within_size | sudo tee /sys/kernel/mm/transparent_hugepage/shmem_enabled
sudo sysctl -w vm.nr_overcommit_hugepages=1048576
런타임 시 자동 메모리 관리
AlloyDB Omni는 시스템 부하를 지속적으로 모니터링하고 성능 향상을 위해 메모리 소비를 조정합니다. 구체적으로 다음과 같은 동작이 발생할 수 있습니다.
동적 shared_buffers 크기 변경
AlloyDB Omni는 시스템 메모리 소비량이 낮을 때 동적 shared_buffers 크기를 늘리고 시스템 메모리 소비량이 높을 때 크기를 줄입니다. 동적 shared_buffers 크기를 모니터링하려면 다음을 사용하세요.
AlloyDB Omni는 시스템의 메모리가 매우 부족한 것을 감지하면 부하가 적절한 수준으로 되돌아갈 때까지 메모리 소비가 가장 많은 PostgreSQL 연결을 삭제하려고 시도합니다. 이러한 이벤트가 발생하면 AlloyDB Omni는 Docker 컨테이너 로그에 다음을 로깅합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-03(UTC)"],[[["\u003cp\u003eAlloyDB Omni employs adaptive algorithms to manage memory, dynamically adjusting the shared buffer size for optimal performance.\u003c/p\u003e\n"],["\u003cp\u003eThe default shared buffer upper limit is 80% of system memory, but it starts at 10% of the limit and can be customized in the \u003ccode\u003epostgresql.conf\u003c/code\u003e file.\u003c/p\u003e\n"],["\u003cp\u003eAn intelligent memory worker monitors memory status and tunes the shared buffer backing up size to enhance data caching performance.\u003c/p\u003e\n"],["\u003cp\u003eWhen the columnar engine is enabled, the dynamic shared buffer size is derived by subtracting the columnar engine memory from 80% of the available memory.\u003c/p\u003e\n"],["\u003cp\u003eAlloyDB Omni optimizes memory usage at runtime by increasing the dynamic shared buffer size during low system load and decreasing it during high system load, and in extreme cases terminates memory-intensive PostgreSQL connections.\u003c/p\u003e\n"]]],[],null,["# About automatic memory management\n\nSelect a documentation version: 15.7.0keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/automatic-memory-management)\n- [16.8.0](/alloydb/omni/16.8.0/docs/automatic-memory-management)\n- [16.3.0](/alloydb/omni/16.3.0/docs/automatic-memory-management)\n- [15.12.0](/alloydb/omni/15.12.0/docs/automatic-memory-management)\n- [15.7.1](/alloydb/omni/15.7.1/docs/automatic-memory-management)\n- [15.7.0](/alloydb/omni/15.7.0/docs/automatic-memory-management)\n- [15.5.5](/alloydb/omni/15.5.5/docs/automatic-memory-management)\n- [15.5.4](/alloydb/omni/15.5.4/docs/automatic-memory-management)\n\n\u003cbr /\u003e\n\nAlloyDB Omni uses adaptive algorithms for memory management.\n\n\u003cbr /\u003e\n\nYou can decide the upper limit of the shared buffer on starting AlloyDB Omni. If you don't set the upper limit, AlloyDB Omni automatically sets the shared buffer backing up size to 80% of system memory. The initial backing up size of the shared buffer can be different from the upper limit.\n\nAlloyDB Omni consists of an intelligent memory worker which constantly monitors the memory status, and tunes shared buffer backing up size for best performance when caching data.\n\nBy default the `shared_buffers` parameter is set to `0` which is a special value that sets the upper limit of the size of the `shared buffers` cache to 80% of system memory. AlloyDB Omni starts at 10% of the `shared_buffers` upper limit. If `shared_buffers` is overridden by a custom value, then AlloyDB Omni respects the value as the upper limit of the `shared_buffers` size, and starts with that specified custom size.\n| **Note:** Memory worker can still decide to shrink, and later grow shared buffer backing up size at runtime.\n\nTo specify a custom size, edit the `postgresql.conf` configuration file. For example, you can set `shared_buffers` to `1GB` using either of the following:\n\n- `docker run --name `\u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e` -e INITDB_ARGS=\"-c shared_buffers=1GB\" $image`\n\n- `docker run --name `\u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e` $image -c shared_buffers=1GB`\n\n Replace \u003cvar translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e with the name that you assigned to the AlloyDB Omni container when you installed it.\n\nOptimize query performance\n--------------------------\n\nThe default value of the `shared_buffers` parameter works for common scenarios.\n\nHowever, you can tune the value for best performance.\nIf you choose to rely on the default value of `shared_buffers` to deduce the shared buffer upper limit, then use the cgroup `memory.max` value to influence the computation.\n\nColumnar engine memory\n----------------------\n\nThe dynamic `shared_buffers` is independent of the [columnar engine memory](/alloydb/omni/15.7.0/docs/columnar-engine/configure). When the columnar engine is enabled, the dynamic `shared_buffers` size can be derived by subtracting the amount of memory used by the columnar engine from 80% of the total memory available to the system or cgroup.\n\nHuge pages\n----------\n\nHuge pages improve database performance. AlloyDB Omni manages huge pages explicitly if possible, otherwise it relies on the transparent huge pages (THP) feature of the operating system. If neither huge page type is supported, AlloyDB Omni falls back to 4k page, and prints a warning in docker container logs `docker logs $container_name` with specific instructions to set up huge pages. See [Start AlloyDB Omni](/alloydb/omni/15.7.0/docs/run-connect#start) for instructions how to start a container.\n\nThe warning looks similar to the following: \n\n HINT: Please either execute the all-in-one setup script:\n docker run --rm --privileged $image setup-host\n OR manually execute:\n echo within_size | sudo tee /sys/kernel/mm/transparent_hugepage/shmem_enabled\n sudo sysctl -w vm.nr_overcommit_hugepages=1048576\n\nAutomatic memory management at runtime\n--------------------------------------\n\nAlloyDB Omni constantly monitors the system load, and adjusts its memory consumptions for better performance. Specifically, you might observe the following:\n\n**Dynamic `shared_buffers` size change**\n : AlloyDB Omni increases the dynamic `shared_buffers` size when the system memory consumption is low, and decreases the size when the system memory consumption is high. To monitor the dynamic `shared_buffers` size, use: \n\n ```bash\n CREATE EXTENSION IF NOT EXISTS g_memory;\n SELECT g_dynamic_shared_size();\n ```\n\n**Termination of a PostgreSQL connection when the system is extremely low on memory**\n : When AlloyDB Omni detects that the system is extremely low on memory, it attempts to delete the most memory-consuming PostgreSQL connections until the load falls back to a reasonable level. When such an event happens, AlloyDB Omni logs the following in docker container logs: \n\n ```bash\n WARNING: Sending SIGTERM to pid=xxx NSpid=xxx (VA size = xxxMB) (RSS size = xxxMB)\n ```"]]
