Назад | Перейти на главную страницу

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

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

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

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

Edit1

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

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

Edit2

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

Просто дикая догадка. Ваша проблема может заключаться в смывании большой грязной страницы. Попробуйте настроить /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).