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

Такие ошибки появляются на любой планке через 1-2 года

Моим планкам лет 8, ошибок нет

Провел последний тест.

1. Своп полностью отключен.

2. Выделил 8 гб оперативки (хотя используется меньше 1 гб).

3. Снова зависание. Правда теперь поработало дольше (почти час).

Вот как это объяснить - никакой нагрузки ни на что. И все-равно виснет. Ведь никаких предпосылок не было, интерфейс отзывчивый, как на основной системе, никаких микро-лагов и фризов - просто в один момент виртуалка виснет.

Момент зависания с отключенным свопом:

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

Решил не дожидаться выходных. Прямо днем перекачаю торренты в обычной папке (вместо общей).

Не хочу показаться бестактным, но позволь все-таки поинтересоваться, зачем качать в виртуалке? У тебя там VPN что-ли отдельный настроен?

По мне так похоже на глюк оперативки

Если так, тогда понятно. Я как-то качал с приватного файлобменника BluRay «Stand by Me» 1986 (ради допов, особенно комментариев актеров) в виде архивов, а там скорость ограничена и один IP. Я распараллелил на четыре: 1. Обычный браузер 2. Тор браузер 3. Виртуалка с VPN 4. Виртуалка с VPN + Tor браузер. Хотя по моему с 4 пунктом уже не заморачивался. Очень помогло.
Зарегил кучу адресов на рамблере (зарегеным выше скорость), но их потом забанили вместе с доменом, пришлось регить опять понемногу. А полного BRay на открытых трекерах так и не появилось. Сорри за оффтоп.

На основной системе IP не позволяет P2P.

Моя надежда не оправдалась, и этот баг:

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

Меня никак не аффектит. В обычной внутренней папке тоже зависает.

Осталось попробовать качать через qBittorent, может он в виртуалке ведет себя нормально. Если и это не поможет, тогда я просто не знаю.

Удостоверьтесь, что у вас tmpfs не забивается. Поставьте watch 'df -h | grep tmpfs'

Пока предварительные тесты показывают, что qBittorent адекватно ведет себя в Virtualbox. За час (при включенном свопе) он нагадил в своп всего 10 мб, и на этом остановился. Закачка идет спокойно, можно даже выставить всего 1 CPU и система остается отзывчивой.

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

В целом KTorrent идеальный торрент-клиент, если запускать на хосте. На современном компе не видно разницы (и тормозов, тем более), зато функционал намного больше. Но в виртуалке он пока работать не может.

По потреблению оперативки оба торрент-клиента примерно одинаковы.

Попробуй Tixati.

Знание-сила. Ф. Бэкон.

Все-таки qBittorent тоже отъедает своп. Но гораздо медленнее. Вчера за 3 часа примерно 280 мб свопа. Когда закрыл клиент, то система подтормаживала где-то 2 минуты, и только потом я смог открыть меню и нормально выключить ее.

Окончательный вердикт:

qBittorent не сжирает своп. За 5 часов что-то съело всего 8 мб свопа.

Своп в виртуалке сжирает автоматическое включение (через 15 минут простоя) блокировки экрана. После каждой такой разблокировки экрана своп прилично подскакивает, и начинает постепенно забиваться (непонятно чем).

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

А на KTorrent надо заводить багрепорт. Он не может использоваться в виртуалке, т.к. постоянно забивает своп до полного зависания. И даже с отключенным свопом - меньше, чем через час, произойдет зависание системы. Правда каким образом оно вешается, пока непонятно. Может быть, это и не моя задача, может быть разработчики должны это выяснить, а мне только надо описать баг.

и начинает постепенно забиваться (непонятно чем)

smem

а куда твоя предыдущая инкарнация делась

Жесть, поторопился я с выводами, поторопился!

На 6й час работы qBittorent что-то резко начало отжирать своп - почти 700 мб и продолжает расти. Почему именно на 6й час? Выше посоветовали поставить smem, поставил, начинаю смотреть...

Вот что показал smem:

  PID User     Command                         Swap      USS      PSS      RSS 
 1261 virtus /usr/bin/VBoxClient --displ      316        0        3      112 
 1268 virtus /usr/bin/VBoxClient --seaml      320        0        3      112 
 1251 virtus /usr/bin/VBoxClient --clipb      312        4        5      112 
  913 virtus /lib/systemd/systemd --user     1056        4        6      260 
  969 virtus /bin/sh /usr/bin/startkde        100        4        6      192 
 1644 virtus /usr/lib/dconf/dconf-servic      560        4        6      300 
 1754 virtus /usr/lib/x86_64-linux-gnu/p      844        4        6      332 
 1812 virtus /usr/lib/bluetooth/obexd         656        4        6      336 
 1216 virtus /usr/bin/dbus-launch --exit      432        4        7      320 
 1273 virtus /usr/bin/VBoxClient --draga      308        4        7      124 
 1252 virtus /usr/bin/VBoxClient --clipb      572        4       10      364 
 1721 virtus /usr/lib/at-spi2-core/at-sp      776        8       11      396 
 1649 virtus kwrapper5 /usr/bin/ksmserve      472        4       14      496 
 1274 virtus /usr/bin/VBoxClient --draga      416       52       60      412 
 1607 virtus kdeinit5: Running...            3008        4       61     1044 
 1851 virtus file.so [kdeinit5] file loc     3048        4       69     1180 
 1724 virtus /usr/bin/pulseaudio --start     3184       68       83      452 
 1262 virtus /usr/bin/VBoxClient --displ      308       80      117      536 
 1269 virtus /usr/bin/VBoxClient --seaml      376      148      187      612 
 1737 virtus /usr/bin/dbus-daemon --conf      308      168      211      700 
 1756 virtus /usr/lib/x86_64-linux-gnu/g      472      204      225      752 
 1823 virtus ksysguardd                       172      180      235      696 
 1842 virtus /usr/lib/at-spi2-core/at-sp      640      216      266      948 
18582 virtus ksysguardd                         0      352      409      868 
 1685 virtus /usr/lib/x86_64-linux-gnu/l     1700      380      441     1936 
 1697 virtus /usr/bin/xembedsniproxy         1832      412      514     2312 
 1639 virtus /usr/bin/kglobalaccel5          4688      476      543     2280 
 1608 virtus /usr/lib/x86_64-linux-gnu/l     3704      500      589     2512 
18535 virtus /usr/lib/x86_64-linux-gnu/l     4148      528      601     2396 
 1739 virtus /usr/lib/x86_64-linux-gnu/l     4096      580      663     2484 
 1658 virtus /usr/bin/ksmserver              4284      608      691     2588 
 1621 virtus /usr/bin/kaccess                3668      576      708     2872 
 1654 virtus /usr/bin/kactivitymanagerd      2492      640      755     2764 
 1711 virtus /usr/lib/x86_64-linux-gnu/l     4504      696      844     2960 
 1228 virtus /usr/bin/dbus-daemon --sysl      380      988     1041     1536 
 1682 virtus /usr/bin/krunner               18228      828     1235     4324 
15846 virtus /bin/bash                       1036     1204     1306     2148 
 1839 virtus /usr/bin/kuiserver              3364     1520     1558     2120 
 1680 virtus /usr/bin/baloo_file             1820     1524     1820     4356 
15247 virtus /usr/bin/konsole                9852     5756     8933    17740 
21545 virtus /usr/bin/python /usr/bin/sm        0    15348    15669    17284 
 1611 virtus kded5 [kdeinit5]               59392    15412    15903    19720 
 1669 virtus kwin_x11                       20504    11788    22154    36736 
18577 virtus /usr/bin/ksysguard                 0    19776    23774    33772 
 1687 virtus /usr/bin/plasmashell           97408   106148   112369   124608 
18543 virtus /usr/bin/qbittorrent           45108   200448   203813   212620

Технические подробности недавнего отключения дополнений в Firefox (комментарий)

Если просуммировать по колонке swap, то там никак не получится 700 мб.

А slabtop что показывает?

Щас посмотрю. Но знаешь что я еще заметил? Первые 5 часов, когда в свопе были жалкие 8 мб, оперативка была занята в среднем на 780 мб.

И вот идет 6й час, своп резко растолстел до 700 мб, а оперативка впервые снизилась до 440 мб. Такое ощущение, что kde начинает неадекватить и зачем-то очищает оперативку, перекидывая ее в своп.

Но все-равно, это было бы где-то 300 мб, а своп уже 700 мб.

Если система 32битная, то такое поведение как раз объяснимо.

Swap за 5 минут растолстел до 1.5 гб, видимо опять все зависнет.

Вывод slabtop:

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

Нет, она 64-битная, а виртуалке выделено 4 гб, из которых никогда больше 800 мб не расходовалось.

Вот и все, своп заполнился, система опять зависла. Рекорд 6 часов, если использовать qBittorent вместо KTorrent (там был максимум 1 час с отключенным свопом и 20 минут с включенным).

Нет, она 64-битная

И хост и гость?

Конечно, это kubuntu 18.04, она же и в виртуалке.

лампочка hdd постоянно светится, и 100% загрузки CPU.

По симптомам похоже на утечку памяти в ядре гостя. Какие-то левые модули ставил? Если да, убери их.

Нет, там все фирменное, ничего не менял на этом компе. И так оно ведет себя только в виртуалке, а мне надо чтобы оно работало именно в виртуалке.

И зависает оно полностью (если это важно), а не только иксы - невозможно послать от Virtualbox сигнал на корректное завершение работы, т.е. только жесткое отключение виртуалки помогает.

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

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

Попробуй rtorrent или какой нибудь консольный клиент поднять в голой TTY

Удостоверьтесь, что у вас tmpfs не забивается. Поставьте watch 'df -h | grep tmpfs'

Вот это я еще не пробовал. Не знаю что это такое, но сейчас поставлю и удостоверюсь.

Тест проведу на KTorrent, чтобы не ждать снова 6 часов.

Что, и guest additions в виртуалке не стоят?

Конечно стоят, я же общую папку поднимал для обмена.

Удали их.

Не вариант. Как я должен файлы перегонять из гостевой системы в хост? И чем тебе так не нравятся гостевые дополнения (не те, что в репозитории ubuntu, а официальные от oracle).

А тут уже спрашивали у ТСа, что он там качает, какого размера и структуры?

Модули VB, очевидно же.

А, ну тогда это меняет дело. Не хочешь удалять их? Чини их.

Цельные файлы по 10-15 гб.

Например, всего 2 таких файла на скорости 2-3 мбит/с, и виртуалка в любом случае зависнет.

По характеристикам виртуалка мощная, дискового пространства, процессоров и памяти там полно. Видеопамять 128 мб (максимум, сколько дает выделить), 3D-акселерация отключена, но она наверно и не нужна здесь.

Да он вообще торрент в VB shared folder напрямую скачивает. При том, что VB качеством кода не славится, ничего удивительного нет.

Хотя изолировать баг было бы интересно.

Да он вообще торрент в VB shared folder напрямую скачивает. При том, что VB качеством кода не славится, ничего удивительного нет.

Ты бы для начала вот это прочитал.

Постоянное зависание Virtualbox при использовании KTorrent (комментарий)

Баг был давно исправлен, и в обычной папке все зависает точно так же, как и в общей.

а мне надо чтобы оно работало именно в виртуалке

Нескромный вопрос — а зачем? Не является ли это https://en.wikipedia.org/wiki/XY_problem ?

Вот и я про это. Мне даже почему-то помнится, что в багзилле ядра игнорируют баг, если в ядро были загружены модули VirtualBox. И вроде исходники всех частей есть, не больно какие-то модули NVIDIA, где здоровенный блоб непонятного содержания, но смотреть в код модулей VirtualBox никому не хочется.

Ну, не этот, так другой какой-нибудь баг VB.

Были ли изменения в sysctl гостевой системы?

Используется ли tmpfs, zram?

Затем, что в основной системе стоит IP с запретом на P2P, и менять его по многим причинам нельзя. Так же там небольшой сервачок, на этот IP завязанный. Комп достаточно мощный, чтобы торренты вертелись в изолированной виртуалке. В основной системе они мне не нужны.

Это именно какая-то проблема новых версий kubuntu. В 14.04 сколько помню, вообще такого не было, все работало нормально и торренты в виртуалке качались неделями.

Были ли изменения в sysctl гостевой системы?

Не знаю, может и были. Как это проверить?

Используется ли tmpfs, zram?

Вот это я сейчас проверяю. Выше попросили ввести:

watch 'df -h | grep tmpfs'

И с начала работы торрент-клиента до момента самого зависания цифры не менялись:

Каждые 2,0с:        df -h | grep tmpfs                                                                         vbox: Sat May 18 21:27:32 2019

tmpfs            395M        1016K  394M            1% /run
tmpfs            2,0G            0  2,0G            0% /dev/shm
tmpfs            5,0M         4,0K  5,0M            1% /run/lock
tmpfs            2,0G            0  2,0G            0% /sys/fs/cgroup
tmpfs            395M          12K  395M            1% /run/user/1000

Т.е. этот tmpfs, если он и есть, то вообще не меняется по цифрам.

А как проверить zram?

Ты просто установил Кубунту в виртуалку и никак её не настраивал? ну кроме установки гостевых дополнений