postmaster 는 postgresql 에 걸리는 transaction 양에 따라서 그렇게 늘어 날수도 있습니다. postmaster 갯수가 몇개인지는 몰라도 1 G 의 메모리라면 그 정도로는 문제가 되지 않을 것 같군요.

mysql 데몬 문제는 뭐가 원인인지 알수가 없군요. 그리고 트랜젝션 양이 얼마나 되며, connection 수는 얼마나 되는지요. 그런 자료들을 한번 잘 검토해 보시기 바랍니다.

죽을때 보면 다음과 같은 메세지가 나옵니다.

그리고 죽은 다음에 확인해 보면 mysqld 가 8개 정도 떠있거든요.....

그런데 mysql은 연결이 안됩니다.....

확인좀 부탁드립니다.

020829 19:58:22 /usr/local/mysql/libexec/mysqld: Forcing close of thread 31994 user: ''

020829 19:58:22 /usr/local/mysql/libexec/mysqld: Forcing close of thread 32014 user: ''

020829 19:58:22 /usr/local/mysql/libexec/mysqld: Forcing close of thread 32015 user: ''

020829 19:58:22 /usr/local/mysql/libexec/mysqld: Forcing close of thread 31996 user: ''

020829 19:58:22 /usr/local/mysql/libexec/mysqld: Forcing close of thread 32013 user: ''

020829 19:58:22 /usr/local/mysql/libexec/mysqld: Forcing close of thread 32012 user: ''

020829 19:58:22 /usr/local/mysql/libexec/mysqld: Forcing close of thread 32011 user: ''

020829 19:58:22 /usr/local/mysql/libexec/mysqld: Forcing close of thread 32010 user: ''

020829 19:58:22 /usr/local/mysql/libexec/mysqld: Forcing close of thread 32009 user: ''

cpu여유로 봐서는 동시사용자에 따른 I/O경합때문에 자원반납이 늦어 그런게 아닌가 생각됩니다.

지금같이 메모리가 풍부한 경우에는 디비가 메모리를 얼마나 쓰냐보다는 각자원을 얼마나 오래 물고 있냐가 중요할것 같습니다.

일단 공유메모리를 mysql에게도 돌아갈수 있도록 충분히 할당하시고 좀더 지켜보시는게 좋을거 같습니다.

가장오래머물고 있게 하는 요인의 query문을 분석해보십시요.

저희도 얼마전 비숫한 사항있었는데,

저희는 분석결과 디비량이 너무컷고 각프로그램의 query문이 최적화되지 못해 그런것이라고 결론을 내고 좀 낮은사양의하드웨어를 구입해서 웝을 이전하고 큰데이블데이타를 년도별로 분리해서 해결했습니다.

(약 500백만건짜리 테이블이 2개있었습니다 수시로 입력/삭제/수정이 일어나는)

포스트그래스가 메모리 잡아먹는 경우는

주로 쿼리시에 발생하는데,

인덱스 값이 제대로 안잡혀 있거나

쿼리 결과가 많을때 주로 발생하는 것으로 보입니다.

인덱스 설정을 잘 해주시고,

속도나 메모리 찾이하는 비중이 늘어나면

reindex table 테이블명

하셔서 인덱스를 재정리해서 돌려 보시면

많이 안정되는 걸 보실수 있습니다.

특히 View 를 사용하실때는 View를 위한

Where 절에서의 조합을 잘 살펴 보세염.

필드하나 잘못 걸면서 엄청남 부하가 발생할수도

있는게 RDB 더군여 ..

도움 되시길 ..