Я создаю данные (файлы по 100 ГБ), которые в конечном итоге копируются на сервер через NFS v4.2 в сети 10 Гбит. Эти файлы хранятся на многих жестких дисках с форматированием XFS (одна копия на целевой диск).
Когда выполняются задачи копирования:
- На клиенте используется огромное количество памяти.(может быть больше 64 ГБ, занимает столько памяти, сколько может).
- Но на сервере оперативная память почти не используется.
Я хотел бы уменьшить использование памяти на клиентах, так как они постоянно производят данные, и это их замедляет. Напротив, сервер в основном не используется.
Я полагаю, поскольку HDD на сервере медленные, клиент буферизует столько данных, сколько может, чтобы сделать копию менее блокирующей. Я не могу изменить настройки оборудования.
Есть ли способ заставить сервер кэшировать больше данных? Я бы предпочел отдать приоритет использованию памяти сервера, а не клиентской памяти.
Конфигурация NFS:
10.0.3.1:/ /mnt/field nfs nfsvers=4.2,noatime,nodiratime,_netdev,noauto,x-systemd.automount,x-systemd.mount-timeout=10 0 0
/etc/exports:
/mnt 10.0.0.0/16(rw,async,fsid=0,no_subtree_check,crossmnt)
Конфигурация сетевой карты на сервере:
MTU 9000
rinbuffer tx 512, rx 1024
Конфигурация сетевой карты на клиенте:
MTU 9000
rinbuffer tx 1024, rx 512
Редактировать: Как и было запрошено, /proc/meminfo:
Клиент ------------------------------------------ Сервер -------------------------------
Мониторинг использования памяти на этом клиенте:
Использование сети:
Примечание: Клиент использует большой tmpfs (100 ГБ) для вычислений. Я думаю, что этот tmpfs никогда не вычитается из количества доступной памяти.
Редактировать2:
Корреляция между сетью и использованием памяти более очевидна на другом клиенте (мне следовало начать с этого). Этот клиент не использует tmpfs.
решение1
Я хотел бы сократить использование памяти на клиентах, поскольку они постоянно генерируют данные, и это замедляет их работу.
Откуда вы это знаете? Большая часть клиентской памяти находится в кэше страниц, что совершенно нормально, и даже улучшение буферизации на сервере не предотвратит агрессивное кэширование этих данных на стороне клиента.
Пробовали ли вы очистить кэш страниц (в качестве теста) и посмотреть, как работает ваше приложение без использования кэша страниц?
NFS обладает так называемой согласованностью «близко к открытию», то есть содержимое данных и метаданных действительно гарантированно стабильно только в том случае, если файл не открыт активно (то есть другой клиент может изменить файл на другой системе, и вы об этом не узнаете).
Из-за этого ограничения согласованности приложения клиентских систем NFS полагаются на кэш страниц, чтобы гарантировать доступность данных для обратного считывания в случае необходимости.
При этом, не зная, что происходит на вашем /etc/exportsсервере, единственным способом выгрузить больше данных на сервер может быть монтирование NFS на ваших клиентах с помощью syncопции монтирования и экспортирование путей на вашем сервере с помощью asyncопции монтирования.
Это обеспечит фиксацию записей на сервере на стороне клиента, в то время как сервер всегда будет отвечать «готово» перед фиксацией данных на диске.
Это повлияет на пропускную способность клиентов, поскольку вы вызовете задержку из-за проверки каждого запроса на стороне клиента, но сервер будет буферизировать гораздо больше данных, поскольку он не будет ждать, пока данные сначала попадут на диск. Вы также, вероятно, захотите покрутить и dirty_write_centisecsдругие биты на сервере, чтобы позволить ему буферизировать больше данных в обратную запись.
Но вот в чем загвоздка — это, скорее всего, приведет к замедлению клиентов и снижению целостности серверов в случае сбоя. Если сервер выйдет из строя, вы можете потерять данные.
Кроме того, это не повлияет на использование памяти для кэширования страниц на клиентах, над которым NFS не имеет реального контроля.
В целом я скептически отношусь к тому, что уменьшение использования памяти клиентами (если вы здесь измеряете кэш страниц) улучшит производительность ваших клиентов.
решение2
Нет, принудительное использование меньшего объема памяти, скорее всего, замедлит работу, а не ускорит. Вы и так тратите энергию на 188 ГБ быстрой DRAM, так что можете использовать ее.
Клиентский хост имеет 188 ГБ MemTotal и использует 162 ГБ для кэширования. На самом деле, это довольно низкое требование к памяти, обратите внимание на 123 ГБ MemAvailable, которые можно освободить очень быстро. Большая часть из 40 ГБ Shmem, вероятно, приходится на tmpfs.
Поскольку Cached + Shmem в сумме дают больше, чем MemTotal, я подозреваю, что tmpfs учитывается дважды, как разделяемая память и в кэшах. Также объяснил бы, как Cached минус Shmem приблизительно равно MemAvailable, tmpfs, не имеющие постоянного хранилища, не могут быть освобождены.
Серверная часть, 15 ГБ и изменение MemTotal, 13 ГБ в кэше. Много доступной памяти на этом хосте. Предположительно, большая часть того, что он делает, это обслуживает файлы, не так много других требований к памяти.
Без доказательств накладных расходов, таких какинтенсивная активность vmscanили если MemAvailable заканчивается, я не рекомендую предпринимать никаких действий.