Tomcat & nginx 운영 · 커넥터와 스레드풀 튜닝 · 퀴즈
퀴즈: 커넥터와 스레드풀
문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
acceptCount 까지 모두 소진됐을 때 클라이언트가 받게 되는 것은?
- HTTP 503 Service Unavailable
- TCP 연결 거부 (Connection refused)
- HTTP 429 Too Many Requests
- HTTP 504 Gateway Timeout
maxConnections 가 maxThreads 보다 훨씬 커도 되는 이유는?
- NIO 커넥터에서는 요청을 보내지 않는 Keep-Alive 유휴 커넥션이 워커 스레드를 점유하지 않기 때문
- 톰캣이 스레드를 자동으로 늘려 주기 때문
- maxConnections 는 실제로 동작하지 않는 설정이기 때문
- OS 가 커넥션을 자동으로 정리하기 때문
스레드 덤프를 떴더니 http-nio 스레드 대부분이 `HikariPool.getConnection` 에서 WAITING 상태였습니다. 가장 적절한 조치는?
- maxThreads 를 두 배로 늘린다
- acceptCount 를 늘린다
- DB 커넥션 풀 크기와 느린 쿼리를 먼저 확인한다
- Keep-Alive 를 비활성화한다
목표 처리량 500 TPS, 평균 응답시간 400ms 일 때 리틀의 법칙으로 계산한 최소 동시 처리 수는?
- 50 — 500 을 응답시간 10 으로 나눈 값
- 125 — 500 을 4 로 나눈 값
- 200 — 500 × 0.4초
- 1250 — 500 을 0.4 로 나눈 값
`connectionTimeout="20000"` 이 제한하는 것은?
- 애플리케이션이 요청을 처리하는 최대 시간
- DB 커넥션을 얻기까지 기다리는 시간
- Keep-Alive 커넥션을 유지하는 시간
- 커넥션 수락 후 요청 라인이 도착할 때까지 기다리는 시간
WAS 인스턴스 12대 × DB 커넥션 풀 20 개인 서비스에서, DB 의 max_connections 가 200 일 때 예상되는 문제는?
- 정상이다. 12 × 20 = 240 이지만 실제로는 다 쓰지 않는다
- DB 성능만 조금 느려질 뿐 장애로 이어지지 않는다
- 롤링 배포로 인스턴스가 일시적으로 늘어나는 순간 커넥션 한도를 초과해 장애가 난다
- 톰캣이 자동으로 풀 크기를 줄여 준다
`-Xms` 와 `-Xmx` 를 같은 값으로 잡는 서버 애플리케이션 관행의 이유는?
- 힙이 커졌다 작아지는 과정에서 생기는 추가 GC 와 지연을 없애기 위해
- JVM 이 필요한 만큼만 잡게 되어 전체 메모리 사용량이 줄기 때문에
- 힙 상한이 고정되면 메모리 부족 오류 자체가 발생하지 않기 때문에
- 기동할 때 힙을 다시 계산하지 않아 기동 시간이 짧아지기 때문에