При сравнительном тестировании GlusterFS & NFS на AWS использование озона и dd дает различные результаты
Изучите добавление некоторых пределов количества процесса в Ваш limits.conf файл, обычно располагаемый в /etc/security/limits.conf.
Следующий отрывок ограничит членов users группа к 200 процессам:
@users hard nproc 200
Это не позволит Вам ограничить пользователей определенным числом какого-то конкретного приложения, но оно будет иметь большое значение для защиты остальной части машины от нескольких злонамеренных пользователей.
Вы могли бы также хотеть рассмотреть использование пределов адресного пространства вместо строгих пределов количества процесса.
Следующее наложит жесткое ограничение 512000 КБ (500 МБ):
@users hard as 512000
Как и во всех тестах, сложно сравнивать яблоки с яблоками. Похоже, что iozone перегружает систему и не моделирует конкретную нагрузку. dd просто измеряет пропускную способность.
Я наткнулся на filebench . С помощью filebench вы можете моделировать определенные типы нагрузки, он называет эти различные тесты «личностями». Это дало мне гораздо более реалистичные цифры. Я смоделировал веб-сервер, который обычно доступен только для чтения. Хотя filebench добавляет журнал к моделированию, в данном случае я удалил его. Я получил следующие результаты:
Результаты в МБ / с
using: sudo filebench (webserver personality without simulation of log append)
Direct to EBS GlusterFS NFS GlusterFS + NFS
24.2 6.0 17.0 20.4
Примечание: filebench был ограничением в тесте EBS, поскольку во время теста он загружал 100% ЦП. Я предполагаю, что результат EBS будет выше.
Примечание 2: GlusterFS сама по себе имела очень высокую задержку, когда я включил тест для добавления журнала. Это можно объяснить в этой публикации . Я не исследовал эту проблему с высокой задержкой, поскольку мы ожидаем в основном чтения.
filebench был ограничением в тесте EBS, так как во время теста он загружал 100% ЦП. Я предполагаю, что результат EBS будет выше.
Примечание 2: GlusterFS сама по себе имела очень высокую задержку, когда я включил тест для добавления журнала. Это можно объяснить в этой публикации . Я не исследовал эту проблему с высокой задержкой, поскольку мы ожидаем в основном чтения.
filebench был ограничением в тесте EBS, поскольку во время теста он загружал 100% ЦП. Я предполагаю, что результат EBS будет выше.
Примечание 2: GlusterFS сама по себе имела очень высокую задержку, когда я включил тест для добавления журнала. Это можно объяснить в этой публикации . Я не исследовал эту проблему с высокой задержкой, поскольку мы ожидаем в основном чтения.