Задержка в небольшой системе клиент / сервер Linux NFS4
Мы - факультет информатики в небольшом университете, на котором запущен сервер RHEL 7 с использованием клиентов NFS4 и Fedora 24 (~ 40 клиентских машин, ~ 150 пользователей - редко одновременно). У нас проблемы с задержкой, и у нас есть проблемы с устранением неполадок / мы пытаемся выяснить, в чем проблема. Примеры симптомов:
- Emacs запускается / готов к использованию примерно через 2 минуты. Графический интерфейс появляется быстро, но затем приложение зависает, если вы пытались открыть файл при запуске. Если вы просто попытаетесь открыть
emacsи , а затем попытаетесь открыть файл, приложение зависнет на две минуты. Примерно через две минуты вы можете без проблем создавать файлы, читать файлы и т. Д. РЕДАКТИРОВАТЬ: запускemacsв локальном файле (например, /tmp/test.out) не вызывает проблемы с задержкой. Кроме того, открытие сетевых файлов с помощьюidle3илиgeditне вызывает проблем. - Проверка проекта с помощью svn + ssh в командной строке выполняется очень медленно с одного из клиентов Linux. / настольные машины - порядка 3 минут. Если вы проверяете проект, используя svn + ssh с другой машины, проверка занимает 3 секунд .
- Невозможно настроить режим ожидания. При нажатии на меню настройки приложение зависает. ОБНОВЛЕНО: Похоже, это ошибка в idle3, которая не была исправлена в Fedora 24, но мы смогли применить исправление.
- Когда вы нажимаете «открыть / просмотреть» в приложении (например, emacs, Eclipse) или откройте файловый менеджер, приложение какое-то время зависнет, пока извлекает файлы. Использование ls и cd из командной строки выполняется быстро.
После долгих задержек вы можете без проблем читать / редактировать / создавать файлы.
Единственное сходство, которое я обнаружил с этими приложениями, заключается в том, что они используют скрытые файлы конфигурации ( .emacs.d , .idle , .eclipse , ...). Кажется, я не могу найти никакой документации, в которой скрытые файлы обрабатывались бы по-другому.
Любые советы приветствуются!
Какие варианты монтирования вы используете для своей nfs?
Удаление таких параметров, как lookupcache = none (и разрешить вместо этого значение по умолчанию), позволит клиентам кэшировать намного более агрессивно, мы заметили, что это может сбить с толку пользователей, когда файл в их домашний каталог добавляется, и это занимает час. до того, как он будет виден на удаленной машине, но для двоичных файлов все оказалось нормально.
Мы также установили actimeo = 60 и noactime для монтирования наших приложений.
Home папки:
rw, noatime, nfsvers = 4, minorversion = 1, soft, tcp, sec = sys, lookupcache = none, небрежные
приложения / двоичные файлы:
rw, noatime, nfsvers = 4, minorversion = 1, soft, tcp, sec = sys, actimeo = 60, sloppy
см. Также раздел DATA AND METADATA COHERENCE на странице руководства https://linux.die.net/man/5/nfs
How I would troubleshoot this:
- if ~/.emacs.d/ is provided by a NFS mount, and
- the target file is a NFS mount provided by a second NFS server, and
- copying all of that local to the client removes the delay,
I'd then move one of them at a time back to NFS and try to recreate the problem.
On re-reading your original post, I realize I assumed you have two or more NFS servers, because that's what I've seen at previous employers. One NFS server provided home directories and a second provided binaries. We found running the binaries locally on the client improved performance. :-)
If you have one NFS server, are you able to set up a second one for troubleshooting? Perhaps the single NFS server is overwhelmed at certain times; working with a second NFS server might help isolate this case.
If the problem shows up on only one or two clients, I'd try to find what makes those clients unique. If the problem shows up on every client, I'd look at the NFS server.
Looking at the logs on the RHEL7 NFS server will help in any case.
A Google search for "NFS Troubleshooting" provided many useful pages, including tldp. There's also Red Hat's nfs server config. You have probably looked at both of those already.
You said the NFS server is Red Hat EL 7. If I had a support contract with my copy of RHEL, I would open a ticket with Red Hat and ask them to help troubleshoot, too.
I hope this helps. Good luck.