В системе с 64 ГБ памяти буфер Linux работает полностью при копировании с dd в dev null, и io останавливается до тех пор, пока не выпадет ручной drop_caches

Я использую сервер с программным обеспечением Linux raid 10. Это двухпроцессорная система с 64 ГБ оперативной памяти. 2x16GB диммеры, связанные с каждым из процессоров. Я хочу использовать dd для резервного копирования виртуальных машин kvm и столкнуться с серьезной проблемой ввода-вывода. Сначала я подумал, что это связано с рейдом, но это проблема управления памятью в Linux. Вот пример:

  1. Память в порядке:
  2. Я запускаю дд:
  3. Вы также видите, что nmon показывает доступ к диску:
  4. Через некоторое время "буферы" становятся большими, и процесс копирования прекращается
  5. Вот меминфо:
  6. Вот вывод dd:
  7. Я могу временно решить проблему и принудительно удалить кеш: "sync; echo 3 > /proc/sys/vm/drop_caches"
  8. Для вызова требуется несколько секунд, и сразу после этого скорость дд достигает нормального уровня. Конечно, я могу cronjob каждую минуту или что-то подобное, но это не реальное решение.

У кого-нибудь есть решение или подсказка конфигурации? Вот также мой sysctl, но все значения по умолчанию в сантистах:

Edit1

Я делаю другой тест и делаю dd на диск вместо /dev/null. На этот раз также в одной команде без PV. Так что это только один процесс. dd if=/dev/vg_main_vms/AppServer_System of=AppServer_System bs=4M

  1. Он начинается с чтения без записи (цель не на тех же дисках)
  2. Через некоторое время запись начинается, и чтение замедляется
  3. После этого пишется только время:
  4. Теперь начинается основная проблема. Процесс копирования замедляется до 1 МБ и ничего не происходит:
  5. Процесс dd теперь требует 100% времени процессора (1 ядро)
  6. И снова я могу вручную решить временную проблему и принудительно сбросить кеш:sync; echo 3 > /proc/sys/vm/drop_caches, После этого та же игра начинается снова...

Edit2

Для локального дд я могу обойти с параметром iflag = прямой и офлаг = прямой. Но это не универсальное решение, потому что есть другой доступ к файлам, например, копирование файлов в локальные общие папки samba из виртуальной машины, и там я не могу использовать такие параметры. Должен быть изменен порядок кеширования системных файлов, потому что не может быть нормальным, что вы не можете копировать большие файлы без таких проблем.

Источник

1 ответ

Просто дикая догадка. Ваша проблема может быть большой грязной страницей. Попробуйте настроить /etc/sysctl.conf как:

# vm.dirty_background_ratio contains 10, which is a percentage of total system memory, the 
# number of pages at which the pdflush background writeback daemon will start writing out 
# dirty data. However, for fast RAID based disk system this may cause large flushes of dirty
# memory pages. If you increase this value from 10 to 20 (a large value) will result into 
# less frequent flushes:
vm.dirty_background_ratio = 1

# The value 40 is a percentage of total system memory, the number of pages at which a process
# which is generating disk writes will itself start writing out dirty data. This is nothing
# but the ratio at which dirty pages created by application disk writes will be flushed out
# to disk. A value of 40 mean that data will be written into system memory until the file 
# system cache has a size of 40% of the server's RAM. So if you've 12GB ram, data will be
# written into system memory until the file system cache has a size of 4.8G. You change the
# dirty ratio as follows:
vm.dirty_ratio = 1

Тогда делай sysctl -p перезагрузить, снова сбросить кеш (echo 3 > /proc/sys/vm/drop_caches).

Источник
Другие вопросы по тегам