머리말
직장에서 Java 개발자로서 Tomcat 서버는 모든 사람이 일반적으로 사용하며 현재 많은 회사에서도 사용됩니다. 그러나 시스템의 동시성이 상대적으로 크면 Tomcat이 중단되고 자동으로 종료됩니다. Tomcat을 최적화하고보다 효율적으로 실행하는 방법이 문제가되었습니다.이 편집기에서는 Tomcat 성능을 향상시키는 방법을 공유 할 것입니다.
Tomcat 성능 조정
Tomcat 루트 디렉토리에서 conf 디렉토리를 찾아 server.xml 파일의 컨텐츠를 수정하십시오. 여기 편집자는 JVM 튜닝 및 실제 전투에 대한 400 페이지 이상의 연구 노트 사본을 편집했습니다. 공식 계정 : Kylin의 버그 수정 및 자세한 PDF를 확인하십시오.이 부분의 튜닝을 위해 제가 아는 것은 Tomcat 서버를 설정하는 것입니다. Tomcat이 초기화 될 때 생성되는 최대 동시성 및 스레드 수 설정 및 기타 성능 튜닝 설정이 있습니다. 다음 그림은 내 컴퓨터의 성능을 기반으로 설정 한 몇 가지 매개 변수 값을 보여줍니다. 자세히 설명하겠습니다.
1. URIEncoding = "UTF-8": Tomcat의 문자 집합을 설정합니다. 특정 프로젝트에서 왜곡 된 문자의 변환을 처리하기 때문에 일반적으로이 구성을 설정하지 않습니다. Tomcat의 문자 집합을 직접 수정하는 것은 너무 엄격합니다.
2. maxThreads = "300": Tomcat의 최대 동시 수를 설정합니다. 기본적으로 Tomcat이 구성하는 최대 요청 수는 150 개이며 이는 150 개의 동시 요청을 지원할 수 있음을 의미합니다. 그러나 실제 애플리케이션에서 최대 동시성 수는 하드웨어 성능 및 CPU 수와 많은 관련이 있습니다. 더 나은 하드웨어와 더 높은 프로세서를 사용하면 Tomcat이 더 많은 동시성을 지원할 수 있습니다. 일반적으로 실제 개발중인 경우 응용 프로그램의 동시성이 250 개 이상인 경우 응용 프로그램 서버 클러스터가 고려됩니다.
3. minSpareThreads = "50": 현재 Tomcat이 초기화 될 때 생성되는 스레드 수를 설정합니다. 기본값은 25입니다.
4. AcceptCount = "250": 동시 연결 수가 maxThreads 매개 변수로 설정 한 값에 도달하면 대기중인 연결 수도 수신 할 수 있으며이 연결을 초과하면 직접 리턴하여 연결을 거부합니다. 요청을 처리하는 데 사용할 수있는 스레드를 여러 개 사용할 때 처리 대기열에 넣을 수있는 요청 수를 지정합니다.이 수를 초과하는 요청은 처리되지 않습니다. 기본값은 100입니다. 실제 응용 프로그램에서 동시 Tomcat 수를 늘리려면 acceptCount 및 maxThreads 값을 늘려야합니다. 개편 : WeChat 공개 계정, Soyunku 기술 팀, ID : souyunku
5. enableLookups = "false": 도메인 이름 백 체킹 사용 여부, 일반적으로 처리 능력 향상을 위해 false로 설정되며 일반적으로 거의 사용되지 않는 값도 true입니다.
6. maxKeepAliveRequests = "1": nginx는 동적으로 tomcat으로 전송되고, nginx는 keepalive를 할 수 없으며 tomcat은 기본적으로 Keepalive가 활성화되어 있으며 keepalive 시간 초과를 기다립니다. 기본 설정은 connectionTimeout을 사용하는 것입니다. 따라서 Tomcat 시간 초과 시간을 설정하고 Tomcat Keepalive를 꺼야합니다. 그렇지 않으면 많은 tomcat 소켓 timewait가 생성됩니다.
maxKeepAliveRequests =”1”은 바람둥이가 많은 수의 TIME_WAIT 연결을 생성하는 것을 방지하여 바람둥이가 일시 중단 된 애니메이션을 어느 정도 방지 할 수 있습니다.
JVM 성능 조정
Tomcat 자체는 여전히 JVM에서 실행 중이므로 JVM 매개 변수를 조정하여 Tomcat의 성능을 향상시킬 수 있습니다. 현재 JVM 튜닝에는 메모리 튜닝과 가비지 콜렉션 전략 튜닝의 두 가지 주요 측면이 있습니다.
하나, 메모리 튜닝
후속 시작 매개 변수가 JAVA_OPTS를 JVM의 시작 매개 변수로 취급하기 때문에 Tomcat 루트 디렉토리 아래에서 bin 디렉토리를 찾고 catalina.sh 파일에서 JAVA_OPTS 변수를 설정하십시오. 게다가 자바 가상 머신의 메모리 구조는 다소 복잡하다. 많은 사람들이 이해하는 데 매우 추상적이라고 생각한다. 주로 힙, 스택, 메소드 영역, 가비지 콜렉션 시스템 등 여러 부분으로 나뉘어져있다. 다음은 인터넷에서 선택한 것이다. 메모리 구조 다이어그램 :
메모리 튜닝은 애플리케이션을보다 합리적으로 만들기 위해 각 메모리 공간의 크기를 수정하는 것입니다. 다음 그림은 내 컴퓨터의 성능에 따라 내가 설정 한 매개 변수를 보여 주며 각 매개 변수의 의미를 자세히 설명합니다. :
1. -Xmx512m : Java 가상 머신 힙의 최대 사용 가능한 메모리 크기를 메가 바이트 (m) 단위로 설정합니다. 전체 힙 크기 = 젊은 세대 크기 + 이전 세대 크기 + 영구 세대 크기입니다. 영구 세대는 일반적으로 고정 크기가 64m입니다. 힙의 다른 분포는 시스템에 특정 영향을 미칩니다. 구세대의 GC 수를 줄이기 위해 가능한 한 젊은 세대의 개체를 유지합니다 (일반적으로 이전 세대는 재활용 속도가 느립니다).
실제 작업에서 힙의 초기 값과 최대 값은 일반적으로 동일하게 설정되어 프로그램 작동 중 가비지 콜렉션 수와 공간 확장을 줄일 수 있으므로 프로그램 성능이 향상됩니다. 개편 : WeChat 공개 계정, Soyunku 기술 팀, ID : souyunku
2. -Xms512m : Java 가상 머신 힙의 초기 메모리 크기, 단위 : 메가 (m)를 설정합니다.이 값은 각 가비지 콜렉션이 완료된 후 JVM이 메모리를 재할 당하지 않도록 -Xmx와 동일하게 설정할 수 있습니다.
3. -Xmn170m : 메가 바이트 (m) 단위로 젊은 세대의 메모리 크기를 설정합니다.이 값은 시스템 성능에 더 큰 영향을 미칩니다. Sun은 공식적으로 전체 힙의 3/8 구성을 권장합니다. 일반적으로 젊은 세대의 기억력을 높이면 구세대의 크기도 줄어들 것입니다.
4. -Xss128k : 각 스레드의 스택 크기를 설정합니다. JDK5.0 이후 각 스레드 스택의 크기는 1M이고 각 스레드 스택의 크기는 이전 256K입니다. 응용 프로그램 스레드에 필요한 메모리 크기를 조정합니다.
동일한 실제 메모리에서이 값을 줄이면 더 많은 스레드가 생성 될 수 있습니다. 그러나 운영 체제는 여전히 프로세스의 스레드 수에 제한이있어 무기한 생성이 불가능하며 경험 값은 약 3000 ~ 5000입니다.
5. -XX : NewRatio = 4 : 구세대 (영구 세대 제외)에 대한 젊은 세대 (Eden 및 두 생존자 영역 포함)의 비율을 설정합니다. 4로 설정하면 젊은 세대와 구세대의 비율은 1 : 4이고 젊은 세대는 전체 스택의 1/5을 차지합니다.
6. -XX : SurvivorRatio = 4 : 젊은 세대의 생존자 영역에 대한 Eden 영역의 크기 비율을 설정합니다. 4로 설정하면 두 개의 생존자 영역과 하나의 에덴 영역의 비율은 2 : 4이고 하나의 생존자 영역은 전체 젊은 세대의 1/6을 차지합니다.
7. -XX : MaxPermSize = 16m : 영구 생성 크기를 16m로 설정합니다. 위에서 언급했듯이 영구 생성은 일반적으로 64m의 고정 메모리 크기를 갖습니다.
8. -XX : MaxTenuringThreshold = 0 : 쓰레기의 최대 수명을 설정합니다.
0으로 설정하면 젊은 세대 개체는 생존자 영역을 통과하지 않고 직접 구세대로 들어갑니다. 더 오래된 세대의 애플리케이션의 경우 효율성이 향상 될 수 있습니다.
이 값을 크게 설정하면 Survivor 영역에서 젊은 세대의 물체가 여러 번 복사되어 젊은 세대의 물체의 생존 시간을 늘리고 젊은 세대의 일반 재활용 이론을 높일 수 있습니다.
둘째, 가비지 수집 전략 조정
Tomcat 루트 디렉토리에서 bin 디렉토리를 찾고 catalina.sh 파일에서 JAVA_OPTS 변수를 설정하십시오. Java 가상 머신에는 기본 가비지 콜렉션 메커니즘이 있지만 가비지 콜렉션 메커니즘에 따라 효율성이 다르다는 것을 모두 알고 있습니다. 이로 인해 Java 가상 머신의 가비지 콜렉션 전략을 적절하게 조정하는 경우가 많습니다. 다음은 내 요구 사항 중 일부를 통해 구성된 가비지 수집 전략이기도합니다.
Java 가상 머신의 가비지 수집 전략은 일반적으로 직렬 수집기, 병렬 수집기 및 동시 수집기로 나뉩니다.
직렬 수집기 :
1. -XX : + UseSerialGC : 가비지 수집 전략이 직렬 수집기임을 나타냅니다. 즉, 전체 스캔 및 복사 프로세스가 단일 스레드 방식으로 수행되어 단일 CPU, 새로운 세대의 작은 공간에 적합하며 일시 중지 시간이 그리 많이 걸리지 않습니다. 고수준 응용 프로그램의 경우 클라이언트 수준의 기본 GC 방법은 주로 JDK1.5 이전의 가비지 수집 방법입니다.
동시 수집가 :
1. -XX : + UseParallelGC : 가비지 수집 전략이 병렬 수집기 (처리 우선 순위)임을 나타냅니다. 즉, 전체 스캔 및 복사 프로세스가 다중 스레드 방식으로 수행되며 CPU가 여러 개이고 일시 중지 시간이 짧은 응용 프로그램에 적합합니다. 위는 서버 수준에서 사용되는 기본 GC 방법입니다. 이 구성은 젊은 세대에게만 유효합니다. 이 구성에서는 젊은 세대 만 동시 수집을 사용할 수 있지만 이전 세대는 여전히 직렬 수집을 사용합니다. 개편 : WeChat 공개 계정, Soyunku 기술 팀, ID : souyunku
2. -XX : ParallelGCThreads = 4 : 병렬 수집기의 스레드 수, 즉 동시에 함께 가비지 수집되는 스레드 수를 구성합니다. 이 값은 프로세서 수와 동일하게 구성하는 것이 가장 좋습니다.
3. -XX : + UseParallelOldGC : 구세대 가비지 수집 방법을 병렬 수집으로 구성합니다. JDK6.0은 구세대의 병렬 수집을 지원합니다.
4. -XX : MaxGCPauseMillis = 100 : 각 젊은 세대 가비지 콜렉션의 최대 시간을 설정합니다.이 시간을 충족 할 수없는 경우 JVM은이 값에 맞게 젊은 세대의 크기를 자동으로 조정합니다.
5. -XX : + UseAdaptiveSizePolicy : 이 옵션을 설정하면 병렬 수집기가 대상 시스템에서 지정한 최소 해당 시간 또는 수집 빈도를 달성하기 위해 자동으로 젊은 세대 영역 크기와 해당 생존 영역 비율을 선택합니다.이 값은 병렬 수집을 사용하는 데 권장됩니다. 장치는 항상 켜져 있습니다.
동시 수집가 :
1. -XX : + UseConcMarkSweepGC : 가비지 수집 전략을 동시 수집기로 나타냅니다.
요약하자면
음, 지금까지 가상 머신의 가비지 수집 전략을 요약했습니다. 여기 편집자는 JVM 튜닝 및 실제 전투에 대한 400 페이지 이상의 연구 노트 사본도 편집했습니다. 공식 계정에 주목하십시오 : Kylin의 버그, 자세한 PDF, 이것은 같은 문장입니다 : 최적의 학습이 진행 중입니다. 아래는 다른 블로그에서 발췌 한 것입니다. 위의 세 가지 GC 메커니즘을 함께 사용해야한다고합니다.
