Страница 1 из 1
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-21 16:18:53
tull
На сервере (FreeBSD 10.2) регулярно делаются бэкапы mysql баз. Суммарный объем где-то около 4-5 Гб.
При запаковывании в архив получается очень высокий load average - иногда больше 10 и даже 12-15. В результате сайт практически перестает работать.
Как ограничить потребление ресурсов архиватором? nice не помогает.
Единственное, что я пока нашел, это использовать rar с ключом -mt1, тогда он работает в одном потоке (все равно загружая одно ядро на 100%), при этом архивирование идет где-то минут 30. К тому же rar закрытый и платный.
В идеале хотелось бы, чтобы работало многопоточно и на нескольких ядрах, но при этом имело самый низкий приоритет, всегда уступая любым другим процессам.
Ну или чтобы как в rar можно было задать кол-во потоков/процессоров.
P.S. И еще заодно спрошу, чем посоветуете надежно шифровать бэкапы. Смысл в том, что локально на машине хранятся простые архивы, а для бэкапирования в облако и на сторонний сервер они шифруются.
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-21 23:26:33
snorlov
а вы не пробовали бзкап, да и сам сайт привязать к конкретным ядрам... По поводу nice, я с приоритетом 20 запускаю скрипт бэкапа и вроде ничего не тормозит...
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-22 0:05:38
tull
snorlov писал(а):а вы не пробовали бзкап, да и сам сайт привязать к конкретным ядрам...
Извините, я ламер, как это сделать?
Только сайт-то зачем? На сервере один проект крутится.
snorlov писал(а):По поводу nice, я с приоритетом 20 запускаю скрипт бэкапа и вроде ничего не тормозит...
Вот рабочее состояние системы вечером:
Код: Выделить всё
last pid: 13577; load averages: 0.16, 0.19, 0.17 up 571+00:51:53 23:41:01
95 processes: 1 running, 94 sleeping
Mem: 4180M Active, 5503M Inact, 2139M Wired, 110M Cache, 1611M Buf, 3896M Free
Swap:
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
13287 www 1 21 0 419M 34252K accept 1 0:09 2.78% php-fpm
12787 www 1 21 0 419M 35144K accept 0 0:30 2.69% php-fpm
Вот состояние через несколько минут работы rar по архивированию 4.5 Гб директории, с nice 20:
Код: Выделить всё
last pid: 13939; load averages: 8.69, 5.15, 2.47 up 571+01:02:39 23:51:47
116 processes: 1 running, 115 sleeping
Mem: 5450M Active, 7811M Inact, 2358M Wired, 192M Cache, 1653M Buf, 17M Free
Swap:
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
13794 root 65 40 20 480M 427M uwait 3 14:52 309.18% rar
1668 mysql 99 20 0 5510M 5079M uwait 2 753.7H 1.17% mysqld
60368 www 1 20 0 414M 29140K accept 1 0:01 0.20% php-fpm
89540 www 1 20 0 423M 29320K accept 2 1:09 0.10% php-fpm
89235 www 1 20 0 419M 27300K accept 3 0:15 0.10% php-fpm
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-22 0:25:17
snorlov
tull писал(а):snorlov писал(а):а вы не пробовали бзкап, да и сам сайт привязать к конкретным ядрам...
Извините, я ламер, как это сделать?
Только сайт-то зачем? На сервере один проект крутится.
Из моих ощущений, большая нагрузка на систему однопоточного процесса возникает из-за переключений этого процесса по разным ядрам, вы понаблюдайте за тем же zip'ом и убедитесь что его процесс работает на "разных" ядрах, т.е. повторяется ситуация с dummynet в 8-ке, когда привязав его к конкретному ядру вы резко снижаете нагрузку на всю систему. Поэкспериментируйте с cpuset, отдайте сайте и mysql'у ядра c 0-2, а zip'у 3-е и посмотрите...
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-23 0:49:54
FiL
1. высокий LA - это ни о чем. Особенно если "высокий" меньше количества ядер.
2. сайт "перестает работать" потому, что база занята бакапом. А не потому, что архивация.
3. lbzip2 и pbzip2 умеют многопоточное сжатие
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-24 2:05:56
tull
FiL писал(а):2. сайт "перестает работать" потому, что база занята бакапом. А не потому, что архивация.
Именно потому, что архивация.
При снятии дампа у меня выставляется флаг, и форум работает в режиме чтения (вообще ничего в БД в этот момент не пишется).
Поверьте, проверял много раз, что именно когда тарится/зипуется.
FiL писал(а):3. lbzip2 и pbzip2 умеют многопоточное сжатие
Спасибо, попробую.
А никто не посоветует чем лучше шифровать? Не на этапе архивации, а после.
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-26 1:24:40
FiL
смотря кому лучше
я-бы выбирал или gpg или openssl. Скорее второй.
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-26 9:00:35
Alex Keda
gstat в этот момент посомтрите/дайте
LA растёт не только от проа, но и при тормозящем вводе-выводе
причём по этой причине - чаще и сильней
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-27 18:33:23
tull
У меня SSD soft RAID
Посмотрел, при LA 10, gstat показывает 3-5%, иногда на мгновение 12-15%
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-29 4:15:41
FiL
интересно... откуда la 10 если диски быстрые, а архивация идет в один поток...
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-29 7:31:58
Neus
интересно... зачем rar-у 65 потоков, если архивация в 1 поток...
высокая нагрузка на проц при архиваций больших бэкапов
Добавлено: 2018-01-30 12:19:11
tull
LA 10 и больше это когда rar.
Я ему выставил -mt4 (ограниение threads), но сегодня при архивации опять словил LA 13
А при -mt1 он дико медленно архивирует мой бэкап, минут 30.