Чистая kubuntu 18.04.1, полное обновление apt-get upgrade, пакет openvpn и гостевые дополнения от oracle. Больше ничего.

А торренты через openvpn тянутся?

Ага, через обычный IP все режется.

Вангую, что проблема в нём. Точнее, в стыке openvpn и торрентов.

Я бы мог наверно не запариваться. 6 часов до зависания позволяет qBittorent, и за это время вполне можно скачать нужные файлы. Но проблема то серьезная, и наверно раз столько людей спохватилось помочь, то неплохо было бы довести дело до конца, и сформировать багрепорт какой-то. Вот только какой и кому - пока непонятно. Не ясно в чем проблема - в торрент-клиентах, новой kubuntu или Virtualbox.

Вангую, что проблема в нём. Точнее, в стыке openvpn и торрентов.

Проблема в закачке торрентов через Virtualbox. На живом железе таких проблем нет, всегда качал через VPN, но сейчас нет возможности качать на живом, только в виртуалке.

Пробрасывай контроллер диска в виртуалку. Хренли ты ожидал?

Ещё бы посмотреть на free -m в момент когда своп начинает забиваться.

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

man контейнеры

Ещё бы посмотреть на free -m в момент когда своп начинает забиваться.

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

До запуска KTorrent - пока все нормально:

              всего        занято        свободно      общая  буф./врем.   доступно
Память:        3944         421        2856         117         666        3190
Подкачка:        2047           0        2047

В момент запуска KTorrent (своп = 0) - пока вроде нормально:

              всего        занято        свободно      общая  буф./врем.   доступно
Память:        3944         690        2412         237         841        2800
Подкачка:        2047           0        2047

Через 8 минут после запуска. Своп еще не начал забиваться, но посмотри на график «свободной памяти» - ее почти не осталось! При том, что кол-во используемой памяти все-равно не превышает 800 мб, и не превысит вплоть до зависания. Как так?

              всего        занято        свободно      общая  буф./врем.   доступно
Память:        3944         733         894        1374        2316        1616
Подкачка:        2047           0        2047

Через 10 минут. Видимо щас начнется забивание свопа...

              всего        занято        свободно      общая  буф./врем.   доступно
Память:        3944         757         198        2044        2988         921
Подкачка:        2047           0        2047

Через 11 минут. А вот и своп начал забиваться.

              всего        занято        свободно      общая  буф./врем.   доступно
Память:        3944         758         101        2210        3083         754
Подкачка:        2047          17        2030

Колдовство какое-то.

В реальности системный монитор показывает то же самое (по части используемой памяти) - программы в сумме не используют больше 800 мб (из максимальных 4 гб).

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

Графический системный монитор не отображает исчезновение свободной памяти, которое приводит к зависанию.

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

Не надо смотреть на свободную память

Хорошо.

надо смотреть на доступную. Но её тоже становится мало.

Вот именно, и она пропадает в неизвестном направлении.

За 2 минуты до зависания:

              всего        занято        свободно      общая  буф./врем.   доступно
Память:        3944         510         130        3227        3303          52
Подкачка:        2047        1737         310

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

Память: 452 Мб / 3.9 Гб

Кто-то может объяснить, на какой лаже сделан этот графический системный монитор, и куда слать багрепорт, чтобы его починили?

Зачем ты держишься за этот VirtualBox и его модули?

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

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

но в новых версиях ПО кто-то где-то конкретно накосячил

VirtualBox

Интересно, кто бы это мог быть…

С памятью всё сложно. Все утилиты упрощают картину, и поэтому в экстремальных условиях могут показывать что-то непонятное. В /proc/meminfo данные ближе к реальности, но там в них ещё нужно вникать.

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

И ты думаешь, что это поможет. Впрочем, вариантов все-равно не осталось, давай так и сделаем...

Говоришь, гостевые дополнения это дико нестабильная штука?

Лучше откатиться на virt-manager. Он не такой красивый, как VirtualBox, но зато все нужные компоненты уже находятся в ядре.

И даже, как уже писали выше, тебе достаточно использовать контейнеры. Немного муторно разбираться с настройкой, но зато у тебя там будет запущены только openvpn и торрент-клиент. Не нужно будет жертвовать оперативку только для того, чтобы она простаивала внутри гостя. Не нужны вспомогательные сервисы, от которых тебе никакой пользы. Общая папка будет просто через mount –bind, то есть без накладных расходов.

И даже, как уже писали выше, тебе достаточно использовать контейнеры. Немного муторно разбираться с настройкой, но зато у тебя там будет запущены только openvpn и торрент-клиент. Не нужно будет жертвовать оперативку только для того, чтобы она простаивала внутри гостя. Не нужны вспомогательные сервисы, от которых тебе никакой пользы. Общая папка будет просто через mount –bind, то есть без накладных расходов.

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

Не знаю, я методом тыка настраивал. Точно знаю, что мой способ — неправильное использование Docker. Но я не devops, мне работает — и ладно. До компа доберусь, выложу dockerfile.

Не знаю, я методом тыка настраивал.

Тогда я лучше сам, а то мало ли ты чего накосячил. Про Docker вроде много статей на хабре есть, часто мельтешит, наверно и для новичков найдется.

-=:=-

Интересно, а если каждые 5 минут в виртуалке гонять костыль:

#!/bin/bash
echo "1" > /proc/sys/vm/drop_caches
echo "2" > /proc/sys/vm/drop_caches
echo "3" > /proc/sys/vm/drop_caches
echo "4" > /proc/sys/vm/drop_caches

Будет ли свап забиваться?

Щас проверим.

Вообще не понятно,чем он забивается?

Вот и мне непонятно.

растут то shared и block буфер?

Как это посмотреть?

Второе как и файл кеш как бы не может в свап попадать?

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

-=:=-

Как это посмотреть?

localhost ~ # free -m
              total        used        free      shared  buff/cache   available
Mem:          31548        1590       29342         168         615       29290
Swap:          6143           0        6143

shared buff/cache

Вообще, я когда нашел чей-то костыль для ntfs-3g, чтобы она не срала в раму, выдавливая файл кеш.

#!/bin/bash
MEM='1536M'
mkdir /sys/fs/cgroup/memory/ntfs-3g 1>/dev/null 2>/dev/null
cd /sys/fs/cgroup/memory/ntfs-3g

PIDS=$(ps aux | grep [m]ount.ntfs-3g | awk '{print $2}')
for PID in $PIDS
do
    echo $PID > tasks
done
echo $MEM > memory.limit_in_bytes
echo $MEM > memory.max_usage_in_bytes
echo $MEM > memory.memsw.limit_in_bytes
echo $MEM > memory.memsw.max_usage_in_bytes
echo $MEM > memory.soft_limit_in_bytes

Интересно, а если каждые 5 минут в виртуалке гонять костыль:

Будет ли свап забиваться?

sudo echo "1" > /proc/sys/vm/drop_caches
bash: /proc/sys/vm/drop_caches: Отказано в доступе

Ну OK. (•‿•)

А можно ли docker в обычной системе осваивать, или лучше в виртуалке, чтоб ничего не сломать?

-=:=-

sudo -команда тебе поможет
этот скрипт или команды для рута

sudo -команда тебе поможет

Так я пробовал и sudo и su.

-=:=-

в терминале набери su
спросит пас рута
введешь, получишь # в командной строке

Не признает своего властелина.

virtus@vm:~$ su
Пароль: 
su: Сбой при проверке подлинности

Докер это система изоляции. Теоретически им, наверное, можно что-то сломать, но я не знаю как.

Единственное что могу посоветовать — не добавляй пользователя в группу docker. Иногда встречается такой совет, чтобы не использовать каждый раз sudo. Чем так делать, проще сделать sudo без пароля, потому что эти действия эквивалентны.

sudo -i

Ты запускаешь echo от рута, но его вывод перенаправляется в файл текущей оболочкой, работающей из-под твоего пользователя. А в эти файлы может писать только root. Поэтому ты получаешь отказ в доступе.

В убунте у рута пароль заблокирован, поэтому в него не получается залогиниться. Но это можно делать через sudo, потому что он принимает пароль пользователя, а не рута, как su.

Просто голова отвалилась в конце дня, совсем забыл что sudo su в ubuntu.

Единственное что могу посоветовать — не добавляй пользователя в группу docker. Иногда встречается такой совет, чтобы не использовать каждый раз sudo. Чем так делать, проще сделать sudo без пароля, потому что эти действия эквивалентны.

Спасибо, запомню.

echo "1" > /proc/sys/vm/drop_caches
echo "2" > /proc/sys/vm/drop_caches
echo "3" > /proc/sys/vm/drop_caches
echo "4" > /proc/sys/vm/drop_caches

Ничего не произошло. Если это должно как-то очищать своп, то нет - он не очищается.

За скрипт спасибо, сохраню пожалуй. Но пока docker попытаюсь освоить, перспектива не тратить столько ресурсов на виртуалки взяла верх.

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

Не морочьте ТС голову.) virt-manager — самый здравый совет в данном случае. Доступ к файлам хоста настраивается прямо в нем по протоколу 9p, реализованному в ядре. 9p работает стабильно, по моему опыту, хотя RH его и не хочет поддерживать. Если оно не нравится — есть десятилетиями отшлифованные NFS и SMB, которые настраиваются в одну строчку.

С docker ТС вряд ли быстро разберется с правами (последствия порочного подхода, когда контейнеры запускаются от рута).

Да, есть такое. Сторонний код в ядре разбирать на предмет багов не любят.

Попробуй ограничить допустимое количество dirty-страниц в памяти ядра (возможно, упадёт скорость скачивания, но перестанет бесконтрольно расти своп):

❯ cat /etc/sysctl.d/50-dirty.conf
vm.dirty_bytes = 66554432
vm.dirty_background_bytes = 33554432

Немного муторно разбираться с настройкой

Да ладно, на systemd это элементарно, вот, за две минуты накарябал на базе своего минимального контейнера (куда только доставил qbittorrent). Контейнер:

$ cat /etc/systemd/network/10-inet.network 

[Match]
Name=mv-mv0

[Network]
DHCP=ipv4

$ systemctl cat torrent

# /etc/systemd/system/torrent.service
[Unit]
Description=Qbittorrent for container
After=network.target

[Service]
Type=simple
User=user
Environment="DISPLAY=:0"
ExecStart=/usr/bin/qbittorrent

[Install]
WantedBy=multi-user.target

Ну и на хосте запускать через

systemd-nspawn -bD /var/lib/machines/minimal --network-macvlan=mv0 --bind=/tmp/.X11-unix/X0

Такое ощущение, что kde начинает неадекватить

Попробуй что-то совершенно другое, например: VMWare, openSUSE Tumbleweed LXDE, Transmission.
Если не хочешь VMware, то попробуй другую версию VirtualBox и гостевые дополнения из родного репозитория, а не собранные из исходников.

У тебя в VPN есть форвардинг портов (входящие подключения доступны)? Если нет, то проще на реальной системе отдельный торрент клиент настроить на socks5 прокси.

virt-manager умеет работать с lxc контейнерами — тебе для просоты использования самое то.

RH это не одобряет.

-=:=-

Ну, видимо таки VirtualBox виновен.
Повторил твой сетап на HVM/QEMU+Virt-manager.Кубунта 18.4.2 и кал_торрент. Все х64.
Ни каких проблем.
Аптайм 45 мин. качаю какуюто дичь на ~18 гиг. До вечера еще далеко, так что посмотрю после работы.

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

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

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

Кстати, а чего они такие тяжелые, эти дополнения? Без них kubuntu с торрентами весит 500 мб в памяти, а с дополнениями 750 мб.

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

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

Тебе поможет NFS. Расшариваемое на хосте настраивается в /etc/exports, в госте монтируется через mount. Работает очень хорошо.

Кстати, а чего они такие тяжелые, эти дополнения?

В ядре довольно тяжело писать код правильно. Если накосячишь, система падает целиком. Если утечка, то у всей системы целиком.