동일합니다. processes 파라미터만 늘린다고 되는게 아니라 커널 파라미터도 마찬가지로 수정되어야겠지요.

process 파라미터도 높게 잡을 이유는 없습니다. 수치를 늘린다고 빨라지지 않습니다.

현재 DB에 얼마나 접속하는지 세션 수를 알고 계십니까? 피크 타임시에는 얼마나 접속하나요? Active 세션 수는 얼마나 되는지요?

이런 정보에 근거를 두고 process파라미터를 설정해주시면 됩니다.

아래 쿼리를 실행 시켜보세요.

select * from v$resource_limit

결과에서 processes 가 프로세스 갯수(백그라운드+Dedicate Process)

session이 동시접속 세션 수 입니다.

current_utilization 이 현재 접속 카운트이고... (1명 접속할 때 마다 1씩 증가)

max_utilization  이 오라클을 시작한 이래로 최대로 접속했을 때 피크 수치입니다. processes 파라미터도 이 값을 근거로 어느 정도 여유를 두고 설정하면 됩니다.

initial_allocation 은...  init.ora 파라미터에서 설정한 수치입니다.

만약 max_utilization 이 limit_value에 근접한다면 processes 를 늘려주어야 하겠지요.

마지막으로 팁입니다.

아래 쿼리는 현재 접속된 세션 수와, 전용서버 방식으로 연결한 세션수, 백그라운드 세션 수(오라클 dbwr,lgwr,smon, pmon...), active 세션수 (현재 실재 SQL이 Run되고 있는 세션) 를 알 수 있는 쿼리입니다.

SELECT COUNT (*) total_cnt,
       COUNT (DECODE (server, 'DEDICATED', 1, NULL)) dedicated_cnt,
       COUNT (DECODE (TYPE, 'BACKGROUND', 1, NULL)) background_cnt,
       COUNT (DECODE (status, 'ACTIVE', 1, NULL)) active_cnt
  FROM v$session

감사합니다.

스트레스 테스트를 하다보니..

동시 접속에 관련된부분이 걸리네요.

커널 관련 값들은 모두 수정이 된상태고 db쪽만 신경을 쓰면 될듯 한데..맘대로 안되네요.

말씀해주신 방법대로 시도해 보겠습니다.

다시한번 좋은 답변 감사드립니다.

오라클에서 스트레스 테스트라는건

동시 접속이 많을 경우... Latch 나 Wait 혹은 잠금 문제를 일으키지 않는지 체크하는데 중점을 둬야합니다.

단순히 몇명까지 접속가능하다는건 아무 의미가 없습니다. 제 노트북 PC에 설치된 오라클에서도 파라미터 조정하면 동시접속 1000을 만들 수도 있을겁니다. (메모리만 허용한다면)

하지만 실재 Production  환경하에서 부하가 걸릴 때와는 전혀 다른 무의미한 측정이 되어버립니다. 어떤 업무를 돌릴지 모르지만 일반적 C/S Type의 OLTP 업무를 제 노트북에서 돌린다면 1000세션이 접속하기 전에 벌써 과부하로 뻗어버릴겁니다.

제가 말하고 싶은 요지는... 대부분 이 정도 스펙이면 얼마나 동시접속을 처리하나요라는 질문에 대한 답을 찾기를 원하지만...

더 중요한 것은 어플리케이션이 확장성이 좋도록 코딩하고 구성하는게 더 중요합니다. 이걸 했다면 위에 문제는 자연스럽게 해결되니까요.

아무리 스펙이 좋은 구성을 해도 동시접속이 얼마 증가되지 않았는데도 과부하를 일으키는 것은 그 만큼 코딩에 문제가 있다는 반증이니까요. DB를 잘 이해하고 DB가 최적화되도록 개발을 해야하는데...

대개는 DB를 이해하려고 하지 않고 블랙박스 취급하다보니 이런 문제가 발생합니다.

결국 동시접속 증가에 따른 확장성의 제한 문제는 모델링과 코딩(개발)의 문제로 귀결되기 마련입니다.

개발 환경에선 아무 문제 없던것이 실재 서비스에 들어가면 중단되고 과부하 문제를 겪는 이유도 여기에 있습니다.

반드시 실재와 똑 같은 데이타량과 분포도, 실 데이타를 가지고 벤치마크 하십시오. 실재와 같은 SQL이 들어오도록 부하를 걸고 statspack 등으로 부하를 측정하십시오.