В нашей устаревшей производственной системе есть сервер данных и вычислительный клиент, которые взаимодействуют через NFSv4; оба работают на виртуализации VMWare.
Мы определили, что по мере работы программного обеспечения вычислительного клиента в течение нескольких дней количество блокировок DELEG (измеряемое с помощью lslocks | wc) на сервере данных со временем увеличивается.
Количество блокировок DELEG READ может временно возрасти до 100 000; в долгосрочной перспективе количество блокировок DELEG увеличивается. Блокировок DELEG WRITE практически нет. Когда количество блокировок DELEG на сервере данных достигает примерно 15 000, вычислительный клиент становится почти не реагирующим; большинство процессов находятся в состоянии «D». Загрузить средн. остается умеренным, но загрузка ЦП падает примерно с 90% до 10% или меньше.
Удаление заданий на вычислительном клиенте не уменьшает счетчик блокировок даже через несколько минут. Завершение работы или перезагрузка из командной строки обычно зависает; размонтирование файловых систем NFS и / tmp может завершиться ошибкой.
Аппаратный сброс часто приводит к невозможности монтирования монтирования NFS при перезагрузке; но количество блокировок на сервере данных резко упадет. Жесткое отключение питания и двухминутное ожидание позволят восстановить виртуальную машину, включая все монтирования NFS.
На сервере данных работает SLES 12 (4.1.16-2.g1a0d915-default); он имеет 12 виртуальных ЦП и 128 ГБ ОЗУ и интенсивно использует сочетание SAN с поддержкой SSD и HD. Версия сервера данных nfs-kernel-server: 1.3.0-9.1. Сервер данных вычисляет около 100 тыс. Файлов данных каждый день. Некоторые из этих файлов перезаписываются и переименовываются самим сервером, но таким образом, что должен быть доступен либо основной файл, либо временная копия основного файла. Клиентский код знает об этом и при необходимости выполняет отказ.
Вычислительный клиент работает под управлением Debian Stable Stretch (4.9.0-6-amd64). Он имеет 24 виртуальных ЦП и 128 ГБ оперативной памяти. Версия клиента nfs-common: 1:1.3.4-2.1. Через NFS считывает эти файлы данных, как активный набор из 100 тыс. Файлов, генерируемых ежедневно, так и исторически создаваемые файлы. Один файл может быть прочитан несколькими процессами одновременно. Доступ к большинству файлов осуществляется небольшими сценариями bash, которые обращаются к 1 или 2 файлам за раз и изменяют данные для последующего использования. Эти скрипты вызываются программами на Python и Perl с временем жизни порядка часов.
На сервере данных есть экспорт, например:
/mnt/ssd 172.26.188.199(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
В вычислительном клиенте есть такие записи fstab:
172.26.188.198:/mnt/ssd /mnt/ssd nfs defaults 3 3
Вычислительный клиент имеет более прямую архитектуру, чем сервер данных. На более раннем экземпляре виртуальной машины с SLES возникли аналогичные проблемы; это потребовало полного пересмотра ОС и вычислительных задач. Это помогло уменьшить, но не устранить проблему.
Следующим очевидным шагом является перенос существующего сервера данных на новую ОС, но это тяжелый подъем с неопределенной отдачей. Поскольку поведение охватывает два разных вычислительных клиентских компьютера с разными версиями Linux и разным программным обеспечением, мы подозреваем, что проблема должна быть в одной из следующих: серверная ОС или версия NFS, высокочастотный перекрывающийся шаблон доступа клиента, шаблон перезаписи файла сервер данных (возможно, если бы сервер данных был полностью отделен от сервера NFS, внутреннее состояние nfsd было бы исправлено), возможную ошибку в NFS или ошибку в том, как мы ее настроили. Я также не хочу отклонять возможные проблемы в нашей сети Ethernet или SAN, но считаю их маловероятными в настоящее время.
Какие краткосрочные исправления могут помочь снизить количество блокировок DELEG на нашем сервере данных, помимо капитального ремонта сервера или перехода на распределенную файловую систему или или установки регулярного интервала перезагрузки?
Чтобы решить эту проблему, мы попытались изменить файловые серверы (все еще NFSv4), оборудование и версии ядра (теперь linux 4.2.8 на NAS с 4.1.16 на x86 / VMWare / SLES). Несмотря на эти изменения, накопление блокировок NFS4 DELEG по-прежнему происходило - по-видимому, это проблема, коренящаяся в программной структуре, которая работала с чисто локальным (прямым) хранилищем. В конечном итоге мы отказались от NFSv4 и теперь используем NFSv3 с нолок вариант; мы также используем noatime, nodiratime, noacl по соображениям производительности. Блокировки больше не накапливаются, что приводит к катастрофическому замедлению, наблюдаемому ранее.