PostgreSQL에서 Matrix Synapse의 높은 데이터베이스 메모리 사용량 문제를 해결하세요

Matrix Synapse 홈서버는 며칠 동안 정상적으로 작동하다가 갑자기 PostgreSQL이 시스템의 가용 RAM 대부분을 소모하는 현상이 발생할 수 있습니다. 흔히 나타나는 증상은 다음과 같습니다. 스왑 영역이 커지고, 클라이언트 동기화 속도가 느려지며, 페더레이션 작업이 대기열에 쌓이고, 그렇지 않아도 괜찮은 서버조차 관리하기 어려워집니다. 가장 먼저 해야 할 일은 PostgreSQL에 메모리 누수가 있다고 단정짓지 않는 것입니다. 높은 메모리 사용량은 공유 버퍼 캐시, 쿼리별 작업 메모리, 여러 데이터베이스 백엔드, 유지 관리 작업자, 그리고 오래된 통계나 테이블 변경으로 인한 비효율적인 쿼리 등 여러 가지 독립적인 원인에서 비롯될 수 있습니다.

cp_minSynapse 자체 문서에서는 프로덕션 환경에 PostgreSQL 사용을 권장하며, `connectionpool` 및 `connectionpool`과 같은 데이터베이스 연결 풀 제어 기능을 제공합니다 cp_max. 하지만 PostgreSQL은 `connectionpool`과 같은 설정이 work_mem하나의 쿼리 내에서 여러 작업에 사용될 수 있고, 동시에 여러 세션에서 사용될 수 있다고 경고합니다. 이러한 이유로 개별적으로는 문제가 없어 보이는 설정이라도 사용량이 많은 시간대에는 비용이 많이 발생할 수 있습니다. 가장 안전한 해결책은 먼저 사용량을 측정하고, 불필요한 동시성을 줄인 다음, 필요한 경우에만 메모리 및 유지 관리 동작을 조정하는 것입니다.

1단계: PostgreSQL이 실제로 메모리 부족의 원인인지 확인합니다.

운영체제 수준에서 시작해 보세요. 리눅스에서는 총 메모리, 사용 가능한 메모리, 스왑 공간, 그리고 가장 큰 프로세스를 비교해 보세요.

free -h
ps aux --sort=-%mem | head -n 15

단일 프로세스 라인만으로 서버를 판단하지 마십시오. PostgreSQL은 백엔드 프로세스에서 공유 메모리와 개인 메모리를 모두 사용하므로, 호스트에 실제로 부하가 걸리고 있는지(예: 사용 가능한 메모리 부족, 스왑 영역 증가, OOM(메모리 부족)으로 인한 프로세스 종료, 지속적인 지연)를 파악하는 것이 중요합니다. 사용량이 적은 시간대와 많은 시간대에 각각 수치를 기록하십시오. 이렇게 기준선을 설정하면 나중에 변경 사항을 추측이 아닌 측정 가능한 근거로 활용할 수 있습니다.

설명: 초기 메모리 점검에서는 구성 변경 전에 호스트 수준에서 사용 가능한 RAM과 PostgreSQL 및 Synapse 프로세스의 메모리 사용량을 비교합니다.

다음으로 메모리 사용량에 영향을 줄 가능성이 가장 높은 PostgreSQL 설정을 확인하십시오.

SHOW shared_buffers;
SHOW work_mem;
SHOW maintenance_work_mem;
SHOW autovacuum_work_mem;
SHOW max_connections;

PostgreSQL 리소스 사용량 관련 문서에서는 핵심적인 차이점을 설명합니다. ` shared_bufferscatch`는 서버 전체에서 공유되는 캐시입니다. 이와 대조적으로 `catch`는 work_mem개별 정렬 또는 해시 작업이 임시 파일로 저장되기 전에 사용할 수 있는 최대 용량입니다. 복잡한 쿼리에는 이러한 작업이 여러 개 포함될 수 있으며, 여러 세션에서 동시에 실행될 수 있습니다. PostgreSQL은 현재 기본값으로 4MB를 명시하고 있으며 work_mem, 실제 사용량은 이 값의 몇 배에 달할 수 있다고 설명합니다.

캡션: PostgreSQL의 메모리 관련 설정을 변경하기 전에 현재 활성화된 설정을 읽어보세요. 위험한 값은 단일 수치보다는 설정값과 동시 실행 횟수의 조합인 경우가 많습니다.

2단계: Synapse 데이터베이스 연결 수를 세고 활성 작업을 찾습니다.

연결 풀 규모가 크다고 해서 모든 연결에 대해 메모리가 자동으로 소모되는 것은 아닙니다 work_mem. 하지만 각 PostgreSQL 백엔드는 자체 프로세스와 전용 메모리를 가지고 있으며, 동시 쿼리가 많을수록 작업별 메모리 할당량이 늘어날 가능성이 높아집니다. 실제로 열려 있는 연결 수와 각 연결의 상태를 확인해 보세요.

SELECT state,
       usename,
       application_name,
       count(*) AS connections
FROM pg_stat_activity
GROUP BY state, usename, application_name
ORDER BY connections DESC;

다음으로 장시간 실행되는 활성 쿼리를 검사하십시오.

SELECT pid,
       usename,
       state,
       now() - query_start AS running_for,
       wait_event_type,
       wait_event,
       left(query, 180) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY query_start;

공식 문서에는 세션pg_stat_activity 및 활동 필드에 대한 설명이 있습니다. 유휴 세션 수가 많은 것과 메모리를 많이 사용하는 활성 쿼리 수가 적은 것은 다르므로 해결 방법도 달라야 합니다. 문제가 연결 수라면 주소 풀 크기를 조정하십시오. 문제가 메모리를 많이 사용하는 몇몇 쿼리 때문이라면 주소 풀 크기만 줄이는 것은 증상만 가릴 뿐일 수 있습니다.

캡션: 그룹화를 통해 pg_stat_activity유휴 상태인 다수의 백엔드와 활성 상태인 소수의 데이터베이스 세션을 쉽게 구분할 수 있습니다.

3단계: Synapse PostgreSQL 연결 풀의 크기를 적절하게 조정합니다.

Synapse는 Twisted 연결 풀에서 로 시작하는 옵션을 사용할 때 대부분의 데이터베이스 인수를 PostgreSQL에 전달합니다 cp_. 현재 Synapse PostgreSQL 가이드에는cp_min: 5 와 를 사용한 예시가 나와 있습니다 cp_max: 10. 이러한 값은 예시일 뿐이며, 모든 경우에 적용되는 일반적인 값이 아닙니다.

database다음 블록을 확인하세요 homeserver.yaml:

database:
  name: psycopg2
  args:
    user: synapse_user
    password: "your-secret"
    dbname: synapse
    host: 127.0.0.1
    cp_min: 5
    cp_max: 10

cp_max이전에 Synapse 연결 수를 급격히 늘려 pg_stat_activity대부분 유휴 상태인 연결 수가 많아지는 경우 , 연결 수를 점진적으로 줄이고 요청 지연 시간을 관찰하십시오. 워커 기반 Synapse 배포 환경에서는 데이터베이스 수요가 여러 Synapse 프로세스에서 발생하므로, 개별 워커 프로세스의 연결 수만 고려하기보다는 전체 연결 수를 평가해야 합니다. Synapse 구성 설명서를 참조cp_ 하면 해당 옵션으로 연결 풀을 구성할 수 있음 을 알 수 있습니다 .

설정을 편집한 후에는 배포 방법에 따라 해당 Synapse 프로세스를 다시 시작하고 연결 수 쿼리를 다시 실행하십시오. 몇 메가바이트를 절약하기 위해 요청이 대기열에 쌓이기 시작할 때까지 연결 풀 크기를 줄이지 마십시오. 연결 풀 크기가 너무 작으면 데이터베이스 동시성이 애플리케이션 지연으로 이어질 수 있습니다.

캡션: Synapse는 PostgreSQL 데이터베이스 구성에서 `concurrent` 옵션을 노출하여 관리자가 불필요한 백엔드 동시 실행을 제한할 수 있도록 합니다 cp_min.cp_max

4단계: PostgreSQL 메모리를 보수적으로 튜닝합니다.

연결 수가 적정 수준에 도달하면, 실제로 데이터베이스에서 사용 가능한 RAM 용량을 고려하여 PostgreSQL 메모리 설정을 검토하십시오. PostgreSQL에서는 최소 1GB의 RAM이 장착된 전용 데이터베이스 서버에서 시스템 메모리의 약 25%를 적절한 시작점으로 권장합니다 shared_buffers. 이 지침은 전용 데이터베이스 서버에 대한 것입니다. Synapse, 리버스 프록시, Redis, 모니터링 시스템 및 PostgreSQL이 하나의 작은 가상 머신을 공유하는 경우, PostgreSQL이 전체 머신을 사용하는 것이 아니므로 이에 맞춰 메모리 용량을 조정해야 합니다.

관리자들이 가장 놀랄 만한 설정은 바로 `sudo sudo`입니다 work_mem. `sudo sudo`를 곱해서 하드 예약처럼 사용하는 것은 피해야 합니다 work_mem. max_connectionsPostgreSQL은 그런 식으로 메모리를 미리 할당하지 않습니다. 대신, 동시 쿼리 작업 수를 고려해야 합니다. 단일 쿼리에서 여러 정렬 노드나 해시 노드를 사용할 수 있으며, 해시 연산은 `sudo sudo`의 배수를 사용할 수 있습니다 work_mem. 만약 특정 보고서의 처리 속도가 느리다는 이유로 `sudo sudo`를 전역적으로 매우 큰 값으로 설정하면 work_mem, 페더레이션 버스트나 동기화 작업이 많은 기간 동안 예상보다 훨씬 큰 메모리 사용량 급증이 발생할 수 있습니다.

합리적인 패턴은 전역 값을 보수적으로 유지하고, 알려진 쿼리가 더 많은 메모리를 필요로 할 때 특정 관리 세션에 대해서만 값을 높이는 것입니다. 값을 변경하기 전에 기존 구성을 보존하고 PostgreSQL 재시작이 필요한 매개변수를 기록해 두십시오. shared_buffers예를 들어, 는 서버 시작 설정입니다. 변경 사항은 예약하여 변경 전후의 메모리 사용량, 지연 시간 및 임시 파일 동작을 비교할 수 있도록 해야 합니다.

또한, `autovacuum` maintenance_work_mem및 ` autovacuum` 설정을 확인하십시오 autovacuum_work_mem. PostgreSQL에서는 자동 진공 청소(autovacuum) 작업자가 유지 관리 메모리를 동시에 할당할 수 있다고 명시하고 있습니다. ` autovacuum` autovacuum_work_mem설정을 기본 동작으로 유지하면 비정상적으로 큰 ` maintenance_work_memautovacuum` 값으로 인해 여러 자동 진공 청소 작업자가 동시에 실행될 경우 비용이 많이 발생할 수 있습니다. RAM을 절약하기 위해 자동 진공 청소를 비활성화하지 마십시오. 일반적으로 단기적인 메모리 절약 효과를 얻는 대신 테이블 크기 증가, 오래된 통계 데이터, 그리고 성능 저하를 초래할 수 있습니다.

5단계: 진공청소기의 상태를 점검한 후 실제 부하 상태에서 수정 사항이 제대로 적용되었는지 확인합니다.

Synapse는 대량의 이벤트 및 상태 데이터를 기록하고 업데이트합니다. PostgreSQL은 재사용을 위해 사용되지 않는 튜플을 회수하고 플래너 통계를 최신 상태로 유지하기 위해 정기적인 vacuum 작업이 필요합니다. PostgreSQL 정기 vacuum 작업 가이드에서는 대부분의 설치 환경에서 autovacuum 사용을 권장합니다.

삭제된 것으로 추정되는 튜플이 많거나 유지 관리 타임스탬프가 오래된 테이블을 찾아보세요.

SELECT relname,
       n_live_tup,
       n_dead_tup,
       last_autovacuum,
       last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

특정 테이블에 명확한 수정이 필요한 경우, 일반적 VACUUM (ANALYZE)으로 가장 먼저 고려해야 할 수동 도구는 정규화된 분석입니다.

VACUUM (ANALYZE) your_table_name;

VACUUM FULLVACUUM 공식 참조 문서 에 따르면 일반 VACUUMVACUUM 작업은 일반 읽기 및 쓰기 작업과 함께 실행될 수 있지만, VACUUM 작업은 VACUUM FULL테이블을 다시 쓰고 락을 획득합니다 . 디스크 공간을 확보하는 것이 계획된 중단을 감수 ACCESS EXCLUSIVE할 만한 가치가 있을 때만 후자를 사용하십시오.

변화가 실제로 효과가 있었는지 어떻게 알 수 있을까요?

문제를 일으켰던 것과 동일한 작업 부하에서 결과를 검증하십시오. 단순히 "Postgres의 RAM 사용량이 즉시 줄어드는 것"만으로 문제가 해결된 것은 아닙니다. 데이터베이스 캐시는 메모리를 사용하도록 설계되어 있습니다. 따라서 안정적인 가용 메모리, 예상치 못한 스왑 증가가 거의 없거나 전혀 없는지, OOM(메모리 부족) 이벤트가 발생하지 않는지, 연결 수가 예상 동시 접속 수와 일치하는지, 그리고 Synapse 응답 시간이 허용 가능한 수준인지 확인하십시오.

• 기준선에 사용된 것과 동일한 트래픽 수준에서 실행 free -h및 프로세스 목록을 확인합니다.
• 연결 쿼리를 다시 실행하고 pg_stat_activitySynapse 풀을 변경했을 경우 유휴 백엔드 수가 감소했는지 확인하십시오.
• 설정을 낮춘 후 쿼리 및 동기화 지연 시간을 모니터링하고 cp_max, 데이터베이스 대기 시간이 눈에 띄게 증가하면 변경 사항을 되돌리십시오.
• pg_stat_user_tables자동 진공 청소 기능이 실제로 손님이 많은 테이블을 방문하는지 시간이 지남에 따라 확인하십시오 .
• 만약 값을 낮췄다면 work_mem, 더 낮추기 전에 대규모 정렬 작업이 임시 파일로 과도하게 유출되는지 모니터링하십시오.

이러한 점검 후에도 호스트 스왑이 심하게 발생할 정도로 PostgreSQL 메모리 사용량이 계속 증가한다면, 전역 메모리 제한을 반복적으로 줄이는 대신 사용량 급증 시점의 활성 쿼리 목록을 캡처하여 워크로드를 조사하십시오. 지원되는 PostgreSQL 버전에서는 pg_backend_memory_contexts현재 백엔드의 메모리 컨텍스트를 검사할 수 있습니다. PostgreSQL 시스템 뷰 설명서 에서 해당 뷰와 권한에 대한 정보를 확인할 수 있습니다. 이는 모든 메모리 사용량이 높은 Synapse 배포 환경의 원인이 동일하다고 가정하는 것보다 데이터베이스 문제를 집중적으로 조사하는 데 더 유용합니다.

결론적으로

PostgreSQL 기반 Matrix Synapse에서 높은 데이터베이스 메모리 사용량을 해결하는 가장 안전한 방법은 여러 단계에 걸쳐 관리하는 것입니다. 호스트에 실제 메모리 부족 현상이 있는지 확인하고, 데이터베이스 세션 수를 계산하고, Synapse의 메모리 풀 크기를 적절하게 조정하고, PostgreSQL의 작업별 메모리 사용량을 보수적으로 유지하고, 자동 메모리 정리(autovacuum)가 정상적으로 작동하는지 확인해야 합니다. 목표는 PostgreSQL의 메모리 사용량을 최소화하는 것이 아니라, 정상적인 데이터베이스 캐싱과 동시성 처리가 불필요한 스왑, 메모리 부족(OOM) 이벤트 또는 Matrix 클라이언트 속도 저하로 이어지지 않도록 예측 가능한 메모리 사용량을 유지하는 것입니다.