db_shared_buffers(총 RAM의 0.1%)와 db_work_mem(총 RAM의 0.03%) 값을 늘릴 수 없습니다

[markersocial]

좀 골치 아픈 문제입니다

새 서버에 방금 이주한 Discourse 인스턴스를 가지고 있습니다.

로그에서 다음과 같은 오류가 발생합니다: PG::DiskFull (ERROR: could not resize shared memory segment "/PostgreSQL.1759815625" to 8388608 bytes: No space left on device )

기존 서버(64GB RAM)에서는 이 문제가 없었는데, 당시 설정은 다음과 같았습니다:

db_shared_buffers: "25632MB"
db_work_mem: "160MB"

새 서버(128GB RAM)에서는 기본값 이상으로 높일 수 없습니다(아래 값을 3배로 올려봤지만 동일한 PG DiskFull 오류가 발생했습니다):

db_shared_buffers: "128MB"
db_work_mem: "40MB"

기존 머신에는 discourse 설치 프로그램으로 자동 설치된 docker 27.x가 설치되어 있습니다. 새 머신에는 지침에 따라 docker.io(26.x)를 설치했습니다. 관련이 있는지 확인하기 위해 docker 27.x로 전환해 보았지만 아무것도 바뀌지 않았습니다. 두 서버 모두 Stable Discourse 브랜치의 3.3.2 버전을 사용하고 있습니다.

shm_size가 주요 원인인 것 같습니다:

PG throws could not resize shared memory segment error

This is due to the fact that docker by default restricts shared memory size to 64MB which makes pg10 run afoul of this limitation when doing a number of scatter/gather jobs in parallel: Outside the container: supermathie@host: ~ $ df -h /dev/shm Filesystem Size Used Avail Use% Mounted on none 63G 1.2M 63G 1% /run/shm Inside the container: supermathie@host: ~ $ docker exec -it postgres-master df -h /dev/shm Filesystem Size Used Avail Use% Mounted on shm …

하지만 이전 서버에서는 문제가 없었는데 새 서버에서는 왜 문제가 되는지 모르겠습니다. 다른 주요 차이점은 기존 서버가 Ubuntu 22.04 LTS를 사용하고, 새 서버는 24.04 LTS를 사용한다는 것입니다.

다음도 시도해 보았지만, 컨테이너를 다시 시작하면 변경 사항가 덮어쓰기 됩니다.

app.yml의 Docker shm_size 옵션

Hey @Ghan In the meantime (for testing purposes, see caveat below), you can change this directly with docker after the container is built, as follows: Edit the /var/lib/docker/containers/$CONTAINER_ID/hostconfig.json file directly. For example, change the value for ShmSize in the file above. Stop and restart the container. In our docker container hostconfig file, it looks like this: "ShmSize":536870912, [Screen Shot 2020-12-29 at 12.39.17 PM] HTH Caveat: Some people have posted that y…

shm_size는 launcher에 하드코딩되어 있는 것으로 보입니다:

launcher

launcher

launcher

어떤 통찰이나 도움이 있다면 감사하겠습니다!

[pfaffman (Jay Pfaffman)]

@markersocial

: 디바이스에 남은 공간이 없습니다

RAM이 아니라 하드 드라이브 공간을 의미합니다.

[markersocial]

@pfaffman

RAM이 아니라 하드 드라이브 공간을 의미합니다.

@pfaffman 감사합니다. 처음에는 저도 그렇게 생각했지만, 이 스레드를 읽게 되었습니다:

PG throws could not resize shared memory segment error

After upgrading (with ‘launcher rebuild app’ times two) to Postgres 10, we’ve started seeing errors like this in /logs: Failed to handle exception in exception app middleware : PG::DiskFull: ERROR: could not resize shared memory segment "/PostgreSQL.682207201" to 283432 bytes: No space left on device : SELECT "topics"."id" AS t0_r0, "topics"."title" AS t0_r1, "topics"."last_posted_at" AS t0_r2, … Ideas? Looks like PG is unable to increase the size of a shared memory segment, can this be tuned …

여기에도 사용 가능한 공간이 많이 있습니다

[markersocial]

간단한 임시 조치는 다음과 같이 런처 파일을 편집하는 것입니다:

cd /var/discourse
vi launcher

그런 다음 --shm-size=512m의 모든 3개 발생 위치를 원하는 RAM 양으로 교체하세요(저는 시스템 RAM의 50%를 사용했습니다).

그 후 다시 빌드해야 합니다. 런처가 업데이트될 때마다 다시 편집해야 합니다.

그동안 이 방법으로 잘 작동하는 것 같습니다.

[markersocial]

@mcdanlj

커널 구성

Redis(Discourse의 핵심 구성 요소 중 하나)는 디스크 기반 영속성을 사용할 경우 투명한 거대 페이지(transparent huge pages)를 비활성화하는 것을 강력히 권장하며(Discourse는 이를 사용합니다), 저도 메모리 오버커밋을 허용하도록 설정했습니다.

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system

혹시 다른 분들도 이 문제를 겪고 계실 수 있어 후속으로 공유드립니다. 위 방법으로 제 문제는 해결되었습니다. 이제 더 이상 launcher에서 shm-size를 수정할 필요가 없습니다.

재빌드 중 다음과 같은 경고를 확인한 후 이 해결책을 찾았습니다:
WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.