Автор: Наслаждайтесь обучением в классе Лао Гу
Публичный номер микроканала: наслаждайтесь онлайн-классом
Введение
"Нет, у онлайн-сервера серьезный тайм-аут, а запрос идет очень медленно. Кажется, количество зарегистрированных подключений слишком велико, что мне делать?" - отзываются друзья. Как правило, наш технический начальник справляется с этим, увеличивая количество соединений и пулов потоков, перезапуская и затем наблюдая.
Часто этот метод является экстренной мерой, а не лекарством от симптомов, потому что причина проблемы неизвестна.
Есть серьезное недоразумение, думая, что параметр пула потоков слишком мал, и запрос будет быстрее, если его увеличить.
Сегодня пообщаюсь с друзьями, как разумно задать размер пула потоков?
Во-вторых, проблема
Если нужно обработать две задачи, одну задачу А и одну задачу Б.
Вариант 1: поток выполняет задачи A и B, а после выполнения A выполняет B. Вариант 2. Два потока A и B одновременно выполняют задачи A и B.
Какой план будет быстрее? Многие люди должны ответить, что это должно быть второе решение, так как должно быть быстрее обрабатывать задачи A и B параллельно с несколькими потоками. Это правильно? Прежде чем ответить на этот вопрос, давайте немного поразмыслим над ним.
3. Выполнение потока
Выполнение потока запланировано ЦП. ЦП будет выполнять только один поток одновременно. Мы, кажется, выполняем поток A и поток B одновременно.
Для того, чтобы пользователь почувствовал, что эти задачи выполняются одновременно, операционная система использует метод ротации временных интервалов: центральный процессор обслуживает каждую задачу в течение определенного времени, а затем сохраняет состояние текущей задачи. загрузка состояния следующей задачи, продолжить Обслуживать следующую задачу. Состояние задачи сохраняется и перезагружается, этот процесс называется переключением контекста.
Процесс переключения контекста требует времени, теперь давайте рассмотрим вышеприведенную проблему и посмотрим, какое решение быстрее? Есть ли друзья, которые скажут первое решение, потому что нет необходимости в переключении потоков; второе решение требует переключения двух потоков туда и обратно, что займет больше времени.
Есть ли у вас сомнения в сердцах в это время, почему существует несколько нитей? Не волнуйся, посмотри вниз.
В-четвертых, почему многопоточность
Маленькие друзья, подумайте, в каком процессе мы находимся в нашем реальном бизнесе?
Процесс, показанный выше:
1. Сначала инициируйте сетевой запрос
2. Веб-сервер анализирует запрос
3. Запросить серверную базу данных для получения данных
4. Получив данные, обработайте их
5. Вернуть результат обработки пользователю
Это обычный процесс запроса, когда мы обрабатываем бизнес; давайте посмотрим, какая компьютерная обработка задействована во всем процессе.
1. Сетевой запрос -----> сетевой ввод-вывод
2. Разобрать запрос -----> ЦП
3. Запросить базу данных -----> Сетевой ввод-вывод
4. Данные запроса MySQL -----> Дисковый ввод-вывод
5. MySQL возвращает данные -----> сетевой ввод-вывод
6. Обработка данных -----> ЦП
7. Возврат данных пользователю -----> Сетевой ввод-вывод
Говоря об этом, вы, ребята, чувствуете, что это больше не грязно?В реальном бизнесе мы будем использовать не только вычисления на процессоре, но и обработку сетевого ввода-вывода и дискового ввода-вывода, что требует очень много времени. Если весь процесс потока представляет собой процесс, показанный на рисунке выше, только 2 узла реально задействованы в ЦП, а остальные узлы обрабатывают ввод-вывод, то когда поток выполняет обработку ввода-вывода, ЦП будет простаивать, а Загрузка процессора не будет высокой.
Друзья теперь знают о пользе многопоточности, да, она улучшает загрузку процессора.
5. Улучшить QPS/TPS
Измеряйте, как работает система, основные показатели системы (QPS/TPS)
QPS/TPS: количество запросов/транзакций, которые могут быть обработаны в секунду.
Параллелизм: количество запросов/транзакций, обрабатываемых системой одновременно.
Время отклика: среднее время, необходимое для обработки запроса/транзакции.
QPS/TPS = параллелизм/время ответа
Приведенная выше формула означает, что чем больше число параллелизма, тем больше число запросов в секунду; поэтому многие думают, что если увеличить пул потоков, число параллелизма будет больше, а число запросов в секунду также улучшится, поэтому оно появится в предисловие, что непонимание большинства людей.
На самом деле, QPS также обратно пропорционален времени отклика: чем больше время отклика, тем меньше будет QPS.
Хотя количество параллелизма увеличивается, количество запросов в секунду будет увеличено, но количество потоков также повлияет на время отклика, потому что мы также упоминали проблему переключения контекста выше, так как же установить количество потоков?
6. Как установить количество потоков
Итак, как мы распределяем потоки? Предлагаем формулу:
Оптимальное количество потоков = ((время ожидания потока + процессорное время потока) / процессорное время потока) * количество процессоров
Обратите внимание, что эта формула также используется пожилыми людьми.Конечно, я читал статью о практике оптимизации системы внешнего интерфейса Taobao ранее.Она очень похожа на приведенную выше формулу, но с точки зрения количества процессоров, они больше уточнены, и приведенная выше формула предназначена только для справки. Однако какой бы ни была формула, она окончательно оптимизируется и корректируется после запуска в производственной среде.
Продолжаем вышеописанную задачу, наш сервер имеет 4 процессорных ядра, задача потока cpu занимает 20 мс, а ожидание потока (сетевой ввод, дисковый ввод) занимает 80 мс, оптимальное количество потоков: ( 80 + 20 )/ 20 * 4 = 20 . То есть лучше всего установить количество потоков равным 20.
Из этой формулы мы можем сделать вывод, что чем больше время ожидания потока, тем большее количество потоков должно быть установлено, что точно соответствует нашему анализу выше и может улучшить загрузку ЦП. С другой точки зрения, количество устанавливаемых потоков зависит от нашего собственного бизнеса, нам нужно самим провести стресс-тест и установить разумное значение.
7. Основные общепринятые стандарты
Тогда наши маленькие друзья спросят, ведь многие бизнесы сосредоточены в одном пуле потоков, что не так просто, как в случае выше.На самом деле бизнесов слишком много.Как это настроить? Это чтобы перейти к стресс-тесту, чтобы приспособиться. Однако наши предшественники помогли нам обобщить базовое значение (в конце концов, оно зависит от операции и настраивается само по себе).
1. Интенсивная нагрузка на ЦП: для операций, связанных с обработкой памяти, общее количество потоков устанавливается следующим образом: количество ядер ЦП + 1 или количество ядер ЦП * 2. Если количество ядер равно 4, обычно устанавливается 5 или 8.
2. Интенсивный ввод-вывод: файловые операции, сетевые операции, операции с базой данных, общая настройка потока: ядра процессора / (1-0,9), если количество ядер равно 4, общая настройка равна 40.
8. Резюме
Сегодня я представил настройку количества потоков и некоторые недоразумения моих друзей. Говоря о том, что у наших друзей обновленное понимание потоков, не такое грубое, как раньше, мы должны проанализировать, почему это так медленно, где появляется узкое место системы, и уменьшить времязатратность узкого места.
Кроме того, я рекомендую своим друзьям взглянуть на Redis и Nginx, почему они такие быстрые? На самом деле, это имеет что-то общее с пунктами знаний этой статьи.
Популярный контент:
1,Опять системный сбой? Эти несколько стратегий настройки помогут вам решить большинство проблем!
2,Как развернуть Tomcat в производственной среде?
3.Признательность за комментарий к коду на уровне Бога, используйте его, если хотите!
6.Если вы не понимаете эти 12 синтаксических сахаров, не говорите, что знаете Java!
7.Кровавое дело о сверхурочной работе, вызванное небольшой проблемой пейджинга!