1. 어떤 요소가 시스템의 병목 현상이 될 것인가
- CPU: 연산량이 많으면 중단 없이 오랫동안 CPU 리소스를 점유하게 되어 다른 리소스가 CPU를 놓고 경쟁하지 못하고 응답이 느려져 FullGC가 자주 발생하는 등 시스템 성능 문제가 발생하고, 멀티 스레딩 스위칭으로 인해 발생하는 빈번한 컨텍스트는 CPU를 사용하게 하므로 일반적으로 CPU 사용량은 75% 미만이 더 적합합니다.
- 메모리: Java 메모리는 일반적으로 jvm 메모리를 통해 할당되며, 주로 jvm의 힙 메모리를 사용하여 Java로 생성된 객체를 저장합니다. 메모리의 읽기 및 쓰기 속도는 매우 빠르지만 메모리 공간이 제한되어 있어 메모리 공간이 가득 차서 개체를 재활용할 수 없으면 메모리 오버플로 또는 메모리 누수가 발생합니다.
- 디스크 I/O: 디스크의 저장 공간은 메모리보다 훨씬 크지만 디스크의 읽기 및 쓰기 속도는 메모리보다 느립니다.현재 SSD 솔리드 스테이트 드라이브가 도입되었지만 여전히 메모리의 속도와 비교하십시오.
- 네트워크: 대역폭의 크기는 전송되는 데이터에 큰 영향을 미치며 동시성이 증가하면 네트워크에 병목 현상이 발생하기 쉽습니다.
- 예외: Java 프로그램은 예외를 발생시키고 예외를 포착해야 합니다. 이 프로세스는 성능을 소비합니다. 높은 동시성 조건에서 예외가 지속적으로 처리되면 시스템 성능에 영향을 미칩니다.
- 데이터베이스: 데이터베이스 작업에는 일반적으로 디스크 I/O 읽기 및 쓰기가 포함됩니다. 많은 수의 데이터베이스 읽기 및 쓰기로 인해 디스크 I/O 성능 병목 현상이 발생하고 데이터베이스 작업이 지연됩니다.
동시 프로그래밍을 할 때 동일한 자원을 운영하기 위해 여러 개의 쓰레드를 사용하는 경우가 많은데, 이때 데이터의 원자성을 보장하기 위해서는 락(lock)을 사용해야 하는데, 락을 사용하면 컨텍스트 스위칭(Context Switching)이 발생하여 성능 오버헤드가 발생한다. JDK1. 6 이후에는 바이어스 잠금, 스핀 잠금, 경량 잠금, 잠금 조대화 및 잠금 제거가 추가됩니다.
2. 시스템 성능을 측정하는 데 사용되는 지표
1. RT 응답 시간
- 데이터베이스 작업 시간인 데이터베이스 응답 시간
- 서버의 응답 시간은 서버가 Nginx에서 배포한 요청에 소요된 시간과 서버 프로그램 실행에 소요된 시간을 포함합니다.
- 네트워크 응답 시간, 네트워크 전송, 전송된 요청을 분석하기 위해 네트워크 하드웨어가 소비하는 시간
- 클라이언트의 응답 시간은 일반적으로 Web 및 App 클라이언트에서 무시할 수 있지만 클라이언트가 많은 논리 처리를 수행하는 경우 소요되는 시간이 더 길어질 수 있습니다.
2. TPS 처리량
- 디스크 처리량: 단위 시간당 시스템이 처리할 수 있는 I/O 요청 수인 초당 IOPS(Input/Output Per Second) 입력 및 출력 I/O 요청은 일반적으로 읽기 또는 쓰기 데이터 작업 요청이며 포커스 랜덤 읽기 및 쓰기 성능, 작은 파일 저장, 메일 서버와 같이 랜덤 읽기 및 쓰기가 빈번한 응용 프로그램에 적합합니다. 데이터 처리량(Data Throughput) 단위 시간당 전송할 수 있는 데이터의 양으로, 동영상 편집과 같이 순차적인 읽기 및 쓰기가 많은 응용 프로그램의 경우 대량의 연속 데이터를 전송합니다.
- 네트워크 처리량: 장치가 네트워크 전송 중에 프레임 손실 없이 수용할 수 있는 최대 데이터 속도를 나타냅니다. 네트워크 처리량은 대역폭뿐만 아니라 CPU 처리 능력, 네트워크 카드, 방화벽 및 I/O와 밀접한 관련이 있으며 네트워크 카드의 처리 능력, 내부 프로그램 알고리즘 및 대역폭에 의해 처리량이 결정됩니다.
3. 자원 활용
- CPU 사용량은 물리적 CPU 개수, 단일 CPU의 코어 개수 등 CPU의 기본 정보를 먼저 파악한 다음 vmstat, mpstat, top 명령을 통해 사용량을 확인할 수 있습니다.
- 메모리 사용량, free -m, vmstat, top
- 디스크 I/O, iostat, iotop
- 네트워크 I/O, netstat, ifconfig, tcpstat
3. 성능 테스트에서 주의해야 할 문제점
우리가 성능 테스트를 할 때 시스템이 점점 더 빨라지고 후속 액세스 속도는 첫 번째 액세스 속도보다 몇 배 더 빠릅니다.Java 언어 컴파일 순서는 .java 파일이 먼저 .class로 컴파일되기 때문입니다. 그런 다음 .class의 바이트코드를 실행하기 전에 인터프리터를 통해 로컬 기계 코드로 변환합니다.
메모리와 실행 효율성을 절약하기 위해 코드가 처음 실행될 때 인터프리터가 먼저 이 코드를 해석하고 실행합니다. 코드 실행 횟수가 증가함에 따라 가상 머신은 특정 메서드나 코드가 특히 자주 실행되는 것을 발견하고 이를 핫스팟 코드(Hot Spot Code)로 식별합니다.
핫 코드의 실행 효율을 높이기 위해 가상머신은 런타임에 이 코드를 JIT(Just-In-Time Compiler)를 통해 로컬 플랫폼과 관련된 머신 코드로 컴파일한 다음 메모리에 저장한다. 이로 인해 시스템이 처음으로 느리게 실행되고 후속 방문 속도가 몇 배 더 빨라집니다.
성능 테스트를 할 때 각 테스트에서 처리하는 데이터 세트는 같지만 결과가 다른 이유는 테스트에는 다른 프로세스가 기계에 미치는 영향, 네트워크 변동, 각 테스트마다 여러 가지 불안정한 요소가 수반되기 때문입니다. JVM 가비지 수집의 여러 단계. 우리는 여러 테스트를 통과하고 테스트 결과의 평균을 낼 수 있습니다.평균값이 합리적인 범위 내에 있고 변동이 너무 크지 않으면 성능 테스트가 통과됩니다.
4. 성능 문제를 찾을 때 상향식 전략 분석 및 문제 해결을 사용할 수 있습니다.
압력 테스트를 수행한 후 스트레스를 받은 서버의 RT, TPS, TP99, CPU, 메모리, I/O 및 JVM의 GC 주파수를 포함한 성능 테스트 보고서를 출력합니다. 이러한 지표를 통해 성능 병목 현상을 발견하고 이를 상향식으로 분석할 수 있습니다.
1. 먼저 운영 체제 수준에서 시스템의 CPU, 메모리, I/O, 네트워크 사용량이 비정상인지 확인한 다음 명령을 통해 비정상 로그를 검색하고 마지막으로 로그 분석을 통해 병목 현상의 원인을 찾습니다. .
2. Java 애플리케이션의 JVM 레벨에서 JVM의 가비지 콜렉션 빈도 및 메모리 할당에 이상이 없는지 확인하고 가비지 콜렉션 로그를 분석하여 병목 현상의 원인을 찾을 수 있습니다.
3. 시스템 및 JVM 레벨에서 비정상적인 상황이 없다면 애플리케이션 서비스 비즈니스 계층에서 성능 병목 현상(예: Java 프로그래밍 문제, 데이터베이스 읽기 및 쓰기 병목 현상 등)이 있는지 확인할 수 있습니다.
5. 성능 문제를 최적화할 때 하향식 최적화 전략을 사용할 수 있습니다.
전반적인 튜닝 순서는 비즈니스 튜닝에서 프로그래밍 튜닝으로, 마지막으로 시스템 튜닝으로 갈 수 있습니다.
1. 애플리케이션 레이어 튜닝
첫 번째는 코드를 최적화하는 것인데, 시스템 리소스 소모로 인해 코드 문제가 자주 노출되는데, 예를 들어 코드로 인해 메모리 오버플로가 발생하여 JVM 메모리가 고갈되고, FullGC가 자주 발생하여 CPU 사용량이 많아지는 경우가 있습니다.
두 번째는 디자인 최적화, 주로 비즈니스 계층과 미들웨어 계층의 코드를 최적화하는 것입니다.예를 들어 자주 호출되는 객체를 생성하는 장면에서 프록시 모드를 사용할 수 있으며 생성 객체를 공유할 수 있습니다. 개체 생성 소비를 줄입니다.
세 번째는 알고리즘을 최적화하고 적절한 알고리즘을 선택하여 시간 복잡도를 줄이는 것입니다.
2. 미들웨어 튜닝: MySQL 튜닝
1) 테이블 구조 및 인덱스 최적화
주로 데이터베이스 설계, 테이블 구조 설계, 인덱스 설정 차원을 최적화하는 것으로, 테이블 구조를 설계할 때 데이터베이스의 수평적, 수직적 확장 능력을 고려하고, 향후 데이터 양, 읽기 및 쓰기 양의 증가를 미리 계획하고, 하위 데이터베이스 계획 하위 테이블 계획. 더 작은 데이터 구조를 선호하는 필드에 적합한 데이터 유형을 선택합니다.
2) SQL 문 최적화
주로 SQL 문을 최적화하기 위해 Explain을 사용하여 실행 계획을 보고 인덱스 사용 여부와 사용되는 인덱스를 확인합니다. 또한 프로필 명령을 사용하여 명령문 실행 프로세스의 각 단계에서 소요되는 시간을 분석할 수 있습니다.
3) MySQL 파라미터 최적화
주로 연결 수 관리와 같은 MySQL 서비스의 구성을 최적화하고 인덱스 캐시, 쿼리 캐시 및 정렬 캐시와 같은 다양한 캐시의 크기를 최적화합니다.
4) 하드웨어 및 시스템 구성
운영 체제 매개변수 조정, 스왑 비활성화, 메모리 증가, 솔리드 스테이트 드라이브 업그레이드와 같은 하드웨어 장치 및 운영 체제 설정을 최적화합니다.
3. 시스템 튜닝
첫 번째는 운영 체제 튜닝으로 Linux 운영의 커널 매개변수 설정을 튜닝하여 고성능을 제공하는 목적을 달성할 수 있습니다.
둘째, JVM 튜닝, 합리적인 JVM 메모리 공간 설정 및 성능 향상을 위한 가비지 수집 알고리즘. 젊은 세대에서 CPU 사용 시간을 줄이기 위해.
4. 튜닝 전략
첫 번째는 시간을 공간으로 교환하는 것입니다.때때로 시스템은 높은 쿼리 속도를 요구하지 않지만 높은 저장 공간 요구 사항을 요구합니다.이 때 시간을 공간으로 교환하는 것을 고려할 수 있습니다.
둘째, 공간을 시간으로 교환하고, 저장공간을 이용하여 접근속도를 향상시키는 전략으로 MySQL의 sub-database와 sub-table 전략이 대표적이다. 이 때 우리는 데이터를 분할할 수 있습니다. , 쿼리를 달성하기 위해 각 테이블의 데이터는 소량이며 성능 향상의 목적을 달성하기 위해.
5. 앞뒤 전략
시스템이 조정된 후에도 여전히 성능 문제가 있을 것입니다. 이때 상향식 전략이 필요합니다. 첫 번째는 흐름을 제한하고 시스템 입구에 최대 액세스 제한을 설정하고 퓨즈를 가져가는 것입니다. 실패한 요청을 반환하는 조치. 두 번째는 수평 확장으로, 트래픽이 일정 임계값을 초과하면 시스템이 자동으로 서비스를 수평 확장할 수 있습니다.
다음은 지원 정보입니다.[소프트웨어 테스트]를 하는 친구에게 가장 포괄적이고 완벽한 준비 창고가 되어야 합니다.이 창고는 또한 가장 어려운 여정을 함께했습니다.당신에게도 도움이 되기를 바랍니다!
소프트웨어 테스트 인터뷰 애플릿
소프트웨어 테스트 문제 은행은 수백만 명의 사람들이 최대로 채웠습니다! ! ! 누가 알겠어! ! ! 전체 네트워크에서 가장 포괄적인 퀴즈 미니 프로그램으로, 지하철이나 버스에서 휴대폰을 사용하여 퀴즈를 풀 수 있습니다.
다음 인터뷰 질문 섹션이 다룹니다.
1. 소프트웨어 테스팅의 기초이론, 2. 웹, 앱, 인터페이스 기능 테스팅, 3. 네트워크, 4. 데이터베이스, 5. 리눅스
6. 웹, 앱, 인터페이스 자동화, 7. 성능 테스트, 8. 프로그래밍 기본 사항, 9. 시간 인터뷰 질문, 10. 공개 테스트 질문, 11. 보안 테스트, 12. 컴퓨터 기본 사항
정보 획득 방법:
