여기서는 시나리오대로 가죠. 결국 시나리오는 실용성을 경험할 수 있는 가장 좋은 곳입니다. 먼저 서버 구성 및 환경에 대해 이야기하겠습니다
Alibaba Cloud ECS 클라우드 호스트, 8G 메모리, 4 코어 CPU, 20M 대역폭, 20G 시스템 디스크 + 200G 데이터 디스크, CentOS 6.564 비트, 통합 lnmp 환경 설치
시나리오: 보내기 WeChat의 빨간 봉투
이 시나리오는 매우 일반적입니다. 일반적으로 고객은 해당 시간에 WeChat 공식 계정에 광고를 푸시합니다. 이때 서버 동시성은 약 3000~5000입니다. 말하자면 이것은 실제로 높은 동시성으로 간주되지는 않지만 여전히 서버가 충돌하여 정상으로 돌아오는 데 약 5분 정도 걸렸습니다. 이는 다소 부적절합니다. 이유를 분석해 보겠습니다. CPU 사용률이 높지 않고 메모리 사용량이 정상입니다. Alibaba Cloud 제어판에서 네트워크 송신 트래픽이 꽉 찬 것 같습니다.
먼저 정적 리소스를 확인해보니 대부분의 사진이 최적화되지 않은 것을 발견하여 사진을 떼어내고 무손실 압축을 수행했습니다. 아마도 1M 정도 크기를 생략한 것 같습니다. 제출한 후에도 여전히 충돌이 발생하고 서버가 자주 502를 표시합니다. .
페이지의 정적 리소스 CSS와 js를 다시 확인하고 일반적으로 사용되는 js 라이브러리를 CDN으로 교체하여 요청 수를 줄인 후 제출 후에도 여전히 큰 변화가 없으며 502가 동일하게 유지됩니다.
따라서 nginx 연결 수를 확인하고
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
명령을 사용하세요. 결과는
TIME_WAIT 3828SYN_SENT 1FIN_WAIT1 107FIN_WAIT2 27ESTABLISHED 661SYN_RECV 23CLOSING 15LAST_ACK 284
좋습니다. TIME_WAITE가 매우 높습니다. 여기에서 TIME_WAITE의 의미에 대해 이야기하세요. TIME_WAIT: 반대편. 릴리스를 초기화했습니다. 이것은 무엇을 의미합니까? 이는 서버가 적극적으로 종료되었으며 클라이언트의 응답을 기다리고 있음을 의미합니다. 클라이언트가 응답하지 않으면 대기하며 이 값이 증가합니다. 당연히 이때 TIME_WAIT 값을 줄여야 합니다.
여기서는 sysctl.conf의 일부 매개변수만 수정하면 됩니다. /etc/sysctl.conf 파일을 편집하고
해당 설정을 찾을 수 없으면 끝에 추가하세요. 파일. 저장한 후
/sbin/sysctl -p
구성을 실행하여 적용하세요.
20분 후에 계속해서 nginx 연결 수를 확인하세요. 결과는
TIME_WAIT 87SYN_SENT 1FIN_WAIT1 60FIN_WAIT2 19ESTABLISHED 477SYN_RECV 12CLOSING 2LAST_ACK 100
정상으로 돌아왔고 네트워크 대역폭도 떨어졌습니다.
하지만 좋은 시간은 오래 가지 못했습니다. 두 번째 시간에 빨간 봉투를 잡기 시작했을 때 502가 다시 나타났습니다. 프로세스를 검사한 결과 mysqld의 CPU 사용량이 매우 높아서 CPU가 완전히 로드되고 서버가 충돌하는 것으로 나타났습니다. mysql 구성 파일을 수정하고 max_connection을 30000으로 조정합니다. 기타 관련 매개 변수를 조정하고 최적화하여 상황은 완화되었지만 몇 분 내에 CPU가 다시 완전히 로드되었습니다.
이상해요! 그래서 mysql에서 프로세스를 확인해 보니 SQL 쿼리가 빈번하게 발생하고, 쿼리된 여러 테이블의 데이터량이 10만 개 정도인 것으로 판단됐다. 백엔드 개발을 컨설팅한 결과 기본키만 설정되어 있는 것으로 나타났습니다. 제출한 지 5분 만에 CPU가 떨어지고 10% 정도에서 안정됐고, 502는 더 이상 나오지 않았다.
위 내용은 서버 유지 관리의 높은 동시성 처리로 인해 발생하는 몇 가지 일반적인 문제를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!