FastNetMon

Thursday 24 July 2014

Вы не умеете бэкапить Ваши данные!

Данный заголовок касается Вас, если Вы ежедневно копируете от 100 гигабайт данных и это не базы данных.

Также этот пост касается Вас, если Вы бэкапите 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 - и тем самым вы избежите от помещения прочтенных данных в страничный кэш. А вот с помещением туда записанных данных все весьма сложно, поэтому я рекомендую бэкапиться вообще на удаленный сервер! Так и безопаснее и не создается лишняя нагрузку на запись на локальную дисковую систему.

4 comments :

  1. Есть также утилита nocache :

    https://github.com/Feh/nocache

    ReplyDelete
    Replies
    1. Да, крутая тема, но O_DIRECT насколько я понимаю вообще исключает попадение в страничный кэш. А fadvise просто вытесняет после прочтения. Но тут я не уверен, надо изучить сабж внимательнее.

      Delete
  2. > бэкапиться вообще на удаленный сервер

    Типа backup_cmd | nc --opts1 на исходном и nc --opts2 > backup.dat на удаленном?
    Я так понял, что запись на смонтированные ФС с удаленного сервера кэш таки будет тревожить.

    ReplyDelete
    Replies
    1. Да, nc в принципе неплохой вариант, еще можно curl --upload или scp/sftp (но это само по себе хреновая идея, ибо сохраняется доступ для удаления бэкапов!).

      При записи на смонтированную по fuse систему данные точно попадут в страничный кэш, там тоже нужно играться с O_DIRECT при записи, чтобы он так не делал.

      Delete

Note: only a member of this blog may post a comment.