Как улучшить Windows Server 2008 R2 для обработки многих соединений?

Уже несколько дней я пытаюсь понять, как решить эту проблему. Во-первых, у меня есть веб-сайт со средним ежедневным просмотром страниц 350 000. Ранее все управление рекламой (отслеживание кликов и показов каждой рекламы) и контент обслуживались на одном сервере со следующей спецификацией:

Сервер 1
ОС: Windows 2008 R2 64-разрядная
Процессор: Intel® Core ™ i5 - 4 ядра
Оперативная память: 8 ГБ
Хранение: 2 х 1 ТБ жестких дисков
Пропускная способность: 10 ТБ в месяц

Чтобы повысить скорость работы нашего веб-сайта, я решил разделить скрипт управления рекламой на другом выделенном сервере, поскольку у нас более 15 рекламодателей на 30 рекламодателей на каждой странице.

Сервер 2
ОС: Windows 2008 R2 64-разрядная
Процессор: Intel® Core ™ i5 - 4 ядра
Оперативная память: 4 ГБ
Память: 2 х 300 ГБ жестких дисков
Пропускная способность: 10 ТБ в месяц

Проблема
Проблема в том, что Server 1может обрабатывать как контент, так и рекламную систему. Теперь, когда я забираю рекламную систему и помещаю ее в Server 2. Server 2едва может обслуживать только рекламную систему.

Тестовое задание

• Прежде всего, я переместил 75% рекламы на Server 2. А затем, выполнить пинг на сервер: ping -t xxxxx. [Я выполнил пинг в течение 10 минут и следовал его примеру, как показано ниже]

Ответ от xxxxx bytes = 32 time = 290ms TTL = 116
Ответ от xxxxx bytes = 32 time = 289ms TTL = 116
Ответ от xxxxx bytes = 32 time = 320ms TTL = 116
Ответ от xxxxx bytes = 32 time = 286ms TTL = 116
Ответ от xxxxx bytes = 32 time = 286ms TTL = 116
Ответ от xxxxx bytes = 32 time = 348ms TTL = 116
Ответ от xxxxx bytes = 32 time = 284ms TTL = 116

• Затем я переместил 100% объявлений в Server 2. Затем снова выполните команду ping на сервер. [Я выполнил пинг в течение 10 минут и следовал его примеру, как показано ниже]

Ответ от xxxxx bytes = 32 time = 290ms TTL = 116
Истекло время запроса
Ответ от xxxxx bytes = 32 time = 320ms TTL = 116
Ответ от xxxxx bytes = 32 time = 286ms TTL = 116
Истекло время запроса
Истекло время запроса
Ответ от xxxxx bytes = 32 time = 284ms TTL = 116

попытки

1. Увеличение MaxUserPortиTcpNumConnection
2. Перезагрузите сервер
3. Увеличить IIS Max InstancesиInstance MaxRequests

Ресурс сервера

• Используется только 10% -15% сетевого подключения
• Используется только 10% -15% процессора
• Используется только 25% памяти

Ну что ж, начнем. Это дольше.

Вы совершенно неверно оценили факты. Windows - даже устаревшая версия 2008 R2, которую вы должны обновить как можно скорее, - полностью способна обрабатывать том, с которым мой мобильный телефон не сталкивается.

Итак, это оставляет 3 возможных области проблем:

• Установка. Ваши водители могут быть дрянными. Учитывая, что вы используете устаревшую операционную систему - насколько хороши ваши драйверы? Обновите их - это МОЖЕТ вызвать всевозможные проблемы.

• Сеть. Это серьезно выглядит как «Моя машина слишком медленная, пожалуйста, помогите мне сделать это быстрее», когда проблема в том, что вы проводите большую часть времени в пробке и жалуетесь на то, что движение не движется. Не проблема тюнинга автомобиля. Трафик 10 Тб ничего не говорит о перегрузке сети. Следите за статистикой сетевого трафика на вашей сетевой карте, а затем реагируйте соответствующим образом - если они не достигли максимума на той скорости, с которой они должны быть ... ваш поставщик перепродал. Просто так.

• Код. Возможно, вам нужно больше оперативной памяти (компьютер занят подкачкой в ​​оперативную память вместо обработки) или дрянное кодирование использует весь ваш процессор до такой степени, что стек TCP на уровне ядра не реагирует должным образом (да, ответы ICMP такие низкие). Это было бы жестоко, но это еще один способ проверить. Возможно также, что вы перегружаете диски, обращаясь к ним слишком часто, а не кешируя в ОЗУ, но я почему-то не вижу, что приводит к потере пингов. Любая проблема здесь не является чем-то, что администратор может обработать, - вы должны бросить аппаратное обеспечение в это, или взять палку и ударить программиста этим, пока он не исправит это (если это - "глупая" ошибка уровня, которая снижает производительность - если это не так, то сделать серьезные успехи намного сложнее, и вам может потребоваться более мощное оборудование).

Это определенно не требует настройки окон - хорошо сконфигурированные окна могут дать МНОГО больше, чем это. Мои файловые серверы регулярно работают в течение более длительных периодов времени - от 4 до 6 гигабит при относительно стандартных настройках.

Теперь все цифры, которые вы даете, ничего не говорят серьезно.

• 10-15% ЦП используется МОЖЕТ означать обмен.
• 25% используемой памяти, вероятно, является хорошим индикатором, теперь происходит обмен, но это все еще может означать, что процессор ожидает ввода-вывода.
• 10% -15% сеть используется, значит - абсолютно ничего, потому что это только ВАША сторона сети. Как насчет вверх по течению? Что, если провайдер помещает 20 серверов с 1 гигабитом в 1 гигабитный канал связи из стойки, и это переполняет, как ад?

Последний пункт вполне вероятен - отброшенные пакеты являются хорошим индикатором этого. И это не будет видно для вас.

Мой совет .... отключите что-нибудь на машине на мгновение, сделайте тест скорости от внешнего с большим статическим файлом. Могу поспорить, что вы столкнетесь с заторами выше.

Все, что вы делали до сих пор - maxuserport, tcpnumconnection, перезапуск сервера, игра с настройками IIS - полностью отключено и ничего не делает в лучшем месте. Удар молотком по медленной машине никогда ничего не исправит - особенно если машина медленная, потому что стоит в пробке. Я бы отменил все изменения и начал анализировать проблему, а не только ваш сервер. Я бы поспорил на загруженность сети в данный момент.

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