мы запускаем кучу gitlabs на кластере k8s. Для постоянства мы используем монтирование NFS, в частности, у нас есть один экспорт NFS, который используется всеми gitlabs. В настоящее время он смонтирован на всех узлах кластера, а затем монтируется с привязкой к модулям, но мы также попробовали один том NFS, а затем смонтировали подпути. Проблема, которая у нас есть, не меняется.
Мы видим, что происходит следующее: время от времени (без заметного шаблона) некоторые из gitlab начинают зависать (в основном это те, которые работают на одном конкретном узле). Эти gitlab не могут быть запущены на другом узле, пока узел, на котором они изначально начали зависать, не будет перезагружен.
Затем этот проблемный узел начинает показывать очень высокую нагрузку и тонну запросов RPC nfs, в основном для двух методов: «OpenNoattr» и «TestStateId». Общее количество запросов RPC от этого узла увеличивается примерно в 20 раз и никогда не прекращается, пока компьютер не будет перезагружен.
В качестве вариантов монтирования мы попробовали некоторые настройки, но это не оказало видимого влияния на проблему, в настоящее время мы используем
rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,local_lock=none
nfsstat читает:
Server rpc stats:
calls badcalls badclnt badauth xdrcall
166383963 19392 0 19392 0
Server nfs v4:
null compound
12 0% 166383895 99%
Похоже, что по какой-то причине мы получаем устаревшие блокировки, срок действия которых не истекает, пока машина не будет перезагружена. Как это могло случиться? Это все внутри кластера VMWare ... так что "плохой переключатель" маловероятен.
Кроме того, я не мог понять значение «badauth» и двух методов RPC. Может кто меня просветить?
---- РЕДАКТИРОВАТЬ: некоторые подробности -----
uname -a
Linux [all machines] 3.10.0-957.27.2.el7.x86_64 #1 SMP Mon Jul 29 17:46:05 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
rpm -qa |grep nfs-utils
nfs-utils-1.3.0-0.61.el7.x86_64
с тех пор мы пришли к выводу, что это, скорее всего, связано с postgresql внутри контейнера, и это было упомянуто в рекомендации от gitlab, которая рекомендовала делать
sysctl -w fs.leases-enable=0
на стороне сервера в качестве временного решения. мы сделали это.