Хорошо, наша новая сборка имеет 100% скачков ЦП на каждом сервере через случайные промежутки времени. На долгое время сайт полностью не отвечает - это будет в часы пик, когда люди из разных стран заходят на сайт и т. Д.
Мы рассмотрели perfmom, профилировщики памяти, профилировщик CLR, профилировщики sql, профилировщик муравьев Red Gate, попробовали нагрузочное тестирование в UAT, но даже не смогли воспроизвести проблему. Это может означать, что только тысячи пользователей попадают на действующий сайт, и это происходит.
Мы заметили одну закономерность, заключающуюся в том, что новый код - сломанная сборка - на самом деле использует заметно меньше потоков.
Мы также используем пружину для IOC - у этого есть репутация кровати?
Что еще хуже, мы не можем развернуть в реальном времени из-за влияния на бизнес - поэтому не можем сузить проблему до подмножества новых функций, которые мы добавили.
Мы действительно уничтожены - есть ли у кого-нибудь боевые шрамы, которые могут спасти нам несколько жизней?
Предлагаю делать дампы памяти и анализировать их в WinDdg с помощью Sos. Я исправил некоторые проблемы в нашей продукции, которые, вероятно, не смог бы диагностировать без WinDbg.
Тесс Фернандес ведет отличный блог, где можно узнать, как анализировать дампы памяти.
Это виртуальный сервер с общими ресурсами или физический сервер? Если это первое, возможно, вам стоит выделить ресурсы для этого сервера. Удачи...
Обычно это вызвано очисткой больших долгоживущих объектов в GC (У stackoverflow была эта проблема, см. ссылку). Вы храните много коллекций объектов в кеше или сеансе?
Я также рекомендую вам создать и настроить новый сервер для тестирования. Если у вас случайное безумие, и вы не знаете, почему, и не можете его воспроизвести, я бы указал пальцем на оборудование или конфигурацию, а не на код.
Попробуйте использовать cache server как фронтенд как Apache Traffic Server (ATS).
Хотя это не решит проблему, это может помочь ее выявить, потому что в то же время вы переместите потенциально опасную нагрузку с бэкэнда (посмотрите, есть ли проблемы и с внешним интерфейсом) и сделаете вещи менее нагретыми на бэкэнде, чтобы он легче увидеть, что не так.
Бессмысленно пытаться угадать неисправность без данных. Да, кому-то в stackoverflow или в вашей команде инженеров может повезти, но это просто плохая инженерия, и вы не можете спланировать, сколько времени у вас уйдет, чтобы испробовать каждое предположение, и если вы даже найдете проблему.
100% CPU немного подозрительно в том смысле, что это вряд ли будет ввод-вывод (если db - это еще один блок, медленная база данных не должна вызывать 100% CPU на веб-серверах). Вам нужно присмотреться к дому.