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

Есть ли рекомендации по оптимизации производительности потоковой передачи W2008R2?

Я хочу быть уверенным, что мой блок W2008R2 имеет как минимум возможные прерывания и переключатели контекста в потоках ЦП.

У меня 4 ядра / 8 потоков HT CPU. Я запускаю одно приложение, которое использует только сокеты в качестве устройства ввода-вывода, поэтому я ожидаю, что единственные прерывания HW будут сетью.

Однако я хочу свести к минимуму прерывания от потоков ОС. Остановил большинство сервисов, понимаю, что не нужны. Но это было всего лишь мое личное предположение.

Я хочу получить хорошие знания о том, что можно остановить, а что нельзя, какие параметры можно настроить.

Также, что и как я должен контролировать, чтобы убедиться, что я принял правильное решение.

Просто для описания работы: это .NET-приложение с очень малой задержкой, которое находится в производстве уже 3 года и довольно стабильно. Он использует очень мало ЦП, имеет небольшое количество GC, использует мало оперативной памяти, использует много сокетов, время от времени дисковый ввод-вывод (ведение журнала некоторых приложений, которое похоже на 10 строк текста в минуту ... Приложение имеет 4 очень важных потока для запуска (но # текущих физических потоков в perfmon для приложения - 44).

Единственный сервис, который я использую вне приложения, - это RDP.

Вы можете использовать более широкий подход и профилировать свою системную активность с помощью такого инструмента, как SysInternals Process Monitor. Он предоставит вам подробную информацию о довольно большом количестве действий, которые постоянно происходят в системах Windows, с минимальной воспринимаемой активностью.

Одним из конкретных источников большой активности является реестр. На панели инструментов есть четыре кнопки, которые позволяют фильтровать по реестру, файловой системе, сетевой активности или отдельным процессам и потокам.

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

Стоит отметить, что в Windows 7/2008 R2 процессы теперь имеют приоритет ввода-вывода и приоритет памяти. Вы можете поэкспериментировать с таким инструментом, как Lasso, чтобы увидеть, сможете ли вы добиться измеримых результатов. Обратите внимание, что может быть невозможно назначить более высокий приоритет ввода-вывода. Я считаю, что такие инструменты, как эта, работают, регулируя приоритет ввода-вывода других выбранных фоновых процессов.

Больше информации:

Монитор процессов 3.01
http://technet.microsoft.com/en-us/sysinternals/bb896645

Я хочу получить хорошие знания о том, что можно остановить, а что нельзя, какие параметры можно настроить.

При всем уважении, это фигня. Если у вас нет реальной проблемы, вы сражаетесь за 2 доллара или около того максимального прироста производительности, который просто не стоит того. Если этот вопрос заключается в том, как эффективно программировать поток, это неправильный форум и неправильный вопрос, но ЭТО было бы достойной битвой.

Самое главное - получить приличную сетевую карту. Уровень сервера. Так как это то, что есть у большинства плат сервоприводов в наши дни - если вы не пошли дешево и не поставили плату для рабочей станции, вы в основном уже вполне оптимальны.

У приложения есть 4 очень важных потока для запуска (но # текущих физических потоков в perfmon для приложения 44).

Что ж, это может быть проблемой, но это не проблема, которую ВЫ можете решить с точки зрения настройки ОС - выясните, почему у нее 44 потока, что они якобы делают. Это задача программиста, и, как я уже сказал, она МОЖЕТ того стоить. Но настройка усиления примерно на 2% - это не то дерево. Сообщение Грега - очень хороший пример - он говорит о доступе к реестру и т. Д. - что РЕДКО имеет значение, и если это имеет значение, это просто сторона «программист облажался, пусть он исправит код», а не «как мне настроить окна».

Кстати, 44 потока могли быть в основном неактивными. Такие вещи, как финализатор, потоки gc, потоки резервирования для пула рабочих элементов, которые просто ждут, пока элемент не будет поставлен в очередь.