Необъяснимая загрузка GlusterFS и низкая производительность
Мы запускаем сервер репликации GlusterFS на 2 узлах и у нас 2 клиента. Демон самовосстановления включен. Каждый клиент подключается к другому серверу с помощью клиента Gluster. У нас есть много очень маленьких файлов на томе Gluster.
Мы используем GlusterFS 3.9.1 из официальных репозиториев APT GlusterFS в системе Debian Jessie.
Проблема, с которой мы сталкиваемся, заключается в том, что один из серверов является при средней нагрузке 0,1-0,5, а другой - при 200. Этот поток данных продолжается, даже когда клиенты не читают данные для записи.
Следующие значения измеряются nload и iftop :
сервер: исходящий 35- 40 МБ / с
Два клиента: входящие 17-20 МБ / с
Наша производительность на клиенте Gluster очень низкая. ls может занять до 10 секунд, а наше приложение работает очень медленно.
Серверы и клиенты подключаются через внутреннюю сеть центра обработки данных и могут обрабатывать гораздо большую пропускную способность, так что это не ограничивающий фактор.
Мои два основных вопроса:
1: Являются ли эти различия в нормальном поведении нагрузки сервера для GlusterFS и чем это вызвано?
2: Почему существует такая высокая константа поток данных к клиентам формирует один из серверов.
Кажется, я не могу найти никакой информации по этому поводу в документации Gluster или в Интернете.
> 1: Являются ли эти различия в загрузке сервера нормальным поведением для GlusterFS и чем это вызвано?
Посмотрите глубже на источник загрузки. Где находится узкое место? CPU/Disk-IO/... (инструменты, например, top, iotop)
Может быть, высокая нагрузка основана на io-wait.
Проверьте, достаточно ли свободной памяти, чтобы gluster мог использовать кэш.
> 2: Почему такой высокий постоянный поток данных к клиентам формирует один из серверов.
Проверьте, какая программа посылает какие данные на какой хост. nload и iftop дают вам представление о трафике для всего сетевого интерфейса. Поэтому попробуйте nethogs, которые дают вам трафик (dev, sent, received) по PID.
Запись от клиентов должна быть написана на текущем gluster-сервере. Текущий gluster-сервер должен послать файл другому gluster-серверу. Когда оба сервера записали файл, клиент получает подтверждение.
Может быть, эта процедура "удваивает" сетевой трафик на gluster-сервере?!? (см. утилиты сетевого мониторинга... какой процесс и куда идет трафик)
общая производительность касается:
Проверьте сетевую задержку и посмотрите запись в блоге Джо Джулиана. (поиск "Across highlatency connections")
ls в течение 10 секунд может быть "нормальным", если в каталоге очень много файлов. Это происходит потому, что каждый метаданный для каждого файла должен быть запрошен с gluster-сервера. Смотрите эту заметку, объясняющую производительность nfs против gluster-клиента, чтобы получить немного больше объяснений.
Может быть http:// blog.gluster.org/2016/10/gluster-уровень и малая производительность/интересна для вас. Для меня это немного помогает при работе с мелкими файлами.