ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | производительность nfs при sec=krb5 критически низкая | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Gleb Kulikov <glebus> |
| Component: | nfs-clients | Assignee: | Sergey Bolshakov <sbolshakov> |
| Status: | NEW --- | QA Contact: | qa-sisyphus |
| Severity: | critical | ||
| Priority: | P5 | CC: | aen, iv, sbolshakov |
| Version: | unstable | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
|
Description
Gleb Kulikov
2020-04-10 09:13:43 MSK
(Ответ для Gleb Kulikov на комментарий #0) > 1. при *ВКЛЮЧЕННОМ* sec=krb5, работа практически невозможна: запрос списка > файлов может отрабатывать крайне медленно, работа с отдельным файлом может > проходить крайне медленно. В то же время копирование отдельного файла > проходит на полной (нормальной) скорости, но *может* внезапно > приостанавливаться. > при *выключенном* sec=krb5, работа идёт на полной скорости, без замираний и > пауз. Падение производительности достигает 20x!!! При включенном sec=krb5, > невозможно пользоваться libreoffice на nfs шарах. > при трассировке и просмотре статистики выяснено: > nfsstat -rs > Server rpc stats: > calls badcalls badfmt badauth badclnt > 0 0 0 0 0 > в то же время, > Client rpc stats: > calls retrans authrefrsh > 700319 0 700319, > в трассировке постоянная проверка атрибутов и постоянные запросы к серверу > керберос, Когда керберос (использую ipa) не на том же сервере, что nfs > сервер, ситауция становится ещё хуже и падение производительности в пиках > достигает 40x. > В то же время, пользоваться несекьюрной nfs в не особенно доверенной сети, > безумие. что-то с этим надо делать. самба тоже, выход так себе. > > в результате, "чисто линуксовый" домен, на практике, невозможен. Вы упомянули на канале, что в RHEL исправили. Есть конкретная информация об этом? (Ответ для Gleb Kulikov на комментарий #0) > 1. при *ВКЛЮЧЕННОМ* sec=krb5, работа практически невозможна: запрос списка > файлов может отрабатывать крайне медленно, работа с отдельным файлом может > проходить крайне медленно. В то же время копирование отдельного файла > проходит на полной (нормальной) скорости, но *может* внезапно > приостанавливаться. > при *выключенном* sec=krb5, работа идёт на полной скорости, без замираний и > пауз. Падение производительности достигает 20x!!! При включенном sec=krb5, > невозможно пользоваться libreoffice на nfs шарах. > при трассировке и просмотре статистики выяснено: > nfsstat -rs > Server rpc stats: > calls badcalls badfmt badauth badclnt > 0 0 0 0 0 > в то же время, > Client rpc stats: > calls retrans authrefrsh > 700319 0 700319, > в трассировке постоянная проверка атрибутов и постоянные запросы к серверу > керберос, Когда керберос (использую ipa) не на том же сервере, что nfs > сервер, ситауция становится ещё хуже и падение производительности в пиках > достигает 40x. > В то же время, пользоваться несекьюрной nfs в не особенно доверенной сети, > безумие. что-то с этим надо делать. самба тоже, выход так себе. > > в результате, "чисто линуксовый" домен, на практике, невозможен. Вы упомянули на канале, что в RHEL исправили. Есть конкретная информация об этом? (Ответ для Gleb Kulikov на комментарий #0) > 1. при *ВКЛЮЧЕННОМ* sec=krb5, работа практически невозможна: запрос списка > файлов может отрабатывать крайне медленно, работа с отдельным файлом может > проходить крайне медленно. В то же время копирование отдельного файла > проходит на полной (нормальной) скорости, но *может* внезапно > приостанавливаться. > при *выключенном* sec=krb5, работа идёт на полной скорости, без замираний и > пауз. Падение производительности достигает 20x!!! При включенном sec=krb5, > невозможно пользоваться libreoffice на nfs шарах. > при трассировке и просмотре статистики выяснено: > nfsstat -rs > Server rpc stats: > calls badcalls badfmt badauth badclnt > 0 0 0 0 0 > в то же время, > Client rpc stats: > calls retrans authrefrsh > 700319 0 700319, > в трассировке постоянная проверка атрибутов и постоянные запросы к серверу > керберос, Когда керберос (использую ipa) не на том же сервере, что nfs > сервер, ситауция становится ещё хуже и падение производительности в пиках > достигает 40x. > В то же время, пользоваться несекьюрной nfs в не особенно доверенной сети, > безумие. что-то с этим надо делать. самба тоже, выход так себе. > > в результате, "чисто линуксовый" домен, на практике, невозможен. Вы упомянули на канале, что в RHEL исправили. Есть конкретная информация об этом? добрый день, извиняюсь за задержку: извещение упало в "спам". к сожалению, точные номера не знаю, только то, что гуглится. В ссылках флажок [solved], например, https://access.redhat.com/solutions/4077291 похоже, критическое падение производительности исправлено, как минимум, в связке 9.1 <-> Сизиф (9.1 <-> 9 планирую потестировать на днях). Проверялось на связке server virt (dist-upgraded) <-> сизиф. Конфигурация: 192.168.10.1 чистый сервер (установлен из образа, минимально необходимая настройка), на нём же nfs - сервер 192.168.10.2 free ipa. Сервер введён в домен ipa. Сделана запись echo 'SECURE_NFS=yes' >> /etc/sysconfig/nfs. Сделаны обычные действия по добавлению в ipa хостов и ключей. клиенты (Kworkstation 9, обновлённая до Сизифа и starter, аналогично) в той-же сети. экспорт на сервере: /mnt/T03-20150129/Archive/Photo 192.168.10.0/24(rw,no_subtree_check,sec=krb5:krb5i:krb5p,async) импорт на клиентах: athena77.athena.gtsk:/mnt/T03-20150129/Archive/Photo /Archive/PHOTO nfs rw,sec=krb5,soft,intr,timeo=4,vers=3,nofail,nodev,nosuid,noexec,noauto,asyn c,x-systemd.automount,x-systemd.device-timeout=3 проблем, пока, не видно, в том числе при интенсивной работе с большим числом относительно малых файлов (в прошлые заходы, таковая работа вешала систему начисто). ещё проверяю с vers=4, есть некоторые нехорошие ощущения см. также https://bugzilla.altlinux.org/show_bug.cgi?id=39728 |
