Спасибо за развернутые пояснения! Задавая вопрос, я тоже полагал, что вы используете, что-то вроде akka streams в java (реактивные стримы, обратное давление, гринтреды, дросселирование). Сам за эту тему активно топлю, но, к сожалению, реалии пока не позволяют использовать активно эти технологии. Для этого, во-первых, нужно, чтобы все взаимодействующие компоненты поддерживали реактивность, вот, вы говорите, что взяли и избавились от базы — мы пока не можем. Во-вторых, перейти на асинхронное stateless взаимодействие всех микросервисов и компонент тоже достаточно проблематично.
Но, вот, вы пишете:
тут просто нагружаем процессор, пока не выйдем на 95%
А какими средствами вы регулируете нагрузку именно в цифрах утилизации CPU? Понятно, что, скажем, в java/akka есть пулы гринтредов (ForkJoinPool), которые по-умолчанию создают столько физических потоков сколько ядер процессора и таким образом должны оптимально использовать имеющиеся вычислительные ресурсы, но как выйти именно на цифру, скажем, в 95% мне непонятно.
Вообще когда вы параллелите операции ввода-вывода, http запрос например, то получаете ускорение за счет того что процессор переключает своей выпонение на полезную нагрузку
Собственно, об этом я в статье и написал. А начальный пост был о том, что при 4 физических и 8 логических ядрах правильно ожидать прироста производительности кратного количеству физических ядер, то есть в 4 раза. То что он может быть больше и зависит от типа задач, само собой разумеется.
И снова нет. ∀ ε > 0: 100 + ε — да. А ровно 100 — нет.
Знать бы еще как обеспечить эти «чуть меньше 100%». Нагрузка обычно неравномерна, поэтому и нужен запас прочности, чтобы «чуть меньше 100%» сейчас не превратились в «чуть больше 100%» через некоторое время. Системы, которые вы разрабатываете, позволяют это обеспечить? Интересно, что это за системы? Какая у них функциональность?
Утилизация меньше 95% — для нас явный сигнал, что мы что-то делаем неправильно
То есть, если на серверах, где работает разрабатываемое вами ПО снять в динамике утилизацию процессора, она будет >95%?
Ни на опыт, ни на статистику вы не ссылались. Вы сказали, что они высосали из пальца нелепую цифру в 80%.
Собственно, спор возник вокруг моего утверждения, что на практике утилизация CPU не должна превышать 80% для обеспечения отказоустойчивости. И я привел пример где такая практика имеет место. Я не говорю, что невозможно построить систему, которая будет отлично работать при стабильной загрузке CPU >95%, но большинство систем, опять же, по моему опыту не такие.
Есть логика, которая «предполагает» и есть статистика, которая «располагает». Я полагал, что мы оба понимаем, что утилизация CPU = 100%, это значит, что «сервер встал» и мы спорим лишь о цифре запаса прочности. Если надо обосновать логически почему цифра в 100% загрузки CPU недопустима — пожалуйста. 100% загрузки CPU означает, что мы даем на процессор такую нагрузку, что он не справляется и задачи выстраиваются в очередь, которая постоянно растет. Иными словами, время выполнения каждой задачи (например, запроса пользователя, SQL-запроса в БД) критично увеличивается. И мой практический опыт подтверждает эту логику. Чтоб это доказать нужно сделать пример и провести нагрузочное тестирование. В переписке, как вы понимаете, это невозможно.
С каких пор «критерии тестирования в [название любой конторы]» — являются доказательной базой?!
Доказать эту конкретную цифру можно только статистикой. Я сослался на опыт (статистику) IT специалистов уважаемой компании. Как еще это можно доказать?
Этот комментарий относился к виртуальным ядрам, и в нем фигурировали цифры 50-60% (тоже нуждающиеся в аргументации, кстати). Каким боком его вообще можно сюда приплести?
Речь шла о том, что реального прироста производительности после некоторой цифры утилизации CPU на графике можно не ждать.
В Сбербанке при проведении нагрузочного тестирования одним из критериев его успешности была цифра в 80% утилизации CPU. Запас прочности в 20% кажется вполне обоснованным, особенно с учетом комментария edo1h
Но, вот, вы пишете:
А какими средствами вы регулируете нагрузку именно в цифрах утилизации CPU? Понятно, что, скажем, в java/akka есть пулы гринтредов (ForkJoinPool), которые по-умолчанию создают столько физических потоков сколько ядер процессора и таким образом должны оптимально использовать имеющиеся вычислительные ресурсы, но как выйти именно на цифру, скажем, в 95% мне непонятно.
Собственно, об этом я в статье и написал. А начальный пост был о том, что при 4 физических и 8 логических ядрах правильно ожидать прироста производительности кратного количеству физических ядер, то есть в 4 раза. То что он может быть больше и зависит от типа задач, само собой разумеется.
Знать бы еще как обеспечить эти «чуть меньше 100%». Нагрузка обычно неравномерна, поэтому и нужен запас прочности, чтобы «чуть меньше 100%» сейчас не превратились в «чуть больше 100%» через некоторое время. Системы, которые вы разрабатываете, позволяют это обеспечить? Интересно, что это за системы? Какая у них функциональность?
То есть, если на серверах, где работает разрабатываемое вами ПО снять в динамике утилизацию процессора, она будет >95%?
Собственно, спор возник вокруг моего утверждения, что на практике утилизация CPU не должна превышать 80% для обеспечения отказоустойчивости. И я привел пример где такая практика имеет место. Я не говорю, что невозможно построить систему, которая будет отлично работать при стабильной загрузке CPU >95%, но большинство систем, опять же, по моему опыту не такие.
Доказать эту конкретную цифру можно только статистикой. Я сослался на опыт (статистику) IT специалистов уважаемой компании. Как еще это можно доказать?
Речь шла о том, что реального прироста производительности после некоторой цифры утилизации CPU на графике можно не ждать.