dtrace 오류로 높은 쓰기 I/O "펄싱"

매 10 초마다 디스크에 "pulsing"쓰기 (1 회 쓰기/초 펄싱 최대 142+ 쓰기 아웃/초)가 발생합니다. https://discussions.apple.com/servlet/JiveServlet/showImage/2-22394173-269851/Screen+Shot+2013-07-03+at+13.22.28.png dtrace 오류로 높은 쓰기 I/O "펄싱"

우리는이 "펄스"기록에 파고가 IOTOP에서 이러한 오류로 정확히 같은 시간에 일어날 것을 발견 : 만

dtrace: error on enabled probe ID 5 (ID 992: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0

는 "펄스"

이 예제 이미지보기 위의 오류가 IOTOP에 나타날 때 발생합니다.

참고 : 두 개의 드라이브에 대해 Apple RAID 소프트웨어 미러링을 실행하고 있습니다.

모든 제안, 도움말 및 도움말을 크게 높이 실 것입니다. 미리 감사드립니다.

출처

2013-07-03 Ted Wilmont

당신이보고있는 펄스 입출력 패턴은 많은/대부분의 파일 시스템 쓰기가 비동기적인 응용 프로그램의 특징입니다. 파일 시스템이 쓰기를 일괄 처리하여 동시에 많은 것을 수행하여 하나를 수행하지 않도록하기 때문입니다 쓰기 당 디스크 검색. 필자가 생각할 수있는 가장 일반적인 예는 데이터베이스 쓰기 쓰기 (write-ahead) 로그를 제외하고 데이터를 쓰는 데이터베이스입니다. 모든 것은 일반적으로 비동기 적으로 작성됩니다. 다른 트랜잭션 액세스 패턴은 크래시에서 일부 비동기 쓰기가 손실 된 경우 복구하기 위해 미리 쓰기 로그가 있으므로 유사한 경향이 있습니다. 이것은 일반적인 액세스 패턴이며 반드시 문제가되는 것은 아니지만 디스크가 매우 단편화되어 있고 파일 시스템이 모든 것을 일괄 적으로 작성할 수없는 경우 문제가 될 수 있습니다 (피해야하는 것처럼 많은 탐색을 유발할 수 있습니다) .

DTrace/iotop 오류는 DTrace 구현 자체 또는 iotop DTrace 스크립트에 버그가 있다는 것을 나타냅니다. iotop의 소스 코드 (OS X의 /usr/bin/iotop)를 보면, 원인이 될 수있는 세 개의 io:::start 콜백이 있습니다. 일부 유형의 I/O에 대해 스크립트에 널 포인터 액세스가있을 수 있지만 스크립트 및 인수 io:::start 프로브를 기반으로하지는 않습니다. 아마 이것은 Apple에게 버그 리포트를 통해 가장 잘 해결 될 것입니다.

출처

2013-07-15 23:01:15 Dan

정보 주셔서 감사합니다. 내가 좀 더 깊숙이 살펴 봤는데, MySQL이 이러한 과도한 펄스 쓰기를 일으키는 것으로 보입니다. 테이블에 항목이 추가되거나 업데이트 된 경우 전체 테이블을 디스크에 다시 써야합니까, 아니면 기존 데이터를 추가/수정할 수 있습니까? 우리는 MyISAM 테이블을 사용하고 있습니다. 또한 ORDER BY 및 TEXT 필드와 함께 SELECT 쿼리를 사용하고 있습니다. 물론 임시 디스크 테이블에 쓰기가 필요하지만 요청이 들어올 때 응답하지는 않습니다. 진단에 도움이된다면 크게 도움이됩니다. . –

그래도 더 깊게 파고 들자면 문제의 원인을 찾아 냈습니다. OS X의 launchd는 다음과 같이 디스크 (아마도 OS X의 디스크 저널링)에 쓰고있는 것 같습니다 :'17 : 55 : 09.274758 IOCTL /dev/disk2 0.073689 W launchd.263 *' –

dtrace 오류로 높은 쓰기 I/O "펄싱"

답변

관련 문제