Оптимальные пороги загрузки процессора - PullRequest
4 голосов
/ 20 февраля 2010

Я создал программное обеспечение, которое развернуло на сервере Windows 2003. Программное обеспечение работает как служба непрерывно, и это единственное важное приложение для Windows. Часть времени он извлекает данные из Интернета, а часть времени выполняет некоторые вычисления для этих данных. Он многопоточный - я использую пулы примерно из 4-20 потоков.

Я не буду утомлять вас всеми этими деталями, но достаточно сказать, что по мере того, как я включаю больше потоков в пуле, происходит больше параллельной работы и увеличивается загрузка ЦП. (как и спрос на другие ресурсы, такие как пропускная способность, хотя это меня не касается - у меня есть много)

Мой вопрос таков: должен ли я просто максимально использовать процессор, чтобы получить максимальную отдачу от затраченных средств? Интуитивно, я не думаю, что имеет смысл работать на 100% CPU; даже 95% ЦП кажется высоким, почти как будто я не даю ОС много места, чтобы делать то, что ей нужно. Я не знаю правильный способ определить лучший баланс. Я предполагаю, что смогу измерить и измерить и, вероятно, обнаружу, что наилучшая пропускная способность достигается при средней загрузке процессора 90% или 91% и т. Д., Но ...

Мне просто интересно, есть ли хорошее эмпирическое правило об этом ??? Я не хочу предполагать, что мое тестирование будет учитывать все виды изменений рабочих нагрузок. Я предпочел бы играть немного безопаснее, но не слишком безопасно (иначе я не использую свое оборудование).

Что вы рекомендуете? Что такое интеллектуальное правило использования, ориентированное на производительность, для многопоточного приложения со смешанной нагрузкой (некоторые операции ввода-вывода, некоторые CPU) в Windows?

Ответы [ 5 ]

4 голосов
/ 24 февраля 2010

Да, я бы предположил, что 100% бьется, поэтому не хотел бы видеть, что процессы работают так постоянно. Я всегда стремился к 80%, чтобы получить баланс между использованием и местом для всплесков / специальных процессов.

Подход, который я использовал в прошлом, заключается в том, чтобы медленно увеличивать размер пула и измерять влияние (как на CPU, так и на другие ограничения, такие как IO), вы никогда не знаете, вы можете обнаружить, что IO внезапно становится узким местом .

4 голосов
/ 20 февраля 2010

Загрузка ЦП не должна иметь значения в этой интенсивной рабочей нагрузке ввода-вывода, вы заботитесь о пропускной способности, поэтому попробуйте использовать подход к альпинизму и, в основном, попробуйте программно внедрить / удалить рабочие потоки и отслеживать ход выполнения. .

Если вы добавляете тему, и она помогает, добавьте еще одну. Если вы попробуете ветку, и это повредит, удалите ее.

Со временем это стабилизируется.

Если это приложение на основе .NET, в пул потоков .NET 4 было добавлено восхождение на холм.

UPDATE:

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

Также, что касается .NET 4, если вы можете переосмыслить вашу проблему как Parallel.For или Parallel.ForEach, то пул потоков отрегулирует количество потоков, чтобы максимизировать пропускную способность, чтобы вам не пришлось об этом беспокоиться.

-Rick

3 голосов
/ 20 февраля 2010

Предполагая, что ничего более важного, но ОС работает на компьютере:

И ваша нагрузка постоянна, вы должны стремиться к 100% загрузке ЦП, все остальное - пустая трата ЦП. Помните, что ОС обрабатывает потоки, поэтому она действительно может работать, трудно заставить ОС голодать с помощью хорошо управляемой программы.

Но если ваша нагрузка является переменной, и вы ожидаете пики, которые следует учитывать, я бы сказал, 80% ЦП - это хороший порог для использования, если вы точно не знаете, как будет изменяться эта нагрузка и сколько ЦП она потребует в этом случае вы можете стремиться к точному числу.

1 голос
/ 20 февраля 2010

Если вы просто дадите своим потокам низкий приоритет, ОС сделает все остальное и примет циклы, необходимые для работы. Server 2003 (и большинство серверных операционных систем) очень хороши в этом , не нужно пытаться управлять им самостоятельно.

0 голосов
/ 23 сентября 2015

Я также использовал 80% в качестве общего практического правила для целевой загрузки ЦП. Как упоминали некоторые другие, это оставляет некоторый запас для спорадических всплесков активности и поможет избежать перегрузки ЦП.

Вот небольшой (более старый, но все еще актуальный) совет от команды Weblogic по этому вопросу: http://docs.oracle.com/cd/E13222_01/wls/docs92/perform/basics.html#wp1132942

Если вы чувствуете, что ваша нагрузка очень равномерна и предсказуема, вы можете увеличить эту цель немного выше, но если ваша пользовательская база исключительно терпима к периодическим медленным ответам и ваш бюджет проекта невероятно ограничен, я бы рекомендовал добавить больше ресурсов Ваша система (добавление ЦП, использование ЦП с большим количеством ядер и т. д.) слишком рискованно, чтобы попытаться выжать еще 10% использования ЦП из существующей платформы.

...