PostgreSQL Meetup Seoul #2 밋업 후기

오늘 퇴근 후, PostgreSQL Meetup Seoul의 두 번째 밋업에 참석했다. 업무에서 PostgreSQL을 하드하게 사용하지는 않지만, 사내 시스템의 모든 DB가 PostgreSQL로 구성되어 있어 성능 이슈에 직면했을 때 어떻게 처리할 수 있을지 궁금해서 참여하게 되었다.

PosgreSQL을 하드하게 다뤄본적은 없지만, 필요한 부분만 얻어가려는 마음가짐으로 참석했다. 밋업에서는 저녁으로 샌드위치와 물을 제공해 줬다.

주요 내용

성능 이슈가 발생하는 이유는 다양했는데, 시스템 성능에 영향을 미치는 요인으로는 서버 스펙, 인프라, 시스템 아키텍처, WAS 구성, 데이터 모델링, DB 구성(파라미터), SQL 비효율 등이 있었다. 이번 세션에서는 주로 데이터베이스 영역인 DB 구성 및 SQL 튜닝에 대해서 다뤘다.

성능 관련 주요 DB 파라미터 튜닝 요소

이번 세션에서 가장 큰 소득은 성능 관련 주요 DB 파라미터 튜닝 요소를 배운 것이었다. 나머지 내용은 좀 더 딥한 부분이라 30분이라는 짧은 세션에 담기에는 부족했고, 나 또한 그 내용을 이해하기 위한 준비나 지식이 충분하지 않았다.

주요 DB 파라미터 튜닝 요소

항목영역 구분	파라미터 항목	기본값	비트나인 권장	설명
postmaster	max_connections	100	고객과 협의	데이터베이스 서버에 대한 최대 동시 연결 수를 결정합니다.
postmaster	shared_buffers	128MB	서버메모리 25~50%	서버에 사용할 공유 메모리 사이즈 (메모리의 25-50% 권장)
sighup	max_wal_size	1GB	50GB	WAL의 보관 유지 최대 사이즈를 설정합니다.
user	effective_cache_size	4GB	서버메모리의 50% 이상	디스크 캐시 크기에 대한 플래너가 작업할 메모리 설정, 높을수록 인덱스 스캔 가능성 향상 (가용 메모리의 50-75%)
user	maintenance_work_mem	64MB	서버메모리의 5%	유지 보수 작업(VACUUM, Create Index, Alter Table 등)에 사용할 메모리 사이즈 (사용 가능 메모리의 약 10% 권장)
user	work_mem	4MB	((서버메모리 - Shared_buffers) / max_connections) * 0.5	세션별 쿼리 작업에 사용할 최대 메모리 사이즈, 정렬 및 해시테이블에 사용 ((서버메모리 - Shared_buffers) / max_connections) * 0.5 권장
user	effective_io_concurrency	1	(HDD: 2, SSD: 200)	I/O 병렬 처리 가능성을 높이기 위한 설정
user	random_page_cost	4	(쿼리 유형에 따라 다름)	풀 스캔보다 인덱스 스캔을 유도하기 위해 cost 값을 낮추어 설정 (일반적으로 random_page_cost=2.0 또는 1.1로 설정하여 옵티마이저에게 인덱스 스캔을 더 유도하기 위함)
user	seq_page_cost	1	(쿼리 유형에 따라 다름)	인덱스 스캔보다 풀 스캔이 유리하다고 판단되는 경우 cost 값을 낮추어 설정
user	enable_partitionwise_join	off	on	파티션 성능 향상을 위해 파티션 조인을 활성화

모니터링

언제 성능 이슈가 발생하는지 어떤 기준으로 판단하는지도 궁금했었는데 모니터링 관련해서는 Top 유틸리티를 사용하여 CPU 및 메모리 점유율을 조회하고, 이를 바탕으로 자원 점유율이 높은 경우를 찾아내어 튜닝이 필요한지를 결정한다.

특히 데이터베이스 관련 문제에서는 문제가 되는 쿼리들을 분석하여 추가적인 최적화가 필요한지를 평가할 수 있다. 예를 들어, SQL 문의 실행 패턴을 분석하여 인덱스를 생성하거나 쿼리를 재작성하는 등의 최적화 방법을 고려할 수 있다.

후기

30분이라는 짧은 시간 동안 너무 광범위한 주제가 다뤄져서 아쉬웠다. 그래서 성능 이슈에 대한 세션에서는 프레젠테이션의 전체적인 완성도가 부족하다고 느꼈다. 그러나 성능 이슈가 발생했을 때 어떻게 모니터링하고, 튜닝, 인덱스 생성, 쿼리 재작성 등의 작업을 수행하는 방법에 대한 정보는 유익했다.

두 번째 세션은 PostgreSQL 17 베타에 대해 다루는 시간이었지만, 그 세션은 생략하였다. 개인적으로는 큰 관심이 없었고, 저녁 9시에 수영 시간이 있어서 운동을 한 후에 내용을 다시 정리하여 올린다. 시간이 부족해서 인적 네트워킹에 참여하지 못했지만, 다음에 기회가 되면 Python과 Django 주제의 컨퍼런스에 참여하고 싶다.