Любой инструмент для отслеживания ошибки страницы и других связанных событий для определенного файла на iOS? - PullRequest
Новая
       71

Любой инструмент для отслеживания ошибки страницы и других связанных событий для определенного файла на iOS?

0 голосов
/ 01 ноября 2018

System Usage(Instruments), кажется, только отслеживает явные вызовы файлов (open, close, write, read). System Trace(Instruments) trace page fault, но он организован по стеку вызовов, что затрудняет фильтрацию.

То есть любой инструмент может отслеживать события низкого уровня для определенного файла?

Ответы [ 2 ]

0 голосов
/ 20 ноября 2018

Оба инструмента System Usage используют Kdebug для получения своей информации. Вы можете отслеживать Kdebug напрямую (если вы root) с помощью встроенного ktrace (1) (или стороннего инструмента, такого как kdv (http://newosxbook.com/tools/kdv.html)),), любой из которых даст вам все сообщения Kdebug с фильтрами, которые вы можно применить позже с помощью grep (1) и т. д. Использование Dtrace не будет работать, если у вас включен SIP (и это также болезненно с точки зрения производительности) - поэтому Kdebug делает хороший выбор.

0 голосов
/ 01 ноября 2018

DTrace может кое-что из этого сделать (по крайней мере, в Solaris вам придется попробовать это самостоятельно на macOS). Поставщик vm имеет зонды с именами fspgin, fspgout и fsfree, которые срабатывают, когда страницы с поддержкой FS выгружаются в память или из нее или освобождаются, если они не изменены соответственно. Существует также более общий, называемый maj_fault, который срабатывает всякий раз, когда сбой страницы приводит к IO.

Единственная проблема заключается в том, что DTrace не дает вам способа вернуться к имени файла с этих пробников, что может быть хорошо, если вы в основном страдаете ошибкой страницы в одном файле, или может действительно раздражать, если вы ' пытаемся выяснить, какой файл становится страничным. Тем не менее, вы все равно можете получить execname или pid процесса, который вызывает ошибку страницы, если это поможет.

Здесь , где вы можете увидеть документацию для провайдера vm. Там есть несколько примеров сценариев, но этот, вероятно, лучше всего использовать: 

vminfo:::maj_fault,
vminfo:::zfod,
vminfo:::as_fault
/execname == "soffice.bin" && start == 0/
{
    /*
     * This is the first time that a vminfo probe has been hit; record
     * our initial timestamp.
     */
    start = timestamp;
}

vminfo:::maj_fault,
vminfo:::zfod,
vminfo:::as_fault
/execname == "soffice.bin"/
{
    /*
     * Aggregate on the probename, and lquantize() the number of seconds
     * since our initial timestamp.  (There are 1,000,000,000 nanoseconds
     * in a second.)  We assume that the script will be terminated before
     * 60 seconds elapses.
     */
    @[probename] =
        lquantize((timestamp - start) / 1000000000, 0, 60);
}

Это распечатывает временную шкалу активности памяти для каждого типа ошибки, и документы объясняют это чуть более подробно.

...