Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Монтирование NFS-ресурсов UNAS с Proxmox - Случайные зависания, UniFi Drive
 
Привет всем, я запускаю UNAS Pro в своей сети и использую NFS для монтирования общих ресурсов на мой сервер Proxmox. Монтирование работает изначально, но я сталкиваюсь со случайными зависаниями. В основном он используется для размещения медиафайлов для Plex, и потоки просто случайно обрываются. В этот момент, если я захожу на хост Proxmox, чтобы проверить, что произошло, и выполняю команду ls на смонтированном ресурсе, всё зависает бесконечно.

Вот моя текущая запись в /etc/fstab на Proxmox:
192.168.100.30:/var/nfs/shared/Media /mnt/nfs/unas-media nfs vers=3,rw,noatime,_netdev,tcp,nconnect=4,soft,x-systemd.automount,x-systemd.idle-timeout=600 0 0

Дополнительные детали:
Я использую NFSv3, как указано в интерфейсе, это поддерживаемая версия.
Сетевая связь стабильна, большие тесты трафика показывают 0% потери пакетов и низкую задержку.
Зависания выглядят случайными и иногда происходят даже при минимальном вводе-выводе.
Интересно, сталкивался ли кто-нибудь с похожими проблемами при использовании NFS экспортов UNAS на Proxmox, и есть ли какие-нибудь рекомендуемые параметры или обходные пути для предотвращения случайных зависаний.

Спасибо заранее за любые советы!
 
У меня была такая же проблема с постоянными зависаниями UNAS при использовании NFS и SMB-ресурсов как из виртуальной машины, так и из LXC-контейнера в Proxmox с медиа-сервером. Это происходило постоянно, и независимо от того, что я ни пробовал, система просто не работала. У меня были похожие проблемы и на Windows-ПК при загрузке на SMB-ресурс — случайные зависания приводили к сбою загрузки. Все это происходило в то время, когда мой сервер Proxmox был подключен к USW-16 Lite POE, который был соединен с коммутатором на UDM SE. UNAS также был подключен напрямую к UDM SE через SFP+.

С тех пор я отказался от встроенного коммутатора UDM. Теперь у меня есть Pro XG 10 POE, подключенный к UDM через SFP+, и UNAS подключен ко второму порту SFP+ на Pro XG. Сервер Proxmox по-прежнему подключен к коммутатору USW-16 Lite, но теперь этот коммутатор соединен с моим новым XG-коммутатором. Я сделал это изменение не из-за проблемы с сетевыми зависаниями и честно не ожидал никаких улучшений. Однако прошло несколько недель, и независимо от того, как сильно я нагружаю пропускную способность UNAS, у меня не было ни одного сетевого зависания с момента переключения.

Не уверен, это совпадение или нет, но решил поделиться своим опытом, поскольку я постоянно обновлял эту ветку больше месяца в надежде на исправление.
 
У меня были похожие проблемы при попытке использования SMB, но я тестировал NFS и вот что вижу:

[Fri Feb 27 22:50:51 2026] rpc-srv/tcp: nfsd: sent 159364 when sending 229504 bytes - shutting down socket
[Fri Feb 27 23:15:13 2026] rpc-srv/tcp: nfsd: sent 260556 when sending 262272 bytes - shutting down socket
[Fri Feb 27 23:15:49 2026] rpc-srv/tcp: nfsd: sent 178104 when sending 262272 bytes - shutting down socket
[Fri Feb 27 23:16:19 2026] rpc-srv/tcp: nfsd: sent 167968 when sending 262272 bytes - shutting down socket
[Fri Feb 27 23:16:49 2026] rpc-srv/tcp: nfsd: sent 169904 when sending 262272 bytes - shutting down socket

Я вернулся обратно на SMB, но время от времени замечаю высокую задержку ввода-вывода и вижу это в логах proxmox:

CIFS: VFS: \\192.168.1.110 has not responded in 180 seconds. Reconnecting...
 
Я столкнулся с точно такой же проблемой. Я избавился от своего Synology NAS и заменил его на Unifi UNAS 4 Pro, и с тех пор у меня начались неприятности. Прошло всего 2 дня, а это уже сводит меня с ума — каждые 6–8 часов Proxmox полностью зависает из-за тормозов. Команда `dmesg | grep rpc-srv` не выдаёт ничего. Вот что я уже пробовал без результата:

Отключил Energy-Efficient Ethernet (EEE) на сетевой карте Intel I219-V (eno1) [хост Proxmox]

Переключил все 4 NFS-монтирования с hard на soft с параметром timeo=50 — как в живом режиме (переподключение), так и постоянно в /etc/pve/storage.cfg
 
Я столкнулся с точно такой же проблемой: мой UNAS Pro, который раздаёт NFS на Proxmox, случайно зависает. Команды типа ls зависают бесконечно, а Proxmox выбрасывает ошибки nfs: server not responding, timed out. Эти ошибки — только симптом на стороне клиента, а настоящая проблема, похоже, на самом UNAS.

Я вытащил support dump с UNAS Pro (v5.0.12) и прошёлся по логам ядра. Вывод dmesg рассказывает реальную историю: более 164 отказов NFS TCP сокетов за одну неделю. Примеры:

rpc-srv/tcp: nfsd: sent 130380 when sending 131200 bytes - shutting down socket
rpc-srv/tcp: nfsd: got error -11 when sending 112 bytes - shutting down socket

Ошибка -11 это EAGAIN, что означает, что буфер отправки TCP ядра переполнен. Когда nfsd не может завершить отправку данных, он закрывает весь TCP-соединение. Поэтому Proxmox зависает — точка монтирования становится неактивной в ожидании соединения, которое UNAS только что убил. Эти отказы приходят волнами с часами тишины между ними, вот почему зависания кажутся "случайными". На самом деле это происходит каждый раз, когда волна чтений заполняет буфер отправки.

Похоже, причина в том, что UNAS поставляется со стандартными размерами буферов TCP из Debian, которые слишком малы для выделенного NAS, выполняющего интенсивные NFS-передачи. Я также заметил, что коэффициент попаданий в кэш ответов NFS на моём UNAS практически нулевой (1383 попадания против 27 миллионов некэшированных запросов). Это означает, что каждая повторная передача, вызванная этими отказами сокетов, должна быть полностью обработана заново вместо того, чтобы быть подана из кэша, что усугубляет проблему.

Я ещё не тестировал исправление, но мой следующий шаг — подключиться по SSH к UNAS и увеличить размеры буферов TCP:

sysctl -w net.core.wmem_max=16777216
sysctl -w net.core.rmem_max=16777216
sysctl -w net.ipv4.tcp_wmem="4096 1048576 16777216"
sysctl -w net.ipv4.tcp_rmem="4096 1048576 16777216"

На стороне Proxmox я планирую уменьшить rsize и wsize со стандартного 1MB до 256KB, чтобы снизить давление буфера на одну операцию.

Если кто-то хочет проверить, не столкнулся ли он с той же проблемой, подключитесь по SSH к UNAS и выполните:

dmesg | grep rpc-srv

Если видите сообщения о закрытии сокета, это та же проблема исчерпания буфера. Буду рад услышать, помогли ли кому-нибудь эти настройки sysctl. Честно говоря, это выглядит как то, что Ubiquiti должна была настроить по умолчанию на UNAS Pro.

________

Обновление: Я подключился по SSH и подтвердил проблему. Это даже хуже, чем я думал — это не просто стандартные значения Debian. Ubiquiti поставляет файл /etc/sysctl.d/10-10g-net-tcp-udp-tune.conf, который явно устанавливает wmem_max и rmem_max в 256KB. Это их конфиг "10Gbps network tuning", и он ограничивает буфер отправки TCP настолько сильно, что nfsd не может завершить отправки. Максимум tcp_wmem установлен на 16MB в этом же файле, но это никогда не может быть достигнуто, потому что wmem_max ограничивает его до 256KB. Так что файл настроек противоречит самому себе.

Я применил исправление sysctl и сделал его постоянным, создав /etc/sysctl.d/15-nfs-tcp-fix.conf со значениями из моего предыдущего поста. Большее число означает, что он загружается после файла Ubiquiti и переопределяет сломанные значения. Теперь наблюдаю, прекратятся ли зависания.

Если вы это применяете, имейте в виду, что обновление прошивки, вероятно, перезапишет или сбросит /etc/sysctl.d/, поэтому вам нужно было бы переприменить его после обновления.
 
Привет @senatorsfc, не могли бы вы предоставить файл поддержки из UNAS и Gateway Console?
 
У меня была такая же проблема, но новое обновление для UNAS и UDM (версии 5.0.9 или выше) это решит. Попробуй получить доступ к Early access или немного подожди 😉 Надеюсь, UI выпустит это как можно скорее.
 
Можешь пожалуйста объяснить, что мне нужно добавить в файлы fstab и lxcs.conf?
 
У меня тоже проблемы с Proxmox и UNAS PRO. Две месяца всё работало идеально, но два дня назад NFS share стал зависать с огромной задержкой ввода-вывода. Это длится минут десять, пока снова не заработает:

Jan 15 08:58:13 cerebro kernel: nfs: server 192.168.2.5 not responding, still trying
Jan 15 08:58:25 cerebro kernel: nfs: server 192.168.2.5 not responding, still trying
Jan 15 08:58:33 cerebro kernel: nfs: server 192.168.2.5 not responding, still trying
Jan 15 08:58:33 cerebro kernel: nfs: server 192.168.2.5 not responding, still trying
Jan 15 08:58:33 cerebro kernel: nfs: server 192.168.2.5 not responding, still trying
Jan 15 08:58:33 cerebro kernel: nfs: server 192.168.2.5 not responding, still trying

И вот это из логов UNAS (не знаю, имеет ли отношение):

UNAS-Pro kernel: rpc-srv/tcp: nfsd: sent 129472 when sending 131200 bytes - shutting down socket
Jan 15 08:50:37 UNAS-Pro kernel: rpc-srv/tcp: nfsd: sent 56700 when sending 127104 bytes - shutting down socket
Jan 15 09:31:28 UNAS-Pro systemd-networkd-wait-online[813125]: Event loop failed: Connection timed out

Кстати, я также использую mp0 для монтирования на lxcs. Странно, никогда раньше проблем не было.
Страницы: 1
Читают тему (гостей: 1)