개발된 시스템에서는 데이터베이스의 절전 상태에 빈 연결이 많이 있습니다. 동시에 로그를 통해 타사 API의 피드백에도 많은 예외가 있는 것으로 나타났습니다. 시스템에서 PHP의 컬을 통해 요청한 인터페이스는 두 가지를 연결하여 이유를 분석할 수 밖에 없습니다. 로그에는 타사 인터페이스가 느리게 응답하고 결과가 비어 있음이 반영되어 있습니다. 이유는 알 수 없지만, 대기 프로세스 중에 PHP가 연결이 반환될 때까지 기다리는 것으로 추정됩니다. 컬 시간이 초과되고 프로세스가 실행된 후 데이터베이스 링크가 해제될 때까지 대기합니다.
1. PHP+mysql+memcache 실용 기술 테스트
이상한 질문이 두 개 있습니다. 문제는 매우 이상하지만 모두 실제 전투에서 발생하는 사례입니다.
mysql 사용시에는 memcache도 함께 사용해야 하는데,
첫 번째 줄은mysql_connect, 두 번째 줄은 memcache_connect
덮어 쓰고, 첫 번째 줄은 memcache_connect, 두 번째 줄은 mysql_connectcaoz는 이 두 가지 방법을 찾았습니다. 실제로 글쓰기에는 큰 차이가 있는데, 무엇이 다른가요? 2: mysql을 사용하여 프로그램을 작성하고 페이지를 생성한 후 마지막으로 echo $html;을 사용하여 출력했습니다. 작성 방법 중 하나는mysql_close();
echo $html;다른 방법입니다. echo $html;mysql_close();caoz는 실제로 둘 사이에 큰 차이가 있음을 발견했습니다. 둘 다 실제로 발견하고 조정한 사례입니다. caoz는 프로그램을 작성할 때 BT를 추구하는 사람이 아닙니다. caoz는 엔지니어들에게 극단적인 기술적 표현이나 기술적인 과시를 추구하지 않는다는 점을 자주 강조합니다. 따라서 독자들이 여기에 있는 질문은 소위 특정 이유 때문이라고 생각한다면. 쓰기 방법은 특정 쓰기 방법보다 자원 집약적이지 않습니다. 조금이라도 다른 것이라면 이것은 실제로 caoz의 의도가 아닙니다. 이 두 가지 질문은 실제 운영 환경에서 발생하는 일반적인 사례입니다. 즉, 시스템 장애가 발생했을 때 어떻게 분석하고, 어떻게 생각하며, 여러 관련 요인의 영향을 어떻게 판단하는지가 중요합니다. 따라서 이 질문에 답할 수 있는지 여부는 중요하지 않습니다. 시스템 간의 관계를 어떻게 생각하는가입니다. 일반적인 시스템 오류는 MySQL 연결이 너무 많거나 연결이 너무 많은 경우입니다. 이 문제는 오랫동안 우리를 괴롭혔습니다. 인덱싱이나 동시 데이터 요청으로 인해 발생하는 경우 원인을 찾는 것이 복잡하지 않습니다. 위의 문제가 해결되었고, 이상한 현상이 발생했습니다. 데이터베이스에 대한 압박도 거의 없었고, 프로세스가 차단되지도 않았으며, 쿼리 속도도 느려지지 않았습니다. 그러나 mysql 연결이 많았으며 모두 절전 연결이었습니다. 이때 웹서버에 대한 링크도 많이 존재합니다. 즉, PHP 실행이 차단되기 때문에 MySQL 링크를 빠르게 해제할 수 없습니다. 그렇다면 PHP는 왜 차단되는 것일까요? 중단점별 분석을 통해 에코가 가장 많은 시간을 지연시키는 것으로 나타났습니다. 이 사건은 caoz에게 약간의 경험을 주었습니다. 저는 이전에 echo가 시간 차단 지점이라고 생각한 적이 없습니다(이 시스템에서 테스트하면 시간 지연이 거의 0이라고 생각할 것입니다). 그러나 인스턴스 추적을 통해 echo가 실제로는 발견되었습니다. 우리 작업 환경에서는 라우팅 및 대역폭 요인으로 인해 대표적인 네트워크 전송 프로세스가 대기하게 됩니다. 이때 mysql 링크는 여전히 존재하며 아직 해제되지 않았습니다. 그렇습니다. 누구나 mysql_close를 생각할 것입니다. 제목을 보면 에코 뒤에 와야 하는데 왜 에코가 시간을 지연시키는지 생각하는 사람은 거의 없을 것입니다. 물론 이것은 작업 환경과도 관련이 있습니다. Caoz는 우리가 구성한 웹 서버에 이런 상황이 있을 것이라는 것을 알고 있습니다. Caoz가 테스트하지 않았으므로 감히 말도 안 되는 소리는 아니지만 여기서의 경험은 다음과 같습니다. mysql_close가 echo 앞에 배치되면 많은 수의 절전 링크가 빠르게 감소합니다. echo는 시스템 리소스를 많이 소모하지 않지만, 네트워크 전송을 기다리게 되므로 동시성이 높은 네트워크 환경에서는 데이터베이스가 이에 주의하는 것이 좋습니다. 이 문제가 해결된 후 mysql은 훨씬 건강해졌으나 간헐적으로 너무 많은 링크가 발생하는 문제가 오랫동안 나를 괴롭혔습니다. 어느 날 사용자들이 보고한 일부 두 질문 모두 최종 분석에서 동일한 의미를 갖습니다. 시스템 문제 및 오류가 발생할 때 일부 관련 요소의 영향과 전체 아키텍처의 응답 순서 논리에 대해 더 생각해 보십시오. 네, 웹링크가 너무 많아서 굳이 웹서버를 최적화할 필요는 없습니다. 관련 요인이 근본 원인일 수도 있습니다. 근본 원인을 해결해야만 증상이 완전히 해결됩니다. 2. MySQL의 Sleep 프로세스를 줄이는 효과적인 방법1. 일반적으로 MySQL은 PHP의 MySQL 긴 링크 데이터베이스 방식, 즉 mysql_pconnect를 사용하여 링크된 데이터베이스를 여는 방식을 채택하기 때문에 Sleep 프로세스가 많습니다. 즉, "짧은" 링크를 사용하는 것입니다. , mysql_connect 함수.
2. mysql_connect 짧은 링크 방법을 사용하여 데이터베이스를 열면 각 페이지는 데이터베이스를 연 후 SQL을 실행합니다. 페이지 스크립트가 끝나면 MySQL 연결이 자동으로 닫히고 메모리가 해제됩니다. 그러나 여전히 많은 수의 절전 프로세스가 있습니다. 웹 사이트에 다음과 같은 문제가 있는지 확인할 수 있습니다.
A. 하드 디스크에 정적 파일이 많거나, 웹 서버의 로드가 너무 많아 HTTP 요청에 대한 응답이 너무 느려질 수도 있습니다. 이로 인해 절전 프로세스가 많이 발생할 수도 있습니다. 웹 서비스 매개 변수 및 파일을 적절하게 조정하고 맹목적으로 정적이거나 웹 콘텐츠를 캐싱하는 것은 만병통치약이 아닙니다.
B, 웹 스크립트에서 일부 계산 및 응용 프로그램은 시간이 많이 걸릴 수 있습니다. 예를 들어 0초에 데이터베이스를 열고 SQL 코드를 실행한 후 웹 스크립트는 복잡한 작업을 수행하는 데 20초를 소비하거나 A를 요구합니다. 거대한 PHP 파일(예: 수천 개의 불법 키워드가 포함된 필터 함수) 이때 MySQL 백그라운드에서 볼 수 있는 프로세스에서 MySQL은 이 20초 동안 아무 작업도 수행하지 않았으며 페이지까지 항상 Sleep 상태였습니다. 실행을 완료하거나 wait_timeout 값에 도달(강제적으로 닫힘)하거나, 웹 페이지 스크립트를 최적화하고 프로그램이 가능한 한 빨리 실행되도록 하거나, mysql_close를 실행하여 시간이 많이 걸리는 실행 프로세스 중에 현재 MySQL 링크를 강제로 닫습니다.
C, 컬렉션 스테이션에서 MySQL의 Sleep 프로세스 수가 많은 현상은 특히 분명합니다(예를 들어 많은 네티즌들이 DeDeCMS의 MySQL에서 Sleep 프로세스의 수가 많은 것에 대해 질문했습니다). 왜냐하면 대부분의 컬렉터 페이지에는 사전 -작업 중에 MySQL 링크를 연 다음(아마도 사용자 권한 등을 확인하기 위해) 원격 사이트의 액세스 속도가 너무 느린 경우 file_get_contents와 같은 작업을 사용하기 시작합니다. 예를 들어, 웹 페이지를 가져오는 데 10초가 걸립니다. 답변, 현재 수집 스크립트 프로그램은 여기서 차단되었으며 MySQL은 아무 작업도 수행하지 않고 Sleep 상태였습니다. 해결 방법은 위와 동일합니다. 원격 웹 페이지를 수집하기 위해 file_get_contents를 실행하는 경우 mysql_close를 사용하여 MySQL 연결을 강제로 닫습니다. 그런 다음 적절한 경우 mysql_connect를 다시 수행합니다.
위 내용은 PHP와 MySQL에서 절전 모드의 빈 연결 프로세스를 줄이는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
