Glaber 3.1 тесты скорости работы

Основная задача тестов

Понять размер мониторинга по NVPS при типовой нагрузке, понять применимость и границы использования Glaber в практических ситуациях.

Тесты осознанно не сравнивают Glaber3.1 с другими версиями Glaber или Zabbix или другим ПО.

Условия теста:

Характеристики сервера: 32 Gb памяти, 1 процессор Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz.

Тестирование проводилось с шагами препроцессинга, целей тестирования «чистой» пропускной способности нужно убирать все шаги препроцессинга,в таком случае результаты будут количественно в 2-3 раза выше но будут нести меньше практической ценности.

На тестах работает конфигурация тестовой зоны со входящим потоком около 2-3 кNVPS, snmp, agent, trapper проверки.

Используется 150 кратное повторение данных в коде отправки данных в препроцессор:

glb_preproc_ipc.c:163

int preprocess_send_metric(const metric_t *metric) {
    int i;

    for (i = 0; i < 150; i++) {
        glb_state_items_set_poll_result(metric->itemid, metric->ts.sec, ITEM_STATE_NORMAL);
        glb_ipc_send(conf->preproc_ipc, metric->hostid % CONFIG_FORKS[GLB_PROCESS_TYPE_PREPROCESSOR], (void *)metric, IPC_LOCK_TRY_ONLY);
        glb_ipc_flush(conf->preproc_ipc);
    }
}

Настроено 16 потоков препроцессинга и 16 потоков процессинга:

StartGLBPreprocessors=16
StartDBSyncers=16

Результаты

Cистема работает стабильно с потоком метрик около 400кNVPS и ниже:

Примечание - после препроцессинга за счет зависимых метрик, метрик становится несколько больше, поэтому уровень входящих в препроцссинг и в процессинг метрик отличается, но пропорционален

В промежуток с момента старта и примерно до 02:00 система работала в «режиме стагнации» - очевидно, не хватало очередей/общей производительности, поэтому были периодические процессы переполнения и очищения очередей, со скачками и падениями производительности.

Далее, при падении входящего потока примерно до уровня 400к метрик в секунду, характер работы стал ровным, размеры очередей минимальны, иногда были всплески утилизации очередей:

Средняя загрузка процессора составляла чуть менее 60%, график idle:

Загруженность процессов:

Препроцессинг

Выбивается один поток (на него приходит много обработки: текстовой netflow c одного из коллекторов). В пике один поток на тестах обрабатывал до 100-150к метрик в секунду.

У большинства метрик предобрабтка есть, тривиальная, числовая, но есть немного (около 10 - 15% метрик) с относительно "дорогими" строковыми манипуляциями.

В целом, для рабочего режима стоит рассчитывать на загрузку в 50-70 kNVPS на один поток препроцессинга.

Процессинг

Ситуация очень похожая, но в реальных системах нагрузка будет в разы больше, так как в данном случае непропорционально мало триггеров относительно транзита метрик.

Судя по результатам, стоит рассчитывать один синкер на 25-35к NVPS.

Загрузка Clickhouse

Работает на той-же машине, что и сервер мониторинга, в среднем около 50-100% по CPU, имеет некоторый «пиковый» характер.

Блокировки и системные вызовы:

Статистика снималась командой

timeout 30 strace -w -c -p <PID>

Препроцессинг

Статистика максимально нагруженного поток около 50-70к NVPS):

Процессинг (максимально нагруженный поток около 50-70к NVPS):

Основной момент – время ожидания блокировок (futex) в обоих случаях составляет примерно 2 – 2,5 секунды, то есть, до 10% времени.

При изменениях нагрузки или изменении количества процессов ощутимо время блокировок не меняется. Есть все основания полагать, что с текущим дизайном IPC вполне можно выйти на 1M NVPS.

Возможно, для этого потребуется еще некоторый тюнинг, например пре-аллокация буферов и разделение SHMEM областей для препроцессинга и процессинга. Но в текущих реалиях более чем достаточно.

Вывод

Учитывая, что тест не включал в себя затраты на получение метрик из сети, то стоит уменьшить цифры на 20-30% на загрузку процессора получения данных.

Системы «все в одном», вполне возможно эксплуатировать с Glaber3.1 без тюнинга на входящих нагрузках до 250к NVPS с хорошим запасом на типовых однопроцессорных серверах.

Glaber будет масштабироваться линейно при увеличении количества ядер процессоров.

После 450к NVPS следует увеличивать размеры очередей/IPC памяти:

Скейлинг по ядрам происходит линейно, есть возможность использовать до 100% процессорной емкости.

При достижении 500-700к NVPS стоит применить некоторые программные оптимизации IPC для уменьшения доменов блокировок.