☰

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

tag-icon • tag-icon linux performance dd pagefile disk-cache
В системе с 64 ГБ памяти буфер Linux заполняется при копировании с помощью dd на dev null, а io останавливается до ручного drop_caches

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

  1. Память в порядке: https://i.stack.imgur.com/NbL60.jpg
  2. Я начинаю дд: https://i.stack.imgur.com/kEPN2.jpg
  3. Вы также видите, что nmon показывает доступ к диску: https://i.stack.imgur.com/Njcf5.jpg
  4. Через некоторое время «буферы» становятся большими и процесс копирования останавливается. https://i.stack.imgur.com/HCefI.jpg
  5. Вот меминфо: https://i.stack.imgur.com/KR0CE.jpg
  6. Вот вывод dd: https://i.stack.imgur.com/BHjnR.jpg
  7. Я могу вручную временно устранить проблему и принудительно удалить кэш: "sync; echo 3 > /proc/sys/vm/drop_caches"
  8. Звонок занимает несколько секунд, и сразу после этого скорость dd достигает нормального уровня. Конечно, я могу делать cronjob каждую минуту или что-то в этом роде, но это не настоящее решение. https://i.stack.imgur.com/zIDRz.jpg https://i.stack.imgur.com/fO8NV.jpg

Есть ли у кого-нибудь решение или подсказка по настройке? Вот также мой sysctl, но все значения - значения centos по умолчанию: https://i.stack.imgur.com/ZQBNG.jpg

Редактировать1

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

  1. Начинается с чтения без записи (цель не на тех же дисках) https://i.stack.imgur.com/jJg5x.jpg
  2. Через некоторое время письмо начинается, а чтение замедляется. https://i.stack.imgur.com/lcgW6.jpg
  3. После этого наступает время писать только: https://i.stack.imgur.com/5FhG4.jpg
  4. Теперь начинается главная проблема. Процесс копирования замедлился до менее 1 Мбит и ничего не произошло: https://i.stack.imgur.com/YfCXc.jpg
  5. Процесс dd теперь требует 100% процессорного времени (1 ядро) https://i.stack.imgur.com/IZn1N.jpg
  6. И снова я могу вручную временно решить проблему и принудительно сбросить кэш: sync; echo 3 > /proc/sys/vm/drop_caches. После этого та же игра запускается снова...

Редактировать2

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

решение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).

Связанный контент