일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Sekai Entertainment
- 신쥬쿠
- TOY
- 원탭바이
- Shimajirou
- しまじろう
- 시마지로
- paypay
- 일본
- 자동차
- 사이타마
- 전철
- 동경 모터쇼
- 칸칸
- 리눅스
- fish
- 영단어
- 명령어
- 米沢、팽이
- youtuber
- 돈까스
- 스테이크
- 토익
- one tab buy
- 라면
- 코라쿠엔
- 점심
- 여름
- 시스템관리
- 돼지갈비
- Today
- Total
IT Japan
PostgreSQL의 파라미터 튜닝 본문
PostgreSQL의 파라미터 튜닝을 해 보았다.
스택 별표 - PostgreSQL 성능 튜닝
All Aobut - PostgreSQL 튜닝
ThinkIT - PostgreSQL 튜닝 실천 기법
한 것은 다음의 매개 변수
1. postgresql.conf
· shared_buffers (공유 버퍼)
· sort_mem (정렬 메모리)
· wal_ buffers (트랜잭션 로그 버퍼)
· checkpoint_segments (체크 포인트 세그먼트)
· max_fsm_pages (FSM [Free Space Map))
2. shmmax (커널의 공유 메모리)
/ proc / sys / kernel / shmmax
/etc/sysctl.conf
이번에는 캐시 기능을 활용하여 캐시 적중률을 높이는 것이 큰 목적 이었기 때문에 다음 사이트의 단계에 따라 매개 변수에 넣어야 수치를 계산했다.
Stray Penguin - 성능 튜닝 (어탁)
메모리 관련 파라미터는 다루고있는 데이터베이스의 크기와 쿼리의 성격과 빈도 구현 메모리의 양 등에 따라 최적 값이 전혀 다르기 때문에 일률적으로는 말할 수 없지만 최적 값을 파악하는 데 황금률은있다. 정말 세상의 문서는 단편적이 작업을 포괄적으로 다룬 문서가없는 것 같았다 때문에 고생하고이를 정리에 이르렀다.
제 1 단계 : 작업 테이블 크기의 산출
테이블 전체에서 약 400,000KB
제 2 단계 : shared_buffers의 계산
shared_buffers = (테이블 크기 + 512K) / 버퍼 블록 크기
버퍼 1 블록의 크기는 8 K 바이트
400,512 / 8 = 약 50,000
제 3 단계 : 커널에서 shmmax 계산
ceil (250 K + (8.2 K * shared_buffers) + (14.2 K * max_connections))
ceil (250 K + (8.2 K * 50000) + (14.2 K * 32)) = 410700 KB
= 401 MB
= 476472934 Byte
제 4 단계 : 커널 shmall의 계산
$ ipcs -l
max total shared memory (kbytes) = 8388608
= 8192MB = 8GB
최종 단계 : 캐시 효과의 확인과 값의 조정
기본적으로는 1> 2> 3> 4
1 <2가 있지만 그래도 괜찮은 것 같다.
1. 구현 메모리
= 1GB × 4 = 4 GB
2. 시스템이 허용하는 공유 메모리의 총량
= shmall = 8 GB
3. 커널의 공유 메모리
= shmmax = 476472934 Byte = 401 MB
4. PostgreSQL의 공유 버퍼
= shared_buffers = 30,000 페이지 = 240 MB
것으로, 결국 다음 매개 변수를 이용.
1. postgresql.conf
· shared_buffers = 30000
· sort_mem = 4096
· wal_ buffers = 96
· checkpoint_segments = 16
· max_fsm_pages = 100000
2. shmmax (커널의 공유 메모리)
/ proc / sys / kernel / shmmax = 476472934
/etc/sysctl.conf → 476472934
것으로, 매개 변수를 설정 한 후 PostgreSQL을 다시 시작하여 캐시가 충분히 활성화되어 있는지를 디스크에서 읽어와 캐시에서로드가 각각 어느 정도인지에 확인!
사전에 파라미터 변경 전의 PostgreSQL의 통계 정보를 취득 해두고, 통계 카운터 값을 0으로하여 여러 쿼리를 흘려에서 다음 SQL에서 확인 해 본다.
SELECT relname AS TBL, heap_blks_read AS DSK, heap_blks_hit AS CASHE FROM pg_statio_user_tables;
변경 전까지는 디스크에서로드와 캐시에서로드가 반반 정도 였지만 파라미터 변경 후 테이블에 따라 약간의 차이는 있지만 캐시에서로드가 거의 95 % 이상이되었다.
잘 당초의 목적은 달성 할 수 있었다.
이것도 잘 정보를 모아 공개 해준 Stray Penguin 씨 덕분이다.
감사합니다.
'IT > PostgreSQL' 카테고리의 다른 글
pgpool-II 3.4의 신기능 (0) | 2016.04.10 |
---|---|
PostgreSQL의 날짜 계산 (0) | 2016.03.21 |
tmc_db01 backup 수순 (0) | 2016.03.21 |
postgresql.conf 기본적인 튜닝 (0) | 2016.03.21 |
PostgreSQL 8.3 이상에서 postgresql.conf를 서버 스펙에 따른 디폴트 값을 설정하여 성능 튜닝 (0) | 2016.03.21 |