Данный заголовок касается Вас, если Вы ежедневно копируете от 100 гигабайт данных и это не базы данных.
Также этот пост касается Вас, если Вы бэкапите ploop контейнеры в OpenVZ.
Почему же? Потому что скорее всего, Ваше решение для бэкапа не отключает использование страничного кэша Linux при чтении данных для бэкапа и вытесняет оттуда данные, которые там должны быть, забивая их ненужным мусором, что в свою очередь крайне негативно сказывается на скорости дисковых операций.
К чему это может привести? К деградации производительности. Из памяти вытесняются файлы, которые реально атм должны быть!
Как это диагностировать? http://www.stableit.ru/2014/07/linux-page-cache.html
Насколько все плохо было в моих тестах? Это была OpenVZ нода с большим числом ploop контейнеров.
Что делать? Использовать прослойку, которая подключает использование O_DIRECT при чтении данных (в таком случае даннные НЕ будут помещены в страничный кэш вообще). Например, я написал такую: https://github.com/FastVPSEestiOu/cat_cache_safe Она, конечно, пока медленнее обычного cat, но зато не засоряет страничный кэш вообще.
Так что Вы можете сделать вот так: ./cat_cache_safe| tar -cpzf /place_to_archive.tar.gz - и тем самым вы избежите от помещения прочтенных данных в страничный кэш. А вот с помещением туда записанных данных все весьма сложно, поэтому я рекомендую бэкапиться вообще на удаленный сервер! Так и безопаснее и не создается лишняя нагрузку на запись на локальную дисковую систему.
Также этот пост касается Вас, если Вы бэкапите ploop контейнеры в OpenVZ.
Почему же? Потому что скорее всего, Ваше решение для бэкапа не отключает использование страничного кэша Linux при чтении данных для бэкапа и вытесняет оттуда данные, которые там должны быть, забивая их ненужным мусором, что в свою очередь крайне негативно сказывается на скорости дисковых операций.
К чему это может привести? К деградации производительности. Из памяти вытесняются файлы, которые реально атм должны быть!
Как это диагностировать? http://www.stableit.ru/2014/07/linux-page-cache.html
Насколько все плохо было в моих тестах? Это была OpenVZ нода с большим числом ploop контейнеров.
total cached size: 72,771,035,136Да, да! 72 гигабайта оперативной памяти через почти сутки после бэкапа были забиты бэкапным хламом, а не реальными данными.
Что делать? Использовать прослойку, которая подключает использование O_DIRECT при чтении данных (в таком случае даннные НЕ будут помещены в страничный кэш вообще). Например, я написал такую: https://github.com/FastVPSEestiOu/cat_cache_safe Она, конечно, пока медленнее обычного cat, но зато не засоряет страничный кэш вообще.
Так что Вы можете сделать вот так: ./cat_cache_safe| tar -cpzf /place_to_archive.tar.gz - и тем самым вы избежите от помещения прочтенных данных в страничный кэш. А вот с помещением туда записанных данных все весьма сложно, поэтому я рекомендую бэкапиться вообще на удаленный сервер! Так и безопаснее и не создается лишняя нагрузку на запись на локальную дисковую систему.
Есть также утилита nocache :
ReplyDeletehttps://github.com/Feh/nocache
Да, крутая тема, но O_DIRECT насколько я понимаю вообще исключает попадение в страничный кэш. А fadvise просто вытесняет после прочтения. Но тут я не уверен, надо изучить сабж внимательнее.
Delete> бэкапиться вообще на удаленный сервер
ReplyDeleteТипа backup_cmd | nc --opts1 на исходном и nc --opts2 > backup.dat на удаленном?
Я так понял, что запись на смонтированные ФС с удаленного сервера кэш таки будет тревожить.
Да, nc в принципе неплохой вариант, еще можно curl --upload или scp/sftp (но это само по себе хреновая идея, ибо сохраняется доступ для удаления бэкапов!).
DeleteПри записи на смонтированную по fuse систему данные точно попадут в страничный кэш, там тоже нужно играться с O_DIRECT при записи, чтобы он так не делал.