Веб-сервер имеет конфигурацию, количество рабочих потоков.
Сервис вообще тоже имеет конфигурацию, количество рабочих потоков.
Опытные архитекторы знают, как настроить эти параметры для оптимизации производительности системы: для некоторых служб установлено 2-кратное количество ядер ЦП, для некоторых служб установлено 8-кратное число ядер ЦП, а для некоторых служб установлено 2-кратное число ядер ЦП. ядер процессора 32 раза.
Основой для установки «количества потоков» является вопрос, который будет обсуждаться в этой статье.
Установлено ли максимально возможное количество рабочих потоков?
Очевидно, что нет:
-
ЦП сервераОграниченное количество ядер, количество потоков, которые могут быть параллельными, ограничено, бессмысленно ставить 1000 рабочих потоков на одноядерном ЦП
-
Переключение потоков имеет накладные расходы, если переключение потоков будет слишком частым, это снизит производительность
При вызове функции sleep() поток продолжает занимать ЦП?
Если он не занят, ЦП будет освобожден во время сна и использован другими потоками, которым требуются ресурсы ЦП.
Не только сон, но и некоторые блокирующие вызовы, например в сетевом программировании:
-
Блокировать accept(), ожидая подключения клиента
-
Заблокируйте recv() и дождитесь нисходящего пакета
Отдаст ресурсов ЦП.
Одноядерный процессор, имеет ли смысл настроить многопоточь?
одноядерный процессор,Настроить многопоточностьМожет ли это улучшить производительность параллелизма?
Даже при наличии одного ядра имеет смысл использовать многопоточность, которая в большинстве случаев улучшает параллелизм:
-
Многопоточное кодирование может сделать код более понятным, например: потоки ввода-вывода отправляют и получают пакеты, рабочие потоки выполняют обработку задач, а потоки тайм-аута выполняют обнаружение тайм-аута.
-
Если есть задача, которая занимает ресурсы ЦП для вычислений, добавление потоков в это время не может увеличить параллелизм.Например, следующий код всегда будет занимать ЦП и доведет уровень загрузки ЦП до 100%:
while(1){ i++; }
-
Вообще говоря, рабочие потоки обычно не занимают ЦП для вычислений все время.В это время, даже если ЦП является одним ядром,Добавление рабочих потоков также может улучшить параллелизм., потому что, когда этот поток отдыхает, другие потоки могут продолжать работать
Каковы общие модели обслуживания потоков?
Понимание общих моделей сервисных потоков помогает понять принцип параллелизма сервисов.Вообще говоря, в Интернете есть две общие модели сервисных потоков:
-
Потоки ввода-вывода и рабочие потоки разделены очередями задач.
-
чистый асинхронный
Во-первых, потоки ввода-вывода и рабочие потоки разделяют модель класса с помощью очередей.
Как показано на рисунке выше, большинство фреймворков веб-серверов и сервисов используют такую модель многопоточности «поток ввода-вывода и рабочий поток, разделенный через очередь»:
-
Есть несколько потоков ввода-вывода, прослушивающих запросы от восходящего потока и отправляющих и принимающих пакеты (производитель).
-
Есть одна или несколько очередей задач, которые используются как каналы передачи данных (критические ресурсы) для асинхронной развязки IO-потоков и Worker-потоков.
-
Есть действительно несколько рабочие потоки для выполнения обычных задач (потребители)
Эта многопоточная модель широко используется и подходит для большинства сценариев.Характеристикой этой потоковой модели является то, что рабочие потоки синхронно блокируются для выполнения задач, поэтому возможность параллелизма может быть увеличена за счет увеличения числа рабочих потоков. обсуждение: «эта модель, сколько рабочих потоков можно установить для достижения максимального параллелизма».
Вторая, чисто асинхронная модель многопоточности.
Без блокировки эта модель потоков требует только установки небольшого количества потоков для достижения высокой пропускной способности.Недостатки этой модели:
-
Трудно использовать преимущества нескольких процессоров и нескольких ядер, если используется однопоточный режим.
-
Программистам привычнее писать синхронный код, способ обратного вызова влияет на читабельность кода, да и требования к программистам выше.
-
Структура более сложна и часто требует поддержки компонентов приемопередатчиков для боковых серверов, очередей сторон серверов, компонентов приемопередатчиков на стороне клиента, клиентские очереди, компонентов управления контекстами, компонентов конечных состояний и компонентов управления тайм-аутами
однако эта модель не является предметом сегодняшнего обсуждения.
Первый тип модели потоков — «поток ввода-вывода и рабочий поток отделены друг от друга через очередь». Каков режим работы рабочего потока?
Понимание режима работы рабочих потоков очень полезно для количественного анализа настройки количества потоков:
На рисунке выше показан типичный процесс обработки рабочего потока.От начала обработки до конца обработки задача состоит из 7 шагов:
(1) Извлеките задачи из рабочей очереди и выполните некоторые локальные инициализационные вычисления, такие как анализ протокола http, анализ параметров, проверка параметров и т. д.;
(2) Получите доступ к кешу, чтобы получить некоторые данные;
(3) После получения данных в кеше выполнить некоторые локальные вычисления, связанные с бизнес-логикой;
(4) вызвать нижестоящую службу через RPC и получить некоторые данные или позволить нижестоящей службе выполнить некоторые соответствующие задачи;
(5) После завершения вызова RPC выполните некоторые локальные вычисления.Как вычислять, связано с бизнес-логикой;
(6) Доступ к БД для некоторых операций с данными;
(7) После работы с базой данных выполните некоторые завершающие работы, и эти завершающие работы также являются локальными вычислениями, связанными с бизнес-логикой;
Анализ временной шкалы всей обработки показывает:
-
Среди них на шагах 1, 3, 5 и 7 (розовая временная шкала на рисунке выше), когда поток выполняет вычисления локальной бизнес-логики.Требуется ЦП
-
И 2,4,6 шага (рисунок над оранжевой осью), доступ к кэше, сервисному обслуживанию, дБ во время потока в состоянии ожидания результатов,Нет процессора, дальнейшая декомпозиция, это время "ожидания результата" делится на три части:
2.1) Запрос передается по сети в нижестоящий кэш, сервис, БД
2.2) Нисходящий кеш, сервис, БД для обработки задач
2.3) кеш, сервис, БД загружают сообщение обратно в рабочий поток в сети
Как количественно оценить анализ и разумно установить количество рабочих потоков?
Благодаря вышеуказанному анализу рабочая нить выполняется:
-
Есть время вычислений, которое должно занимать ЦП
-
Другая часть времени ожидания не должна занимать ЦП.
С помощью количественного анализа, такого как статистика регистрации, можно рассчитать долю двух частей времени при выполнении всего потока Worker, например:
-
Выполните расчет, время процессора (розовая временная шкала) составляет 100 мс.
-
Время ожидания, время, которое не занимает ЦП (оранжевая временная шкала) тоже 100мс
В результате получается, что этот поток вычисляет и время ожидания составляет 1:1, то есть 50% времени вычисляется (занято ЦП), 50% времени (не занимая ЦП):
-
Предполагая, что в настоящее время это одно ядро, установка для него 2 рабочих потоков может полностью использовать ЦП и позволить ЦП работать на 100%.
-
Предполагая, что в это время имеется N ядер, установка 2N рабочих мест может полностью использовать ЦП и позволить ЦП работать до N * 100%
Данг Данг Данг! ! !
Вывод здесь:
N основной сервер, посредством однопоточного анализа исполнительного бизнесаЛокальное время вычислениядля х,время ожиданияу, тогдаколичество рабочих потоков(Число потоков пула потоков) устанавливается равным N*(x+y)/x для максимального использования ЦП.
Вообще говоря, для сервисов, не интенсивно использующих ЦП (шифрование и дешифрование, сжатие и декомпрессия, поиск и сортировка и т. д. — это сервисы, интенсивно использующие ЦП), узким местом является доступ к серверной базе данных или вызов RPC, а также локальные вычисления ЦП. времени очень мало, поэтому установка десятков или сотен рабочих потоков может повысить пропускную способность.
ПОЛУЧИТЕ новые навыки?
мыслительные вопросы:
Какое количество потоков в вашей компании?
Голос за кадром: Случайным образом установить 200?