У меня есть серверная система под управлением Ubuntu 12.10 с 12 подключенными дисками. Я использую все эти диски в своей 10-гигабитной сети с помощью NFSv4. Однако в целом у меня низкая производительность по NFS по сравнению с производительностью, которую я могу получить локально. Общее решение проблемы низкой производительности NFS, с которым я столкнулся в своем исследовании, - это использование опции async в файле экспорта сервера вместо синхронизации. Однако это просто не вариант для моих целей. Я понимаю, что это приведет к снижению производительности, но я не ожидал того, что вижу.
Я обнаружил, что чем больше дисков я активно использую в клиенте NFS, тем хуже моя пропускная способность на каждый диск. Например, если я активно использую только 1 диск, я могу писать со скоростью 60 МБ / с. Однако, если я активно использую все 12 дисков, я могу писать только со скоростью 12 МБ / с на диск. Эквивалентные локальные тесты могут без проблем дать 200 МБ / с на диск. Есть ли какие-нибудь настройки, которые можно сделать для оптимизации производительности NFS с несколькими дисками? Похоже, что ни ЦП, ни память не используются очень сильно, пока сервер активно используется.
Похоже, что в этом виновата синхронная запись, и, к сожалению, вы мало что можете с этим поделать, когда синхронная запись является требованием для системы.
Проблема возникает из-за того, что удаленная система, которая записывает данные, должна дождаться записи всего блока файловой системы, прежде чем записывать следующий. Как вы уже видели, при малых размерах блоков это может отрицательно сказаться на производительности.
У этой проблемы нет хорошего решения, но вот несколько возможных вариантов устранения узкого места:
Увеличьте размер блока, чтобы он мог записывать больше данных за одну операцию.
Получите отдельный быстрый SSD или устройство NVRAM для кэширования записи / ведения журнала. Это значительно повысит вашу пропускную способность для всех рабочих нагрузок. Это можно сделать с помощью ext4, используя tune2fs (8) в Ubuntu и добавление внешнего журнального устройства с -J параметр.
Разделите общий ресурс NFS на один, предназначенный для синхронизирующей записи, а другой - для асинхронной записи. Таким образом, вы можете поместить любые некритические данные в общий ресурс async, чтобы независимо повысить пропускную способность для этой рабочей нагрузки.
Попробуйте использовать другую файловую систему, которая позволяет выполнять стабильное кэширование записи изначально. я использую ZFS на FreeBSD на моем SAN с журналом намерений, поддерживаемым SSD (эквивалент журнала на ext4). Я никогда не пробовал ZFS в Linux но сейчас это кажется несколько зрелым проектом. Моя пропускная способность чтения и записи по iSCSI значительно улучшилась после добавления SSD. Я не уверен, что вы знакомы с ZFS, но если вы не знаете, цель ZIL (ZFS Intent Log) - предоставить кеш записи в быстром и стабильном хранилище, таком как SSD. Журнал будет периодически фиксироваться на диске в группах транзакций, чтобы гарантировать, что данные не будут потеряны, а в случае отключения электроэнергии записи могут быть воспроизведены из журнала для восстановления целостности файловой системы.
Я сталкивался с этой проблемой в прошлом и действительно не нашел хорошего способа полностью устранить проблему. Если вы обнаружите другие способы решения проблемы, дайте мне знать!