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