История изменений

Добрый день! Вы один из тех крайне не многих людей, с которыми очень, очень классно общаться. Всё классно описали и нагуглили. Именно всё это же самое я и нагуглил ранее. - Только, вот какая штука, что ещё из не совсем очевидного, последствия присасывания, через vzdump: в случае присасыввания, никакие ionice я так понимаю, в принципе не работают! Оно и очевидно. Посколько, сам процесс qemu и сосет данные, по сути. Таким образом, происходит вот какая не приятная штука то: допустим, у меня жесткий диск, в моём случае raid10. Сеть 1гбит, я начинаю присасываться, вычитывать со скоростью 100 мегабайт в секунду… Казалось бы, не страшно, но, тут виртуальная машина хочет записать блок 8, блок 100 и блок 875. - Что будет происходит? - Система начинает разрываться, между чтением и записью! - Мы ведь не забыли, что у нас всё идет через kvm… И так, остановится чтение потока. Головки диска побегут по блокам 8,100,875 - побегут скорее их класть в бекап. Потом, откроется шлагбаум для записи этих блоков на диск, потом, диски снова попытаются перейти в режим потокового чтения… - Отсюда я и вижу, в момент бекапа дичайший la, который обусловлен задержкой ввода-вывода. Как бы это не парадкосально, но, машины у меня падают, в первую очередь из-за большого кол-ва чтения, а не из-за медленной записи в гигабитной сети (а пишу я на nfs в режиме async, если что). Похоже, у меня режим async ещё забивает - надо бы посмотреть сколько грязных страниц у меня появляется во время бекапа. Весьма любопытно.

И так: основное решение вопроса лежало в том, что я снизил скорость работы vzdump. Вот так вот просто. Я не читаю настолько активно, и диски успевают и почитать, и пописать… - Такой вот парадокс. И машины не падают.

Совершенно верно сказали, что стоит пересмотреть на стратегию бекапа. Тут же ещё какой момент? А момент такой, что, один диск в kvm, это один процесс чтения. А zfs, в зеркале, при таком раскладе всегда будет читать только с одного диска. Вот оно всё в купе и собирается, и дает негативный результат.

Спасибо огромное, Вы очень круто всё пишите. Ваши советы по ограничению памяти через systemd, так же буду рассматривать. И при возможности применю.

P.S. - посколько от zfs отказываться не хочется, сейчас смотрю что в этом плане у proxmox backup server. Но, и повторюсь, что снижение скорости vzdump избавило от проблем. Но, там да, другие минусы никуда не делись - а именно, это отсутствие инкремент бекапов и т.д.

Добрый день! Вы один из тех крайне не многих людей, с которыми очень, очень классно общаться. Всё классно описали и нагуглили. Именно всё это же самое я и нагуглил ранее. - Только, вот какая штука, что ещё из не совсем очевидного, последствия присасывания, через vzdump: в случае присасыввания, никакие ionice я так понимаю, в принципе не работают! Оно и очевидно. Посколько, сам процесс qemu и сосет данные, по сути. Таким образом, происходит вот какая не приятная штука то: допустим, у меня жесткий диск, в моём случае raid10. Сеть 1гбит, я начинаю присасываться, вычитывать со скоростью 100 мегабайт в секунду… Казалось бы, не страшно, но, тут виртуальная машина хочет записать блок 8, блок 100 и блок 875. - Что будет происходит? - Система начинает разрываться, между чтением и записью! - Мы ведь не забыли, что у нас всё идет через kvm… И так, остановится чтение потока. Головки диска побегут по блокам 8,100,875 - побегут скорее их класть в бекап. Потом, откроется шлагбаум для записи этих блоков на диск, потом, диски снова попытаются перейти в режим потокового чтения… - Отсюда я и вижу, в момент бекапа дичайший la, который обусловлен задержкой ввода-вывода. Как бы это не парадкосально, но, машины у меня падают, в первую очередь из-за большого кол-ва чтения, а не из-за медленной записи в гигабитной сети (а пишу я на nfs в режиме async, если что). Похоже, у меня режим async ещё забивает - надо бы посмотреть сколько грязных страниц у меня появляется во время бекапа. Весьма любопытно.

И так: основное решение вопроса лежало в том, что я снизил скорость работы vzdump. Вот так вот просто. Я не читаю настолько активно, и диски успевают и почитать, и пописать… - Такой вот парадокс. И машины не падают.

Совершенно верно сказали, что стоит пересмотреть на стратегию бекапа. Тут же ещё какой момент? А момент такой, что, один диск в kvm, это один процесс чтения. А zfs, в зеркале, при таком раскладе всегда будет читать только с одного диска. Вот оно всё в купе и собирается, и дает негативный результат.

Спасибо огромное, Вы очень круто всё пишите. Ваши советы по ограничению памяти через systemd, так же буду рассматривать. И при возможности применю.