LabHub

Tomcat & nginx 운영 · 커넥터와 스레드풀 튜닝 · 퀴즈

퀴즈: 커넥터와 스레드풀

LabHub 에서 이어서 보기

문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. acceptCount 까지 모두 소진됐을 때 클라이언트가 받게 되는 것은?

    1. HTTP 503 Service Unavailable
    2. TCP 연결 거부 (Connection refused)
    3. HTTP 429 Too Many Requests
    4. HTTP 504 Gateway Timeout
  2. maxConnections 가 maxThreads 보다 훨씬 커도 되는 이유는?

    1. NIO 커넥터에서는 요청을 보내지 않는 Keep-Alive 유휴 커넥션이 워커 스레드를 점유하지 않기 때문
    2. 톰캣이 스레드를 자동으로 늘려 주기 때문
    3. maxConnections 는 실제로 동작하지 않는 설정이기 때문
    4. OS 가 커넥션을 자동으로 정리하기 때문
  3. 스레드 덤프를 떴더니 http-nio 스레드 대부분이 `HikariPool.getConnection` 에서 WAITING 상태였습니다. 가장 적절한 조치는?

    1. maxThreads 를 두 배로 늘린다
    2. acceptCount 를 늘린다
    3. DB 커넥션 풀 크기와 느린 쿼리를 먼저 확인한다
    4. Keep-Alive 를 비활성화한다
  4. 목표 처리량 500 TPS, 평균 응답시간 400ms 일 때 리틀의 법칙으로 계산한 최소 동시 처리 수는?

    1. 50 — 500 을 응답시간 10 으로 나눈 값
    2. 125 — 500 을 4 로 나눈 값
    3. 200 — 500 × 0.4초
    4. 1250 — 500 을 0.4 로 나눈 값
  5. `connectionTimeout="20000"` 이 제한하는 것은?

    1. 애플리케이션이 요청을 처리하는 최대 시간
    2. DB 커넥션을 얻기까지 기다리는 시간
    3. Keep-Alive 커넥션을 유지하는 시간
    4. 커넥션 수락 후 요청 라인이 도착할 때까지 기다리는 시간
  6. WAS 인스턴스 12대 × DB 커넥션 풀 20 개인 서비스에서, DB 의 max_connections 가 200 일 때 예상되는 문제는?

    1. 정상이다. 12 × 20 = 240 이지만 실제로는 다 쓰지 않는다
    2. DB 성능만 조금 느려질 뿐 장애로 이어지지 않는다
    3. 롤링 배포로 인스턴스가 일시적으로 늘어나는 순간 커넥션 한도를 초과해 장애가 난다
    4. 톰캣이 자동으로 풀 크기를 줄여 준다
  7. `-Xms` 와 `-Xmx` 를 같은 값으로 잡는 서버 애플리케이션 관행의 이유는?

    1. 힙이 커졌다 작아지는 과정에서 생기는 추가 GC 와 지연을 없애기 위해
    2. JVM 이 필요한 만큼만 잡게 되어 전체 메모리 사용량이 줄기 때문에
    3. 힙 상한이 고정되면 메모리 부족 오류 자체가 발생하지 않기 때문에
    4. 기동할 때 힙을 다시 계산하지 않아 기동 시간이 짧아지기 때문에