database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
ㆍPostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
PostgreSQL Q&A 8702 게시물 읽기
No. 8702
postgresql 성능 하락
작성자
nowplace
작성일
2010-08-30 16:14
조회수
16,265

안녕하세요

postgresql를 사용하는데 프로그램을 돌리면서 장시간 스트레스 테스트를 하다가 보면 심한 성능하락이 발생합니다.

이것을 해결할수 있는 방법이 있을까요

vacuumdb -a -z
클린을 시켜 줘도 그때 뿐이고 근본적인 해결은 안되었습니다.

시스템 성능은 cpu z510 램 1G 하드 160G 입니다.

조언 부탁 드립니다.

top - 16:12:22 up 4 days,  6:22,  6 users,  load average: 6.89, 6.05, 5.23
Tasks: 130 total,   6 running, 119 sleeping,   0 stopped,   5 zombie
Cpu(s): 50.0%us, 48.1%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.9%si,  0.0%st
Mem:   1029472k total,  1013272k used,    16200k free,    19192k buffers
Swap:        0k total,        0k used,        0k free,   861640k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7187 postgres  16   0 22888  11m  10m S 75.4  1.1 109:18.87 postmaster
7186 postgres  15   0 22896  11m  10m S  2.9  1.1 335:44.15 postmaster
 5027 postgres  15   0 23452  11m  10m S  1.9  1.1  25:06.83 postmaster     

 

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0      0  15604  19124 860820    0    0     0    32 1050 3443 53 44  0  3  0
 6  0      0  15480  19124 860924    0    0     0    24 1041 3425 58 42  0  0  0
 3  0      0  15356  19124 861028    0    0     0   168 1013 2559 54 46  0  0  0
 2  0      0  15108  19124 861140    0    0     0    32 1053 3515 54 46  0  0  0
 1  0      0  15108  19132 861236    0    0     0  1124  746 1508 40 60  0  0  0
 6  0      0  14860  19132 861328    0    0     0    24 1062 3299 55 45  0  0  0
 2  0      0  14860  19132 861432    0    0     0    32 1041 3216 48 51  0  1  0
 3  0      0  14736  19132 861572    0    0     0   256  998 2955 52 47  0  1  0
 6  0      0  14612  19132 861728    0    0     0    24 1051 3416 54 44  0  2  0
19  1      0  14488  19140 861832    0    0     0   956 1040 2566 44 53  0  3  0
 2  1      0  14364  19140 861936    0    0     0    40 1041 3420 51 49  0  0  0
 1  0      0  14240  19140 862076    0    0     0    24 1062 3373 53 46  0  1  0
 3  0      0  14116  19140 862180    0    0     0   112 1035 3358 54 46  0  0  0
 6  0      0  13992  19140 862288    0    0     0    24 1058 3263 53 44  0  3  0
 5  0      0  13868  19140 862444    0    0     0    32 1059 3453 56 44  0  0  0
 3  0      0  13868  19148 862488    0    0     0  1048  778 1607 45 55  0  0  0
 3  0      0  13744  19148 862644    0    0     0    32 1045 2932 55 45  0  0  0
 1  0      0  13620  19148 862748    0    0     0    24 1055 3269 53 47  0  0  0
 1  0      0  13496  19148 862900    0    0     0    32 1043 3490 56 44  0  0  0
10  0      0  13248  19148 863004    0    0     0    24 1056 3474 52 46  0  2  0
15  0      0  13248  19148 863084    0    0     0  1132 1021 1836 48 52  0  0  0
 8  0      0  13124  19152 863236    0    0     0    56 1049 3216 53 47  0  0  0
 4  0      0  12972  19152 863340    0    0     0    48 1049 3356 54 46  0  0  0
 3  0      0  16276  19096 860072    0    0     0   148 1015 2722 54 46  0  0  0
 4  0      0  16276  19096 860208    0    0     0    48 1039 3454 56 44  0  0  0
 3  0      0  16220  19096 860324    0    0     0    48 1039 3506 52 47  0  1  0
 5  0      0  15848  19108 860416    0    0     0  1108  759 1789 42 58  0  0  0
 8  0      0  16348  19140 860516    0    0     0   524  929 2499 49 51  0  0  0
 5  0      0  16472  19140 860620    0    0     0    56 1043 3230 54 46  0  0  0
 1  0      0  16472  19140 860780    0    0     0   248 1041 3172 51 49  0  0  0
 1  0      0  16472  19140 860884    0    0     0    24 1058 2718 57 43  0  0  0
 1  0      0  16348  19140 860992    0    0     0    48 1051 3423 51 46  0  3  0
17  0      0  16224  19148 861140    0    0     0  1184  933 2160 44 56  0  0  0
 3  0      0  16224  19148 861220    0    0     0    48 1048 3375 51 48  0  1  0
 6  0      0  15976  19148 861376    0    0     0    88 1029 3319 54 46  0  0  0
 1  0      0  15976  19148 861488    0    0     0    48 1053 3286 55 45  0  0  0
11  1      0  15232  19152 861588    0    0     0  1020  914 2032 43 57  0  0  0
 2  0      0  15232  19156 861716    0    0     0    68 1060 2800 56 44  0  0  0
 4  0      0  15232  19156 861872    0    0     0    72 1031 3310 54 46  0  0  0
 2  0      0  15232  19156 861988    0    0     0    24 1070 3409 54 46  0  0  0
 3  0      0  15232  19156 862092    0    0     0   232  998 3172 52 48  0  0  0
 3  0      0  15108  19156 862248    0    0     0    40 1062 3471 53 45  0  2  0
 1  0      0  14984  19164 862332    0    0     0   992  803 1691 46 54  0  0  0
 3  0      0  14860  19168 862432    0    0     0    24 1052 3360 55 44  0  1  0
 3  0      0  13124  19200 862480    0    0     0   892  816 1849 40 55  0  4  0
 

이 글에 대한 댓글이 총 4건 있습니다.

스트레스 테스트를 어떤식으로 진행하시나요? 단순 입력이라면 설정 조정으로 성능이 크게 향상될 수 있습니다.

WAL 관련된 설정을 조정해 보시면 입력 속도는 크게 나아질 수 있습니다.

WAL을 데이터 파일에 반영하는 동안 입력 속도가 낮아질 수 있는데 이 부분은 물리적인 디스크의 속도와 파일시스템의 종류에 따라 역시 크게 달라질 수 있습니다.

신기배(소타)님이 2010-08-31 13:15에 작성한 댓글입니다.

답변 감사 드립니다.

일단 빈번한 update 및 insert를 연속적으로 발생시키는 프로그램인데

아래와 같이 프라메터 튜닝과 conf파일 변경을 해주니 약간에 성능 향상은 있는것은 확인했습니다.

/etc/sysctl.con

vfs.vmiodirenable=1
kern.ipc.maxsockbuf=2097152
kern.ipc.somaxconn=8192
kern.ipc.maxsockets=16424
#kern.maxusers=128
kern.maxfiles=65536
kern.maxfilesperproc=32768
net.inet.tcp.rfc1323=1
net.inet.tcp.delayed_ack=0
net.inet.tcp.sendspace=65535
net.inet.tcp.recvspace=65535
net.inet.udp.recvspace=65535
net.inet.udp.maxdgram=57344
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535


3cps cpu 90%
/var/lib/pgsql/data/postgresql.conf
shared_buffers = 31250
sort_mem = 32168
max_connections=64
fsync=false

그런데도 cpu사용율이 80-90%수준까지 올라가더라요.;;

postgresql 버전이

postgresql-8.1.11-1.el5_1.1
postgresql-libs-8.1.11-1.el5_1.1
postgresql-odbc-08.01.0200-3.1
postgresql-server-8.1.11-1.el5_1.1
이렇게 사용중인데

버전 업을 하면 성능 향상이 있을까요.

또는 다른 튜닝에 방법이 있는지요..;;

 

nowplace(nowplace)님이 2010-08-31 14:55에 작성한 댓글입니다.

버전을 올려보시길 추천합니다 ㅎ

CPU 90% 사용이 항상 나쁜건 아닙니다. 오히려 자원을 풀로 잘 쓰고 있으니 잘하고 있는 경우도 있습니다.

여러가지 부분에서 튜닝을 해봐야 하는데요. 일단 병목이 어디에 있는지 알아내야 합니다.

데이터 파일의 용량이 메모리보다 커지기 시작할 때부터 속도 저하가 보통 시작됩니다. sysstat 패키지를 까신 후 sar -P ALL 1 명령어로 상태를 보시면 도움이 됩니다.

%user에서 높으면 pgsql이 cpu를 직접 사용하는 것이라고 보시면 되고요.

%system에서 높으면 커널레벨에서 사용하는 것이라고 보시면 됩니다.

%iowait에서 높으면 디스크가 느린것이고요. 이건 램을 늘리거나, 디스크를 빠른 디스크로 바꿔야 보통 해결됩니다.

 

%user에서 높은 점유율은 어쩔수 없다고 보시면 되고 %system에서 높은건 파일시스템의 동작 방식에 크게 영향을 받을 수 있습니다. 이 부분은 높아도 크게 문제가 되지 않을 수 있습니다. 최신의 파일시스템일수록 이 부분이 더 높게 나옵니다.

%iowait을 줄이는 것이 비용이 들고 가장 어려운 부분인데 이건 어쩔 수 없이 돈으로 바르는 수 밖에 없습니다;;

 

설정 파일에서 checkpoint_segments 를 올리시면 성능 저하가 일어나는 부분이 몰리는 대신 평균적으로 성능 향상이 됩니다. 단 너무 크게 잡으면 성능 저하가 일어나는 시간이 길어집니다. 디스크 성능을 체크해서 디스크가 한번에 썼을 때 1초 미만으로 쓸 수 있는 용량으로 잡아주면 좋습니다.

 

 

신기배(소타)님이 2010-08-31 16:53에 작성한 댓글입니다.

신기배님

자세한 답변 감사 드립니다.

말씀데로 9.0버전을 설치하고 난뒤 약간의 설정 변경뒤 부터는 아이들 상테가 30정도를 유지하고 있습니다.

좋은 조언 감사 드립니다.^^

nowplace(nowplace)님이 2010-09-02 14:52에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
8707PostgreSQL 9.0 now available! [2]
신기배
2010-09-21
9011
8704PostgreSQL 9.0 Release Candidate 1 now available! [3]
김도경
2010-09-01
8191
8703배열을 사용해도 괜찮을까요? [2]
심상호
2010-08-31
8248
8702postgresql 성능 하락 [4]
nowplace
2010-08-30
16265
8701동일 DB의 읽기, 쓰기 서버 분리가 가능할까요? [1]
김병길
2010-08-30
7640
8700Postgresql 에서 Record ID(Page ID, offset)을 알 수 있는 방법이 있나요. [1]
kwangsoo
2010-08-24
8030
8699ODBC 세팅시 패스워드 인증 오류 [1]
greenluck
2010-08-23
7697
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다