마소 4월호 발췌
커넥션 폴 튜닝
JDBC 애플리케이션 튜닝에서 살펴본 커넥션 폴에 관련된 내용이다.
최근의 WAS서버들은 이 커넥션 폴 기능을 제공하며, 이 부분에 대한 설정 부분도 튜닝 포인트가 된다. WAS서버를 부팅시키면 커넥션 폴 내의 커넥션이 오픈되어 모든 클라이언트가 사용할 수 있게 된다. 클라이언트가 커넥션 폴의 커넥션을 클로우즈하면 그 커넥션은 폴로 되돌려져 다른 클라이언트가 사용할 수 이쓴 상태가 된다. 즉, 커넥션 그 자체가 클로우즈되는 것이 아니다.
커넥션 폴 설정시 초기 값(InitialCapacity)과 최대 값(MaxCapacity)을 설정랗 수 있는데, 개발시에는 초기 값을 작게 설정하면 서버의 기둥이 빠르기 때문에 편리하다. 하지만 운영시스템에서는 서버에 부하가 걸리면 가능한 한 빠르게 서비스를 해주기 위해서는 모든 자원이 프로세스의 처리에 소비되게 된다. 따라서 초기 값과 최대값을 같게 설정해 모든 자원이 프로세스 처리에 사용되도록 할 수도 있으나, 이럴 경우 DB와 커넥션 수가 항상 최대값으로 운영되므로 자원의 여유 정도를 봐가면서 조정해야 한다. 운영 시스템에서는 풀내의 커넥션 수를 JDBC 커넥션을 필요로 하는 동시 유저의 세션 수와 같게 하는것을 추천한다. 커넥션 수 설정시 WAS서버에 설정된 실행 쓰레드 개수 이상으로 설정하는 것은 의미가 없다. 실행 쓰레드개수 내에서 적절하게 조절해야 된다.
Multi-CPU 머신에서 튜닝
최근 WAS 서버들은 Multi-CPU나 Multi-Machine 구성을 위해 클러스터 기능을 지원한다. Multi-CPU를 탑재한 머신이거나 여러대의 Machine으로 아키텍처가 구성되는 경우는 WAS서버 아키텍처를 클러스터로 구성하는 것을 고려할 필요가 있다. 서버에 대한 CPU의 비율을 결정하려면 다음과 같이 검증을 해봐야 한다.
- 네트웍크 요건 : 웹 애플리케이션이 주로 네트워크 I/O 바운드의 경우에는 더 고속의 NIC를 인스톨하는 것이 CPU의 추가보다 높은 퍼포머스를 얻을 수 있다. 이것은 대부분의 CPU가 이용 가능한 소켓의 Read를 기다리는 동안 Idle 상태이기 때문이다.
- 디스크 I/O 요건 : 웹 애플리케이션이 주로 디스크 I/O바운드의 경우에는 CPU의 추가 전에 디스크의 스핀들(spindle)또는 각각의 디스크와 컨트롤러를 업그레이드하는것을 생각해 볼 필요가 있다. 즉, 추가의 CPU를 할당하기 전에 웹 애플리케이션이 네트워크 또는 I/O 바운드보다 CPU 바운드 인지를 확인해야 한다.
앞의 내용들이 실제 검증 후 클러스터를 구성할 때 가장 고민되는 내용으로, 바로 몇 개의 WAS 서버 인스턴스로 구성하느냐이다. Multi-CPU에서 CPU 개수 이상의 인스턴스 구성은 별로 좋지 않다. 가급적이면 CPU개수 내에서 인스턴스 개수를 정하고 다음의 순서로 진행한다.
1)실 운영시 시스템에 접속하는 동시 사용자 수를 산정한다.
2)동시 사용자에 따른 WAS 서버의 실행 쓰레드 수를 설정한다.
3)CPU 개수를 고래해 WAS 서버 인스턴스 개수를 산정한다.
실제로 4개의 CPU를 가진 장비에 동시 접속자 수가 200명이라고 한다면, 실행 쓰레드 개수를 200개로 설정한 WAS서버 인스탄스를 4개로 운영하는 것이 휠씬 좋은 퍼포먼스를 보여준다. 이 클러스터 구성에 대한 사항은 반드시 위와 같은 형태로 구성할 필요는 없다. 어디까지나 경험에 의한 참고사항이고, WAS 서버와 애플리케이션에 대한 특성, 해당 사이트의 특성을 감안해 최적의 구성안을 찾는것이 좋을 것이다.
날짜: 2003-07-23 17:18:09,
조회수: 2067 |