Назад | Перейти на главную страницу

Проблема производительности с сетевым хранилищем QNAP TS-410

У нас в офисе есть QNAP TS-410. Его оборудование:

Мы думали, что будет достаточно сделать резервные копии для наших серверов, но мы столкнулись с несколькими проблемами:

  1. На изготовление ежедневной rsync между двумя каталогами по 100 ГБ. Дерево каталогов большое и сложное, потому что это наш производственный сервер с 200 веб-сайтами. Но изменения должны быть незначительными. И пропускная способность сети, конечно, не проблема (мы проводили тесты с регулярной загрузкой / скачиванием файлов).
  2. После выполнения rsync и передачи всех изменений на ротацию этих резервных копий уходит более 15 часов. Мы используем cp -al подход к созданию жестких ссылок вместо копирования.
  3. Встроенная программа vs_refresh на выполнение поставленной задачи уходит почти целый день.

Мы думаем, что каждая проблема напрямую связана со сложностью и размером дерева каталогов. Представьте себе двести веб-сайтов, каждый из которых является Joomla, WordPress, Moodle и т. Д.

Мы думаем, что это относительно нормально для rsync и cp занять определенное количество времени. Но столько времени? Это ожидаемое и нормальное поведение?

Если да, то что можно сделать для повышения производительности NAS? Может быть, увеличить оперативную память, чтобы избежать замены подкачки?

Спасибо!

На форуме QNAP сообщалось о проблемах с производительностью ввода-вывода, когда пропускная способность ввода-вывода снижается при определенных условиях (свободное место на диске и свободная оперативная память). Соответствующий выпуск посвящен ядру linux 2.6.33.2. Это ядро ​​используется во всех NAS от QNAP. В случае вышеупомянутого io perf. проблема попадает в эту категорию, то обходной путь (который, как сообщается, работает) состоит в том, чтобы получить больше свободного дискового пространства (80% +), а также 180 МБ свободной доступной ОЗУ.

подробная ветка http://forum.qnap.com/viewtopic.php?f=25&t=51741

Было бы неплохо узнать, совпадает ли ваша проблема с тем, что основная причина сообщенной проблемы с ядром не полностью понята - поэтому на форуме qnap есть много других потоков, которые сообщают о подобном поведении. но с сегодняшнего дня нет ни хорошего понимания, ни патча. более новые ядра больше не имеют этой проблемы.