데이터베이스를 사랑하는 사람들의 모임 데이터베이스 사랑넷

PostgreSQL Q&A 6341 게시물 읽기

No. 6341

DB서버 상태가 이상합니다 ㅠ_ㅠ;
작성자	신기배(소타)	작성일	2005-09-28 17:13	조회수	5,598

[root@magicdb01 pgsql8]# uptime

17:02:27 up 153 days, 10:59, 3 users, load average: 3.60, 3.53, 2.63

[root@magicdb01 pgsql8]# uptime

17:04:46 up 153 days, 11:02, 3 users, load average: 3.18, 3.43, 2.72

[root@magicdb01 pgsql8]# vmstat 1

procs memory swap io system cpu

r b swpd free buff cache si so bi bo in cs us sy wa id

1 0 1988 631488 154500 847524 1 1 1 3 4 2 1 1 1 2

0 0 1988 631484 154500 847524 0 0 0 0 119 68 3 7 0 90

0 0 1988 631016 154500 847532 0 0 0 368 214 497 3 2 3 92

0 0 1988 630784 154500 847540 0 0 8 0 157 333 1 4 0 95

0 0 1988 630776 154508 847540 0 0 0 428 145 88 5 8 11 76

0 0 1988 630732 154508 847556 0 0 0 328 155 116 1 0 3 96

0 0 1988 630732 154508 847556 0 0 0 0 108 48 1 4 0 95

1 0 1988 630728 154508 847556 0 0 0 332 153 181 3 9 1 87

0 0 1988 630728 154508 847556 0 0 0 0 106 37 0 1 0 99

0 0 1988 630716 154520 847556 0 0 0 340 128 78 1 3 8 87

1 0 1988 630612 154520 847556 0 0 0 0 111 37 2 6 0 92

0 0 1988 630584 154520 847556 0 0 0 0 137 126 2 4 0 94

0 0 1988 630504 154520 847580 0 0 0 732 287 420 2 3 14 81

1 0 1988 630504 154520 847580 0 0 0 0 109 28 1 4 0 95

0 0 1988 630376 154524 847580 0 0 0 272 127 65 3 5 8 84

0 0 1988 630256 154524 847580 0 0 0 0 126 81 1 3 0 96

0 0 1988 630256 154524 847580 0 0 0 0 107 36 1 3 0 96

0 0 1988 630248 154524 847580 0 0 0 252 148 119 3 6 2 89

1 0 1988 630248 154524 847580 0 0 0 0 114 39 1 3 0 97

0 0 1988 630248 154528 847576 0 0 0 272 128 74 1 3 8 87

0 0 1988 630248 154528 847576 0 0 0 0 113 56 3 6 0 92

1 0 1988 630248 154532 847576 0 0 0 0 168 224 3 0 0 97

1 0 1988 628988 154536 847584 0 0 8 0 160 941 4 4 0 91

0 0 1988 627508 154540 847584 0 0 0 416 191 116 2 7 6 85

0 0 1988 626256 154552 847584 0 0 0 380 170 136 0 0 17 82

2 0 1988 626120 154552 847584 0 0 0 0 116 43 1 3 0 96

[root@magicdb01 pgsql8]# ps aux | grep postgres | wc -l

169

PostgreSQL와 모니터링 툴만 돌아가고 있습니다.

웹서버를 재시작해서 프로세스가 169개인데 많을대는 450~500개를 유지합니다.

웹서버 2대, 미들웨어 1대, 파일서버 1대가 물려있고 미들웨어에서는 약 4~8개, 파일서버에서는 1~2개, 나머지는 웹서버 2대의 세션들입니다.

auto_vacuum을 꺼놓은 상태이고 PGDATA 의 크기는 2기가 정도 됩니다. vacuum한 지가 꽤 되었는데 그 때문일까요?

postgresql.conf 파일에서 기본값이 아닌 것들 입니다.

max_connections = 1000

shared_buffers = 10000 # min 16, at least max_connections*2, 8KB each

work_mem = 8192 # min 64, size in KB

maintenance_work_mem = 65536 # min 1024, size in KB

vacuum_cost_delay = 200 # 0-1000 milliseconds

vacuum_cost_page_hit = 6 # 0-10000 credits

wal_buffers = 8 # min 4, 8KB each

checkpoint_segments = 16 # in logfile segments, min 1, 16MB each

checkpoint_timeout = 1800 # range 30-3600, in seconds

checkpoint_warning = 60 # 0 is off, in seconds

effective_cache_size = 100000 # typically 8KB each

random_page_cost = 3.5 # units are one sequential page fetch cost

log_destination = 'syslog' # Valid values are combinations of stderr,

syslog_facility = 'LOCAL0'

syslog_ident = 'postgres'

stats_row_level = true

lc_messages = 'C' # locale for system error message strings

lc_monetary = 'C' # locale for monetary formatting

lc_numeric = 'C' # locale for number formatting

lc_time = 'C' # locale for time formatting

버전입니다.

MagicHome=# SELECT version();

version

----------------------------------------------------------------------------------------------------------

PostgreSQL 8.0.1 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

(1건 있음)

최근 갑자기 load average가 3이상을 유지하고 있습니다. 원래는 0.10~0.20 수준이었고 그 이하일때도 많습니다. 세션이 많아져서 그런걸까요? 최근 신규 사용자가 늘어서 데이터의 삽입과 갱신이 잦아지긴 했습니다만 크게 문제가 될 정도로 늘어난건 아닙니다..

아.. 이거참;; 문제입니다. 도움 좀 주십시오~~

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

[root@magicdb01 pgsql8]# ipcs

------ Shared Memory Segments --------

key shmid owner perms bytes nattch status

0x0052e2c1 32768 postgres 600 98492416 242

------ Semaphore Arrays --------

key semid owner perms nsems

0x0052e2c1 2064384 postgres 600 17

0x0052e2c2 2097153 postgres 600 17

0x0052e2c3 2129922 postgres 600 17

0x0052e2c4 2162691 postgres 600 17

0x0052e2c5 2195460 postgres 600 17

0x0052e2c6 2228229 postgres 600 17

0x0052e2c7 2260998 postgres 600 17

0x0052e2c8 2293767 postgres 600 17

0x0052e2c9 2326536 postgres 600 17

0x0052e2ca 2359305 postgres 600 17

0x0052e2cb 2392074 postgres 600 17

0x0052e2cc 2424843 postgres 600 17

0x0052e2cd 2457612 postgres 600 17

0x0052e2ce 2490381 postgres 600 17

0x0052e2cf 2523150 postgres 600 17

0x0052e2d0 2555919 postgres 600 17

0x0052e2d1 2588688 postgres 600 17

0x0052e2d2 2621457 postgres 600 17

0x0052e2d3 2654226 postgres 600 17

0x0052e2d4 2686995 postgres 600 17

0x0052e2d5 2719764 postgres 600 17

0x0052e2d6 2752533 postgres 600 17

0x0052e2d7 2785302 postgres 600 17

0x0052e2d8 2818071 postgres 600 17

0x0052e2d9 2850840 postgres 600 17

0x0052e2da 2883609 postgres 600 17

0x0052e2db 2916378 postgres 600 17

0x0052e2dc 2949147 postgres 600 17

0x0052e2dd 2981916 postgres 600 17

0x0052e2de 3014685 postgres 600 17

0x0052e2df 3047454 postgres 600 17

0x0052e2e0 3080223 postgres 600 17

0x0052e2e1 3112992 postgres 600 17

0x0052e2e2 3145761 postgres 600 17

0x0052e2e3 3178530 postgres 600 17

0x0052e2e4 3211299 postgres 600 17

0x0052e2e5 3244068 postgres 600 17

0x0052e2e6 3276837 postgres 600 17

0x0052e2e7 3309606 postgres 600 17

0x0052e2e8 3342375 postgres 600 17

0x0052e2e9 3375144 postgres 600 17

0x0052e2ea 3407913 postgres 600 17

0x0052e2eb 3440682 postgres 600 17

0x0052e2ec 3473451 postgres 600 17

0x0052e2ed 3506220 postgres 600 17

0x0052e2ee 3538989 postgres 600 17

0x0052e2ef 3571758 postgres 600 17

0x0052e2f0 3604527 postgres 600 17

0x0052e2f1 3637296 postgres 600 17

0x0052e2f2 3670065 postgres 600 17

0x0052e2f3 3702834 postgres 600 17

0x0052e2f4 3735603 postgres 600 17

0x0052e2f5 3768372 postgres 600 17

0x0052e2f6 3801141 postgres 600 17

0x0052e2f7 3833910 postgres 600 17

0x0052e2f8 3866679 postgres 600 17

0x0052e2f9 3899448 postgres 600 17

0x0052e2fa 3932217 postgres 600 17

0x0052e2fb 3964986 postgres 600 17

0x0052e2fc 3997755 postgres 600 17

0x0052e2fd 4030524 postgres 600 17

0x0052e2fe 4063293 postgres 600 17

0x0052e2ff 4096062 postgres 600 17

------ Message Queues --------

key msqid owner perms used-bytes messages

[root@magicdb01 pgsql8]# cat /proc/sys/kernel/shmmax

106496000

[root@magicdb01 pgsql8]# free -m

total used free shared buffers cached

Mem: 2007 1542 464 0 151 829

-/+ buffers/cache: 561 1445

Swap: 3071 1 3070

[root@magicdb01 pgsql8]# top -d 1

17:14:30 up 153 days, 11:12, 3 users, load average: 3.42, 3.40, 3.05

304 processes: 302 sleeping, 2 running, 0 zombie, 0 stopped

CPU states: cpu user nice system irq softirq iowait idle

total 1.4% 25.0% 2.2% 0.0% 0.0% 6.3% 64.9%

cpu00 0.0% 70.5% 0.0% 0.0% 0.0% 0.0% 29.4%

cpu01 0.0% 29.4% 0.9% 0.0% 0.0% 8.8% 60.7%

cpu02 2.9% 0.0% 0.9% 0.0% 0.0% 7.8% 88.2%

cpu03 2.9% 0.0% 6.8% 0.0% 0.0% 8.8% 81.3%

Mem: 2055464k av, 1585152k used, 470312k free, 0k shrd, 155636k buff

1014332k actv, 252440k in_d, 4456k in_c

Swap: 3145656k av, 1976k used, 3143680k free 849488k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND

22557 postgres 16 0 91284 89M 90460 S 4.1 4.4 1:04 1 postmaster

22560 postgres 16 0 91268 89M 90460 S 4.1 4.4 0:58 3 postmaster

22559 postgres 16 0 91264 89M 90456 S 3.1 4.4 0:58 1 postmaster

[root@magicdb01 pgsql8]# cat /proc/cpuinfo

processor : 0

vendor_id : GenuineIntel

cpu family : 15

model : 4

model name : Intel(R) Xeon(TM) CPU 3.00GHz

stepping : 1

cpu MHz : 3000.206

cache size : 1024 KB

...

제온 3기가 듀얼입니다. 하이퍼쓰레딩으로 4개로 인식되구요.. 2기가 메모리 -.-

[root@magicdb01 pgsql8]# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/cciss/c0d0p1 3.0G 2.1G 818M 72% /

/dev/cciss/c0d0p2 79G 3.0G 72G 4% /data

/dev/cciss/c0d0p8 42G 241M 39G 1% /home

/dev/cciss/c0d0p3 3.0G 47M 2.8G 2% /logs

none 1004M 0 1004M 0% /dev/shm

/dev/cciss/c0d0p6 3.0G 248M 2.6G 9% /var

/dev/cciss/c0d0p5 3.0G 33M 2.8G 2% /www

/data/pgsql8이 $PGDATA입니다. 공유 메모리를 1기가 할당했습니다.

신기배(소타)님이 2005-09-28 17:16에 작성한 댓글입니다.

경험상 vacuum full 한방에 90% 짜리 Load Average 가 5%로 줄었었습니다...

무서워요...

송효진님이 2005-09-28 21:34에 작성한 댓글입니다. Edit Ｘ

엄.. 엄청난 시스템이군요.

그런데 지금 올리신 당시에는 별 문제가 없는건가요? top으로 봤을 때에 CPU idle이 80%를 넘는 것 같은데... load average만 3이 넘네요. 메모리도 충분하구요.

IO의 문제인가요? iostat의 내용도 보고 싶네요.

만약 IO의 문제라면 일단 DB외의 IO는 최소화 시키는 것이 좋을 것 같습니다. system log나 다른 프로그램의 로그도 가능한 줄이도록 하구요.

지금 보니 RAID로 전체 하드를 다 묶었군요. 시스템과 프로그램 설치용으로 하드를 하나 분리하고 나머지 하드들을 RAID로 묶어 오직 DB 저장용으로만 운영하는 것이 훨씬 효율적이더군요.

혹시 WAL log를 다른 파티션으로 분리하셨나요? 만약 그랬다면 지금 상황에서는 원래 위치로 복귀 시키는 것이 좋을 듯 합니다.

제가 보기에는 이미 해볼 것은 다 해보셨을 것 같아서 막막하네요.

원론적으로는 auto_vacuum 돌려 놓고 가끔 vacuum만 해주면 문제 없어야 하는데요. 쩝...

쿼리문들의 처리 속도는 정상적인가요?

박성철(gyumee)님이 2005-09-29 02:23에 작성한 댓글입니다.

[root@magicdb01 root]# ps aux | grep postgres | wc -l

331

[root@magicdb01 root]# uptime

09:13:09 up 154 days, 3:10, 2 users, load average: 0.16, 0.17, 0.17

특별한 조치를 한게 없는데 이렇게 돌아왔습니다 -.-;;;

auto_vacuum을 띄워놓고 vacuum analyze 한번 돌려줬습니다..

vacuum full도 해봤는데 중간에 쿼리들이 락이 걸리는 바람에 취소했다가 다시 하고를 반복했는데 이걸로 큰 효과는 못본듯 합니다 ^^;;

다행이네요 -.-; 왜 그런건지 갑자기..

재기동을 새벽에 한번 했습니다. 로그를 syslog를 통해 남기게 해놨었는데 상황실에서 따로 돌려달라고 해서 로그를 strerr로 하고 pg_log디렉토리에 남기게 하는걸로 바꿨는데 이것도 큰 영향이었을런지.. 로그가 별로 남지 않긴한데

여튼 정상이 되었습니다~

신기배(소타)님이 2005-09-29 09:15에 작성한 댓글입니다.

최근(약 일주일?)에 5초 이상 걸리던 쿼리를 하나 발견해서 최적화를 해주었습니다.

어디 복병이 숨어 있을 듯 한데 =_=;

아 그리고 자꾸 로그에 이런게 찍힙니다

ERROR: unsupported type: 23

메일링을 뒤져보니 좀 이상한 에러 같던데 -_-;;

http://www.spinics.net/lists/pgsql/msg24749.html

On Sat, Mar 26, 2005 at 08:25:24AM -0800, Ben wrote:

> gr-test=> select expires from invitecodes where expires <

> ((now())::abstime)::int4;

> ERROR: unsupported type: 23

Hmmm...

CREATE TABLE foo (x integer);

INSERT INTO foo (x) VALUES (1000000000);

INSERT INTO foo (x) VALUES (2000000000);

SELECT x FROM foo WHERE x < now()::abstime::integer;

------------

1000000000

(1 row)

ANALYZE foo;

SELECT x FROM foo WHERE x < now()::abstime::integer;

ERROR: unsupported type: 23

신기배(소타)님이 2005-09-29 09:20에 작성한 댓글입니다.

다행이네요. 원 상태가 되어서... 밤새 잠을 못 주무셨겠군요.

그런데 확실히 원인을 찾지 못했으니 앞으로 또 그럴 수 있겠네요. 당시에 pg_stat_activity에서 특별히 이상한 쿼리는 찾지 못하셨나요?

그리고 저도 같은 에러가 나네요. unsupported type : 23...

엄.. 그런데 다시해보니 이게 8.x의 버그인가봐요. 7.4.7에서는 잘 나오네요.

박성철(gyumee)님이 2005-09-29 10:13에 작성한 댓글입니다.
이 댓글은 2005-09-29 10:16에 마지막으로 수정되었습니다.

특정 쿼리가 느려지는건 없었습니다.

pg_stat_activity 에서도 확인했고요...

여튼 지금은 로드가 0.17~0.5 사이에서 왔다 갔다 하니 일단 냅두면서 추이를 지켜볼 생각입니다

pg_autovacuum 옵션 어떻게 해서 쓰고 계신지 쫌 알려주세여~

신기배(소타)님이 2005-09-29 13:01에 작성한 댓글입니다.

위의 에러의 원인을 찾았습니다.

MagicHome=# select count(*) as count from view_member where gid=2639 and regist_time >= ((now()-('1 day'::interval))::timestamp::abstime::int);

ERROR: unsupported type: 23

MagicHome=# select ((now()-('1 day'::interval))::timestamp::abstime::int); int4

------------

1127885326

(1건 있음)

이유를 모르겠습니다;;

신기배(소타)님이 2005-09-29 14:29에 작성한 댓글입니다.

그러게요. 조건에 abstime::int이 들어가면 저렇게 되는 것 같습니다. 둘다 int인데 말이죠. 아무래도 8.x의 버그 같습니다.

박성철(gyumee)님이 2005-09-30 01:02에 작성한 댓글입니다.

[Top]

No.	제목	작성자	작성일	조회
6344	pgpool을 도입했습니다.. [2]	신기배	2005-10-01	2712
6343	복구시 한글깨짐 문제... [2]	박순철	2005-09-30	3330
6342	db복구 방법? 이상함. [4]	김해정	2005-09-30	2591
6341	DB서버 상태가 이상합니다 ㅠ_ㅠ; [9]	신기배	2005-09-28	5598
6339	to_timestamp가 이상합니다. [2]	이현순	2005-09-27	2473
6338	schema_path초기화 하려면? [1]	이세진	2005-09-26	1868
6336	Version 7.3.4에서는 Function 안에서 to_char(XXX,'')식의 형변환을 어떻게 하나요? [1]	조성배	2005-09-26	2281