|
> 아래 질문에서, Postgres 컴파일시 디폴트로 설정된
> 최대 백엔드 수를 늘리기 위한 방법을 물었습니다.
>
> 컴파일시 옵션을 256개로 준다고 하더라도, 솔라리스 커널이
> 지원하는 공유메모리의 디폴트 값을 증가시키지 않으면,
> postmaster 실행시 에러가 발생하더군요.
> 그래서, 커널의 공유메모리 최대 사이즈를 증가시키고
> 수행하니 잘 돌아갔습니다.
> 공유메모리 증가 요령은 아래 질문의 내용에 있습니다.
>
그렇습니다. postmaster 의 경우 IPC 중 semaphore/shared memory 소모가 제법 많습니다. 이것을 적당한 정도로 올려 주지 않으면 제대로 backend가 동작하지 않게 됩니다.
솔라리스의 경우 시스템 설정을 바꿀수 있도록 되어 있지만 리눅스의 경우 문제가 되면 소스에서 변경하여 다시 커널을 컴파일하여야 한답니다. /./
> 근데, 또 질문이 있습니다.
> 최대 백엔드의 수를 256으로 설정하였지만,
> 하나의 실행 어플리케이션 바운드 내에서는 49개 까지의
> 백엔드를 사용할 수 있다는 거죠.. <// 이게 맞는지요 ?
> 실제로 실행해보니, 한 어플리케이션에서 49개 까지
> 백엔드를 사용할수 있습니다.(DB connect를 finish 없이
> 49개 까지 할수 있다는).
> 여러 어플리케이션(쓰레드가 아닌, Process들)에서
> 동시에 DB connect를 요청하니, 각각 49개 까지만
> 되더군요. 물론 모두 합한 최대는 256개 일테지만요.
>
> 테스트를 통해 제가 내린 판단이 맞는지요 ??
>
이건 저가 해 보지 못한 부분이라서 정확한 답변을 드리지는 못하겠습니다. 하지만 테스트 결과 그렇게 나왔다면 당연히 옳겠지요.
개인적으로는 아직까지는 256까지 될 것이라고 막연히 생각하고 있었습니다. 좋은 정보 감사드립니다.
> 저의 경우, CORBA를 이용해 분산 어플리케이션을
> 구축하고 있기 때문에, 다른 프로세스로 동작하는
> 여러 어플리케이션들이 동시에 DB에 접근해야 하는데,
> 한 프로그램 내에서 사용할 수 있는 최대 백엔드가
> 총 백엔드의 수보다 작다면, 각각에 할당될
> 백엔드 수를 결정하기 쉽지 않을 것 같네요.
> 그것도 동적으로 결정해야 한다면........
>
만약 위와 같은 문제가 있다면 방법은 그렇게 간단하질 않을 것 같습니다. 일단 메모리와 시스템 리소스 문제가 걸리고 다음으로 하나의 트랜젝션에서 사용할 수 있는 백엔드의 수가 고정되어 있다고 가정한다면 DB connection 을 조절하는 middle ware 를 하나 작성하는 수 밖에 없습니다. 이것은 예전에 미국에 계시는 어느분이 이렇게 해결했다고 제안한 방법입니다.
Middle ware 에서 일정 갯수의 DB connection pool 을 만들어서 요청이 들어오는 순서대로 DB connection을 할당시키고 만약 여분의 pool 이 남아 있지 않다면 request를 대기 시키는 방법을 사용하는 것입니다.
그리고 디비로의 모든 접속은 이 middle ware 를 통해서 하면 해결은 됩니다. 하지만 문제는 이 middle ware 를 만드는 자체가 그렇게 간단하지 만은 않을 것이라는 것입니다. 하지만 안정성은 확실하게 제공할 것으로 판단됩니다.
> 두서가 없는데, 한마디로 질문을 요약하면,
>
> 만일, 한 프로그램에서 49개의 한계를 넘어,
> 256개 까지 사용할 수 있도록 하는 방법이 있는지요 ??
>
> 고수 여러분의 답변 부탁드립니다.
>
> 추신) 아래 정재익님의 답변 감사드립니다. 백엔드 수를
> 늘리기 위해, 다시 컴파일을 할 필요가 없었군요.
> 한가지 더 궁금한 것은, 백엔드 수와 커널에서
> 설정해야 하는 공유 메모리의 사이즈와 어떤
> 관계가 있는 지요......
>
> 이런 좋은 홈페이지를 갖추어 주셔서 감사드려요.
> 홍홍 ~~~~
모두가 함께 가꾸어 가는 사이트입니다. 앞으로 보다 좋은 정보를 갖게 되시면 언제든지 알려 주신다면 감사 드리겠습니다.
|
