帶有dtrace錯誤的高寫入I/O「脈動」

大約每10秒鐘發生一次「脈衝」寫入磁盤（從1次寫入/秒脈衝到142+次寫入/秒）。帶有dtrace錯誤的高寫入I/O「脈動」

看到這個例子形象： https://discussions.apple.com/servlet/JiveServlet/showImage/2-22394173-269851/Screen+Shot+2013-07-03+at+13.22.28.png

我們深入到這些「脈衝」寫道，發現他們出現完全相同的時間，這些錯誤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

你看到的脈衝I/O模式是許多/大多數文件系統寫入都是異步的應用程序的特徵 - 這是因爲文件系統會批量寫入，因此它可以同時執行很多操作以避免執行磁盤尋道每寫。我能想到的最常見的例子是數據庫寫入數據 - 除了數據庫的預寫日誌外，一切通常都是異步寫入的;其他事務訪問模式往往是相似的，因爲如果某些異步寫入在崩潰中丟失，它們會提前寫入日誌以進行恢復。這是一種常見的訪問模式，並不一定是問題，但當磁盤高度碎片化並且文件系統無法批量寫入所有內容（導致許多查找，就像它試圖避免的那樣）時，它可能會成爲問題。。

您看到的DTrace/iotop錯誤意味着DTrace實施本身或iotop DTrace腳本中存在錯誤。查看iotop的源代碼（在OS X上的/usr/bin/iotop），有三個io:::start回調可能是罪魁禍首。對於某些類型的I/O，腳本中可能存在某種類型的空指針訪問，但根據腳本和io:::start探針所做的參數，看起來不太可能。也許這是最好的解決與蘋果的錯誤報告。

來源

2013-07-15 23:01:15 Dan

非常感謝您提供的內容豐富的評論。我更深入地研究了它，它似乎是MySQL導致這些重大的脈衝寫入。當表中添加或更新了一個表項時，是否必須將整個表重新寫入磁盤，還是可以附加/修改現有數據？我們正在使用MyISAM表格。我們也在使用帶有ORDER BY和TEXT字段的SELECT查詢，這當然需要寫入臨時磁盤表，但是它們不會被輪詢，它們會在請求進入時寫入。任何診斷的幫助都非常感謝。 –

確實如此挖掘更深入，我發現問題的確切原因。看來在OS X中啓動的是用磁盤寫入（可能是OS X中的磁盤日誌記錄）：'17：55：09.274758 IOCTL /dev/disk2 0.073689 W launchd.263 *' –

帶有dtrace錯誤的高寫入I/O「脈動」

回答

相關問題