경경계의 가용성과 성능 최적화
2803 단어 서버성능 최적화springboot
문제
어제 새벽 1시가 넘었는데 V친구가 너무 열정적이거나 파충류가 너무 부지런해서 경경지의 서버가 다운되었는지 슬그머니 오류 로그를 남기지 않았습니다.
나는 오전에 사용자의 피드백을 받았는데, 빨리 서버를 다시 시작해서 놀라움을 가라앉히고 다시 원인을 분석해야 한다.
오류 일지도 없는데 이게 어느 정도 문제인가요?
가장 큰 가능성은 JVM 메모리가 부족하거나 스레드 수가 너무 많다는 것입니다.관련 매개변수를 조정해야 합니다.
서버가 자동으로 복구될 수 있도록 해야 한다.
메모리
JVM 메모리를 조정하기 전에 시스템 메모리 사용량을 확인하십시오.
$ free -m
total used free shared buff/cache available
Mem: 1696 1336 68 20 291 155
Swap: 0 0 0
빈 메모리가 거의 없습니다.
어떤 프로세스가 메모리를 먹었는지 다시 봅시다.
11869 sorrada+ 20 0 2438544 *417292 15332 S 0.7 24.0 1:24.82 java
5442 sorrada+ 20 0 2420764 *353808 0 S 0.0 20.4 278:47.83 java
3876 mysql 20 0 1111688 *203020 0 S 0.3 11.7 18:38.52 mysqld
2026 sorrada+ 20 0 3118488 *313664 0 S 0.0 18.1 580:09.45 java
첫 번째는 경경계본체(417M), 두 번째는 중요하지 않은 프로그램(353M), 세 번째는 MySQL(203M), 네 번째는 ElasticSearch(313M)이다.
그래서 나는 그 중요하지 않은 프로그램을 죽였다. 현재 메모리 상황은 다음과 같다.
$ free -m
total used free shared buff/cache available
Mem: 1696 986 431 20 277 505
Swap: 0 0 0
그리고 JVM의 최대 메모리 매개 변수를 조정하려면 G를 하나 주세요 ~
-Xmx1024m
.스레드 수에 대해 문서를 찾아봤습니다.
얼마나 고치면 좋을까요?내가 계산해 보니 최악의 경우 한 라인당 평균 5MB를 먹고 100라인은 500MB이다. 게다가 이미 점용한 약 400MB를 더하고 JVM 백그라운드 라인과 MetaSpace를 더하면 1G를 다 쓸 뻔했다. 캐시에 남겨둘 공간이 없고 Full GC를 자주 촉발하여 거북이 속도가 될 것이다.그럼 상한선을 60선으로 합시다!
Spring Boot 응용 프로그램을 수정합니다.properties
server.tomcat.max-threads = 60
사용 가능 유지(keep alive)
Keepalived 이 도구는 집단의 고가용성을 유지하기에 적합합니다. 저는 서버 하나만 있고 셸 스크립트만 써서 프로세스가 실행 중인지 확인합니다.
https://github.com/sorra/sage...
로그 최적화
로그백에 비동기 파일 출력을 설정했지만 개발의 편의를 위해 사용하지 않고 동기화 파일 출력과 컨트롤러로 출력했습니다.
Spring의 Profile 기능을 활용하여 환경에 따라 다양한 Logback 구성을 로드할 수 있도록 개선해야 합니다.예를 들어 프로필=production을 사용할 때 비동기 파일 출력을 사용하고 동기화 파일 출력을 닫으며 컨트롤러 출력을 닫습니다.
src/main/resources/application에 있습니다.properties 파일에 기본 구성 항목이 저장되어 있습니다. 이 줄을 포함하여 환경을 개발 환경으로 설정합니다.
spring.profiles.active = dev
# ... other properties ...
나는 또 한 줄만 있는 응용 프로그램을 만들었다.properties 파일, 원본 코드의production-files 디렉터리에 저장되며, 스크립트를 배치하면 자동적으로copy를 생산 환경의 응용 루트 디렉터리에 저장합니다.우선 순위가 높으면 이전 파일의 구성을 덮어씁니다.
spring.profiles.active = production
총결산
JVM 메모리 상한선 조정, Tomcat 스레드 상한선 조정, 자동 복구 지원, 로그 최적화 등의 개선 사항에 대해 설명합니다.
캐시 방면: 현재 첫 페이지의 데이터만 캐시를 하고 있으며, 더욱 캐시를 활용하여 SQL 조회를 줄여야 한다. 특히 전체 테이블 스캐닝을 촉발하지 않도록 해야 한다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
집 서버 설계 (하드웨어 편)자신의 Redmine이나 ownCloud를 운용하기 위해 사쿠라 VPS, DigitalOcean, OpenShift 등을 놀랐습니다만, 침착 해 왔으므로 현상을 정리하고 싶습니다. 먼저 하드웨어 구성을 정리합니다. ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.