분명히 문제가 있고 디스크 활동이 많은 것 같았는데, 그 활동이 무엇을 성취했습니까? dtrace를 사용하여 추적한 결과 Apple Mail이 하나의 파일을 통해 엄청난 양의 활동을 수행하고 있음을 발견했습니다. 메일은 SQLite라는 오픈 소스 SQL 데이터베이스 모듈을 사용하여 메일 메시지를 추적하는데, 내 메일은 확실히 최적. 이 파일에 대한 자세한 내용을 Google에서 빠르게 확인하면 파일을 최적화하는 명령이 나왔고 다시 한 번 내 이메일을 읽을 수 있었습니다. 만세!
두 번째 예는 훨씬 더 큰 문제에 관한 것입니다. 우리 회사는 100Mb/초 링크로 연결된 두 개의 호스팅 센터에서 웹사이트 모음을 운영하고 있습니다. 호스팅 센터에는 백엔드 데이터베이스 서버와 통신하는 로드 밸런싱된 웹 서버 팜이 있습니다. 이는 많은 메모리와 듀얼 컨트롤러 EMC 파이버 채널 RAID를 갖춘 쿼드 소켓 Opteron Sun입니다. 정렬. 이러한 서버는 MySQL을 실행하며 한 센터의 업데이트가 다른 센터로 복사되어 그곳에서도 실행되도록 복제됩니다.
몇 주 전에 이러한 시스템 중 하나의 성능이 일상적으로 절벽에서 떨어지기 시작했습니다. 일반적으로 생성하는 데 10분의 1초가 걸리는 웹 페이지가 대신 몇 초가 걸립니다. 프런트엔드 웹 서버는 모두 괜찮았고 거의 땀을 흘리지 않았으며 백엔드 데이터베이스도 모든 면에서 괜찮아 보였습니다. "top"과 같은 명백한 도구는 유용한 정보를 제공하지 않으며 MySQL의 성능을 조정합니다. 변수는 큰 개선을 가져오지 못했습니다. 특히 문제를 재현하는 것이 매우 어려웠기 때문입니다. 어려운. 다른 원인이 있을 수밖에 없었습니다. 문제의 가장 암시적인 측면은 하나의 호스팅 센터에만 영향을 미치므로 한 센터에서는 문제가 발생하고 다른 센터에서는 발생하지 않는다는 것입니다. 서로 다른 웹사이트가 서로 다른 센터에서 실행된 것은 사실이지만 모든 데이터베이스 쓰기 트랜잭션이 중복되었습니다.
아이러니하게도 첫 번째 힌트는 제가 앞서 비판했던 겸손한 "iostat"에서 나왔습니다. 한 특정 장치가 최대 90%의 부하로 매우 바쁘고 평균 대기 시간이 내가 원하는 것보다 길다는 것을 보여주었습니다. 파이버 채널과 RAID의 2Gb/초 대역폭을 모두 흡수하고 있다는 것은 정말 놀라운 일이었습니다. dtrace가 없었다면 우리는 이제 순전히 추측만으로 거의 혼자 일했을 것입니다. RAID 장치의 컨트롤러 사이에서 I/O 로드의 균형을 맞춰야 하는데 어떻게 할 것입니까? 그리고 그 원인이 무엇인지 정말로 확신할 수 있을까요?
이것이 dtrace가 실제로 진가를 발휘한 부분입니다. 내가 시도한 첫 번째 일은 dtrace 툴킷의 "rfileio"를 사용하여 정말 바쁜 파일의 신원을 알아내는 것이었습니다. 데이터베이스의 특정 유형의 테이블이 많이 타격을 받고 있다고 말했는데 어떤 종류의 트래픽이 타격을 받았습니까? MySQL dtrace 툴킷(www.pcpro.co.uk/links/163open에서 사용 가능)의 스크립트를 입력하면 MySQL 데이터베이스의 특정 호출을 모니터링할 수 있습니다. 서버(위에 언급된 프로세스 공급자 사용)를 통해 데이터베이스가 실행 중인 SQL 쿼리를 알려주었습니다. 그들을. 한 번의 쿼리가 실행되었을 때 두 개의 쿼리가 실행되는 특별한 경우가 있고 논리 문제도 노출된다는 것을 알 수 있는 패턴이 곧 나타났습니다.
하나로 대체될 수 있는 이 두 가지 쿼리의 경우는 개발자의 잘못이 아닙니다. 테이블에서 하나의 열을 가져온 다음 곧이어 동일한 테이블에서 다른 열을 가져오는 쿼리가 만들어졌습니다. 이 두 쿼리가 서로 나란히 실행되는 것을 볼 수 있었고 이를 통해 중복된 문을 제거할 수 있는 컴파일러의 엿보기 최적화와 같은 기술인 병합이 가능해졌습니다. 이 작업을 수행하면 부하가 심한 경우의 성능 외에도 응용 프로그램의 순간적인 성능(일반적으로 작동하는 방식)을 완전히 변화시킬 수 있었습니다. 일반적으로 1초 이상 걸리던 특정 작업이 이제는 0.4초 미만, 즉 약 3배 더 빠른 속도로 지속적으로 수행됩니다. 또한 애플리케이션을 개선할 수 있는 몇 가지 약점도 보여주었습니다.
