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

Какие должны быть правильные dist_threads в сильно загруженном SphinxSearch

У нас есть экземпляр сфинкса с тяжелой нагрузкой. Индекс выполняется в реальном времени, но мы массово вставляем данные только раз в неделю или около того.

Он работает на выделенном 12-ядерном / 24-поточном сервере.
На сервере установлен только сфинкс.

Вот фрагмент файла conf:

index data_all
{
        type                    = distributed

        local                   = data_0
        local                   = data_1
        local                   = data_2
        local                   = data_3
}

searchd
{
        listen                  = 9305:mysql41
        listen                  = 9405
        log                     = /usr/local/sphinx/var/log/searchd.log
        query_log               = /usr/local/sphinx/var/log/query.log
        read_timeout            = 5
        max_children            = 2000
        pid_file                = /usr/local/sphinx/var/log/searchd.pid
        seamless_rotate         = 1
        preopen_indexes         = 1
        unlink_old              = 1
        workers                 = threads
        dist_threads            = 4
        binlog_path             =
}

Каждый локальный индекс составляет около 17 ГБ.

В большинстве случаев средняя загрузка сервера составляет менее 2–3, но иногда средняя загрузка машины достигает 50 или около того.

В настоящее время у нас очень хорошее время отклика, даже во время этих всплесков.

Мне интересно о dist_threads. Мне нужно оставить его 4 (как количество локальных индексов) или мне нужно выбрать 24 (количество потоков ЦП). Или я должен выбрать 1, потому что у нас все равно много запросов параллельно.

Краткий ответ - настройка должна быть равна количеству локальных индексов.

длинный коллектор - это зависит:

В случае рабочей нагрузки, связанной с ЦП, рекомендуется установить dist_threads равным 1x количество ядер (создание большего количества потоков, чем ядер, не улучшит время запроса). В случае смешанной рабочей нагрузки, связанной с ЦП / диском, иногда может иметь смысл использовать больше (чтобы можно было использовать все ядра, даже если есть потоки, ожидающие завершения ввода-вывода).