좋습니다. 새 빌드에서는 무작위 간격으로 각 서버에서 CPU 스파이크가 100% 발생합니다. 오랜 기간 동안 사이트가 완전히 응답하지 않게 됩니다. 이는 다른 국가의 사람들이 사이트에 로그인하는 등의 피크 시간에 발생합니다.
성능, 메모리 프로파일러, CLR 프로파일러, SQL 프로파일러, Red Gate ants 프로파일러를 살펴보고 UAT에서 로드 테스트를 시도했지만 문제를 재현할 수도 없습니다. 이는 라이브 사이트를 방문하는 수천 명의 사용자만이 이러한 일이 발생한다는 것을 의미할 수 있습니다.
우리가 발견한 한 가지 패턴은 새 코드(깨진 빌드)가 실제로 눈에 띄게 적은 스레드를 사용한다는 것입니다.
우리는 IOC에도 스프링을 사용하고 있습니다. 침대 평판이 좋나요?
설상가상으로 비즈니스 영향으로 인해 실시간으로 배포할 수 없습니다. 따라서 추가한 새 기능의 하위 집합으로 문제의 범위를 좁힐 수 없습니다.
우리는 정말 멸망했습니다. 우리에게 몇 명의 생명을 구할 수 있는 전투 상처를 입은 사람이 있습니까?
답변1
Sos를 사용하여 WinDdg에서 메모리 덤프를 수행하고 분석하는 것이 좋습니다. WinDbg 없이는 진단할 수 없는 몇 가지 문제를 프로덕션에서 수정했습니다.
테스 페르난데스메모리 덤프를 분석하는 방법을 배울 수 있는 훌륭한 블로그가 있습니다.
답변2
이는 일반적으로 GC(stackoverflow에 이 문제가 있었습니다. 링크를 참조하세요.). 캐시나 세션에 많은 개체 컬렉션을 저장하고 있습니까?
또한 테스트를 위해 프로덕션 환경에서 새 서버를 구축하고 구성하는 것이 좋습니다. 임의의 광기가 있고 이유를 모르고 재현할 수 없다면 코드가 아닌 하드웨어나 구성을 지적하고 싶습니다.
답변3
공유 리소스가 있는 가상 서버입니까, 아니면 물리적 서버입니까? 전자라면 아마도 이 서버에 리소스를 할당하는 것을 살펴볼 수 있습니다. 행운을 빌어요...
답변4
데이터 없이 결함을 추측하는 것은 의미가 없습니다. 예, stackoverflow 또는 엔지니어링 팀의 누군가가 운이 좋을 수도 있지만 이는 잘못된 엔지니어링일 뿐이며 모든 추측을 시도하는 데 시간이 얼마나 걸릴지, 심지어 문제를 발견할지에 대한 계획을 세울 수 없습니다.
- 당신은해야재현문제. Jmeter는 범위가 넓기 때문에 좋은 시작이지만 아키텍처를 알지 못하면 올바른 도구를 추천할 수 없습니다.
- 벌채 반출특히 애플리케이션 계층에서는 필수입니다. 느린 성능을 위해 IIS 추적을 활성화할 수 있지만 Microsoft의 머펫은 느릴 때 전체 파이프라인 흐름을 캡처할 수 없도록 만들었습니다. 재현하기가 너무 어렵다면 범위를 좁히는 데 도움이 되는 로그가 필요할 것입니다.어디문제는. (아, 우리가 이 저장 프로시저를 호출할 때마다 그렇습니다).
100% CPU는 I/O가 아닐 가능성이 있다는 점에서 약간 의심스럽습니다(db가 또 다른 상자인 경우 느린 데이터베이스로 인해 웹 서버에서 100% CPU가 발생해서는 안 됩니다). 집에서 좀 더 가까이서 살펴봐야 합니다.