이미 사이트나 MySQL 문서 어디에서도 이에 대한 답변을 볼 수 없다는 사실에 상당히 놀랐습니다.섹션 5.2로깅이 잘 처리된 것 같습니다!)
binlog를 활성화하면 (주관적으로) 약간의 추가 IO로 예상되는 작은 성능 저하가 나타납니다. 그러나 일반 쿼리 로그를 활성화하면 엄청난 성능 저하가 나타납니다(쿼리 실행 시간이 두 배, 또는 더 나쁜 경우), binlog에서 보는 것보다 훨씬 더 많습니다. 물론 지금은 모든 UPDATE/INSERT뿐만 아니라 모든 SELECT를 기록하고 있지만 다른 데몬은 중단 없이 모든 요청(Apache, Exim)을 기록합니다.
IO와 관련하여 성능 "티핑 포인트"에 가까워지는 효과를 보고 있는 걸까요, 아니면 이러한 일이 발생하는 쿼리 로깅에 근본적으로 어려운 점이 있습니까? 개발을 더 쉽게 하기 위해 모든 쿼리를 기록할 수 있으면 좋겠지만 일반 쿼리 로깅을 통해 성능을 백업해야 한다고 생각되는 하드웨어 종류를 정당화할 수는 없습니다.
물론 느린 쿼리도 기록하며, 이 기능을 비활성화해도 일반적인 사용에는 미미한 개선이 있습니다.
(이 모든 것은 Ubuntu 10.04 LTS, MySQLd 5.1.49에 있지만 연구에 따르면 이는 상당히 보편적인 문제입니다.)
답변1
일반 쿼리 로그는많은바이너리 로그보다 IO가 더 많습니다. 대부분의 SQL 서버는 읽기 90%, 쓰기 10%라는 사실 외에도 바이너리 로그는 디스크 공간을 덜 사용하는 일반 텍스트가 아닌 바이너리 형식으로 저장됩니다. (얼마나 적은 공간인가요? 잘 모르겠습니다. 죄송합니다.)
Apache와 Exim이 성능에 큰 영향을 주지 않고 모든 요청을 기록할 수 있는 이유에는 두 가지 측면이 있습니다. 첫 번째는 요청이 발생했다는 사실을 기록하지만 로그에 기록하는 내용은 일반적으로 실제 요청보다 훨씬 작다는 것입니다. HTTP 요청은 종종 로그에 들어가는 줄보다 두 배 더 크며, 짧은 일반 텍스트 이메일이라도 그에 수반되는 로그 줄보다 10~20배 더 큽니다. 10MB 첨부 파일이 포함된 이메일의 로그에는 몇 줄만 기록됩니다.
두 번째 부분은 일반적인 웹 애플리케이션에는 일반적으로 단일 HTTP 페이지와 관련된 수십 개의 SQL 쿼리가 있다는 것입니다. 이메일은 HTTP 요청보다 훨씬 적은 수로 오는 경향이 있습니다. 귀하의 MySQL 서버는 아마도 Apache나 Exim보다 훨씬 더 많은 로그를 기록하려고 시도하고 있을 것입니다.
하루가 끝나면 MySQL 바이너리 및 일반 로그와 Apache 및 Exim 로그의 크기(압축되지 않은)를 살펴보세요. 아마도 MySQL 일반 로그는 최소 5배 이상 큰 로그일 것입니다.
답변2
제공된 항목에 추가하려면답변, MySQL 데이터 저장소가 있는 것과 동일한 장치에 로그인하는 경우에도 성능 저하가 발생합니다. 동일한 디스크인 경우 항상 여러 위치에 읽고 쓰게 되어 속도가 느려집니다. 전체 과정.
이는 동일한 물리적 디스크의 다른 파티션인 경우에도 마찬가지입니다.
로깅이 다른 장치로 이동하는 경우 완화되어야 합니다.일부성능 문제 중.