Tomcat 바 텀 원리 분석: 9. Tomcat 성능 개선

6230 단어 Tomcat 바 텀 원리
[칼럼 목록]Tomcat 바 텀 원리 분석: 1. 기초 환경 구축 Tomcat 바 텀 원리 분석: 2. Tomcat 구조 분석 Tomcat 바 텀 원리 분석: 3. Jasper 엔진 Tomcat 바 텀 원리 분석: 4. Tomcatd 의 server. xml 배치 내용 분석 Tomcat 바 텀 원리 분석: 5. Web 응용 배치 분석 Tomcat 바 텀 원리 분석: 6. Tomcat 에서 JVM 의 배치 분석 Tomcat 바 텀 원리 분석: 7. Tomcat 클 러 스 터 설정 분석 Tomcat 바 텀 원리 분석: 8. Tomcat 안전성 설정 분석 Tomcat 바 텀 원리 분석: 9. Tomcat 성능 개선 [본 고 는 안내]
본 고 는 주로 세 가지 측면 에서 Tomcat 를 최적화 시 켰 다. 1. Tomcat 의 JVM 메모리 최적화 2. Tomcat 의 JVM 의 GC 전략 최적화 3. Tomcat 의 커 넥 터 최적화
1. JVM 변조Tomcat Java , JVM 。 ,JVM GC , :
  • 메모 리 는 서비스의 운행 효율 과 스루풋 에 직접적인 영향 을 미친다.
  • JVM 의 GC 메커니즘 은 어느 정도 프로그램 실행 중단 (즉 JVM 이 쓰레기 수 거 를 실행 할 때 프로그램 실행 이 중단 되 는 것) 을 초래 할 수 있 으 며, 응용 프로그램의 특성 에 따라 서로 다른 GC 정책 을 선택 하면 GC 횟수 를 크게 줄 이 고 GC 효율 을 제시 하여 프로그램 실행 성능 을 개선 할 수 있다.

  • 1.1 메모리 변조
    1.1.1 매개 변수 에 대한 상세 한 설명
    매개 변수
    속뜻
    -server
    서버 를 시작 합 니 다. 서버 모드 로 실행 합 니 다. 서버 모드: 시작 속도 가 느 리 고 시작 후 응답 속도 가 빠 릅 니 다.
    -Xms
    메모리 의 초기 크기
    -Xmx
    메모리 최대 크기
    -Xmn
    신세대 의 메모리 크기 는 전체 더미 의 3 / 8 이다.
    -XX:MetaspaceSize
    원 공간 메모리 의 초기 크기 는 JDK 1.8 버 전에 서 다음 과 같이 설정 합 니 다. - XX: PermSize (영구 대 / 영구 대)
    -XX:MaxMetaspaceSize
    원 공간 메모리 의 최대 크기 는 JDK 1.8 버 전에 서 다음 과 같이 설정 합 니 다. - XX: PermSize (영구 대 / 영구 대)
    -XX:InitialCodeCacheSize -XX:ReservedCodeCacheSize
    코드 캐 시 영역 크기
    -XX:MaxNewSize
    신세대 최대 메모리
    -XX:NewRatio
    신세대 와 노년의 비율 을 설정 하 다.장점: 신세대 의 크기 는 전체 더미 의 크기 에 따라 동태 적 으로 확 대 될 수 있다. 예 를 들 어 - XX: NewRatio = 3 은 옛날 에 더미 크기 의 3 / 4 를 차지 하고 신세대 가 더미 크기 의 1 / 4 를 차지한다.
    -XX:SurvivorRatio
    에덴 단지 (Eden) 와 생존 지역 의 비율 을 설치 하 다.예 를 들 어 - XX: SurvivorRatio = 8 은 에덴 단지 (Eden) 의 크기 가 생존 지역 의 8 배 이 고 에덴 단지 (Eden) 는 신세대 크기 의 8 / 10 을 차지 하 며 생존 지역 From 는 1 / 10 을 차지 하 며 생존 지역 To 는 1 / 10 을 차지한다.주의 하 세 요. 두 생존 지역 은 영원히 똑 같 습 니 다.
    1.1.2 변조
    매개 변수
    최적화 건의
    원인.
    -server
    오픈 제안
    서버 모드: 시작 속도 가 느 리 고 시작 후 응답 속도 가 빠 릅 니 다.
    -Xms
    권장 - Xmx 설정 과 같 음
    Tomcat 가 실행 되 는 동안 메모 리 를 재분배 하여 자원 낭 비 를 초래 하지 않도록 합 니 다.
    -Xmx
    사용 가능 한 메모리 의 80% 로 설정 하 는 것 을 권장 합 니 다.
    -Xmn
    공식 적 인 건 의 는 전체 더미 의 3 / 8 이다.
    -XX:MetaspaceSize
    없다
    -XX:MaxMetaspaceSize
    기본 값 을 사용 하 는 것 을 권장 합 니 다. 기본 값 은 무한대 입 니 다.
    -XX:InitialCodeCacheSize -XX:ReservedCodeCacheSize
    없다
    -XX:MaxNewSize
    기본 값, 기본 16M 사용 을 권장 합 니 다.
    -XX:NewRatio
    기본 값 사용 을 권장 합 니 다. 기본 값 은 2 입 니 다.
    -XX:SurvivorRatio
    기본 값 을 사용 하 는 것 을 권장 합 니 다. 기본 값 은 8 입 니 다.
    1.2GC 튜 닝JVM GC :
  • 스루풋: 작업 시간 (GC 시간 포함 하지 않 음) 은 전체 시간의 백분율 을 차지 하고 작업 시간 은 프로그램 운행 시간 뿐만 아니 라 메모리 배분 시간 도 포함한다.
  • 일시 정지 시간: 테스트 시간 동안 'GC 체제 로 인 한 응용 프로그램 이 응답 을 멈 춘 횟수' / '시간' 의 비율
  • 1.2.1 각종 쓰레기 수집 기의 비교
    쓰레기 수집 기
    결점.
    장점.
    장면 에 적응 하 다
    시리 얼 (직렬 수집 기)
    단일 스 레 드 수집 기 는 쓰레기 수집 을 실행 할 때 모든 사용자 스 레 드 를 일시 정지 시 킵 니 다. 즉, 시스템 이 멈 추 는 것 입 니 다.
    단일 스 레 드 로 실행 되 기 때문에 단일 핵 이나 핵 수가 적은 프로세서 환경 에서 스 레 드 전환 비용 이 없고 쓰레기 회수 에 전념 하면 최고의 수집 효율 을 얻 을 수 있 습 니 다.
    데스크 톱 애플 리 케 이 션 과 최근 몇 년 동안 유행 해 온 일부 마이크로 서비스 에서 가상 컴퓨터 관리 에 분 배 된 메모리 가 매우 작 습 니 다. 1200 조 의 신 생 대 를 수집 하 는 데 몇 십 밀리초, 최대 100 밀리초 밖 에 걸 리 지 않 습 니 다. 주파수 가 높 지 않 으 면 사용 자 는 감지 되 지 않 는 다 고 할 수 있 습 니 다. 이런 장면 에서 좋 은 선택 입 니 다.
    병렬 (병렬 수집 기)
    시스템 이 멈 추 는 모든 사용자 스 레 드 를 일시 정지 시 킬 것 입 니 다.
    신세대 쓰레기 수 거 를 병행 하 는 방식 으로 집행 하여 쓰레기 수 거 비용 을 현저히 낮 춘 다.
    "다 핵 cpu 또는 다 중 스 레 드 하드웨어 에서 데 이 터 를 많이 실행 하 는 응용" 에 적용 되 며, 스루풋 수집 기 라 고도 부른다.
    CMS (병렬 태그 수집 기 제거)
    사용자 스 레 드 와 쓰레기 회수 스 레 드 가 동시에 실행 되 지만 반드시 병행 되 는 것 은 아니 며 교체 진행 이 가능 하기 때문에 프로그램의 성능 이 떨 어 질 수 있 습 니 다.
    대부분의 쓰레기 수 거 작업 을 병행 하여 쓰레기 수 거 시의 일시 정지 시간 을 단축 시킨다.
    "응답 시간 이 스루풋 보다 우선 합 니 다" 및 "쓰레기 회수 와 공유 프로세서 자원 을 부담 할 수 있 습 니 다" 에 적용 되 는 응용
    G1 (동시 수집 기)
    위 와 같다
    위 와 같다
    메모리 용량 이 큰 다 핵 서버 에 적용 되 며, 쓰레기 수 거 일시 정지 시간 을 충분히 적 게 채 우 는 동시에 최대한 높 은 스루풋 (JDK 1.7 이후) 을 구현 할 수 있다.
    1.2.2 Tomcat 에서 GC 정책 설정
    1.2.2.1 쓰레기 수집 기 파라미터
    매개 변수
    묘사 하 다.
    -XX:+UseSerialGC
    직렬 수집 기 사용 하기
    -XX:+UseParallelGC
    병렬 수집 기 를 사용 합 니 다. 이 인자 가 설정 되 어 있 으 면 기본 값 으로 - XX: + UseParallelOldGC 를 동시에 사용 합 니 다.
    -XX:+UseParallelOldGC
    FullGC 는 병렬 수집 을 사용 합 니 다. 기본적으로 사용 하지 않 습 니 다.
    -XX:+UseParNewGC
    새 세대 에 병렬 수집 기 를 사용 합 니 다. 이 인 자 를 설정 하면 기본 값 으로 - XX: + UseConcMarkSweetGC 를 동시에 사용 합 니 다.
    -XX:+UseConcMarkSweepGC
    오래된 연 대 를 위해 CMS 쓰레기 수집 기 를 사용 합 니 다. 병렬 수집 기 가 응용 지연 수 요 를 만족 시 키 지 못 할 때 CMS 나 G1 수집 기 를 사용 하 는 것 을 추천 합 니 다. 이 인 자 를 설정 하면 기본 값 으로 동시에 사용 합 니 다 - XX: + UseParNewGC
    -XX:+ParallelGCThreads
    신세대 와 오래된 쓰레기 수집 기 에 스 레 드 개 수 를 설정 합 니 다. 기본 값 은 JVM 에서 사용 하 는 cpu 개수 에 의존 합 니 다.
    -XX:+UseG!GC
    G1 수집 기 를 사용 합 니 다. G1 은 서버 형식의 수집 기로 다 핵, 메모리 에 사용 되 는 기계 입 니 다.그것 은 높 은 물동량 을 유지 하 는 상황 에서 '일시 정지 시간 단축' 의 수 요 를 높 은 확률 로 만족시킨다.
    1.2.2.2 "쓰레기 수집 기 정보 인쇄" 매개 변수
    매개 변수
    묘사 하 다.
    -XX:+PrintGC
    매번 GC 의 정 보 를 인쇄 합 니 다.
    -XX:+PrintGCApplicationConcurrentTime
    마지막 일시 정지 후 지나 간 시간, 즉 동시 실행 시간 에 응답 합 니 다.
    -XX:+PrintGCApplicationStoppedTime
    GC 인쇄 시 일시 정지 적용
    -XX:+PrintGCDateStamps
    매번 GC 시간 스탬프 인쇄
    -XX:+PrintGCDetails
    매번 GC 의 자세 한 정 보 를 인쇄 합 니 다.
    -XX:+PrintGCTaskTimeStamps
    매번 GC 작업 라인 작업 의 시간 스탬프 인쇄
    -XX:+PrintGCTimeStamps
    매번 GC 시간 스탬프 인쇄
    1.2.2.3 예시
    #  tomcat/bin/catalina.sh       
    JAVA_OPTS="-XX:+UseConcMarkSweepGC -XX:+PrintGCDetails"
    #   :      CMS     ,     GC     
    
    : Tomcat ,
    2. Tomcat 설정 변조 (커 넥 터) Tomcat ,
    매개 변수
    묘사 하 다.
    최적화 하 다.
    maxConnections
    최대 연결 수, 이 수 치 를 초과 하면 연결 수가 이 값 보다 낮 을 때 까지 추가 요청 이 막 힙 니 다.
    cpu 요구 가 높 을 때 (계산 형) 너무 크게 설정 하지 않 는 것 을 권장 합 니 다.낮은 경우 2000 정도 로 설정 하 는 것 을 권장 합 니 다 (실제 서버 성능 에 따라 결정 합 니 다)
    maxThreads
    최대 스 레 드 수
    서버 하드웨어 정보 에 따라 합 리 적 인 값 을 설정 해 야 합 니 다.
    acceptCount
    최대 대기 열 대기 수, 요청 수가 최대 연결 수 를 초과 하면 추가 요청 은 작업 대기 열 에 저 장 됩 니 다. 대기 열 용량 이 이 값 이기 때문에 Tomcat 의 최대 요청 처리 수량 = maxConnections + acceptCount

    좋은 웹페이지 즐겨찾기