자바 애플리케이션 성능 튜닝 (재 인쇄가)

자바 애플리케이션 성능 병목 지점이 매우 큰, 같은 디스크, 메모리, 네트워크 I / O 등의 Java 응용 프로그램 코드, JVM GC, 데이터베이스, 캐싱과 같은 전신적인 요인. 나는 개인적인 경험에 근거하여  응용 프로그램 계층, 데이터베이스 층, 프레임 계층의 JVM 층 : 자바 성능 최적화는 네 단계로 나누어 도 같이.

도 계층 적 모델의 성능 최적화 1.Java

 

 

각 레이어 점점 하드 최적화, 지식은 다를 것이다 관련된 문제를 해결합니다. 소스 코드 프레임 워크, 메커니즘을 이해하기위한 프레임 워크를 이해하는 계층 필요성, 교착 위치, 데이터베이스 레벨 필요가 SQL을 분석하기 위해, 예를 들어, 응용 프로그램 로직 계층은 코드를 이해 자바 스레드 스택에 의해 해당 코드의 줄을 찾습니다, 등등 필요가 JVM 레벨과 작품의 유형은 GC에 필요한 메커니즘은 다양한 매개 변수 JVM 이득의 역할의 좋은 이해를 가지고있다.

 

현장 분석 및 사후 분석 : 자바 성능 튜닝의 주위에, 분석의 두 가지 기본 방법이 있습니다.

 

사이트 예약 사이트에 의해 분석 한 다음 진단 도구를 사용하여 분석을 찾습니다. 줄에 사이트 분석 큰 영향 장면 (는 온라인 사용자에 관해서 특히 중요한 비즈니스)의 일부는 적합하지 않습니다.

 

나중에 분석은 즉시 서비스를 복원, 멀티 사이트 데이터로 수집 할 필요가 있지만, 분석 후 현장 데이터 수집을위한 복제. 진단 도구의 성능에서하자의 시작은, 케이스 및 연습의 번호를 공유 할 수 있습니다.

 

첫째, 성능 진단 도구

 

하나는 확인 된 성능 문제 및 코드 시스템의 진단 성능 진단이다, 온 - 라인 성능 요구 사항 여부를 결정하기 전 사전 시스템 성능 테스트에서 한 쌍의 라인이있다.

 

전자의 시험이 논문은, 후자는 다양한 성능 측정 도구 (예를 들어 JMeter가)로 가압 할 수 있고, 그 범위는 본 명세서에서 논의되지 않는다.

 

: Java 응용 프로그램의 성능 진단 도구는 주로 2 층으로 나누어 져 OS 레벨과 (응용 프로그램 코드 진단 및 진단 GC 포함) 응용 프로그램 수준의 자바.

 

OS 진단

주요 관심사의 OS 진단은 세 가지 측면에서 CPU, 메모리, I / O입니다.

 

 

두, CPU 진단

 

평균 부하는 CPU (보통 하중), CPU 사용률, 컨텍스트 스위치 (문맥 전환)에 대한 주요 관심사.

 

상부의 명령으로 시스템 부하 평균 CPU 사용량을 볼 수도. 2는 명령 상태를 통해 시스템의 상위 뷰입니다.

도 2.top 명령 예.

 

 

63.66,58.39,57.18 각각 이상 일분 5 분, 기계 부하 15 분 : 세 개의 숫자의 평균 부하. 값이 CPU 미만 0.7 * 수의 경우 경험에 따르면, 시스템은 제대로 작동하고, 더 심지어 CPU 코어의 네다섯 배 수에이 값보다, 시스템의 부하가 상당히 높은 경우.

 

도 2에서, 부하는 시스템 부하의 문제가 발생하는 바와 57.18,1로드 (16 코어 시스템) 63.66 분, 15 분에 도달하고 현재의 경향은 또한, 특정 이유를 찾을 필요가 증가된다.

 

도 3에 도시 된 명령 컨텍스트 스위치 vmstat를 CPU에 의해 볼 수있다 :

도 3.vmstat 명령 예제

 

상황의 발생 장면 수는 다음과 같은 주요 범주를 전환 :

• 1) 타임 슬라이스는 CPU 정상적인 작업 예약 만료;

• 2) 다른 하나는 더 높은 우선 순위 태스크 선점되고;

• 3) 작업은 I / O를 방해은, 현재 작업, 다음에 작업 스위치를 중단 발생 실시합니다;

• 4) 사용자 코드 이니셔티브는 CPU를 포기하고 현재 작업을 중단;

• 이 때문에 5) 선점 형 멀티 태스킹 리소스를 더 잡아가 중단되지 않습니다;

• 6) 하드웨어 인터럽트.

 

공유 자원 경쟁에서 주로 전환 자바 스레드 컨텍스트. 잠금 단위가 너무 큰 경우를 제외하고 일반적으로 하나의 객체 잠금 시스템은 거의 병목 현상이 없습니다. 그러나, 액세스 빈도가 높은 코드 블록의 로크 연속적인 복수의 객체는 컨텍스트 스위치의 수가 표시 시스템 병목이 될 수있다.

 

세, 메모리

 

신청 절차의 적절성에 운영 체제, 메모리, 관심의 관점에서, 당신은보기 메모리 사용에 대한 무료 -m 명령을 사용할 수 있습니다.

 

당신은 공식 VIRT에 따라, 상부의 명령 가상 메모리 VIRT와 물리적 메모리 RES에 의해 사용되는 과정을 볼 수 = SWAP + RES는 사용 된 스왑 파티션의 특정 응용 프로그램 (스왑), swappiness 할 수있는 Java 응용 프로그램의 성능에 스왑 너무 많은 효과의 사용을 계산할 수 있습니다 가능한 한 작게 값으로 옮겼다.

 

때문에 자바 애플리케이션을 위해 메모리보다 훨씬 느린, 결국, 성능, 디스크 성능에 영향을 미칠 수있는 너무 많은 스왑을 차지합니다.

 

네 I / O

 

I / O는 일반적으로 I / O 병목 현상에 디스크 I / O, 네트워크 I / O, 경향 디스크가 포함되어 있습니다. 디스크 / 디스크 I / O가 정상입니다 볼 수있는 CPU I O 대기를 통해, iostat를 읽을 방법을 볼 수 있습니다.

 

디스크 I / O가 높은 상태가 된 경우, 느리거나 디스크 실패를 나타내는, 그것은 성능 병목 현상, 애플리케이션 최적화 또는 디스크 교체에 대한 필요성이되었다.

 

일반적인 가기 추가, PS, vmstat 명령은 명령 iostat를, 같은 mpstat의, tcpdump를, NETSTAT, pidstat, SAR 등과 같은 시스템 문제를 진단하기 위해 다른 리눅스 도구가 있습니다. 참조 용으로도. 4와 같이 리눅스 브렌든 요약, 장치 성능 진단 도구의 다른 유형을 나열합니다. 

도 성능 관측 도구 4.Linux

 

 

다섯, 자바 응용 프로그램 및 진단 도구

 

응용 프로그램 코드는 성능 문제의 클래스의 성능 문제를 해결하기가 비교적 쉽다. 일부 응용 프로그램 수준 모니터링 알람을 통해 직접 찾을 수 있습니다 코드에 의해 결정 문제와 코드가있는 경우, 또는 상단 + jstack을 통해, 당신은 문제를 찾을 수 있습니다, 문제에 위치 코드를 스레드, 문제 스레드 스택을 식별합니다. 더 복잡한 로직 이상의 코드 세그먼트에 대한 가장 자주 애플리케이션 코드는 성능 로그를 인쇄하여 스톱워치 성능 문제가 위치 될 수있다.

 

일반적인 자바 진단 스레드 스택, GC 및 다른 측면을 포함하여 응용 프로그램 진단.

 

jstack을

상부 명령은 일반적 jstack을 가기 -H -p PID 재사용 jstack을 -l PID 수출 스레드 스택을 통해 자바 제이션 프로세스와 쓰레드를 사용한다. 스레드 스택 따라서 라인에 보통 세 번 덤프, 일반적으로 모든 매 5 초를 여러 덤프를 요구, 일시적이기 때문에. 상단 Java 스레드의 위치는 16 진수로 전환 자바 스레드 스택 꾸벅 꾸벅를 얻을 PID, 문제는 해당 스레드 스택에서 찾을 수 있습니다.

그림 5는 상단을 통해 오랫동안 자바 스레드가 어떻게 작동하는지 볼 -p -H

 

 5 24,985 이상을 실행하는 스레드가,도에 도시 한 바와 같이 문제를 찾을 0x6199로 대응 스레드 스택을 찾기 위해 자바 스레드 스택 진수 데이터로 변환 문제 일 수있다 방법.

그림 6.jstack보기 스레드 스택

 

 

JProfiler와

도에 나타내는 바와 같이 JProfiler와는 CPU, 힙 메모리 분석 강력한 수행 될 수있다. 압력 측정 도구와 결합 된 코드는 시간이 많이 소요되는 샘플링 통계가 될 수 있습니다.

JProfiler와 의해도 7의 메모리 분석

 

 

여섯, GC 진단

 

자바 GC는 프로그래머가 관리하는 메모리의 위험을 해결하지만, GC 일시 정지의 응용 프로그램은 또 다른 문제가 해결 될하는 원인이되었다. JDK는 GC 문제를 찾을 수있는 도구의 범위를 제공하고, 같은 MAT으로 그러면 jstat, jmap는뿐만 아니라 타사 도구를 사용하여 더 일반적으로.

 

그러면 jstat

GC 그러면 jstat 명령은 인쇄, 젊은 전체 GC 및 GC 주파수 정보 스택을 자세히 설명합니다. 이 명령의 형식은

그러면 jstat -gcxxx PID -t <간격> <카운트>에 도시 된 바와 같이.

도 8.jstat 명령 예제

 

 

jmap는

jmap는 인쇄 공정 Java 힙 정보 jmap는 -heap PID. 으로 jmap의 -dump : 파일 = XXX PID 후 더 다른 도구 스택의 사용에 의해 분석 될 수 덤프 파일을 스택

 

매트

MAT는 자바 힙 분석 도구 직관적 인 진단 보고서를 제공 힙 클래스 SQL 쿼리, 강력한 나가는 참조 및 수신 참조가 객체 참조를 추적 할 수 있습니다 내장 OQL 수있는.

도 예제 9.MAT

 

 

도 9는 MAT를 사용하는 예는, MAT 두 열은 오브젝트 각각 얕은 크기 보존 크기의 크기를 표시 갖고, 전자는 메모리의 크기가 직접적으로 또는 간접적으로 참조되는 오브젝트 자체에 의해 참조 된 오브젝트가 포함되지 않은 개체 자체에 의해 점유 나타낸다 존재가 GC 메모리 크기를 회수 한 후 대상 오브젝트 및 그 얕은 크기는 해제 크기 일반적인 관심사에있는 캔.

열린 MAT에 대용량 메모리를 필요로 Java 응용 프로그램의 일부 더미 (수십 G)하십시오.

일반적으로 지역 개발의 시스템 메모리는이보기에 원격으로 열고, 서버 쪽 설치 그래픽 환경 및 MAT에서 온라인 권장 열 수 없습니다, 너무 작습니다. 매트 더미 또는 명령 원시 인덱스, 로컬 복사본에 인덱스를 실행하지만,이 방법으로 한정되는 스택 정보를 참조.

+ PrintGCDateStamps : 문제 GC를 진단하기 위해서는, JVM 인수 -XX를 추가 제안했다. 도에 도시 된 바와 같이, GC 파라미터는 일반적으로 사용된다.

그림 10. 일반적인 GC 매개 변수

 

 Java 응용 프로그램의 경우, 최고 의해 + jstack을 + jmap는 + MAT는 응용 프로그램과 메모리 문제 대부분을 찾을 수 있습니다, 그것은 필수적인 도구로 설명 될 수있다. 때때로, Java 응용 프로그램은 OS 정보를 진단하는 데 참조 할 필요가, 당신은 Zabbix 같은보다 포괄적 인 진단 도구의 일부를 사용할 수 있습니다 (모니터링 OS 및 JVM을 통합) 등등. 분산 환경에서 분산 추적 시스템 등의 인프라가 애플리케이션 성능 진단에이 강력한 지원을 제공합니다.

세븐, 성능 최적화 연습

 

성능 후 일반적으로 사용되는 진단 도구의 도입 후, 다음은 JVM 층, 응용 프로그램 계층 및 코드의 데이터베이스 계층에서 사례 공유의 자바 애플리케이션 튜닝에 우리의 관행의 일부를 결합합니다.

JVM 튜닝 : GC 통증

RMI 리모팅 프로토콜의 내부 재구성과 같은 비즈니스 플랫폼 시스템을 선택 XX, 서비스가 응답 라인, 몇 초에서 수십 초에 이르기까지 일시 정지 시간을 정지 한 후 시스템에 주기적으로 나타나기 시작했다. GC의 로그를 관찰하고 출시 이후 서비스 후 시간이 전체 GC가있을 것이라는 점을 발견함으로써. 시스템 힙이 크게 설정되어 있기 때문에, 전체 GC 일시 정지 시간이 길어 응용 프로그램의 시간이 될 것입니다, 온라인 실시간 서비스에서이 더 큰 영향.

 

분석 후, 정기적으로 상황은 전체 GC는 재건하기 전에 시스템에 따라서 의심 RMI 프레임 워크 차원이 표시되지 않습니다. 공공 정보를 통해 RMI의 GDC (분산 쓰레기 수집, 분산 가베지 컬렉션) 2는 그 데몬 스레드에 대한 코드 목록, 원격 객체를 되찾기 위해 전체 GC를 수행 주기적으로 데몬 스레드를 시작합니다 것을 발견했다.

스레드 소스 코드 데몬 목록 2.DGC

개인  정적  클래스 데몬 확장 스레드 {
  공공  무효 실행 () {
  에 대한 (;;) { 
      // ... 
 긴 D = maxObjectInspectionAge ();
 경우 (d> = l) { 
    이루어지는 시스템 (); 
 D = 0 ; 
 } 
 // ... 
} 
     } 
}

문제를 찾은 후 비교적 쉽게 해결합니다. + DisableExplicitGC를 매개 변수는 사용하지 않도록 표시가 직접 GC 시스템을 부르지 만, NIO를 사용하는 시스템은 외부 메모리 힙 오버 플로우의 위험이있을 것이다 : 하나는 -XX를 추가하는 것입니다.

+를 ExplicitGCInvokesConcurrent를 완전 정지 -로 : 다른 방법은 파라미터 -XX 증가하면서 큰 -Dsun.rmi.dgc.server.gcInterval 및 -Dsun.rmi.dgc.client.gcInterval 전체 GC 간격 증가의 파라미터를 조정하는 것이다 NIO 응용 프로그램이 영향을받지 않습니다 동안 동시 GC 사이클 시간으로 조정 전체 GC의 - 세계는 응용 프로그램의 일시 정지 시간을 줄일 수 있습니다.

크게 세 개월 감소의 수를 조정 한 후.도 11에서 본 전체 GC.

통계를 모니터링 그림 11.Full GC

 

 

많은 양의 데이터와 상호 작용 높은 동시성 애플리케이션을위한 GC 튜닝은 특히 JVM 매개 변수는 일반적으로 비즈니스 요구 사항, 전문 튜닝의 필요성에 만족하지 않는 기본에, 여전히 매우 필요하다. GC 로그의 해석은 공공 정보를 많이 가지고,이 가지 않을 것이다.

GC 튜닝 타겟 기본 세 아이디어 : GC의 빈도를 줄일 수는 불필요한 오브젝트를 줄이기 위해 힙을 증가시킴으로써 생성 될 수있다; GC 휴지 시간이 감소 CMS GC 알고리즘을 이용하여 더미 공간을 줄임으로써, 전체가 GC 조정 트리거 CMS 회피 비율을 피 추진 실패와 동시 모드 실패 (년 된 복구 속도를 속도를 GC ​​쓰레드의 수를 증가, 더 많은 공간을 할당), 생성, 다른 큰 개체를 줄일 수 있습니다.

튜닝 응용 프로그램 레이어 : 나쁜 맛 코드 냄새

코드 튜닝 시작의 응용 프로그램 계층에서, 루트는 코드 효율성, 자바 응용 프로그램의 성능을 향상시킬 수있는 좋은 수단 의심 할 여지없이 하나의 감소에 대한 발생합니다.

 

상업 시스템은 신속하게 재생 날카로운 여러 시스템 부하의 증가, CPU 사용량을 포함한 라인에 매일 일정 시간 후 (균형 Nginx에 부하를 사용하여). 우리는 jmap을하고 jstack을 구원하는 서버에 온라인 및 현장 응급 롤백했다.

스택 필드 MAT 의한 분석도 12

 

 

필드 스택 (12), 덤프 MAT 데이터의 분석에 따르면, 대부분의 메모리 오브젝트 바이트 [] java.util.HashMap에 $ 엔트리로, 원형 기준 java.util.HashMap에 $ 항목 객체가있다. 예비가되는 HashMap의 처리 넣어 무한 루프 문제 (도 java.util.HashMap에 $ 엔트리 0x2add6d992cb8 0x2add6d992ce8 및 다음 기준주기 형태)도 찾을 수있다.

 

오류를 동시 사용의 전형적인 장면을 위치에 속하는 관련 문서에 대한 액세스 (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6423457), 간단히 넣어, 멀티 스레딩 기능이없는 HashMap의 자체입니다, 풋 동작의 다중 쓰레드의 경우에는, 배열 형성된 환형 구조리스트의 HashMap 내부 확장의 내부로 이끌 때문에 무한 루프가있다.

온 라인의 경우, 가장 큰 변화는 Listing 3과 같이 두 게으른 로딩 메커니즘을 사용하여, 메모리 캐시 사이트 데이터를 통해 시스템 성능을 향상하는 것입니다.

3. 웹 사이트 데이터 게으른 로딩 코드 목록

개인  정적 지도 <롱, UnionDomain> domainMap = 새로운 HashMap의 <롱, UnionDomain> ();
    개인  부울 isResetDomains () {
         경우 (CollectionUtils.isEmpty (domainMap)) {
             // 从远端HTTP接口获取网站详情 
            목록 <UnionDomain> newDomains = unionDomainHttpClient 
                    .queryAllUnionDomain (); 
            경우 (CollectionUtils.isEmpty (domainMap가)) { 
                domainMap는 = 새로운 해시 MAP <롱 UnionDomain> ();
                대한 (UnionDomain 도메인 : newDomains) {
                     경우 ! (도메인 =널 ) { 
                        domainMap.put (domain.getSubdomainId () 영역); 
                    } 
                } 
            } 
            반환  사실 ; 
        } 
        반환  거짓 ; 
    }

DomainMap 여기서 참조 정적 공유 자원 인 수는 고리 구조, 무한 루프 형태의 내부에서 발생할 것이다 스레드 상황에서 입력되는 HashMap이다.

시스템이 수지 용기를 시작하는 사용자 요청을 축적 Nginx에 다시 시작되기 때문에 그것은, 프런트 엔드 연결 및 Nginx의 접속 로그를 볼 수 있습니다, 많은 사용자가 응용 프로그램의 유입을 필요로 여러 사용자가 동시에 데이터를 초기화 사이트를 요청 일, HashMap의 동시성 문제로 이어지는 발생한다. 고장 위치 솔루션은 비교적 간단 한 후, 주요 솔루션은 다음과 같습니다 :

• (1) 블록의 동기화를 사용하거나 ConcurrentHashMap의 동시는 문제를 해결;

• (2) 완전한 웹 사이트 캐시는 시스템이 시작되기 전에로드, 게으른 로딩 등을 제거;

• 분산 캐시처럼 로컬 캐시 대체 (3).

 

빨리 어느 정도 시스템 포인트의 성능 병목 현상을 찾을 수 등 MAT와 같은 도구를 사용하여 기존의 의미에서 코드 리뷰뿐만 아니라 나쁜 코드의 위치,하십시오. 그러나 궁극적으로하기 위해 특정 장면이나 바인딩 비즈니스 데이터,하지만 보조 코드 검토, 성능 테스트 도구, 데이터 라인, 심지어 시뮬레이션 배수 등의 필요성에 묶여 경우에 성능 문제의 원인을 확인합니다. 다음은 우리의 나쁜 코드의 일부를 요약 한 것입니다 수도 일부 기능, 참조 용 :

 

• 기본적인 프로그래밍 사양 않고 코드 (1) 나쁨 가독성;

• (2) 오브젝트 생성하거나 너무 큰 물체, 메모리 누출 생성 같은;

• (3) IO 과도한 흐름 작동하거나 해제하는 것을 잊지;

• 과도한 (4) 데이터베이스 작업은 트랜잭션이 너무 깁니다;

• 동기화 오류 시나리오 사용 (5);

• (6)에 루프 반복 동작 시간을 소모.

 

데이터베이스 계층 튜닝 : 교착 상태 악몽

장면 데이터베이스가 매우 일반적으로 대부분의 Java 응용 프로그램의 경우, 특히 OLTP 애플리케이션을 요구하고이 데이터 일관성을 위해, 데이터베이스 성능을 직접 전체 응용 프로그램의 성능에 영향을 미칠 것입니다, 상호 작용할 수 있습니다. 광고주 및 광고 제공 플랫폼의 적시성 및 재료의 일관성 등 Sogou는 비즈니스 플랫폼 시스템은 높은 요구를 가지고, 우리는 또한 경험을 축적하고 관계형 데이터베이스 최적화에 있습니다.

 

쉽게 데이터베이스 교착 될 물질 라이브러리 (특히 벌크 공구 조작을 통해) 동작의 높은 주파수를 광고에 대한보다 일반적인 시나리오 중 하나가 재료 가격 조정 광고를 발생한다. 고객은 입찰 물질의 빈번한 조정하는 경향이, 따라서 간접적으로도 교착 상태의 가능성에 기여 데이터베이스 시스템을로드하기 위해 더 큰 압력을 발생합니다. 아래의 광고 시스템 케이스 Sogou는 비즈니스 플랫폼 광고 재료 가격 조정을 설명한다.

 

일 방문 증가 시스템 부하 및 데이터베이스 자주 교착 상태의 결과로 상용 시스템의 급격한 증가는, 교착 상태 문은 그림 13에 표시됩니다.

그림 13. 교착 상태 문

 

 

상기 엔진 이노 MySQL을 사용, 인덱스 테이블 idx_groupdomain_accountid (계정 아이디) idx_groupdomain_groupid (그룹 ID), 3 개의 단일 인덱스 구조 차 (groupdomainid)를 groupdomain.

그룹 입찰가를 업데이트 한 장면 그룹, 산업 그룹 (groupindus 테이블) 및 그룹 웹 사이트 (groupdomain 테이블)이있을 때이 시나리오가 발생합니다.

 

그룹 입찰가를 업데이트 할 때, (그것이 사용 그룹 입찰가 경우, isusegroupprice로 표시) 그룹 입찰가를 사용하여 산업 그룹 입찰하는 경우. (이 산업 그룹 입찰가를 사용하는 경우, isuseindusprice로 표시) 입찰 팀 웹 사이트가 산업 그룹 입찰가를 사용하는 경우 동시에, 그룹은 또한 웹 사이트 입찰을 업데이트해야합니다. 그룹 입찰가를 업데이트 할 때 3000 사이트 다음 각 그룹에 대해 가능한 최대 때문에 그래서 관련 기록이 고정됩니다 오래.

 

교착 문제는 트랜잭션 1 이상에서 알 수있는 트랜잭션과 2 번의 인덱스를 idx_groupdomain_accountid 선택된다. 고정되면 보조 인덱스의 사용, 기본 키 인덱스를 잠그려고 할 경우 엔진 잠금이 인덱스를 사용하도록 선택하는 단일 트랜잭션 기능을하지만, 이노 디비 MySQL의에 따르면. 2 거래 요청 유지 ( "스페이스 ID 5726 페이지 없음 8658 N 비트 (824) 인덱스"의 로크 범위) idx_groupdomain_accountid` 보조 인덱스 '하지만 트랜잭션 로크 트랜잭션 차 인덱스 2 ( "공간되었음을 추가 분석 프로그램 ID 5726 페이지에 아무런 8658 N 비트 824 지수 ") 추가 잠금 장치, 기본 키 인덱스 차 인덱스에 대한 잠금을 기다리는 잠금 요청. 대기 트랜잭션 실행 시간이 너무 길거나이 오래되지 않은 트랜잭션 롤백의 결과로, 잠금을 해제하는 것입니다으로 최종 1가 발생합니다.

 

하루 방문 로그 추적 볼 수 있습니다으로 잠금을 해제 할 수있는 이전 트랜잭션의 키 PRIMARY 인덱스를 기다리고 기본 루프에서 대량의 트랜잭션의 결과로, 그 날 스크립트 방법을 통해 그룹의 작업을 촉진하기 위해 고객의 입찰에 의해 시작된 수정의 종류는 매우 다양하다. 이 문제는 유명하지 않은 Oracle 데이터베이스에서 제한적으로 사용을위한 인덱스의 MySQL InnoDB의 엔진에서 실제로 거짓말 문제의 소스.

 

자연적인 방법은 가능한 한 레코드의 수가이 교착 가능성이 크게 감소 될 단일 트랜잭션 로크를 해결하는 것이다. 최종 사용 (계정 아이디, 그룹 ID) 지수, 단일 트랜잭션 로크 레코드의 수를 줄일뿐만 아니라, 이에 의해 이러한 교착 상태의 발생 확률을 줄여 다른 프로그램 하에서 데이터 레코드의 분리의 실현을 촉진.

 

일반적으로 우리는 기본적으로 다음과 같은 측면에서 시작됩니다 데이터베이스 계층을 튜닝, 말하기 :

(1) SQL 문 레벨 최적화 : 느린 SQL 분석, 지수 분석 및 조정, 분할 및 기타 사항을;

(2)는 데이터베이스의 구성을 최적화하는 단계 : 이러한 필드는 버퍼 크기, 디스크를 조정하도록 설계된 I / O 데이터베이스 파라미터 최적화, 데이터 조각 모음;

(3) 구조 레벨을 최적화하기 위해 데이터베이스에서 분할하는 수직 및 수평 분할 데이터베이스를 고려하고, 같은;

(4) 적합한 데이터베이스 엔진을 선택하거나 같은 도입 등을 고려되는 NoSQL 같은 장면의 다른 유형에 적응.

 

여덟, 요약 및 권고

 

2-8 튜닝 성능 문제 따라서 키 코드 곱셈기의 최적화, 생성 된 코드의 80 %에서 20 %로 동일한 원리를 따른다. 동시에, 오버 최적화 더 많은 문제를 초래할 수있다, 할 주문형 최적화의 성능을 최적화 할 수 있습니다. 자바 성능 튜닝, 시스템 아키텍처, 응용 프로그램 코드를 이해하는 것이 아니라, 같은 관심의 JVM 레벨과도 기본 운영 체제가 필요합니다. 다음과 같은 점에서 고려 될 수있는 기본을 요약하면 :

 

1) 조정 및 성능

자료 등록은 여기에 하드웨어 수준을 의미 또는 시스템 버전 업그레이드, 하드웨어 최적화를 운영, 같은 네트워크 튜닝으로, 운영 시스템 레벨 최적화를 업그레이드 할 수 있습니다. 이용 F5의 하드 드라이브와 SDD와 같은 응용 프로그램을 촉진 크게 할 수있는 성능의 리눅스 업그레이드 NIO 측면의 새로운 버전을 포함하여, 도입;

 

2) 데이터베이스 성능 최적화

일반적인 업무 분할, 인덱스 튜닝, SQL 최적화, 포함되는 NoSQL은 트랜잭션이 분할 비동기 처리의 도입으로 도입하고, 궁극적으로 특정 장면되는 NoSQL 데이터베이스의 다양한 유형의 도입을 포함한 관행의 일관성 도입을 달성 다른, 크게 높은 동시성에서 기존 데이터베이스의 부족을 완화 할 수 있습니다;

 

3) 애플리케이션 프레임 워크 최적화

계산 원래 클러스터의 성능 병목 현상을 해결하기 위해 새로운 기능, 새로운 컴퓨팅 또는 스토리지 프레임 워크를 소개 등 또는 분산 전략의 도입을 포함, 컴퓨팅 및 스토리지 수준의 시간 전형적인 연습 공간을 사용하여, 사전에 미리가 계산 등 등; 부하가 어느 정도 저감 할 수있는 시스템;

 

최적화 4) 동작 레벨

기술은, 사실, 당신이 종종 가장, 사실, 할 경우 사업의 회피 또는 조정으로 인해 발생하는 특별한 비즈니스 시나리오의 많은 부분을 볼 수있는 성능 문제의 많은 장면에서 시스템 성능을 향상시킬 수있는 유일한 수단이 아니다 효과적인.