NCache 상태 및 성능 모니터링
녹화된 웨비나
론 후세인
이 비디오 웨비나는 실행 중인 애플리케이션의 최적 상태를 위해 사용할 수 있는 옵션과 도구에 대한 포괄적인 소개입니다. NCache.
두 가지 모두에 대한 상태 경고 및 성능 옵션에 대해 알아봅니다. NCache 서버 및 NCache 클라이언트(애플리케이션 측), 특히:
- NCache 건강 경고 기능: 개요 및 사용 방법
- NCache 성능 모니터링: 개요 및 기능
- 상태 및 성능 모니터링을 위한 기본 제공 도구
- NCache 운영 체제(Windows) 리소스를 통한 모니터링
- NCache 타사 도구를 통한 모니터링
- 디버깅 방법 NCache 건강 및 성능 문제
오늘 저희가 선택한 주제는 NCache 상태 및 성능 모니터링. 따라서 기본적으로 내에서 다양한 모니터링 옵션을 다룰 것입니다. NCache 이 특정 웨비나에서는 두 가지 다른 방법으로 이를 다룰 것입니다. 활용할 수 있는 상태 관련 옵션과 성능 모니터링, 그리고 애플리케이션 성능에 대해 이야기하겠습니다. NCache 서버 측 성능. 이것은 NCache 에 대한 세부 정보를 이미 알고 있다고 가정하겠습니다. NCache 몇 가지 기본적인 세부 정보도 공유하겠지만 오늘 웨비나의 의제는 특정 주제를 다루고 있다는 것입니다. 그것은 약 NCache 그리고 노출하겠습니다 NCache 상태 및 성능 모니터링과 관련된 기능.
NCache 전개
괜찮은! 그래서 먼저 시작점은 NCache 전개. 내가 말했듯이, 나는 NCache 이미 설정되어 있지만 그렇지 않은 경우 다음을 위한 일반적인 배포입니다. NCache.
여러 서버가 상주하는 서버 계층이 있고 클라이언트-서버 모델에서 실제로 이에 연결되는 애플리케이션 계층이 있습니다. 따라서 서버가 캐싱 전용인 별도의 캐싱 계층을 사용하면 애플리케이션이 자체 각 계층에서 실행될 수 있습니다. 이들은 ASP.NET 웹 응용 프로그램, 웹 양식 또는 MVC, ASP.NET 웹 서비스 또는 Java 웹 서비스, WCF 또는 기타가 될 수 있으며 모두 연결되는 백엔드 서버 응용 프로그램이 될 수 있습니다. NCache. 따라서 이러한 배포가 있을 때마다 캐싱이 있는 위치에서 NCache 그런 다음 귀하의 응용 프로그램이 NCache, 캐시된 항목과 관련하여 여러 가지 질문이 있을 수 있습니까? 처리량은 얼마입니까? 성능 매트릭스는 무엇입니까? 개체 크기가 다르거나 문제가 있는 경우 성능 향상은 무엇입니까? 그것을 디버깅하는 방법?
그래서 오늘 다룰 내용은 여기까지입니다. 상태와 관련하여 모니터링 기능을 캡처하고 캐시할 수 있는 다양한 로그, 다양한 상태 관련 이벤트에 대해 이야기하겠습니다. 설정할 수 있는 다양한 디버그 로그에 대해 이야기하고 성능 비교도 제공하므로 이 모든 것이 이 웨비나에 포함되어 있습니다. 많은 것이 올 것이고 모든 것이 실습입니다.
NCache 서버 요구 사항
더 이상 지체하지 않고 실제로 시작하겠습니다. NCache 서버 요구 사항. 일반적으로 정기 데모 및 웨비나에서 이를 다룹니다. 따라서 8코어 이상이면 최소 권장 설정입니다. NCache 그러나 더 많은 코어를 가질 수도 있습니다. RAM은 사용 사례에 따라 16GB 이상입니다. 모든 Windows 환경에서 지원되며 NCache 서버 부분은 2012 또는 2016을 사용하는 것이 좋지만 2008 운영 체제, .NET 4.0 이상, 4.6.1 또는 4.6.2 또는 4.5와 같은 이전 버전에서도 작동할 수 있습니다. 가장 많이 사용하는 방법입니다. 그리고, remote clients는 모든 Windows 환경에서 다시 모든 프레임워크에 있을 수 있습니다. 32비트 및 64비트 모든 환경도 지원합니다.
설정 환경
그래서 그렇게 말하면서 나는 빨리 점프하고 이것을 시작하겠습니다. 신속하게 데모 환경을 만들고 이를 위해 두 개의 노드와 몇 개의 클라이언트를 사용하여 연결합니다. 그리고 다시 캐시를 생성하는 방법, 구성, 토폴로지에 대한 많은 세부 정보를 공유하지 않는다는 가정을 사용합니다. 나는 당신이 이미 그 세부 사항을 알고 있다고 가정합니다. 그렇지 않은 경우 매달 진행되는 건축 웨비나 또는 건축 시연을 찾아보십시오. NCache 또는 우리가 수행하는 기술 웨비나의 일부로.
따라서 ASP.NET 웹 응용 프로그램과 함께 설치되는 콘솔 응용 프로그램을 사용하겠습니다. NCache 그것이 내가 염두에 둔 것입니다. 그래서, 기본적으로 이것은 이것을 시작하기 위해 내가 빨리 할 것입니다. 내 개발 환경에 로그온하겠습니다. 이미 구성한 캐시가 있으므로 새 프로젝트를 생성한 다음 캐시를 생성합니다. 따라서 데모 캐시를 생성하겠습니다. 이 캐시는 모든 성능 및 상태 관련 모니터링 측면에 사용할 캐시입니다. NCache. 가장 많이 사용되는 파티션 복제본 캐시를 선택하겠습니다. 따라서 이 캐시를 선택한 다음 서버와 demo1 및 demo2 간의 복제 모드인 async도 선택하는 것이 좋습니다.
이러한 모든 단계는 웹사이트에서 찾아볼 수 있는 기존 웨비나 및 데모에 매우 자세하게 문서화되어 있습니다. 따라서 이것은 통신을 위한 서버의 TCP 포트를 지정한 다음 캐시 클러스터의 크기를 지정하는 방법입니다. 캐시가 꽉 찼을 때 알림을 받고 이에 대응하는 방법에 대해 염두에 두고 있는 것이 있습니다. 그리고 지금은 퇴거를 끄거나 계속 켜두겠습니다. 실제로 캐시가 가득 차는 방법과 해당 시나리오에서 무엇이 필요한지 실제로 보여줄 것이기 때문에 꺼두겠습니다. 제거는 캐시가 가득 차면 자동으로 캐시에서 일부 항목을 제거하여 새 항목을 위한 공간을 만드는 방법입니다. 그러니 그렇게 하지 말고 완료를 선택하면 캐시가 생성됩니다.
바로 여기 내 개인용 컴퓨터인 내 상자를 클라이언트로 빠르게 추가하겠습니다. 있는지 확인해야합니다 NCache 서비스가 시작되었는지 여부. 나는 환경을 만지작 거리고 있었으므로 나와 함께하십시오. 그럴지도.. 그래 시작해서 추가된 것 같아, 알았어! 그럼 실제로 시작해 봅시다. 그래서 환경이 설정되었습니다. 테스트 캐시를 가지고 놀았기 때문에 지금은 테스트 캐시를 무시하십시오. 데모 캐시에 집중하세요. 나는 그것을 클릭했다. 오른쪽 창에서 볼 수 있습니다. 이 특정 캐시에 대한 모든 설정입니다. 아직 시작되지 않았습니다. 따라서 두 서버가 모두 시작되도록 빠르게 시작하겠습니다. 여기 또는 여기에서 시작 버튼을 사용하면 실제로 모든 캐싱 서버에서 캐시를 시작합니다. 그런 다음 실제로 몇 가지 기본 단계부터 시작하겠습니다. 캐시가 시작되었는지 어떻게 알 수 있습니까? 그것이 건강하다는 것을 어떻게 알 수 있고 그것이 활동을 보여주고 있는지 어떻게 알 수 있습니까? 자, 이것들은 우리가 바로 지금 취할 몇 가지 기본 단계이며 그 위에 구축할 것입니다. 우리는 그것을 몇 가지 광범위한 수준, 일부 고급 수준으로 가져감으로써 그것을 발전시킬 것입니다.
따라서 캐시가 시작되어 관리자 또는 명령줄에서 사용할 수 있는 첫 번째 단계이며 이 모든 작업은 명령줄을 통해서도 수행할 수 있으므로 GUI 도구만이 아닙니다. GUI와 비교하여 동등하게 갖춰진 명령줄 도구가 있습니다. 마우스 오른쪽 버튼을 클릭하고 캐시 클러스터의 상태를 확인하기 위해 보기 클러스터 연결 상자를 엽니다.
그것은 실제로 완전히 연결된 상태에 대한 아이디어를 제공합니다. 각 서버에는 활성 및 백업이 있습니다. 정말 빠른 다이어그램을 보여 드리겠습니다. 토폴로지를 선택했기 때문에 이 파티션 복제본 캐시가 있고 아키텍처는 존재하는 활성 파티션이 있고 다른 서비스의 복제본이 유지되는 수동 파티션이 있습니다.
따라서 서버 XNUMX의 활성 백업은 서버 XNUMX에 다시 열려 있고 서버 XNUMX의 활성 백업은 하나에 있습니다. 이들은 능동태이고 이들은 수동태입니다. 이것들만 활성화되고 이것은 내려가죠, 그렇죠? 따라서 이것이 다운되면 이것이 활성화되고 이것이 다운되면 백업이 활성화됩니다. 따라서 각 서버에는 두 개의 파티션이 있습니다. 우리는 XNUMX개의 서버가 있고 XNUMX개의 파티션이 있고 이것이 바로 여기에서 보고 있는 것입니다.
따라서 하나는 자체 백업에 연결되고 다른 서버는 활성 상태이며 다른 서버는 백업 서비스에 연결됩니다. 그리고, 서버 107는 상대 서버인 자신의 백업(XNUMX)과 상대 서버의 백업 및 자신의 백업에 연결된다. 당신은 그것이 증가하는 패턴에 있고 완전히 연결되어 있다는 것을 알고 있습니다. 보이신다면 이제 몇 가지 세부 사항을 공유하겠습니다. 상태 메시지가 연결되지 않았거나 부분적으로 연결되었거나 캐시 서비스가 시작되지 않았습니다. 따라서 이 모든 것은 캐시 클러스터에 문제가 있음을 의미하므로 완전히 연결된 상태가 표시될 때까지 또는 그렇지 않으면 캐시가 제대로 시작되지 않은 것입니다. 이것이 첫 번째 구축 지점입니다. 캐시를 생성할 때 완전히 연결된 캐시 상태를 확인해야 합니다.
그리고 이 출력은 목록 캐시를 통해서도 사용할 수 있습니다. 그것은 오는 도구입니다. 여기로 가져오겠습니다. 이 캐시입니다. 그리고 목록 캐시를 실행하면 /a를 사용하여 방금 실행하면 데모 캐시가 시작된 로컬 정보만 제공됩니다. 하지만 이 캐시(예: A 스위치)로 작업을 수행하면 실제로 107개 포트에 대한 클러스터 크기(백업용 107:7802)를 제공합니다. 108:7807 및 708 및 카운트.
그래서 이것은 이것에 대한 건전한 표시를 제공합니다. 따라서 목록 캐시를 사용하는 경우 이 정보를 조회해야 합니다. 그렇지 않으면 보기 클러스터 연결이 GUI 방식으로 이를 제공합니다.
각 캐시에는 캐시 호스트 프로세스가 있으므로 데모 캐시와 데모 캐시 XNUMX에 대한 캐시 흐름 프로세스가 있습니다. 예를 들어 자세한 설명을 추가하면 관련 캐시도 실제로 볼 수 있습니다. 명령줄에 있는 것 같지만 여기에 명령줄 열을 추가하면 실제로 캐시 이름을 볼 수 있습니다. 그러나 프로세스 ID가 우리에게 중요하기 때문에 일반적으로 프로세스 ID에 의존합니다. 이에 대해서는 다음 슬라이드에서 자세히 설명하겠습니다. 따라서 우리의 캐시가 작동하고 실행되는 것 같으므로 이것이 우리의 첫 번째 구축 지점입니다.
다음은 캐시에 대한 활동, 캐시가 요청을 받고 있는지 여부에 대한 기본 활동을 확인하는 방법입니다. 따라서 이를 위해 마우스 오른쪽 버튼을 클릭하고 통계를 선택할 수 있습니다. 이렇게 하면 perf-mon 카운터가 열리며 이들은 서버 측 카운터입니다. NCache 관리자이지만 클라이언트 측 카운터도 볼 수 있습니다. 이에 대해 자세히 설명하겠습니다. 다양한 개체 크기로 보여줄 시나리오가 있습니다. 클라이언트 측 평균과 이것이 어떻게 영향을 받는지 보여줄 것입니다. 이것이 제가 이 웨비나의 마지막 부분에 정리한 것입니다. 그래서 그것도 나옵니다. 그러나 기본적인 측면을 보여드리기 위해 여기로 가져오겠습니다. 데모 캐시와 복제본 데모 캐시 및 복제본이 있습니다. 테스트를 실행하지 않기 때문에 이 시점에서 활동이 생성되지 않습니다. 테스트를 수행해야 합니다. 내 상자를 클라이언트로 추가했으므로 명령줄을 실행하겠습니다. 이를 시작하기 위한 도구입니다.
다른 매개변수도 사용할 수 있지만 지금은 몇 가지 기본 값을 사용하고 초당 요청이 이미 들어오는 것을 볼 수 있습니다. 따라서 우리는 요청을 받는 서버 XNUMX이 있고 백업은 요청을 받지 않고 카운트가 업데이트되지만 서버 XNUMX는 요청을 받고 있으므로 여기에서 바로 볼 수 있으며 실제로 백업인 서버 XNUMX의 백업이 있습니다. 따라서 하나의 백업 파티션이 정렬됩니다. 따라서 이것은 실제로 캐시가 제대로 실행되고 있다는 또 다른 확인을 제공합니다.
요청이 고르게 분산됩니다. 바로 여기에서 초당 요청 카운터를 볼 수 있습니다. 그리고 백업도 업데이트되고 있습니다.
따라서 우리의 첫 번째 단계인 상태에 관한 기본 모니터링은 이 주변의 벽을 둘러싸는 것입니다. 그런 다음 이 지점부터 계속 진행하여 캐시에 어떤 문제가 있는지 확인할 수 있습니다. 우리는 알림을 받을 수 있으며 그에 대해 더 자세히 이야기하겠습니다.
모니터링 옵션
신속하게 진행하여 내에서 모니터링 옵션을 시작하겠습니다. NCache. 자, 이렇게 정리했습니다. 어제 나는 이것들을 설명하는 데 많은 시간을 할애했고, 그 다음에는 실습 부분에 더 집중해야 한다는 피드백을 받았습니다. 그래서, 이것이 제가 오늘 할 것입니다. 내가 말했듯이 오늘 이 웨비나에서는 다른 방법을 사용할 것입니다.
PerfMon 카운터를 사용한 모니터링
따라서 PerfMon 카운터가 있습니다. 우리는 서버 측과 클라이언트 측을 가지고 있습니다. 그것들을 보여드리겠습니다. 이벤트 로그 항목이 있고 이러한 이벤트 로그 항목을 사용하여 경고를 제공하는 이 모니터링 도구가 있습니다. 이메일 관련 알림을 제공하는 이메일 알림이 있습니다. 그런 다음 타사 도구를 사용하여 이러한 이벤트 로그에 연결할 수도 있습니다. 따라서 이것들은 꽤 광범위하며 모니터링 측면에서 가장 중요한 요소라고 말할 수 있습니다. NCache.
로그를 이용한 모니터링
그런 다음 로그가 있습니다. 로그를 구성할 수 있는 여러 가지 방법이 있습니다. 서버 측 로그, 클라이언트 측 로그가 있으며 로그 분석기라는 별도의 도구가 있습니다. 그런 다음 링크 패드 통합의 도움을 받는 데이터 분석기 도구가 있고 API 로그도 있어 개별 통화에 얼마나 많은 시간이 걸리는지 실제로 보여줄 수 있으며 플러그 앤 플레이 옵션일 뿐입니다. 그리고 제가 말했듯이, 우리는 SCOM을 사용하여 이러한 로그에 연결하고 이러한 이벤트 로그 항목에 연결한 다음 AppDynamics 또는 다른 타사 도구를 사용할 수 있는 타사 통합이 있습니다. NCache 그에 대한.
NCache 모니터링 도구 – 데모
오늘은 다양한 방법의 실제 데모를 사용하여 시작하겠습니다. NCache 함께 설치되는 모니터링 도구 NCache. 이제 요청을 설정했으므로 다른 클라이언트로 이동하여 서버 상자를 실제로 사용해 보겠습니다. 서버는 또한 클라이언트를 사용할 수 있으므로 실제로 볼 수 있습니다. 여기에서 스트레스 테스트 도구를 실행한 다음 여기에서도 스트레스 테스트 도구를 실행하여 초당 요청 수에 관한 한 상당한 로드라고 하겠습니다. 그리고 서버 XNUMX과 서버 XNUMX에서 초당 약 XNUMX개의 요청과 이제 XNUMX개 이상의 요청, 초당 XNUMX~XNUMX개의 요청을 볼 수 있습니다.
이제 모니터링 도구를 통해 다룰 수 있는 실시간 및 로깅에 대한 기본 모니터링 요구 사항입니다. 다른 곳을 볼 필요도 없고 로그를 검토할 필요도 없으며 이벤트 로그에 들어가거나 타사 도구에 연결할 필요가 없습니다. 함께 설치되는 도구가 있습니다. NCache 따라서 그대로 사용하는 것이 좋습니다. 해당 특정 도구에 대한 빠른 데모를 제공하겠습니다.
사전 구성된 모니터링 대시보드
마우스 오른쪽 버튼을 클릭하고 모니터 클러스터를 선택하면 NCache 함께 설치되는 모니터링 도구 NCache. 이것에 대한 좋은 점은 서버와 클라이언트를 모니터링하고 서버나 클라이언트 중 하나일 필요가 없으며 네트워크의 세 번째 상자가 될 수 있다는 것입니다. 캐시 배포일 필요는 없습니다.
따라서 우리는 107, 108 및 3개의 고객을 보유하고 있습니다. 내 상자에는 몇 가지 규칙이 있으므로 원격 모니터링을 허용하지 않지만 108 및 107 카운터를 볼 수 있으며 보기로 이동하여 이러한 서버 및 클라이언트 대시보드가 선택되어 있는지 확인하기만 하면 됩니다. 내 상자는 예상대로 오류가 발생합니다. 그러나 완전히 연결된 상태를 보여주는 동일한 연결 상자를 볼 수 있으며 변경 사항이 있으면 실시간으로 변경됩니다. 모든 상태를 실시간으로 보여주는 것이 이 모니터 도구의 장점입니다.
CPU 서버 1과 서버 2에 대한 CPU 그래프가 여기에 나열됩니다. 네트워크 그래프(여기에 표시될 네트워크 활동이 있는 경우). 캐시 크기 그래프와 초당 요청 그래프. 따라서 크기와 네트워크에 관한 한 이 시점에서 진행 중인 큰 활동이 없으므로 거의 3,000에 가까운 값을 볼 수 있지만 초당 요청 수는 약 수천 배이므로 약 108입니다. 서버 107과 서버 XNUMX의 초당 요청. 그리고 메모리도 올라갑니다. 따라서 이것은 실제로 서버 XNUMX과 서버 XNUMX가 사용 중이고 여기에 연결된 세 개의 클라이언트가 있으며 클라이언트 대시보드도 볼 수 있음을 설명합니다. 따라서 XNUMX과 XNUMX은 클라이언트이고 읽기 요청을 보내고 있으며 활동도 있음을 알 수 있습니다.
맞춤형 모니터링 대시보드
따라서 사전 구성된 일부 대시보드의 실시간 모니터링 측면을 다룹니다. 그러나 이것들에 의존할 필요는 없습니다. 실제로 한 발 앞서 나갈 수 있고 자신만의 대시보드를 만들 수 있으며 여기에서 재미가 시작됩니다. 대시보드를 좀 더 강력하게 만들기 위해 한 가지만 하겠습니다. 모니터 도구를 여는 다른 방법을 보여드리겠습니다. 여기에서 직접 모니터 도구를 열 수도 있습니다. 여러분이 해야 할 일은 서버를 선택하는 것입니다. 그러면 서버도 원격 서버가 될 것이고 캐시의 이름만 지정하면 됩니다. 그래서 그것은 실제로 지정하는 또 다른 방법이며 이제 동일한 것을 볼 수 있고 이제 하나의 클라이언트를 닫았기 때문에 두 개의 클라이언트가 있습니다. 이제 두 개의 서버와 두 개의 클라이언트만 있기 때문에 실제로 CPU 요청만큼 더 많은 활동을 볼 수 있습니다.
이제 돌아와서 다음에서 자신만의 대시보드를 만들 수 있습니다. NCache 모니터링 도구. 그건 그렇고, 이것들은 모두 Perf-mon 카운터입니다. 실제로 Windows 성능 모니터링을 사용하여 동일한 결과를 얻을 수 있는 성능 모니터 도구도 보여드리겠습니다. 그래서 당신이 그것에 익숙하다면 그것을 사용하십시오. 그냥 사용하고 싶다면 NCache 함께 설치되는 모니터 도구 NCache, 그것은 또 다른 훌륭한 선택입니다. 그런데 이것은 실시간 보기입니다. 이 대시를 만들겠습니다. 따라서 자신만의 대시보드를 만든다는 것은 빈 패널이 있다는 것을 의미합니다. 2x2 열을 사용하고 이것은 화면 왼쪽에 표시되는 모든 perf-mon 카운터에 활용됩니다. 서버 측의 CPU 사용량, 이벤트 로그, 클러스터 상태, 쓰기 작업, 항목 수 등이 지금까지는 양호했습니다. 모든 것이 여기에 나열되고 클라이언트 측 카운터도 있습니다.
따라서 서버 측 및 클라이언트 측 개인화된 모니터링을 제공하고 그 위에 실제로 바로 여기로 끌어다 놓을 수 있는 성능 제어도 제공합니다. 따라서 성능 카운터를 추가할 수 있습니다. Windows 성능 카운터일 수도 있고 메모리, .NET 셀룰러 메모리, CPU, 모든 종류의 성능 관련 카운터 또는 상태 관련 카운터일 수도 있습니다. NCache 여기에 추가할 수 있습니다. 그리고 그것들에 대해 좀 더 자세히 이야기하겠습니다. 괜찮은! 따라서 두 개의 대시보드가 있도록 대시를 하나 더 만들겠습니다. 대시 2라고 하고 2 x XNUMX가 크기라고 합시다. 그것이 표준입니다.
좋아요! 그래서 우리가 하는 동안 첫 번째 대시보드를 빠르게 보여주고 여기에 연결된 클라이언트 프로세스를 보여드리겠습니다. 따라서 이것은 현재 내 캐시에 연결된 모든 클라이언트 프로세스에 대한 개요를 제공합니다. 따라서 여기로 와서 이 창을 사용하고 클라이언트 IP, 프로세스 ID, 연결된 포트, 연결된 서버 IP, 보내고 받은 바이트를 사용할 수 있습니다. 따라서 클라이언트 애플리케이션 중 하나에서 과도한 활동이 표시되는 경우 여기에서도 실제로 연결을 볼 수 있습니다. 연결이 끊어졌을 수 있습니다. 항상 모든 서버에 연결된 하나의 프로세스 ID를 볼 수 있으므로 4016은 107에 연결되고 4016은 108에도 연결됩니다. 예를 들어 작업자 프로세스가 시작된 경우와 같이 연결 문제가 있는 경우 캐시에 세 개의 서버가 있습니다. 작업자 프로세스 중 하나가 서버 3에 연결할 수 없습니다. 그렇다면 어떻게 알 수 있습니까?
우선 트리거되는 이벤트가 있으며 이에 대해 곧 설명하겠습니다. 이는 알림을 받는 명시적인 방법입니다. 그러나 서버가 클라이언트에 의해 연결되지 않은 경우 클라이언트가 다른 서버로 요청을 보내고 해당 요청을 다시 라우팅하기 때문에 비정상적인 동작이 있는지, 속도가 느리거나 확장된 요청 양이 있는지 확인할 수 있습니다. 다른 서버로 전송하는 데 시간이 걸릴 수 있습니다. 따라서 이 화면에 와서 IP를 선택하고 프로세스 ID로 시작한 다음 여기에 나열되지 않은 연결이 있는지 확인할 수 있습니다.
다른 방법은 클라이언트 수입니다. 따라서 여기에 있는 서버 중 하나는 다른 서버에 비해 이 창에 나열된 클라이언트 수가 적을 것입니다. 이것이 제가 보여드리고 싶었던 중요한 도구 중 하나입니다. 그러면 초당 일부 개인화된 가져오기가 수행되고 초당 추가가 수행되는 것을 볼 수 있습니다. 그런 다음 대시 XNUMX에서 클라이언트 측으로 와서 네트워크 사용량을 볼 수 있습니다. 사전 구성된 대시보드에서 일반적으로 볼 수 없는 클라이언트의 클라이언트 CPU 사용량입니다.
그래서 이것은 다시 실시간 모니터링을 위한 것입니다. 과거 데이터는 어떻습니까? 로깅은 어떻습니까? 따라서 이 도구에도 내장되어 있습니다. 따라서 실제로 여기로 와서 로깅을 시작할 수 있으며 이것은 실제로 일부 로깅을 예약할 수도 있고 요구 사항인 경우 여기에 복제본을 표시하도록 선택할 수도 있으며 몇 가지 옵션이 있습니다. . 예를 들어 샘플 속도를 선택하고 그래프를 사용한 다음 실제로 캐시 내부에서 보고 싶은 이벤트 로그를 사용합니다. 그래서 이것은 내가 언급한 실시간 모니터링을 제공합니다. 요청 로드가 들어오면 다음을 볼 수 있습니다. 그런 다음 이 특정 시간에 확장할 수 있습니다. 채우는 데 걸리는 시간과 변경할 수 있는 이러한 개별 대시보드의 창과 함께 갈 수 있는 로그인 지원이 있다고 말했듯이.
따라서 다음의 기본 데모를 다룹니다. NCache 모니터링 도구 및 상태 확인, 클라이언트 연결 확인, 요청과 같은 일부 사용 사례에 대한 세부 정보를 제공했습니다. 여기에도 요청이 추가되고 서버의 활동도 볼 수 있습니다. 따라서 이것은 귀하의 클라이언트이고 이것은 요청 부하를 나타내는 귀하의 서버이며 그 위에 연결 클라이언트 프로세스 통계 및 연결이 있고 네트워크 및 NCP 사용에 대한 클라이언트 활동도 있습니다. 현재 네트워크 사용량이 많지 않거나 이 대시보드가 게시되지 않고 게시되는 일부 권한 문제가 있을 수 있기 때문에 네트워크 활용이 크게 나타나지 않을 것입니다. 그러나 지금까지는 모든 것이 정상적으로 보입니다. 우리는 약간의 활동을 하고 있으며 클라이언트와 서버가 건전한 방식으로 서로 상호 작용하고 있습니다. 지금까지 질문이 있으십니까? 그래서, 이것으로 우리의 NCache 함께 설치되는 모니터 도구 데모 NCache.
괜찮은! 따라서 모니터링 도구를 닫고 스트레스 테스트 도구를 계속 실행하겠습니다. 웹 애플리케이션도 사용해야 하는데 그건 나중에 할 일입니다.
이벤트 로그 및 이메일 알림 - 데모
다음으로 몇 가지 건강 관련 경고를 보여 드리겠습니다. 이를 위해 시스템의 일부가 된 다음 이벤트가 있을 때마다 정기적으로 업데이트되는 이벤트 로그 항목에 대해 설명해야 합니다. 이제 Windows 이벤트 로그로 이동하겠습니다. NCache.. 실제로 매우 권리가 있으며 모든 이벤트에 해당됩니다. 예를 들어, 우리는 캐시를 시작했고 시스템의 각 이벤트 로그는 자체 서버, 캐시 보기, NCache 서비스 또는 해당 서버의 캐시 호스트이므로 캐시를 시작했습니다. 첫 번째는 별도의 프로세스가 시작되어 여기에서 발생한 것입니다.
Windows 이벤트 뷰어 로깅
다음 이벤트 로그는 레플리카 조인트이므로 시작되고 이 레플리카 조인트가 캐시에서 성공적으로 시작된 데모 캐시를 갖게 된다는 것입니다. 그런 다음 108이 캐시에 결합되었습니다. 108 복제본이 캐시에 결합되었습니다. 그리고 이것들은 우리가 건너뛸 수 있는 몇 가지 구성 메시지입니다. 그게 다입니다. 이들은 관련이 없습니다 NCache 그러나 이러한 메시지에 관한 한 이벤트 로그에 대한 전체 정보를 제공해야 합니다. 그리고 여기서 테스트 캐시를 실제로 사용하는 시나리오를 빠르게 시뮬레이트하겠습니다. 그래서 캐시 중 하나를 시작하겠습니다. 저는 107에 있으므로 107을 시작하면 이와 관련하여 일부 이벤트 로그가 전파되는 것을 볼 수 있습니다. 따라서 이것이 완료되면 기다리십시오. 그래서 시작되었습니다. 다시 말하지만, 보기 클러스터 연결을 사용할 수 있으며 하나의 서비스만 시작되지 않았지만 어떤 상태도 없는 것을 볼 수 있습니다. 캐시가 중지되었기 때문에 연결되지 않은 것입니다. 맞습니까? 따라서 필요한 경우 모니터 클러스터를 사용하여 별도로 모니터링할 수 있습니다.
이제 이벤트 로그로 돌아갑니다. 이제 테스트 캐시가 시작되어야 하지만 해당 테스트 캐시 프로세스가 시작되기 전에 107개의 복제본이 있어야 합니다. 따라서 캐시를 시작할 때마다 캐시 프로세스가 시작되므로 이에 대한 이벤트 로그 항목이 있고 실제 상자가 실제로 시작되는 복제본이 있고 해당 복제본이 캐시 클러스터에 합류합니다. 그리고 그 일부로 추가된 정보가 있고 실제로 시작되는 데이터 수집기 세트가 있지만 현재는 내 컴퓨터입니다. 나는 그것들을 껐기 때문에 우리가 거기에 도달하고 테스트 캐시가 성공적으로 시작된 이유입니다. 당신은 당신의 응용 프로그램에 관심이 있어야합니다. 그런 다음 연결하여 다른 도구를 사용하거나 사용할 수 있는 이벤트 ID가 있습니다. NCache 그 또는 그 주위에 알림을 받을 수 있는 도구를 모니터링하십시오. 그래서 이들은 이벤트 로그입니다.
이제 이것들은 Windows에 게시되기 때문에 캐시가 시작될 때마다 중지되고 여기에 다른 노드를 추가하는 것을 보여드리겠습니다. 이벤트 로그를 통해 알림을 받지 않으며 캐시를 중지하면 이벤트 로그를 통해 알림을 받습니다. 캐시가 가득 차면 알림을 받게 됩니다. 상태 전송이 시작되면 네트워크 결함이 발생하고 두 서비스가 연결을 끊는 경우 이러한 업데이트된 이벤트가 있을 때마다 실제로 거기에서 가져옵니다. 그래서 다시 107명이 합류했습니다. 캐시가 성공적으로 시작되었으며 이제 108이 테스트 캐시에 결합되었고 108 복제본이 테스트 캐시에 결합되었습니다. 따라서 이들은 다시 기록되는 이벤트이며 이벤트 ID는 동일하게 유지되지만 메시지는 중요합니다. 따라서 알림을 받습니다. 그리고 캐시를 빠르게 중지하면 이벤트 로그가 다시 채워지는 것을 볼 수 있습니다.
따라서 대부분의 타사 모니터링은 이에 관한 것입니다. 이제 캐시를 중지했으므로 새로 고침을 다시 수행하면 몇 가지 정보가 표시되며 이는 경고입니다. 맞습니까? 복제본 조인 후 노드 XNUMX 또는 XNUMX가 테스트 캐시를 떠났기 때문입니다. 그래서 그것은 당신이 그것을 중지했거나 자체적으로 다운될 수 있기 때문에 놀라운 상황입니다. 따라서 이 경우 알림을 받게 됩니다.
그런 다음 또 다른 108개의 복제본이 다운되고 기본 107개의 복제본이 다운됩니다. 그런 다음 무시하고 캐시 중지를 성공적으로 테스트해야 하는 또 다른 항목입니다. 따라서 일반적인 시나리오에서는 중지했을 때 이 안전한 이벤트도 받게 됩니다. 그러나 경고가 표시되지만 아래로 내려가면 세부 수준이 표시되고 오류 수준이 오류로 변경되지 않습니다. 그것은 경고가 아니거나 더 이상 정보가 아닐 것입니다. 별도의 테스트 캐시 프로세스도 중지되었습니다.
따라서 Windows 이벤트 잠금을 사용하고 타사 모니터링이 있는지 확인해야 하는 정보입니다. 예를 들어 앱 다이내믹을 사용하는 고객이 있었고 이러한 이벤트를 활성화하도록 도왔습니다. 따라서 그들이 해야 할 일은 이벤트 ID를 사용하여 이벤트 로깅을 설정하고 캐시하여 귀하가 당사에 연락할 수 있도록 하는 것이었습니다. 우리는 당신에게 모든 이벤트의 목록을 줄 것입니다. NCache 기록하고 거기에서 가져옵니다. 타사 모니터링 도구를 사용하여 모니터링하고 캐시할 수도 있습니다. 그래서 나는 이것을 닫을 것이다.
가상 에이전트
이제 우리로 돌아와서 NCache 우리는 실제로 이벤트 로그에 정보를 집어넣지만 거기에서 기다리지 않고 실제로 자체 경고 시스템도 구현했으며 이러한 기능을 기반으로 하는 것이 이메일 경고라고 합니다. 이제 캐시에서 이메일 알림을 활성화하기만 하면 됩니다. 실행 중인 캐시에서도 가능합니다. 그리고 여기에 내 세부 정보를 입력할 수 있습니다(예: Ron@).alachisoft.com. 여기에서 확인해야 할 것이 있습니다. smtp.gmail.com입니다. 나는 단지 내 개인을 사용하고 있습니다… 그리고 포트도 제공하겠습니다. 이 정보를 유지합시다. 그리고 저는 로그인만 사용하겠습니다. 수신자를 사용하겠습니다.
나 자신에게 이메일을 보내고 캐시 시작 또는 캐시 중지라고 말할 것입니다. 크기가 가득 차게 됩니다. 클러스터는 분할 브레인으로 들어가고 부서집니다. 노드가 다른 서버에 합류하거나 떠날 때마다 프로세스인 상태 전송은 다음 중 하나를 수행해야 합니다. redis그것을 공물하거나 백업을 활성화하십시오. 그래서 시나리오입니다. 연결된 노드도 왼쪽 노드도 아닙니다. 맞습니까? 따라서 알림을 받을 수 있으며 여기에 와서 구성을 적용하기만 하면 됩니다.
나는 실제로 내 캐시를 위해 이것을하지 않을 것입니다. 바로 여기 이 캐시. 테스트 캐시와 모든 이벤트 설정을 위해 이미 그렇게 했습니다. 구성 적용이라고 말하고 예제를 통해 이를 보여드리겠습니다. 그럼, 이만 시작하겠습니다, 그렇죠? 107만 시작했는데 이벤트 로그를 다시 가져와서 새로 고침하면 몇 가지 정보가 있으므로 성공적으로 시작했습니다. 107명이 합류했습니다. 테스트 캐시가 성공적으로 시작되었습니다. 그리고 오류 메시지는 무시해도 됩니다.
이제 이메일 알림은 어떻습니까? 따라서 이를 위해서는 바로 여기 내 컴퓨터로 돌아와야 하며 이메일이 실행되어야 합니다. 이것을 무시하십시오. 따라서 이메일 알림의 형태로 동일한 이벤트를 받게 되지만 이번에는 NCache 해당 이벤트를 사용하고 구독한 수신자에게 이메일 알림을 보냅니다. 그래서, 당신은 그것을 볼 수 있습니다.. 첫 번째 경고, 실제로 많은 경고가 있습니다. 따라서 테스트 캐시에 107개를 결합한 다음 바로 여기 이 창을 사용하겠습니다. 열 필요가 없습니다. 성공적으로 시작되었습니다. 108명이 합류했다. 사실, 이것은 오래된 이벤트이므로 1133을 사용하겠습니다. 예, 이러한 경고가 열려 있었기 때문에 이를 기반으로 테스트를 수행했습니다.
좋아요! 이제 1133에 초점을 맞추겠습니다. 따라서 107 복제본이 조인한 다음 테스트 캐시가 성공적으로 시작되었습니다. 여기로 돌아와서 빠르게 108을 시작하고 이것이 실제로 이메일 경고와 이벤트 로그 항목을 나란히 트리거한다는 것을 보여드리겠습니다. 이제 이것은 우리가 구현한 SMTP이지만 배후에서 이벤트 로그를 사용하고 있습니다. 맞습니까? 따라서 그렇게 할 수도 있습니다. 다시 한 번 여기서 새로고침하겠습니다. 항목이 있습니까? 따라서 106과 106은 다시 두 번 기록되었고 여기로 돌아와서 여기에서 보내기 수신을 수행하면 상태 이전 및 기타 이벤트도 있기 때문에 두 개 이상의 이메일을 더 받을 수 있어야 합니다. 캐시에 일부 데이터가 있는 경우 해당 이벤트도 있을 것입니다. 자, 여기 있습니다. 그래서 108 테스트 캐시가 시작되었습니다. 테스트 캐시가 성공적으로 시작되었고 이것은 108에 대한 것입니다. 맞습니까? 그래서 더 이상 이메일이 없는지 확인하기 위해 보내기 받기를 한 번 더 수행합니다.
따라서 문제가 발생할 경우 시스템 관리자에게 알리고 실제로 문제를 시뮬레이션해 보겠습니다. 노드 107가 다운되면 어떻게 될까요? 또는 연결이 끊어진 경우. 여기에서 연결 끊김을 실제로 시뮬레이트할 수는 없지만 노드가 다운되는 것을 시뮬레이트할 수 있으며 방금 완료했습니다. 따라서 우선 이벤트 로그에 실제로 이벤트가 표시됩니다. 경고가 있습니다. 그리고 이메일 알림이 놀림을 받는지 살펴보겠습니다. 나는 그것이 매우 간단하기를 바랍니다. 건강에 관한 한 환경 모니터를 사용하고 얻을 수 있는 몇 가지 기본 기능을 강조하고 있습니다. 따라서 실제로 노드가 떠난 후 107, XNUMX 이벤트 로그가 생성된 것을 확인할 수 있습니다. 따라서 필요에 따라 수신자 목록을 여기에 입력하거나 그룹일 수 있지만 한 줄에 수신자를 하나씩 지정해야 합니다. 괜찮은?
그래서 다른 하나는 support@alachisoft.com 또는 kal@일 수 있습니다.alachisoft.com. 그래서 실제로 거기에서 가져갈 수 있습니다. 이메일 알림을 시작하는 것이 얼마나 간단합니다. NCache 모니터 도구. 이벤트 로그를 다루었습니다. 우리는 다루었습니다 NCache 이메일 알림.
NCache 로그 - 데모
다음은 NCache 로그는 약간 고급 주제이지만 로그에 가능한 한 많은 시간을 할애하고 거기서부터 시작할 수 있습니다.
테스트 캐시는 내가 사용하고 있는 것이기 때문에 이 캐시를 중지하겠습니다. 이 캐시가 중지되는 동안 응용 프로그램을 열겠습니다. 폴더 구조에 대해 유감스럽게 생각합니다. 다른 환경에서 복사해왔으니..알았어! 이제 Visual Studio를 열어 보겠습니다. 이 섹션에서는 필요하지 않지만 캐시가 중지되기를 기다리는 동안 준비하고 로깅 기능을 보여주기 위해 열어 두겠습니다. NCache. 웹사이트를 엽니다. 이것은 어떤 이유로 매우 느립니다. 그 동안 여기로 돌아올 수 있도록 기다립니다. 비쥬얼 스튜디오에서 그러지 말았어야 했기 때문이라고 생각합니다. 어쨌든, 내가 그것을 닫을 수 있는지 보자. 괜찮은! 다시 돌아와서 테스트 캐시를 중지했습니다. 맞습니까?
따라서 로그인 기능을 보여 드리겠습니다. NCache. 따라서 로그는 유지되며 이들은 캐시 로그입니다. 적어도 이것들은 제거할 수 있습니다. 중지된 캐시는 이제 실제로 삭제할 수 있습니다. 그래서 새로 시작하겠습니다. 실행 중인 캐시입니다. 로그 파일을 삭제하지 마세요. 이 특정 데모를 위해 방금 수행했습니다. 여기에서 하나의 노드를 시작하고 서버 측에서 생성된 로그 파일을 보여주고 이에 대한 세부 정보를 제공합니다. 로그 파일을 이해하려면 클러스터링 및 프레임워크에 대한 고급 정보가 필요합니다. NCache. 그래서 몇 가지 기본 사항에 대해서만 이야기하겠습니다.
LogViewer 도구를 사용한 로그 분석
이제 캐시를 만들었고 테스트 캐시와 복제본을 시작했으므로 이 기회를 사용하여 로그 뷰어에 대한 로그를 실제로 열겠습니다. 따라서 빈, 도구, GUI로 이동하면 함께 설치되는 로그 뷰어 도구가 있습니다. NCache. 모든 메모장, 워드패드, 메모장++를 사용할 수 있지만 이것은 실제로 읽기, 타임스탬프, 로거 수준으로 정렬한 다음 메시지를 정확히 찾아내는 데 도움이 될 수 있는 것입니다. 그럼 이만 열어보겠습니다. 동일한 디렉토리로 이동합니다. 여기에서 테스트 캐시를 열면 거기에 있는 모든 로그를 볼 수 있습니다. 그래서 우리는… 그런데 이것은 매우 흥미로운 도구입니다. 다른 필드와 노드를 사용할 수 있습니다. 맞습니까? 그런 다음 이를 기반으로 필터를 제공할 수 있습니다. 따라서 여기에 필터가 지정됩니다.
서버 측 로그
그래서 기본적인 정보만 알려드리겠습니다. 작동 매개변수는 107, 7805입니다. 복제본은 항상 7806입니다. 포트를 지정하는 것이 무엇이든 다음 포트는 복제본용입니다. 따라서 첫 번째 서버인 보기를 설치합니다. 따라서 7805가 유일한 서버입니다. 따라서 서버가 시작될 때마다 클러스터링 계층과 대화하고 보기를 가져옵니다. 따라서 자신을 코디네이터로 사용하여 설치하고 7805 107이 자체 보기를 사용하고 있음을 알 수 있습니다. 보기 ID는 0이고 회원이 이벤트에 참여했습니다. 이들은 다시 관련된 이벤트 로그입니다. 그런 다음 여기에 많은 정보 메시지가 표시되고 복제본이 여기에 조인되었을 것입니다. 7805 그리고 이제 107과 7806을 결합한 것을 볼 수 있습니다. 따라서 복제본이 결합되었습니다.
따라서 각 서버가 시작되고 사용 가능한 다른 서버를 찾으려고 시도합니다. 사용 가능한 서버가 없으면 첫 번째 서버로 시작한 다음 복제본을 시작하고 하나의 노드 캐시 클러스터를 만듭니다. 그런 다음 캐시, 상태 전송 이벤트 및 캐시 초기화가 표시됩니다. 성공적으로 시작되었습니다. 따라서 여기에서 이 이벤트 전에 이와 같은 오류 메시지가 표시되는 경우 다른 서버에 연결을 시도하고 있고 108이 아직 시작되지 않았기 때문에 다른 서버가 아직 거기에 없을 수 있으므로 걱정하지 마십시오. 그래서 연결을 시도했지만 응답을 받지 못했습니다. 이 시점에서 저는 여기로 빠르게 이동하여 새로운 인스턴스인 스트레스 테스트 도구를 사용하겠습니다. 클라이언트 연결 이벤트도 보여드리겠습니다. 그런데 모든 이벤트 로그, 모든 창, 우리가 설정한 이메일 알림은 그대로 유지됩니다.
그래서 그냥 닫고 돌아와서 내가 말했듯이 notepad++로도 열 수 있습니다. 메모장으로 동일한 도구를 열면 됩니다. 이제 동일한 로그 파일이 열리지만 이번에는 클라이언트도 시작했기 때문에 끝까지 클라이언트 연결 상자도 표시됩니다. 여기로 가져오겠습니다. 따라서 Box의 IP, Box의 이름, GUI 및 프로세스 ID에 대한 데모가 캐시에 연결됩니다. 따라서 하나의 서버와 연결된 클라이언트를 볼 수 있습니다. 이제 시나리오는 캐시에 문제가 있는지 확인하는 방법일 수 있습니다. 따라서 이 시점 이후에 오류 메시지가 표시되며 이는 해당 오류 메시지를 나타냅니다. 이 앞의 오류 메시지는 단지 발견일 뿐입니다. 따라서 이러한 오류 메시지가 많이 표시되기 전까지는 매우 정상입니다. 몇 가지 오류가 표시되지만 이는 검색 메시지일 뿐입니다.
이제 이 캐시를 시작하고 이 서버의 로그와 서버에 대한 로그를 보여주고 어떻게 변경되는지 보여드리겠습니다. 이제 이 작업이 시작되었으므로 여기로 돌아와 새로고침되는지 확인하고 새로고침되지 않았으므로 여기로 돌아와서 이 서버의 로그를 살펴보겠습니다. 이제 108이 시작되었습니다. 따라서 더 많은 활동을 볼 수 있습니다. 마지막 항목은 어디에 있었습니까? 한번 보도록 하죠. 좋아요! 그래서, 우리는 이것을 손실 항목으로 가지고 있었습니다, 그렇죠? 이제 108의 조인 권한과 조인을 시작했습니다. 107은 107, 107 및 108이 있는 보기를 설치했습니다. 이제 108 복제본도 조인하고 107, 107 복제본 108, 108 레플리카. 그리고 상태 이전이 시작되고 종료되어 모든 것이 순조롭게 진행되는 것을 볼 수 있습니다. 그래서 새 서버가 합류했고 이 모든 것이 이전에 표시된 것처럼 이벤트 로그에 기록되고 있습니다.
이제 서버 2의 로그 파일을 보여주어 자세한 정보를 얻을 수 있도록 하겠습니다. 다른 서버는 어떻게… 다른 서버가 시작되었고 서버 하나는 이미 거기에 있었습니다. 그래서 로그 파일은 보통 날짜를 수정해서 시작해서 최신 파일이 맨 위에 오도록 보여드리겠습니다. 그러길 바랍니다. 테스트 캐시는 어디에 있습니까? 자! 이 상자에서 실행 중인 다른 캐시도 있습니다. 시간이 안맞는거 같은데 한번 봐주세요. 괜찮은! 여하튼 시간이 부족하기 때문에 이것을 예로 들어보겠습니다. 그래서 시간이 걸릴 것입니다. 그래서 108이 시작되었고 이때 실제로 요청을 하게 되었습니다. 그렇다면 단일 노드 였을 것입니다. 맞습니까? 그러나 이 경우 실제로 조인 권한이 표시됩니다. 그래서 나는 이것을 실제로 사용하지 않을 것입니다. 로그 파일을 볼 수 없습니다. 알겠습니다!
나는 무슨 일이 일어나고 있는지 압니다. 로컬 로그 파일 폴더를 보고 있으니 발생하는 로그 파일이 있겠죠? 따라서 수정된 날짜를 보면 이것이 실제 로그 파일입니다. 사과드립니다. 괜찮은! 이제 108이 시작되었고 실제로 시도했지만 실패했음을 알 수 있으므로 실제로 여기에 몇 가지 오류 메시지가 표시됩니다. 복제본이 없기 때문에 이 오류가 발생했습니다. 복제본이 없으므로 첫 번째 복제본이 아닙니다. 107이 보입니다. 이미 시작되어 보기를 제공한 다음 상태 이전이 시작되었습니다. 이들은 몇 가지 버킷 정보이며 구성원은 캐시 클러스터에 가입합니다. 좋습니다!
따라서 로그 파일을 보는 것이 얼마나 간단한지 말씀드린 것처럼 사용 사례에 따라 복잡해질 수 있습니다. 시밍 중인 문제와 복제 로그 파일도 있습니다. 따라서 그녀가 실제로 우리와 오류를 공유하는 것이 좋으며 우리는 실제로 당신이 그것을 더 잘 이해하도록 도울 수 있습니다. 따라서 타임라인이 있는 각 서버에서 로그 파일에 기록된 문제를 볼 수 있습니다. 빨리 돌아오겠습니다. 시간이 좀 더 남아 있으므로 실제로 다른 시나리오를 보여 드리겠습니다. 모니터 도구를 열 수 있는지 확인하겠습니다.
API 로그
이제 모니터링 도구 내부에 다른 종류의 로그 파일이 있으므로 이 특정 캐시에 대해 사용하겠습니다. 새 대시보드를 만들어 보겠습니다.
괜찮은! 서버가 일부 요청을 완료하는 데 더 많은 시간이 걸리거나 속도가 느려지는 시나리오가 있는 경우 이를 해결하는 방법은 무엇입니까? 따라서 한 가지 방법은 애플리케이션의 성능 카운터와 NCache 솔직히 말해서 다음 섹션 마지막 섹션인 perf-mon 카운터입니다. 그러나 이 로그 파일은 실제로 이 API 로그가 있음을 정확히 파악하는 데 도움이 될 수 있습니다. 따라서 모니터 도구를 열고 API 로그를 드래그 앤 드롭하면 기본 설정을 사용하여 실제로 여기에 정보를 기록하므로 파일 로깅 활성화라고 말하고 켜고 실행해 보겠습니다.
따라서 테스트를 시뮬레이트해야 합니다. 테스트에 15분이 걸리고 속도가 느려지는 특정 시간이 있거나 어떤 응용 프로그램이 속도 저하를 일으키는지 확실하지 않은 경우 프로덕션 환경에서 문제를 재현한다고 가정합니다. 속도 저하를 유발하는 응용 프로그램 내의 방법이 무엇인지, API 로그의 도움을 받아 실제로 이를 정확히 찾아낼 수 있습니다. 따라서 이것을 실행하기만 하면 됩니다. 모든 정보를 덤프한 다음 문제가 재현되면 중지한 다음 타임스탬프가 표시되는 여기를 통해 검토합니다. 서버 노드. 요청이 시작된 클라이언트, 클라이언트 ID 및 실행 시간. 따라서 이 실행 시간이 여기서 가장 중요한 요소입니다. 이 시점에서 밀리초 미만이지만 부하를 시뮬레이션하고 /M 1 024에 대한 테스트 캐시가 있는 시나리오를 사용하여 스트레스 테스트 도구를 다시 말하면 이것은 확실히 더 큰 값을 사용하게 될 것입니다. 맞습니까? 0.03 보이시죠? 0.07 그래서… 다른 스트레스 도구를 닫겠습니다. 응! 이제 알 수 있습니다. 시간이 많이 흘렀죠? 0.02 맞죠? 그리고 실제로 서버 측에 기록되는 모든 오류를 볼 수 있습니다.
따라서 모든 실패, 실패는 로그 파일에 기록될 수 있는 명백한 것이지만 이 기능의 도움으로 속도 저하를 매핑할 수 있습니다. 다시 여기로 돌아가서 이 API 로그 폴더에는 데이터의 기록 추적을 유지하는 로그 파일이 있습니다. 따라서 처음 몇 개의 평균은 0.02, 0.01이고 끝으로 갈수록 값이 증가하는 것을 볼 수 있습니다. 맞습니까? 따라서 이 특정 호출이 느린 시간에 대한 표시를 제공합니다. 나는 방법을 검증해야 하고 당신은 당신의 애플리케이션 내에서 그 방법과 연관시켜야 합니다. 따라서 이것이 고객 환경을 디버깅하는 데 항상 사용할 수 있는 것이라고 생각합니다. 시간을 확인하고 우리 앞에서 문제를 재현하도록 요청하고 로그를 활성화한 다음 클라이언트 측 로그와 결합할 수 있습니다. 클라이언트 설치 내에서 로그를 지정할 수 있습니다. 예를 들어 클라이언트 부분으로 이동하면 NCache 웹 서버가 있는 클라이언트 시스템에는 이 활성화 로그가 있습니다. 맞습니까?
클라이언트 측 로그
따라서 각 캐시에는 켤 수 있는 클라이언트 로그 활성화 플래그가 있습니다. 따라서 이것은 실제로 클라이언트 측의 로그 파일도 생성합니다. 지금까지 본 것과 유사한 로그 파일입니다. 그래서 로깅 측면에서 도움이 된다고 생각합니다. 10분 정도 더 시간을 보낸 다음 성능 카운터에 대해 결론을 내리겠습니다. 이것이 우리가 가진 가장 중요한 섹션이기 때문입니다.
NCache 성능 모니터링(시나리오)
성능 모니터링을 수행하는 방법 NCache? 너무 많은 정보가 아니길 바랍니다. 나는 그것을 기본으로 유지했지만 시나리오는 일상적인 사용 사례와 일치하는 것입니다.
PerfMon을 통한 실시간 모니터링
이제 성능 모니터링으로 돌아가서 NCache 두 종류의 카운터를 제공합니다. 이것은 PerfMon 카운터이므로 PerfMon이라고 말하고 성능 모니터가 내부에 있기를 바랄 수 있습니다. NCache 여기를 닫고 이 도구를 빠르게 실행하여 시간을 절약하겠습니다. 따라서 성능 카운터를 열면 NCache 카테고리 맞죠? 아래에 NCache 범주에는 필요한 모든 카운터가 있습니다. 평균은 매우 중요합니다. 이것은 캐시에 추가, 가져오기, 삽입을 위한 평균 시간을 제공합니다. 그래서 저는 그냥 이 모든 것을 사용할 거에요, 그렇죠? 그리고 추가를 선택하고 확인을 선택하면 이 성능 평균을 보여드리겠습니다.
따라서 가져오기의 평균 마이크로초는 27마이크로초이고 삽입의 평균 마이크로초는 약 65마이크로초입니다. 그러나 클라이언트는 어떻습니까?
따라서 작업을 완료하는 데 걸리는 시간을 나타내는 클라이언트 측 카운터를 살펴보겠습니다. 그래서, 당신은 선택 NCache 클라이언트 범주에서 클라이언트에 대한 테스트 캐시를 선택한 다음 추가를 선택합니다. 그래서 여기 아래에서 볼 수 있습니다. NCache 클라이언트 섹션도 마찬가지이며 이것이 가장 중요합니다. NCache 클라이언트측 수행자 추정. 그것은 항목 크기를 제공하므로 1024입니다. 가져오기당 평균 마이크로초 718을 제공합니다. 이는 전체 시간과 응용 프로그램이 응용 프로그램 내부에서 직렬화하는 데 걸린 시간입니다. wire, 거기에 저장되어 서버 시간이 포함된 다음 다시 돌아와 역직렬화됩니다. 그래서 수술 시간입니다. 가져오기의 경우 역직렬화입니다. 삽입의 경우 직렬화도 마찬가지이며 실제로 삽입의 경우 직렬화당 평균 마이크로초, 페치의 경우 역직렬화당 평균 마이크로초를 볼 수 있습니다.
그리고 이들에 대한 로그를 활성화할 수도 있습니다. 바로 지금 제가 실제로 그렇게 할 것입니다. 내가 문을 열 수 있는지 보자. 어떤 이유에서인지 당신이 나에게 죽을 수도 있지만, 내가 그렇게 할 수 있는지 보자. 그리고 이 특정 시나리오에서 제가 염두에 두고 있는 것은 웹 애플리케이션이 있다는 것입니다. 이것은 뭔가를 하고 있습니다... 내가 바라고 있던 웹 애플리케이션이 있습니다... 좋아요! 질문이 있습니다. 이것들을 할 수 있습니까? NCache 카운터에 원격으로 액세스할 수 있습니까? 물론! 나는 항상 서버와 클라이언트에서 카운터에 액세스하므로 이러한 서버에 원격으로 액세스할 수 있는 경우 perf-mon 액세스가 허용됩니다. 실제로 그렇게 할 수 있습니다. 그래서 문제가 아닙니다. 따라서 일반적으로 이러한 모든 작업을 처리하는 모니터링 서버로서 하나의 서버입니다. 미리 Visual Studio를 열고 응용 프로그램을 생성했어야 하는데 그러지 않아서 문제가 발생했습니다. 이번에는 이것이 효과가 있기를 바랍니다. 자! 나는 우리가 실제로 거기에 없다고 생각합니다. 그래서, 내 프로젝트의 디렉토리를 넣겠습니다... 참아주세요. 잠시 시간을 내겠습니다. 이것은 매우 흥미로운 부분입니다. 이건 정말 보여드리고 싶어요. 이것이 픽업되는지 봅시다. 자!
PerfMon 데이터 수집기 세트 로깅
이제 이 응용 프로그램은 다양한 개체 크기로 실험할 수 있는 방식으로 설계되었습니다. 맞습니까? 그리고 이를 바탕으로 성능 카운터를 기록하고 개체 크기가 어떻게 증가하고 성능이 떨어지는지 보여드리겠습니다. 따라서 실제로 응용 프로그램의 사용 사례, 알림을 받는 방법 또는 응용 프로그램 문제가 있을 때 알 수 있는 방법을 제시합니다. 그래서 제가 할 일은 로깅을 시작하는 것입니다, 맞죠? 따라서 스트레스 도구를 사용하여 캐시에 연결할 수 있는지 확인하겠습니다. XNUMX~XNUMX분만 더 시간을 내겠습니다. 제 시간에 괜찮은지 알려주세요. 문제가 있으면 항상 할 수 있습니다. 그래서 저는 우리가 잘하고 있다고 생각합니다. 방금 실행해서… 자! 그리고 이제 여기에서 내 기계를 사용할 것입니다. 그리고 perf-mon 카운터의 로깅을 시작하고 이를 위해 실제로 사용자 수집기 집합을 사용할 수 있습니다. 실시간 모니터링을 위해 perf-mon 카운터가 있죠? 실제로 여기를 클릭하고 생활에 추가할 수 있습니다. 그러나 그것은 문제를 해결하는 데 실제로 도움이 되지 않습니다. 애플리케이션이 느리게 실행될 때 이를 해결하는 방법은 무엇입니까?
그래서 데이터 수집기 집합을 만들면 됩니다. 맞습니까? 테스트 11 맞죠? 수동으로 생성하고 성능 카운터를 사용하며 샘플링 간격을 XNUMX초로 사용하고 추가합니다. NCache 이것이 내 응용 프로그램 상자이기 때문에 클라이언트 카운터가 정확해야 합니다. 다른 것을 사용할 수도 있습니다. 그냥 추가하겠습니다 NCache 카운터, NCache 고객. 이 테스트 캐시가 시작되도록 스트레스 도구를 한 번 더 사용하겠습니다. 자! 추가하고 이제 스트레스 도구를 닫을 수 있습니다. 확인을 선택하고 그동안 희망합니다… 이로 인해 문제가 발생했습니다.
그래도! 따라서 이 찾아보기에서 신속하게 다음을 선택하고 쉽게 선택할 수 있는 위치를 선택합니다. 예를 들어 이것을 사용하고 확인, 다음, 저장 후 닫기를 선택하겠습니다. 그래서 테스트 11이 생성되었습니다. 실제로 여기로 와서 수집기 세트를 시작할 수 있으며 그동안 어떤 이유로 내 웹 응용 프로그램이 실행되지 않았습니다. 그래서 한 번만 더 실행하겠습니다. 흥미롭군... 알았어! 무슨 일이 있었는지 보여주려고 합니다. 실제로 실행했어야 했습니다. 그것이 내가 어제 한 일이고 절대적으로 잘 작동하므로 한 번만 시도하겠습니다. 파이프라인 모드 문제가 있는 것 같아서 이것으로 실행되지 않을 것이므로 그냥 건너뛰겠습니다. 내가 할 수 있는 것은 내가 어제부터 사용한 이것의 데이터를 보여줄 수 있다는 것입니다. 그래서 제가 여기 온다면, 이것의 디자인은 우리가 세 종류의 테스트를 하는 방식으로 되어 있습니다, 그렇죠? 10KB, 50KB, 100KB 및 10KB이므로 500KB 개체를 통과하면 실제로 10KB의 가져오기 및 삽입 로드를 시뮬레이트하므로 10KB, 10KB, 50KB, 100KB 및 그러면 카운터를 기록하겠습니다. 맞죠? 따라서 E 내부에서 하나를 테스트합니다.
좋아요! 자! 그래서 이 테스트를 실행했고 정말 문제를 보여주고 싶었습니다. 컨트롤+A라고 말하고 선택한 카운터를 숨긴 다음 테스트 캐시를 위해 실제로 다른 모든 카운터도 소비합니다. 따라서 먼저 평균 항목 크기를 확인하므로 첫 번째 테스트는 1킬로바이트, 10킬로바이트, 다시 10킬로바이트, 50킬로바이트, 400킬로바이트, 마지막으로 500킬로바이트를 실행했습니다. 그래서 항목 크기를 설명합니다.
이제 가져오기에 걸린 평균 시간을 살펴보겠습니다. 따라서 가져오기당 평균 마이크로초라는 카운터가 있습니다. 시간이 지날수록 걸리는 시간이 늘어난 걸 볼 수 있겠죠? 따라서 항목 크기를 추가함에 따라 항목 크기가 증가했기 때문에 가져오기 및 동일합니다. 해당 항목을 가져오는 데 걸리는 시간도 그에 따라 증가합니다. 그러나 가져오는 중이므로 역직렬화 오버헤드가 있어야 합니다. 여기에서 다룹니다. 따라서 대부분의 시간은 실제로 역직렬화에 소비되므로 실제로 그와 함께 역직렬화를 계획할 수 있습니다. 그래서 이것들은 역직렬화에 대부분의 시간을 소비했고 그것이 느린 이유입니다.
이제 인서트 평균, 인서트당 평균 마이크로초를 살펴보겠습니다. 이 값도 다음에 따라 달라지는 것을 볼 수 있습니다… 따라서 삽입에 시간이 걸리고 항목 크기를 추가함에 따라 삽입에 시간이 걸립니다. 따라서 응용 프로그램에서 응용 프로그램이 느려지는 것을 확인했다면 맞습니까? 따라서 이러한 카운터를 기록하고 직렬화인지 역직렬화인지, 가져오기인지 삽입인지 제거인지 또는 실제로 증가하는 요청 대기열 크기인지 확인합니다. 따라서 활동이 있을 때마다 요청 대기열 크기에 일부 항목이 있고 처리할 때마다 해당 항목이 지워지는 것을 볼 수 있습니다. 따라서 삽입의 경우 직렬화당 평균 마이크로초를 살펴보겠습니다. 이것이 오버헤드입니다. 빨간색과 색상으로 만들겠습니다. 실제로 평균에 영향을 미치는 것은 직렬화라는 것을 알 수 있습니다.
따라서 클라이언트 측에서 삽입, 가져오기, 제거당 전체 평균 마이크로초는 애플리케이션이 나타내는 성능을 추정하는 동시에 이러한 카운터를 기록한 다음 살펴볼 수 있습니다. 불행히도 내 응용 프로그램을 실행할 수 없었지만 이것은 어제부터입니다. 어제 웹 세미나에서 성공적으로 실행했고 10KB로 다시 10KB, 50KB, 100KB 및 500KB로 실행했습니다. 따라서 우리는 성능 간의 다양한 차이를 볼 수 있었고 이것이 카운터를 확인하고 캐시하는 모든 성능 문제를 해결하는 방법이며 이것은 애플리케이션 카운터와 결합되어야 하므로 항상 애플리케이션 카운터를 함께 선택해야 합니다.
예를 들어 웹 응용 프로그램에 대한 ASP.NET 카운터를 볼 수 있습니다. 맞습니까? ASP.NET 응용 프로그램. 일반적으로 .NET CLR 메모리의 경우 메모리 경합 애플리케이션이 다운될 수 있는지도 확인합니다. 따라서 시스템 카운터를 기록한 다음 로그를 기록할 수 있습니다. NCache 내가 한 것처럼 카운터를 만든 다음 거기에서 가져 와서 성능 모니터링 섹션을 완료하십시오.
결론
정규 시간 표시보다 약 XNUMX분 앞서 있습니다. 문제 때문에 괜찮기를 바랍니다. 이것은 실습 웨비나이므로 이러한 문제를 볼 수 있을 것으로 예상되지만 간단히 요약하면 캐시 생성을 통해 NCache 모니터링 도구, 상태, 이벤트 로그 항목, 이메일 알림, NCache 로그, 로그 분석 도구, 클라이언트 측 API 로그 그리고 서버 측에서 사용할 수 있는 perf-mon 카운터도 보여 드렸습니다. 서버 측 카운터는 서버 측 통계를 위해 존재하고 클라이언트 측 카운터는 클라이언트 측 통계를 위해 존재합니다. 카운터를 설명하는 데 많은 시간을 할애하지 않았습니다. 그렇게 했어야 했지만 같은 주제에 대한 다음 웨비나에서 그렇게 할 것입니다.
그리고 끝으로 스파이크를 사용하거나 perf-mon 카운터 로깅을 NCache. 유익하고 흥미로웠기를 바랍니다.