Хорошо, наша новая сборка имеет 100% пики процессора на каждом сервере в случайные интервалы. На длительные периоды это делает сайт полностью неотзывчивым - это будет в пиковые часы, когда люди из разных стран заходят на сайт и т. д.
Мы рассмотрели perfmom, профилировщики памяти, профилировщик CLR, профилировщики sql, профилировщик Red gate ants, попробовали нагрузочное тестирование в UAT, но не смогли даже воспроизвести проблему. Это может означать, что только тысячи пользователей, заходящих на сайт, могут вызвать ее.
Одна из замеченных нами закономерностей заключалась в том, что новый код — сломанная сборка — на самом деле использует заметно меньше потоков.
Мы также используем пружину для МОК — имеет ли она репутацию кровати?
Что еще хуже, мы не можем развернуть решение вживую из-за его влияния на бизнес, поэтому не можем сузить проблему до подмножества новых функций, которые мы добавили.
Мы действительно уничтожены — есть ли у кого-нибудь боевые шрамы, которые могут спасти нам несколько жизней?
решение1
Предлагаю делать дампы памяти и анализировать их в WinDdg с Sos. Я исправил некоторые проблемы на нашем производстве, которые я, вероятно, не смог бы диагностировать без WinDbg.
Тесс Фернандесотличный блог, где вы можете узнать, как анализировать дампы памяти.
решение2
Обычно это вызвано очисткой больших долгоживущих объектов в GC(у stackoverflow была такая проблема, см. ссылку). Вы храните множество коллекций объектов в кэше или сеансе?
Я также рекомендую вам построить и настроить новый сервер в продакшне для тестирования. Если у вас есть случайные безумия и вы не знаете почему и не можете их воспроизвести, я бы указал пальцем на оборудование или конфигурацию, а не на код.
решение3
Это виртуальный сервер с общими ресурсами или физический сервер? Если это первый вариант, возможно, вы могли бы рассмотреть возможность выделения ресурсов этому серверу. Удачи...
решение4
Попытка угадать ошибку без данных бессмысленна. Да, кому-то на stackoverflow или в вашей команде инженеров может повезти, но это просто плохая инженерия, и вы не можете составить план того, сколько времени вам понадобится, чтобы перебрать все догадки, и найдете ли вы вообще проблему.
- Вы должнырепродукцияпроблема. Jmeter — хорошее начало из-за своей широты охвата, но мы не можем рекомендовать правильный инструмент, не зная нашей архитектуры.
- Ведение журналаособенно на вашем прикладном уровне является обязательным. Вы можете включить трассировки IIS для медленной производительности, но маппеты в Microsoft сделали так, что вы не можете захватить весь поток конвейера, когда он медленный. Если это так трудно воспроизвести, вам действительно нужны некоторые журналы, которые помогут вам сузить круггдепроблема в том, что (типа, о, это происходит всякий раз, когда мы вызываем эту хранимую процедуру).
100% CPU немного подозрительно в том смысле, что это вряд ли I/O (при условии, что db — это еще один ящик, медленная база данных не должна вызывать 100% CPU на веб-серверах). Вам нужно поискать поближе к дому.