Постоянное зависание Virtualbox при использовании KTorrent

Запускать требовательные к IO процессы в виртуалке и удивляться, что всё виснет на IO.

Что-то мне подсказывает, что все это полный бред и решение лежит где-то на поверхности. Может какие-то опции или виртуалку донастроить.

не 12309?

Тем более что несколько лет назад (в другой версии ubuntu) все торренты благополучно качались в виртуалке и ничего не зависало.

Нужно отключить COW для каталога с виртуалками. И желательно использавать фиксированный диск, тогда тормозит меньше

В торрент клиенах есть пункт резервитовать все месть сразу. Может поможет.

А если отключить swap?

Нужно отключить COW для каталога с виртуалками.

Где и как это сделать?

И желательно использавать фиксированный диск, тогда тормозит меньше

Всегда делаю фиксированный при создании виртуалки.

В торрент клиенах есть пункт резервитовать все месть сразу. Может поможет.

Проверю попозже.

А если отключить swap?

И это тоже проверю.

Запусти в виртуалке iotop и посмотри, кто хард насилует

Где и как это сделать?

для btrfs както так отключается

chattr +C /path/to/folder

Запусти в виртуалке iotop и посмотри, кто хард насилует

Запустил. Пока все очень тихо и редко переваливает за 1%. После зависания залью скриншот.

Маленькая заметка - скорость закачки низкая (2 мбит/с), а отдачи нет (отключена), если это важно.

Запусти в виртуалке iotop и посмотри, кто хард насилует

Готово, сделал 5 скриншотов разных стадий.

1. Начало запуска Ktorrent - пока все чисто.

https://i.imgur.com/SmqDDdY.png

2. Через 5 минут файл подкачки немного вырос. После этого своп начал толстеть все быстрее с каждой минутой.

https://i.imgur.com/hRrpMoE.png

3. Еще через 2 минуты своп занимал 1/3 от своего объема.

https://i.imgur.com/6cctrhD.png

4. Еще через 5 минут своп заполнился и начались предсмертные лаги.

https://i.imgur.com/VniDzLX.png

5. Спустя 10 секунд - окончательное зависание.

https://i.imgur.com/rdCTPxA.png

Причем, как видно из скринов, пока своп толстеет - iotop ничего интересного не показывает, а как заполняется полностью, то сразу много разных процессов загружает систему. Непонятно, ктож виноват то.

В торрент клиенах есть пункт резервитовать все месть сразу. Может поможет.

В KTorrent 2 похожих опции.

Зарезервировать свободное место перед началом загрузки

Полностью зарезервировать место на диске (для избежания фрагментирования)

Причем первая и так была включена, а вторую включил только щас, но своп все-равно довольно быстро забивается. Так что нет, видимо это не влияет.

Первые 5 минут ничего не происходит, но потом начинается активное засерание свопа... и через 10 минут зависание.

Нужно отключить COW для каталога с виртуалками.

Это надо в основной или гостевой системе сделать?

для btrfs както так отключается

chattr +C /path/to/folder

А в kubuntu вроде не btrfs, не знаю что там.

кэширование ввода-вывода для sata-контроллера попробуй включить в VirtualBox

Включил, щас затестим.

Интересно, что для IDE оно включено (хотя носителя там нет), а для SATA выключено. По идее это же полезная функция, чего бы сразу не включать.

Это надо в основной или гостевой системе сделать?

В основной системе. Если не btrfs то не надо.

тут про отключение CoW глянуть можно

кэширование ввода-вывода для sata-контроллера попробуй включить в VirtualBox

Не помогло. Проверил дважды, все-равно зависает.

кэширование ввода-вывода для sata-контроллера

Причем метод с кэшированием в настройках Virtualbox дает не совсем тот же эффект - после полного забивания свопа начинаются лаги, но вместо полного зависания системы KTorrent автоматически закрывается. Интересно, кто посылает сигнал на завершение его процесса, как это работает.

В любом случае, метод не подходит, процесс закачки прекращается, своп освобождается где-то на 100 мб, т.е. остается на планке 1900 из 2000 мб, и дальше запускать бессмысленно.

sudo nano /etc/sysctl.conf

vm.swappiness=10

Начинаю пробовать этот метод.

Вообще, прочитал про него немного:

The Linux kernel provides a tweakable setting that controls how often the swap file is used, called swappiness.

A swappiness setting of zero means that the disk will be avoided unless absolutely necessary (you run out of memory), while a swappiness setting of 100 means that programs will be swapped to disk almost instantly.

Ubuntu system comes with a default of 60, meaning that the swap file will be used fairly often if the memory usage is around half of my RAM. You can check your own system's swappiness value by running:

Все это очень странно.

1. Во-первых, где проверить, что в Ubuntu действительно стоит значение 60? В моей виртуалке 4 гб памяти, а используется всего 1. Это явно не 60%, чтобы постоянно забивать своп.

2. Во-вторых, в самом файле /etc/sysctl.conf этой строчки нет. Понятно, что надо добавить, но где найти изначальное вот это значение «60» - где оно прописано системой? Почему оно не работает, если оно действительно 60?

1. Во-первых, где проверить, что в Ubuntu действительно стоит значение 60?

cat /proc/sys/vm/swappiness

2. Во-вторых, в самом файле /etc/sysctl.conf этой строчки нет.

echo "vm.swappiness=10" >> /etc/sysctl.conf

Спасибо, и правда 60. Пошел тестить.

Просто нет слов.

virt@vm:~$ cat /proc/sys/vm/swappiness
10

Своп продолжает активно заполняться до зависания системы. Баг чтоли какой-то?

Я не понимаю как это работает. Оно просто игнорит все эти значения. После того, как я выставил своп на 10, оно все-равно заполняется, хотя оперативка не вылазит за пределы 1 гб, т.е. 25% (и это с настроенным порогом в 90%). Надо отключить своп вообще.

У тебя ядро не может использовать озу по какой-то причине. ищи по какой.

Вряд ли мне хватит знаний и квалификации это найти. Тем более, если это мейнстримовая система (ubuntu), и она так себя ведет, то наверно разработчики об этом знают, но почему-то не хотят исправлять. Я же не первый человек, который запускает торренты в виртуалке и меняет своп. Возможно, стоит отправить багрепорт. Может они не тестировали торренты под виртуалкой?

Я же не первый человек, который запускает торренты в виртуалке

Может и не первый, но не жирнокде софт же запускать. Можно вообще в консоли качать и по web интерфейсу заходить.

tmpfs чем занята и насколько?

Не знаю, чем она занята и как это проверить. И есть ли она вообще. В вики что-то отдельное написано про ее монтирование, наверно нет такого в ubuntu.

Может и не первый, но не жирнокде софт же запускать. Можно вообще в консоли качать и по web интерфейсу заходить.

А сам ты не жирный? На скриншоты смотрел? 800 мб для системы с жирнющими торрентами - это много?

Два момента:

1. Убедись, что на хосте достаточно оперативки (на всякий случай) и посмотри, как она заполняется при работе гостя;
2. Отсортируй процессы по потреблению памяти

Убедись, что на хосте достаточно оперативки (на всякий случай) и посмотри, как она заполняется при работе гостя;

Ее там просто дофига. И если смотреть из хоста, то Virtualbox весь занимает около 100 мб.

Отсортируй процессы по потреблению памяти

А этим я занимался еще вчера. Смысла немного, т.к. системный монитор сам переодически выводит наверх самые жирные процессы. Вобщем все как на скриншотах, самый жирный все-равно KTorrent, который за пределы 300-400 мб не выходил.

Может проблема в ktorrent. Попробуй другой клиент поставить

df|grep tmpfs

А оперативку потестить не пробовал? Запусти memtest на ночь, чтобы убедиться, что ничего не сбоит. И перед этим можешь вывести в терминале tail -f /var/log/kern.log (не помню, как он в убунте называется, в общем, dmesg в файле), поискать подозрительные сообщения. Как на хосте, так и в госте

Может быть, вполне может быть. В выходные поставлю. Пока много торрентов завязано на KTorrent, и возиться с переносом не хочется. Завтра все докачается, и новые торренты протестирую на qBittorent.

А пока просто отключаю своп. Но даже если это поможет, потом поставлю qBittorent, верну своп обратно на стандартный 60, интересно посмотреть на результат. Хочется все же какой-то вывод сделать, кто виноват, и что за косяк.

Оперативке конечно годков много, и даже как-то я запускал несколько лет назад memtest, редкие ошибки пролетали. Но на хосте таких проблем не было по части торрентов, просто понадобилось заизолировать их в виртуалке.

несколько лет назад memtest, редкие ошибки пролетали

хера ты бесбашенный, я бы наверно с ума сошёл от того что файлы рандомно бьются и все программы идут в разнос

Ничего не идет в разнос. Такие ошибки появляются на любой планке через 1-2 года. Если бомбить с этого и менять их каждые 2 года, то надо быть олигархом. Но так делают только идиоты. Нормальным людям хватает бэкапа на внешний носитель или облако и проверки по контрольной сумме.

800 мб для системы с жирнющими торрентами - это много?

Да.

Ты застрял где-то в конце 90х.

Отключил своп - нихрена не изменилось! Все зависло опять. Только теперь в графе свопа красивая циферка «0». При этом, оперативка так же не превышала 600-800 мб (из выделенных 4 гб). Я так понимаю, остался только один шанс - в выходные попробовать qBittorent. Я давно так не обламывался.

Похоже, я нашел ответ. Может ли быть проблема в том, что торренты сохраняются в общей папке? Вроде глупость какая-то, но вот что я нашел.

https://www.virtualbox.org/ticket/15662

В тикете парень пожаловался на фризы при активном использовании общей папки (видимо, операции ввода-вывода).

Ниже в каментах дофига похожих историй, с самыми разными конфигурациями хостов и гостевых систем.

И целых 2 камента с торрентами и общей папкой.

Same here Windows 10 64 bit as host and windows 7 64 bit as guest. When fast downloading torrents it freezes. Thanks got I found this issue and downgraded to 5.0.26

Same here with Gentoo host and Windows 8.1 64-bit guest. My use case is running uTorrent and seeding a lot of files from a share folder. 5.0.26 host is also fine here, even with 5.1.4 guest additions.

Правда, в моем случае нет никаких больших скоростей и большого кол-ва файлов, но все же.

Если почитать все каменты, то это какой-то кроссплатформенный баг, который тянется аж со времен Virtualbox 5 и вешает виртуалки из-за частого обращения к общей папке (запись или чтение).

Плохо, что там статус «fixed», хотя это явно не так.

Я настроил скачивание торрентов в общюю папку, чтобы не тратить часы на перенос больших файлов из виртуалки в хост (а переносятся они очень долго, не знаю из-за чего). Но видимо, от этого варианта придется отказаться.

Начинаю тестить скачивание в обычную папку в /home.

Самба тормозит. Как всегда оказалось, что сам своими руками наворотил, а потом своп виноват, да?

Пострадал от автоматизации процессов. И это еще надо проверить. Но скорее всего да, все дело в этой косячной папке, которая неспособна выдержать жалкие 2 мбит/с.

Помимо прочего, я сделал маленькое открытие.

vm.swappiness=0

Не отключает своп. Он продолжает забиваться.

А вот команда:

swapoff -a

Его отключает - даже в системном мониторе теперь пишет:

Область подкачки недоступна

И я выделил 8 гб оперативки для виртуалки.

Если и после всего этого она зависнет, то проблема явно в общей папке. Но с этим я в выходные разберусь, докачаю старые файлы как есть, а новые тогда в обычной папке настрою.