ZFS: Проблемы памяти с dedup даже при том, что zdb - DD выглядит хорошо
bofh ALL=(root) NOPASSWD: /usr/bin/top
хорошо работает для меня, я могу sudo вершина только; возможно, у Вас есть другие правила sudo, который помогает Вам уничтожающий procs также?
если Вы говорите о праве уничтожить процесс с вершиной хорошо, это нормально; главное использование уничтожает () внутренне для завершения процесса, который требуют; после того как Вы выполняете вершину как корень, Вы также сделаете syscalls включенным как пользователь root
Отвечая на этот вопрос сейчас сам - очевидно, в 0.6.2.1 все еще много памяти накладные расходы на фрагментацию, часть которой, связанная с дедупликацией, будет улучшена в версии 0.6.3. Думаю, я собираюсь попробовать текущую версию разработчика или исправления, предложенные в проблеме, которую я открыл: https://github.com/zfsonlinux/zfs/issues/2083 . Посмотрим, как это пойдет.
Обновление: см. ниже - я решил использовать версию 0.6.2 без дедупликации. Я буду продолжать тестирование новых выпусков, пока не почувствую себя «в безопасности» с дедупликацией, поскольку считаю, что это может иметь смысл для моего приложения.
Всем спасибо!
Дедупинг в ZFS не всегда оправдан . Ладно, это редко того стоит ... Я знаю, что это привлекательно, красиво звучит и кажется отличным аргументом в пользу продажи ... но какой ценой?
- Предсказуемость.
- Стабильность.
- Использование ОЗУ.
- Планирование и проектирование.
- Производительность.
См. Также: ZFS - уничтожение дедуплицированного zvol или набора данных останавливает сервер. Как восстановить?
Итак, давайте проверим вашу таблицу ДДТ ...
Если вы не знаете, как выполнять вычисления, см .: Насколько велика моя таблица дедупликации ZFS на данный момент?
DDT-sha256-zap-duplicate: 615271 запись, размер 463 на диске, 149 в ядре
615271 * 149 = 91675379 -> 91675379/1024/1024 == 87,42 мегабайт.
Итак, хмм ... для набора данных не требуется много оперативной памяти.
Другие элементы на заметку. Вероятно, вам следует использовать сжатие lz4 , но это все, что я могу отсюда увидеть. Вы можете увидеть, является ли это взаимодействием между подсистемами виртуальной памяти Linux и ZFS? Я бы оставил ARC там, где он есть ... но проверяйте статистику Linux VM во время низких скоростей. Это может немного зависеть от того, какой тип данных вы храните. Какие это типы файлов?
Хорошее практическое правило - планировать около 5 ГБ ОЗУ на каждый 1 ТБ диска. Таким образом, если у вас есть 2 ТБ данных, это будет 10 ГБ только для дедупликации + метаданные ARC + ZFS. Это не тот ответ, который вам нужен, но он не стоит усилий. Вы все равно получите некоторую экономию при включенном сжатии. Взгляните на эту статью
5 ГБ - это общее правило, но оно не обязательно должно быть правдой. Мы предполагаем, что вам понадобится 5 ГБ ОЗУ на 1 ТБ, если вы используете блоки размером 64 КБ. Но размер блока может отличаться от 512b до 128K. Решением могут быть диски L2ARC и SSD, но это будет дорогое удовольствие.
Возможно, вы столкнулись с проблемой, связанной с реализацией. Для Linux существует проект ZFS в Linux , а также реализация zfs-fuse. Последний работает значительно медленнее, но вы должны попробовать свой сценарий с обоими из них, чтобы исключить проблемы с кодом конкретной версии. Кроме того, возможно, стоит протестировать выпуск Nexenta / OpenIndiana или даже установку ODN Solaris 11.1.
Имейте в виду, что интерактивная дедупликация ZFS имеет некоторые архитектурные проблемы, огромное потребление памяти и довольно высокую загрузку ЦП при записи в пул являясь основными. Возможно, стоит проверить, подходит ли автономная дедупликация, подобная той, что предлагается Windows Server 2012 для NTFS или BTRFS с исправлениями ошибки , вашей модели использования.