Какой хороший способ проверить использование msync в последних ядрах Linux?

Question

Я использую msync в своем приложении на Linux 2.6 для обеспечения согласованности в случае сбоя.Мне нужно тщательно протестировать мое использование msync, но реализация, кажется, сбрасывает все соответствующие страницы для меня.Есть ли способ предотвратить автоматическую сброс страниц mmap на диск, чтобы разоблачить ошибочное использование msync с моей стороны?

Answer 1

С извинениями @samold, "swappiness" не имеет к этому никакого отношения. Перестановка просто влияет на то, как ядро ​​обменивается заменой грязных анонимных страниц по сравнению с удалением страниц кэша страниц при нехватке памяти.

Вам нужно поиграть с настройками Linux VM, управляющими задачей pdflush . Для начала я бы предложил:

sysctl -w vm.dirty_writeback_centisecs=360000

По умолчанию vm.dirty_writeback_centisecs равно 3000, что означает, что ядро ​​будет считать любую грязную страницу старше 30 секунд «слишком старой» и попытаться сбросить ее на диск. Проворачивая его до 1 часа, вы сможете вообще избежать сброса грязных страниц на диск, по крайней мере, во время короткого теста. За исключением ...

sysctl -w vm.dirty_background_ratio=80

По умолчанию vm.dirty_background_ratio равно 10, как и в 10 процентах. Это означает, что когда более 10 процентов физической памяти занято грязными страницами, ядро ​​будет думать, что ему нужно заняться записью чего-либо на диск, даже если оно моложе dirty_writeback_centisecs. Поверните его до 80 или 90, и ядро ​​должно быть готово вынести большую часть оперативной памяти, занятую грязными страницами. (Я бы не стал устанавливать этот слишком высокий, хотя, потому что держу пари, что никто никогда этого не сделает, и это может вызвать странное поведение.) Кроме ...

sysctl -w vm.dirty_ratio=90

По умолчанию vm.dirty_ratio равен 40, что означает, что, если 40% ОЗУ составляют грязные страницы, процессы, пытающиеся создать больше грязных страниц, будут блокировать до тех пор, пока что-то не будет выселено. Всегда делайте это больше dirty_background_ratio. Хм, подумай об этом, поставь этот перед этим, просто чтобы убедиться, что этот всегда больше.

Вот и все для моих первоначальных предложений. Возможно, ваше ядро ​​в любом случае начнет удалять страницы; Виртуальная машина Linux - загадочный зверь, и кажется, что она настраивается в каждом выпуске. Надеюсь, это послужит отправной точкой.

См. Documentation / sysctl / vm.txt в исходных кодах ядра для полного списка настроек VM. (Желательно обращаться к документации по версии ядра, которую вы на самом деле используете.)

Наконец, используйте интерфейс / proc / PID / pagemap , чтобы увидеть, какие страницы действительно грязные в любое время.

Answer 2

Несколько догадок:

Вы можете поиграть с перестановкой системы через /proc/sys/vm/swappiness с настройкой:

   /proc/sys/vm/swappiness
          The value in this file controls how aggressively the
          kernel will swap memory pages.  Higher values increase
          agressiveness, lower values descrease aggressiveness.
          The default value is 60.

(Wow. proc(5) нужно пройти через проверку орфографии.)

Если установка swappiness на 0 не помогает, существуют более настраиваемые ручки; файл Documentation/laptops/laptop-mode.txt содержит хорошее описание поведения сценария laptop_mode:

To increase the effectiveness of the laptop_mode strategy, the laptop_mode
control script increases dirty_expire_centisecs and dirty_writeback_centisecs in
/proc/sys/vm to about 10 minutes (by default), which means that pages that are
dirtied are not forced to be written to disk as often. The control script also
changes the dirty background ratio, so that background writeback of dirty pages
is not done anymore. Combined with a higher commit value (also 10 minutes) for
ext3 or ReiserFS filesystems (also done automatically by the control script),
this results in concentration of disk activity in a small time interval which
occurs only once every 10 minutes, or whenever the disk is forced to spin up by
a cache miss. The disk can then be spun down in the periods of inactivity.

Возможно, вы захотите довести эти цифры до крайности; если вам действительно интересно поведение вашего приложения, разумно установить эти значения достаточно высоко и посмотреть, сколько времени займет команда sync(1), когда все это будет сделано. Но это общесистемные переменные - другие приложения могут быть не такими уж счастливыми.