반응형
여기서 항상 디비관련 정보만 얻어가는 넘입니다.
근데 포스트그레스를 사용하다 보니 문제점에 부딫히는 경우가 좀 있어서요
쩝......
웹서버는 버팅기는데 디비서버가 쩝...
cpu사용율이 장난 아니네요....
일단 문제 해결을 위해 os(freebsd)공유메모리 자체를 커널에서 늘렸는데용
>ipcs -T 하면
shminfo:
shmmax: 245760001 (max shared memory segment size)
shmmin: 1 (min shared memory segment size)
shmmni: 192 (max number of shared memory identifiers)
shmseg: 128 (max shared memory segments per process)
shmall: 60000 (max amount of shared memory in pages)
이정도 까지 늘렸어용
근데도 ... 쩝 서비스될때 보면 한사용자가 한페이지를 로딩될때
top을 쳐보면
CPU states: 3.3% user, 0.0% nice, 28.7% system, 0.2% interrupt, 67.8% idle
Mem: 30M Active, 709M Inact, 160M Wired, 2496K Cache, 112M Buf, 103M Free
Swap: 2048M Total, 2048M Free
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
50880 postgres 60 0 24912K 14524K RUN 1 0:01 71.00% 3.47% postgres
50881 postgres 60 0 24828K 14444K CPU1 1 0:00 27.00% 1.32% postgres
거의 70%를 육박하더군요...쯔업 -_-;;
메모리 사용률은 음 만족할 수준인데.......웨 cpu사용률은 목까지 차서
버벅되는지....
쿼리문때문일까용??
음 한번 페이지로딩할때 쿼리는 6번 정도 날리거든요(select , update,insert 합쳐서)
문서를 찾아보니 공유메모리를 늘리면 된다해서
늘렸는데...
늘려도 이모냥이니.. 쯔업...
머가 문젤까용???
cpu는 듀얼 1G 메모리는 1G거든용.......
흠냐 fsync를 사용하나 안하나 cpu사용률은 거의 비슷하구요...
고수님들의 조언 부탁드립니당
by 박래정
수정 | 삭제 | 알람 설정 코멘트 달기
◀ 이전글 : 포스트그레스에서의 B+tree
DBA: NUMBER OF INDEX TUPLES (1553) IS NOT THE SAME AS HEAP 오류 처리 방법 : 다음글 ▶
덧말 [1] by 김상기 (ioseph) 2003-01-13 13:48:45
cpu 사용량이 많다는 것은 당연한 것이고,
문제는 하나의 작업이 cpu 를 사용하는 시간이 얼마나 되는가? 이것입니다.
콘솔에서 ls 명령을 내려도, 그명령이 cpu에서 작업하고 있는 동안, 그리고, 다른 작업들이 없는 동안은 당연히 cpu가 ls 명령의 처리를 위해 100% 가동하기 때문입니다.
ls의 경우 워낙 순십간에 이루워지는 일이기 때문에 cpu 사용률이 극히 낮은 것처럼 보일뿐이겠지요.
다시 원점으로, 하나의 쿼리가 cpu를 얼마나 쓰는가가 아니라, 하나의 쿼리 실행시간을 얼마나 최소화 시길 것인가? 이것이 관건입니다.
이것이 모두 깔끔하게 처리된 다음에 PostgreSQL 서버 튜닝 작업을 해야할 것입니다.
이곳 database.sarang.net 서버의 문제도 같은 문제였거든요.
사용되는 쿼리가 얼마나 완벽한가? 부터 살펴보세요.
가장 단순한 방법은 모든 쿼리 목록을 만들고, 하나씩 explain 명령으로 각 쿼리들이 인덱스를 사용하는지를 살펴보세요.
덧말 [2] by 김상기 (ioseph) 2003-01-13 13:50:37
또한,
처리 속도는 높이는 한 방법으로,
vacuumdb 명령을 통한 물리적인 데이터파일 최적화도 틈틈히 계속 해 주어야합니다.
아랫글 참조.
덧말 [3] by 박래정 2003-01-13 14:52:48
상기님
감사합니다 ^^;;
음 그럼 쿼리최적화가 관건이다 이말씀이신가요?
쿼리문을 다시한번 봐야 겠군욥...
그리고 테이블 삭제와 생성액션이 자주일어나는것도
cpu에 부하를 꽤 높히겠죠?
덧말 [4] by 김상기 (ioseph) 2003-01-13 16:40:33
create table, drop table 작업이 일어나면,
내부적으로
다음 카타로그 테이블들을 insert, delete 합니다.
pg_type,
pg_attribute,
pg_class,
pg_index (index를 만든다면),
pg_inherits (inherits 기능을 사용한다면)
즉, 꽤 많은 시스템 카타로그들의 자료변경이 생깁니다.
이곳 DSN 처럼 검색을 임시테이블로 처리하는 경우라면, 하루가 지나면, 무려 2만여개의 attribute 가 생겼다가 지워집니다.
그래서 서버 상태를 최적화 하기 위해서는 vacuum이 필수입니다.
덧말 [5] by 김대성 2003-01-14 15:03:07
제 오래된 기억으로는 히히~
Postgres를 구동시킬때 파라미터 파일의 SGA영역을 어떻게 잡을것인지.. 글구 인덱스를 탈때 어떻게 탈것인지 등의 파라미터가 있던걸로 기억되는데...
그거 중요한거니깐.. 손봐야 될거에요.. ^^
근데 포스트그레스를 사용하다 보니 문제점에 부딫히는 경우가 좀 있어서요
쩝......
웹서버는 버팅기는데 디비서버가 쩝...
cpu사용율이 장난 아니네요....
일단 문제 해결을 위해 os(freebsd)공유메모리 자체를 커널에서 늘렸는데용
>ipcs -T 하면
shminfo:
shmmax: 245760001 (max shared memory segment size)
shmmin: 1 (min shared memory segment size)
shmmni: 192 (max number of shared memory identifiers)
shmseg: 128 (max shared memory segments per process)
shmall: 60000 (max amount of shared memory in pages)
이정도 까지 늘렸어용
근데도 ... 쩝 서비스될때 보면 한사용자가 한페이지를 로딩될때
top을 쳐보면
CPU states: 3.3% user, 0.0% nice, 28.7% system, 0.2% interrupt, 67.8% idle
Mem: 30M Active, 709M Inact, 160M Wired, 2496K Cache, 112M Buf, 103M Free
Swap: 2048M Total, 2048M Free
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
50880 postgres 60 0 24912K 14524K RUN 1 0:01 71.00% 3.47% postgres
50881 postgres 60 0 24828K 14444K CPU1 1 0:00 27.00% 1.32% postgres
거의 70%를 육박하더군요...쯔업 -_-;;
메모리 사용률은 음 만족할 수준인데.......웨 cpu사용률은 목까지 차서
버벅되는지....
쿼리문때문일까용??
음 한번 페이지로딩할때 쿼리는 6번 정도 날리거든요(select , update,insert 합쳐서)
문서를 찾아보니 공유메모리를 늘리면 된다해서
늘렸는데...
늘려도 이모냥이니.. 쯔업...
머가 문젤까용???
cpu는 듀얼 1G 메모리는 1G거든용.......
흠냐 fsync를 사용하나 안하나 cpu사용률은 거의 비슷하구요...
고수님들의 조언 부탁드립니당
by 박래정
수정 | 삭제 | 알람 설정 코멘트 달기
◀ 이전글 : 포스트그레스에서의 B+tree
DBA: NUMBER OF INDEX TUPLES (1553) IS NOT THE SAME AS HEAP 오류 처리 방법 : 다음글 ▶
덧말 [1] by 김상기 (ioseph) 2003-01-13 13:48:45
cpu 사용량이 많다는 것은 당연한 것이고,
문제는 하나의 작업이 cpu 를 사용하는 시간이 얼마나 되는가? 이것입니다.
콘솔에서 ls 명령을 내려도, 그명령이 cpu에서 작업하고 있는 동안, 그리고, 다른 작업들이 없는 동안은 당연히 cpu가 ls 명령의 처리를 위해 100% 가동하기 때문입니다.
ls의 경우 워낙 순십간에 이루워지는 일이기 때문에 cpu 사용률이 극히 낮은 것처럼 보일뿐이겠지요.
다시 원점으로, 하나의 쿼리가 cpu를 얼마나 쓰는가가 아니라, 하나의 쿼리 실행시간을 얼마나 최소화 시길 것인가? 이것이 관건입니다.
이것이 모두 깔끔하게 처리된 다음에 PostgreSQL 서버 튜닝 작업을 해야할 것입니다.
이곳 database.sarang.net 서버의 문제도 같은 문제였거든요.
사용되는 쿼리가 얼마나 완벽한가? 부터 살펴보세요.
가장 단순한 방법은 모든 쿼리 목록을 만들고, 하나씩 explain 명령으로 각 쿼리들이 인덱스를 사용하는지를 살펴보세요.
덧말 [2] by 김상기 (ioseph) 2003-01-13 13:50:37
또한,
처리 속도는 높이는 한 방법으로,
vacuumdb 명령을 통한 물리적인 데이터파일 최적화도 틈틈히 계속 해 주어야합니다.
아랫글 참조.
덧말 [3] by 박래정 2003-01-13 14:52:48
상기님
감사합니다 ^^;;
음 그럼 쿼리최적화가 관건이다 이말씀이신가요?
쿼리문을 다시한번 봐야 겠군욥...
그리고 테이블 삭제와 생성액션이 자주일어나는것도
cpu에 부하를 꽤 높히겠죠?
덧말 [4] by 김상기 (ioseph) 2003-01-13 16:40:33
create table, drop table 작업이 일어나면,
내부적으로
다음 카타로그 테이블들을 insert, delete 합니다.
pg_type,
pg_attribute,
pg_class,
pg_index (index를 만든다면),
pg_inherits (inherits 기능을 사용한다면)
즉, 꽤 많은 시스템 카타로그들의 자료변경이 생깁니다.
이곳 DSN 처럼 검색을 임시테이블로 처리하는 경우라면, 하루가 지나면, 무려 2만여개의 attribute 가 생겼다가 지워집니다.
그래서 서버 상태를 최적화 하기 위해서는 vacuum이 필수입니다.
덧말 [5] by 김대성 2003-01-14 15:03:07
제 오래된 기억으로는 히히~
Postgres를 구동시킬때 파라미터 파일의 SGA영역을 어떻게 잡을것인지.. 글구 인덱스를 탈때 어떻게 탈것인지 등의 파라미터가 있던걸로 기억되는데...
그거 중요한거니깐.. 손봐야 될거에요.. ^^
반응형