+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

NFS зависает, Proxmox WebGUI перестаёт отвечать и не удаётся сделать резервную копию., Proxmox Виртуальная Среда

Maciej Bursztynowski

Guest

26.06.2015 15:51:00

Это моя первая тема, так что хочу поздороваться со всеми. У меня странная проблема с NFS. Я установил Proxmox 3.4 на свой выделенный сервер OVH. Все работает довольно отлично, ВМы работают очень быстро, но есть странная проблема с NFS. Когда я подключаю NFS-шару через WebGUI как NFS share или монтирую NFS-шару в консоли + добавляю её как локальное хранилище, у Proxmox WebGui зависает интерфейс во время задачи резервного копирования. Иногда зависание проходит, но я не могу проверить сводку и статус этого хранилища во время бэкапа. Следующая проблема — резервное копирование не удаётся: у меня три ВМ. У двух из них маленькие диски ~20 ГБ, и резервное копирование на NFS-хранилище всегда завершается успешно, а при попытке сделать бэкап ВМ с диском примерно 256 ГБ оно постоянно падает. Если выбрать локальное хранилище и сделать резервное копирование, оно проходит успешно. Кто-нибудь сталкивался с такой проблемой?

manu Guest	#2 0 21.06.2017 09:56:00 26526KB → 25MB/c – это на самом деле не так уж и быстро. У меня был лучший показатель скорости с жёстким диском ноутбука, подключённым по USB (35 MB/c).

carles89

Guest

01.10.2015 15:45:00

Привет, Maciej! У меня похожая проблема с OVH. Когда я делаю резервное копирование нескольких гигабайт, всё нормально, но как только пытаюсь сохранить несколько ВМ (около 300-400 ГБ), иногда весь NFS-шар (BackupStorage) перестаёт отвечать, из-за чего на гипервизоре возникает высокая задержка ввода-вывода, и ВМ становится неподвижной. Иногда даже веб-интерфейс Proxmox тормозит из-за сбоев с NFS. Я уже обращался в поддержку OVH, но обычно они отвечают, что с Backup Storage всё в порядке. Я не доволен OVH. Хоть выделенные серверы и интерфейс управления действительно хорошие, по моему мнению, служба поддержки по телефону/почте и сервис BackupStorage оставляют желать лучшего. Кто-нибудь может посоветовать альтернативу OVH? С уважением,

jazzl0ver

Guest

19.06.2017 12:13:00

Все еще сталкиваюсь с такими проблемами NFS в Proxmox VE 4.4.. Код:
Jun 17 01:40:05 vm-box-1 kernel: INFO: задача lzop:1093 заблокирована более 120 секунд.
Jun 17 01:40:05 vm-box-1 kernel: Tainted: P W O 4.4.49-1-pve #1
Jun 17 01:40:05 vm-box-1 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" отключает это сообщение.
Jun 17 01:40:05 vm-box-1 kernel: lzop D ffff88014e10fa48 0 1093 1075 0x00000000
Jun 17 01:40:05 vm-box-1 kernel: ffff88014e10fa48 0000000000017300 ffff88081aaaad00 ffff88010500bc00
Jun 17 01:40:05 vm-box-1 kernel: ffff88014e110000 ffff88083ed17300 7fffffffffffffff ffffffff8185cb00
Jun 17 01:40:05 vm-box-1 kernel: ffff88014e10fba8 ffff88014e10fa60 ffffffff8185c215 0000000000000000
Jun 17 01:40:05 vm-box-1 kernel: Трассировка вызова:
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8185cb00>] ? bit_wait_timeout+0xa0/0xa0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8185c215>] schedule+0x35/0x80
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8185f465>] schedule_timeout+0x235/0x2d0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8185cb00>] ? bit_wait_timeout+0xa0/0xa0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8185b70b>] io_schedule_timeout+0xbb/0x140
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8185cb1b>] bit_wait_io+0x1b/0x70
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8185c5cf>] __wait_on_bit+0x5f/0x90
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8185cb00>] ? bit_wait_timeout+0xa0/0xa0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8185c681>] out_of_line_wait_on_bit+0x81/0xb0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff810c45d0>] ? autoremove_wake_function+0x40/0x40
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffffc0960c54>] nfs_wait_on_request+0x34/0x40 [nfs]
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffffc09659ed>] nfs_updatepage+0x1bd/0x9f0 [nfs]
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffffc0955dbf>] nfs_write_end+0x14f/0x4d0 [nfs]
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8140d97f>] ? iov_iter_copy_from_user_atomic+0x8f/0x230
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8118eb64>] generic_perform_write+0x114/0x1c0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff81190e06>] __generic_file_write_iter+0x1a6/0x1f0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8122c653>] ? touch_atime+0x33/0xd0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff81190f34>] generic_file_write_iter+0xe4/0x1e0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffffc095553a>] nfs_file_write+0x9a/0x160 [nfs]
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8120eafb>] new_sync_write+0x9b/0xe0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8120eb66>] __vfs_write+0x26/0x40
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8120f1d9>] vfs_write+0xa9/0x190
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff8120ffb5>] SyS_write+0x55/0xc0
Jun 17 01:40:05 vm-box-1 kernel: [<ffffffff81860336>] entry_SYSCALL_64_fastpath+0x16/0x75
Jun 17 01:40:26 vm-box-1 pvestatd[1519]: обновление статуса (105.333 секунды)
Jun 17 01:40:58 vm-box-1 pvestatd[1519]: получен таймаут
Код:
root@vm-box-1:/var/log# pveversion -v
proxmox-ve: 4.4-86 (запущенное ядро: 4.4.49-1-pve)
pve-manager: 4.4-13 (текущая версия: 4.4-13/7ea56165)
pve-kernel-4.4.35-1-pve: 4.4.35-77
pve-kernel-4.4.49-1-pve: 4.4.49-86
lvm2: 2.02.116-pve3
corosync-pve: 2.4.2-2~pve4+1
libqb0: 1.0.1-1
pve-cluster: 4.0-49
qemu-server: 4.0-110
pve-firmware: 1.1-11
libpve-common-perl: 4.0-94
libpve-access-control: 4.0-23
libpve-storage-perl: 4.0-76
pve-libspice-server1: 0.12.8-2
vncterm: 1.3-2
pve-docs: 4.4-4
pve-qemu-kvm: 2.7.1-4
pve-container: 1.0-97
pve-firewall: 2.0-33
pve-ha-manager: 1.0-40
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u3
lxc-pve: 2.0.7-4
lxcfs: 2.0.6-pve1
criu: 1.6.0-1
novnc-pve: 0.5-9
smartmontools: 6.5+svn4324-1~pve80
zfsutils: 0.6.5.9-pve15~bpo80

Есть хоть какие-то шансы это как-то решить?

carles89 Guest	#5 0 19.06.2017 12:37:00 Похоже, проблема на стороне вашего NFS-сервера. Вы случайно не используете OVH?

jazzl0ver

Guest

19.06.2017 13:39:00

Нет, я не использую OVH. Мой NFS-сервер — это CentOS 7 с хранением данных на двух дисках, управляемых зеркалом ZFS. Proxmox и CentOS находятся в одной и той же 1Gb локальной сети.

NFS-сервер:
Код:
[root@filer-1 ~]# exportfs -v
/zmir/backup/images
vm-box-*.dom.com(rw,async,wdelay,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)

Клиенты Proxmox:
Код:
root@vm-box-1:/var/log# mount
...
filer-1.dom.com:/zmir/backup/images на /mnt/pve/filer-1-images тип nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.26.1.31,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=172.26.1.31)

Я только что сменил планировщик на deadline (думал, что уже делал это раньше, но, видимо, нет, или он как-то сбросился на noop). Не уверен, поможет ли это.

Код:
[root@filer-1 etc]# cat /sys/block/sd{a,b}/queue/scheduler
noop [deadline] cfq
noop [deadline] cfq

carles89

Guest

19.06.2017 17:41:00

Привет, jazzl0ver! Похоже, что связь по NFS прерывается, из-за чего виснет vzdump. Это может быть из-за плохого сетевого соединения или плохой работы сервера NFS. Ты пробовал использовать mdadm вместо zfs? ZFS требует много оперативной памяти для кэширования, и если у тебя недостаточно железа, это может стать узким местом. У меня проблема была из-за какого-то QoS, применённого в сети: после передачи X ГБ на резервный сервер сеть зависала на какое-то время, из-за чего всё становилось нестабильным. Мы решили это, переключившись на выделенную сеть и отдельный сервер для резервных копий.

jazzl0ver

Guest

19.06.2017 18:46:00

@carles89, спасибо за ответ и желание помочь! Думаю, дело не в сети. Порт коммутатора загружен меньше чем на 100 Мбит/сек во время бэкапа (хотя порт 1 Гбит). Скорее всего, проблема в NFS-сервере. Я не пробовал mdadm, потому что ZFS мне показался предпочтительнее из-за компрессии и дедупликации. В системе 16 ГБ оперативной памяти:
Код:
[root@filer-1 etc]# free -m
total used free shared buff/cache available
Mem: 15847 8635 5436 239 1775 5618
Swap: 0 0 0

Так что не думаю, что дело в оперативке. Однако загрузка ввода-вывода при бэкапе поднимается до 86%:
Код:
09:00:01 PM CPU %user %nice %system %iowait %steal %idle
...
09:40:01 PM all 6.07 0.00 13.56 44.09 0.00 36.28
09:50:01 PM all 6.22 0.00 7.33 48.03 0.00 38.42
10:00:01 PM all 5.80 0.00 6.67 53.73 0.00 33.80
10:10:01 PM all 6.91 0.00 8.92 52.28 0.00 31.90
10:20:01 PM all 6.89 0.00 8.10 48.02 0.00 36.99
10:30:01 PM all 6.66 0.00 8.75 45.83 0.00 38.76
10:40:01 PM all 1.34 0.00 5.90 55.32 0.00 37.44
10:50:01 PM all 0.97 0.00 5.79 64.41 0.00 28.83
11:00:01 PM all 1.32 0.00 5.59 61.02 0.00 32.06
11:10:01 PM all 1.19 0.00 5.41 63.69 0.00 29.72
11:20:01 PM all 4.26 0.00 7.87 59.43 0.00 28.44
11:30:01 PM all 3.21 0.00 4.40 86.98 0.00 5.41
11:40:01 PM all 3.15 0.00 4.50 87.74 0.00 4.61
11:50:01 PM all 4.15 0.00 5.46 86.19 0.00 4.19

Возможно, из-за этого NFS-сервер начинает тормозить. Интересно, есть ли способы как-то настроить NFS-сервер, чтобы избежать таких проблем...

manu

Guest

20.06.2017 09:51:00

@jazzlOver
1. Наличие I/O wait просто значит, что хранилище сейчас является узким местом для 44% твоих процессов в целом. Когда у тебя есть процессы, например бэкапы, которые больше читают и пишут, чем вычисляют, эти процессы всегда будут ждать ввода-вывода. Например, эта команда вызовет I/O wait на любом хранилище, просто потому что чтение из RAM быстрее, чем запись на диск:
dd if=/dev/zero of=/root/bla bs=1M
(если только твоё хранилище не на базе RAM, конечно).

2. Сообщение dmesg с "task blocked for more than 120s" — это предупреждение, что ядро заметило: процесс не смог выполнить запланированную операцию ввода-вывода за 120 секунд. Это может значить либо, что хранилище сильно занято, либо просто офлайн, если речь идёт о NFS-сервере. Если NFS-сервер недоступен, pve это обнаружит и зафиксирует в логах. Проверить, не отмечено ли хранилище как офлайн, можно командой:
journalctl -u pvestatd | grep 'not online'

А теперь про сильно занятое хранилище: выключи все свои ВМ и замерь производительность хранилища! Для сравнения: у меня на тестовой лаборатории NFS-сервер выдаёт 125 МБ/с при последовательной записи, что значит, что я полностью загружаю гигабитный Ethernet.

jazzl0ver

Guest

#10

20.06.2017 11:43:00

Привет, @manu. Спасибо за ответ. Дело в том, что NFS-сервер онлайн, просто он, похоже, зависает из-за высокой нагрузки ввода/вывода во время бэкапа и перестаёт отвечать на fsstat RPC-запросы клиентов nfs. Поэтому я думаю, есть ли какой-то способ настроить сервер, чтобы повысить его отзывчивость. Это не проблема Proxmox, я в курсе.

Бенчмаркинг ZFS — задача не из простых, так как он не поддерживает directio — вся нагрузка, по сути, кешируется:

Код:
filebench> load singlestreamwrite
27895: 9.689: Single Stream Write Version 3.0 personality successfully loaded
filebench> set $dir=/zmir/legacy/bench
filebench> run 60
27895: 19.904: Создаётся/предварительно выделяется место для файлов и наборов файлов
27895: 19.904: Файл largefile1: 0.000MB
27895: 19.906: Удалён любой существующий файл largefile1 за 1 секунду
27895: 19.906: Строится дерево для набора файлов /zmir/legacy/bench/largefile1
27895: 19.907: Создаётся файл largefile1...
27895: 19.907: Предварительно выделено 1 из 1 файла largefile1 за 1 секунду
27895: 19.907: Ожидание завершения предварительного выделения набора файлов
27903: 19.907: Запуск 1 последовательного потока записи
27904: 19.907: Запуск 1 потока seqwrite
27895: 20.907: Выполняется...
27895: 80.926: Запуск длился 60 секунд...
27895: 80.926: Детализация по операциям
seqwrite 239261 операций 3986 операций/с 3986.4 МБ/с 0.2 мс/операция 193 мкс/операция CPU [0мс - 75мс]
27895: 80.926: Итоги IO: 239261 операций, 3986.456 операций/с, (0/3986 чтение/запись), 3986.4 МБ/с, 521 мкс CPU на операцию, 0.2 мс задержка

filebench> load fileserver
27678: 11.207: File-server Version 3.0 personality successfully loaded
filebench> set $dir=/zmir/legacy/bench
filebench> run 60
27678: 55.093: Создаётся/предварительно выделяется место для файлов и наборов файлов
27678: 55.103: Набор файлов bigfileset: 10000 файлов, 0 обычных папок, средняя ширина папки = 20, средняя глубина папки = 3.1, 1240.757MB
27678: 55.105: Удалён любой существующий набор bigfileset за 1 секунду
27678: 55.105: Строится дерево для набора /zmir/legacy/bench/bigfileset
27678: 55.118: Создаётся набор файлов bigfileset...
27678: 57.948: Предварительно выделено 7979 из 10000 файлов набора bigfileset за 3 секунды
27678: 57.948: Ожидание завершения предварительного выделения набора файлов
27681: 57.948: Запуск 1 экземпляра filereader
27682: 57.949: Запуск 50 потоков filereaderthread
27678: 58.983: Выполняется...
27678: 118.987: Запуск длился 60 секунд...
27678: 118.990: Детализация по операциям
statfile1 108457 операций 1808 операц/с 0.0 МБ/с 0.0 мс/операция 2274 мкс CPU [0мс - 4мс]
deletefile1 108460 операций 1808 операц/с 0.0 МБ/с 0.3 мс/операция 2678 мкс CPU [0мс - 264мс]
closefile3 108465 операций 1808 операц/с 0.0 МБ/с 0.0 мс/операция 2273 мкс CPU [0мс - 1мс]
readfile1 108469 операций 1808 операц/с 237.7 МБ/с 0.5 мс/операция 3213 мкс CPU [0мс - 200мс]
openfile2 108473 операций 1808 операц/с 0.0 МБ/с 0.0 мс/операция 2232 мкс CPU [0мс - 11мс]
closefile2 108476 операций 1808 операц/с 0.0 МБ/с 0.0 мс/операция 2274 мкс CPU [0мс - 1мс]
appendfilerand1 108479 операций 1808 операц/с 14.1 МБ/с 0.4 мс/операция 3131 мкс CPU [0мс - 236мс]
openfile1 108481 операций 1808 операц/с 0.0 МБ/с 0.0 мс/операция 2262 мкс CPU [0мс - 11мс]
closefile1 108488 операций 1808 операц/с 0.0 МБ/с 0.0 мс/операция 2256 мкс CPU [0мс - 5мс]
wrtfile1 108495 операций 1808 операц/с 223.7 МБ/с 0.1 мс/операция 2410 мкс CPU [0мс - 98мс]
createfile1 108497 операций 1808 операц/с 0.0 МБ/с 0.3 мс/операция 2659 мкс CPU [0мс - 99мс]
27678: 118.990: Итоги IO: 1193240 операций, 19886.104 операций/с, (1808/3616 чтение/запись), 475.5 МБ/с, 437 мкс CPU на операцию, 0.6 мс задержка

manu

Guest

#11

20.06.2017 11:53:00

Это не проблема Proxmox, я в курсе, спасибо. Многие думают, что у них проблемы с виртуализацией из-за хранилища. Я тестирую ZFS с помощью fio и запускаю команду: fio --size=9G --bs=64k --rw=write --direct=1 --runtime=60 --name=64kwrite --group_reporting | grep bw. При этом я обязательно отключаю кэш перед тестом: sudo zfs get all | grep cache
tank/backup primarycache none local
tank/backup secondarycache none local.

Но, честно говоря, тест лучше проводить со стороны PVE на монтировании NFS. Не знаю, что у тебя на сервере ZFS, но если там обычные жесткие диски, стоит задуматься о SSD slog. Большинство производительности ZFS, которые я видел, страдали из-за того, что механические винчестеры не справлялись с синхронизацией лога транзакций на диск. Это хорошо видно на Linux-серверах с ZFS, когда процесс tgx_sync забирает весь IO-канал, что можно отследить с помощью iotop.

jazzl0ver

Guest

#12

20.06.2017 13:31:00

Вот результаты при отключённом кэше (с directio и без):
Хост Proxmox:
Код:
root@vm-box-1:/mnt/pve/filer-1-images# fio --size=9G --bs=64k --rw=write --direct=1 --runtime=60 --name=64kwrite --group_reporting | grep bw
write: io=2352.7MB, bw=40141KB/s, iops=627, runt= 60016msec
bw (KB /s): min=3984, max=65280, per=100.00%, avg=40415.02, stdev=20285.91

root@vm-box-1:/mnt/pve/filer-1-images# fio --size=9G --bs=64k --rw=write --runtime=60 --name=64kwrite --group_reporting | grep bw
write: io=3923.5MB, bw=66921KB/s, iops=1045, runt= 60035msec
bw (KB /s): min=211, max=3027297, per=100.00%, avg=71287.87, stdev=333613.91

NFS сервер:
Код:
[root@filer-1 legacy]# fio --size=9G --bs=64k --rw=write --direct=1 --runtime=60 --name=64kwrite --group_reporting | grep bw
fio: похоже, ваша файловая система не поддерживает direct=1/buffered=0
fio: пункт назначения не поддерживает O_DIRECT

[root@filer-1 legacy]# fio --size=9G --bs=64k --rw=write --runtime=60 --name=64kwrite --group_reporting | grep bw
write: io=1647.8MB, bw=26526KB/s, iops=414, runt= 63610msec
bw (KB /s): min=11, max=2165248, per=100.00%, avg=52684.16, stdev=270808.40

jazzl0ver

Guest

#13

23.06.2017 18:02:00

Извини за задержку. Да, это действительно не выглядит быстро. Возможно, дело в том, что включены дедупликация и сжатие ZFS. Но это не должно влиять на задержку, если выбран планировщик deadline (если я не ошибаюсь). Есть идеи, как заставить NFS-сервер отвечать быстрее?

jazzl0ver

Guest

#14

27.06.2017 12:02:00

Для протокола. Я забыл, что на NFS-сервере работает сервис Syncthing, который начал синхронизировать папку, которую я использовал для fio (моя ошибка). Вот результаты после его отключения:

Code:
root@vm-box-1:/mnt/pve/filer-1-images# fio --size=9G --bs=64k --rw=write --direct=1 --runtime=60 --name=64kwrite --group_reporting | grep bw
write: io=2838.8MB, bw=48446KB/s, iops=756, runt= 60001msec
bw (KB /s): min=14464, max=64896, per=100.00%, avg=48617.77, stdev=15286.39

root@vm-box-1:/mnt/pve/filer-1-images# fio --size=9G --bs=64k --rw=write --runtime=60 --name=64kwrite --group_reporting | grep bw
write: io=3809.2MB, bw=64959KB/s, iops=1014, runt= 60046msec
bw (KB /s): min= 427, max=3096047, per=100.00%, avg=68524.05, stdev=317124.94

[root@filer-1 legacy]# fio --size=9G --bs=64k --rw=write --runtime=60 --name=64kwrite --group_reporting | grep bw
write: io=2718.6MB, bw=46370KB/s, iops=724, runt= 60035msec
bw (KB /s): min= 56, max=2086016, per=100.00%, avg=48791.51, stdev=225312.56

manu

Guest

#15

03.07.2017 08:38:00

Хорошо, эти показатели немного лучше, но всё ещё не слишком впечатляют, так что неудивительно, что ваши бэкапы занимают много времени — нет никакой магии в создании быстрого NFS-сервера, кроме как использовать SSD и 10G/e Ethernet. У вас всё ещё появляются сообщения «task blocked for more than 120s»? Я бы посоветовал посмотреть на временные метки, когда это происходит, и попытаться сопоставить их с пиками I/O на стороне NFS.

jazzl0ver

Guest

#16

06.07.2017 12:25:00

Ну.. В общем, я не жалуюсь на скорость бэкапов.
Код:
INFO: transferred 85899 MB in 480 seconds (178 MB/s)
INFO: archive file size: 260MB
INFO: Finished Backup of VM 107 (00:08:02)

В другой день/время:
Код:
INFO: transferred 311385 MB in 5490 seconds (56 MB/s)
INFO: archive file size: 27.85GB
INFO: Finished Backup of VM 124 (01:31:33)

Так что сами бэкапы работают довольно хорошо. Проблема возникает, когда я пытаюсь получить счетчики диска через SNMP или просто выполнить команду «df -h» во время работы бэкапа — появляется значительная задержка перед выводом, которую я хотел бы сократить.

Сообщение ядра «INFO: task lzop:9045 blocked for more than 120 seconds» из моего первого поста всё ещё появляется, но очень редко (последний раз было 29 июня).

Тем не менее, я всё ещё наблюдаю ошибки «kernel: nfs: server filer-1 not responding» и «pvestatd: got timeout» во время бэкапов.

jazzl0ver Guest	#17 0 07.07.2017 11:40:00 Только что обнаружил, что планировщик ввода-вывода сбросился на noop: Код: [root@filer-1 ~]# cat /sys/block/sd{a,b}/queue/scheduler [noop] deadline cfq Интересно, как это могло произойти... Единственная догадка — профиль стоял на «balanced». Переключил на «latency-performance». Это ZFS. Он использует свой собственный планировщик и устанавливает системный в noop (если весь диск выделен под ZFS). Вот почему NFS-сервер зависает при интенсивных операциях ввода-вывода — ZFS не делит эти операции с ним. Опубликовал запрос на исправление: https://github.com/zfsonlinux/zfs/issues/6322

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры