Lync Server 2013 성능 모니터링Monitoring Lync Server 2013 performance

 

마지막으로 수정 된 항목: 2014-05-15Topic Last Modified: 2014-05-15

Lync Server 2013 성능은 사용자 프로필, 시스템 아키텍처, 소프트웨어, 하드웨어 구성 요소, 게이트웨이 및 전화 통신 장비, 네트워크 연결 및 성능, Windows Active Directory 서비스 구성 및 성능과 같은 타사 통합 지점과 Windows 운영 체제 기능에 영향을 받습니다.Lync Server 2013 performance is affected by various factors such as user profiles, system architecture, software, hardware components, third-party integration points such as gateways and telephony equipment, network connectivity and performance, Windows Active Directory service configuration and performance in addition to the Windows operating system functionality.

Lync Server 2013 배포 성능은 구현 되는 서버 소프트웨어 및 하드웨어를 중심으로 합니다.At the core of a Lync Server 2013 deployments’ performance is the server software and hardware it is implemented on. 예를 들어 프런트 엔드 서버에는 예상 되는 (단기) 사용자 부하를 처리할 수 있는 충분 한 하드웨어 리소스가 있어야 합니다.As an example, a front-end server must have sufficient hardware resources to cope with the expected (short-term) user load. 해당 하는 프런트 엔드 서버가 1만 사용자에 게 서비스를 제공 해야 하는 경우 적절 하 게 구성 된 서버가 예상 되는 로드 요구 사항을 충족 해야 최종 사용자에 게 가장 적합 한 환경을 유지할 수 있습니다.If a respective front-end server is required to provide services to 10 thousand users, then an adequately configured server must meet the expected load requirements to ultimately help ensure the best possible end-user experience.

따라서 구현 된 서버 인프라에 일상적인 최대 부하 요구 사항에 적합 한 하드웨어 리소스가 있는지 여부를 측정 하려면 서버 성능이 매우 중요 합니다.Monitoring server performance is therefore extremely important to gauge whether the implemented server infrastructure have suitable hardware resources for the day-to-day peak-load requirements. 모니터링 서버 성능은 최종 사용자 환경에 영향을 주기 전에 관리자가 정정 작업을 적용할 수 있도록 하는 시스템 병목 현상을 식별 하는 데 도움이 됩니다.Monitoring server performance helps identify system bottlenecks allowing administrators to apply corrective action before the end-user experience is affected. 장기적 용량 계획에는 성능 데이터를 사용 해야 합니다.The performance data should be used for long-term capacity planning.

확인할 모든 성능 개체 및 카운터에 대 한 자세한 내용은 System Center Operations Manager를 사용 하 여 Lync Server 2013을 모니터링하는에 연결 되어 있지만, 사용자가 수행 해야 하는 일부 성능 카운터는 관리자에 게 시스템 성능을 빠르게 확인할 수 있습니다.While detailed information on all performance objects and counters to be observed is linked to in Monitoring Lync Server 2013 with System Center Operations Manager, some performance counters that you should follow can provide administrators a quick view of the system performance:

  • 프런트 엔드 서버의 전체 시스템 상태를 추적 하려면 프로세서의 프로세서 시간을 검사 하는 것이 좋습니다 \ .To track overall system health of the front-end server, a good starting point is to check Processor\% Processor Time. 값은 항상 80% 미만 이어야 합니다.The value should always be below 80 percent.

  • 프런트 엔드 풀에 사용 되는 백 엔드 SQL Server 데이터베이스 소프트웨어 인스턴스의 성능을 추적 하려면 다음 성능 카운터를 모니터링 합니다.To track the performance of the back end SQL Server database software instance used by the Front End pool, monitor the following performance counters:

    LC: USrv-00-DBStore \ usrv – 002 – Queue Latency (밀리초)LC:USrv – 00 – DBStore\Usrv – 002 – Queue Latency (msec)

    LC: USrv-00-DBStore \ usrv – 0 04-저장 프로시저 대기 시간 (밀리초)LC:USrv – 00 – DBStore\Usrv – 0 04– Sproc Latency (msec)

    정상 상태의 서버에는 < 100 밀리초의 대기 시간 값이 표시 됩니다.The healthy server at steady state should show <100 ms latency values. 대기 시간이 12 초에 도달 하는 경우 제한 메커니즘은 프런트 엔드 서버가 백 엔드에 대 한 제한 요청을 시작 함을 의미 합니다.The throttling mechanism will engage when latency reaches 12 seconds, which means the front-end server starts throttling requests to the back end. 이로 인해 클라이언트에서 사용 하지 않은 503 서버의 통화 오류 메시지가 표시 됩니다.This causes clients to start to receive a 503 Server too busy error message.

  • 프런트 엔드 서버에서 처리 시간을 추적 하려면 다음 카운터를 모니터링 합니다.To track the processing time at the front-end server, monitor the following counter:

    LC: SIP-07-부하 관리 \ sip-000-받는 메시지에 대 한 평균 대기 시간LC:SIP - 07 - Load Management\SIP - 000 - Average Holding Time For Incoming Messages

    프런트 엔드 서버의 또 다른 제한 메커니즘은 프런트 엔드의 처리 시간이 높을 때부터 시작 하는 시간입니다.This is another throttling mechanism on the front-end servers, this time starting when the processing time on the front end is high. 평균 처리 시간이 6 초를 초과 하면 서버가 제한 모드로 전환 되 고 클라이언트 연결당 해결 되지 않은 트랜잭션이 하나만 허용 됩니다.If average processing time is more than six seconds, the server goes into throttling mode and only allows one outstanding transaction per client connection.

  • SQL 백 엔드 서버에서 메모리 문제를 추적 하려면 다음 카운터를 모니터링 합니다.To track memory issues at SQL Back End Server, monitor the following counter:

    SQL Server 버퍼 관리자 \ 페이지 수명 예상SQL Server Buffer Manager\Page life expectancy

    낮은 값 (예를 들어, 3600 초 미만, 높은 대기 시간 쓰기/초 및 검사점 페이지/초)은 메모리 압력을 나타냅니다.A low value, below 3600 seconds (together with high latency writes/sec and checkpoint pages/sec) indicates memory pressure.

확인할 추가 카운터Additional Counters to View

프런트 엔드 서버의 전체 상태를 나타내는 훌륭한 지표 인 몇 가지 주요 카운터가 있습니다.There are several key counters that are good indicators of overall health from the front end server. 이 목록은 포괄적인 목록이 아니며 근본적인 원인을 파악 하기 위한 것이 아닙니다.This is not a comprehensive list and is not meant to identify root cause. 이러한 카운터를 사용 하 여 서버 상태를 빠르게 확인할 수 있습니다.These counters will let you perform a quick check on your server health. 풀의 각 서버에서 이러한 카운터를 확인 하는 것이 좋습니다.We recommend verifying these counters on each of the servers in the pool. 서버가 정상 상태 이면 이러한 카운터 값이 무엇 인지 이해 하는 것이 중요 합니다.It is important to understand what these counter values are when your server is healthy. 사용자 환경에 문제가 발생 했을 때 변경 된 내용을 이해 하려면 기준이 필요 합니다.A baseline is required to understand what changed when the user experience is degraded.

프런트 엔드 서버는 시스템의 다른 곳에서 발생 하는 병목 현상으로 인해 발생할 수 있는 문제를 나타낼 수 있습니다.The front-end server can indicate issues that may be caused by bottlenecks elsewhere in the system. 즉, 전체 시스템 상태를 볼 때부터 시작 하는 것이 가장 좋은 위치입니다.This means that it is the best place to start when looking at overall system health.

먼저 검토 하는 두 가지 추가 카운터는 다음과 같습니다.Two additional counters to review first are as follows:

LC: USrv-00-DBStore \ usrv-002-큐 대기 시간 (밀리초)LC:USrv-00-DBStore\Usrv-002-Queue Latency (msec)

LC: USrv-00-DBStore \ usrv-004-저장 프로시저 대기 시간 (밀리초)LC:USrv-00-DBStore\Usrv-004-Sproc Latency (msec)

큐 대기 시간 카운터는 큐에서 백 엔드로 요청이 소비한 시간 및 저장 프로시저 대기 시간을 나타내며 백 엔드에서 요청을 처리 하는 데 걸린 시간을 나타냅니다.The queue latency counter represents the time that a request spent in the queue to the back end and the Sproc latency represents the time that it took for the back end to process the request. 어떤 이유로 든 백 엔드에서 디스크, 메모리, 네트워크 및 프로세서가 문제가 되는 경우 큐 대기 시간 카운터가 더 높아집니다.If, for any reason, disk, memory, network, and processor on the back end are in trouble, the queue latency counter will be high.

또한 프런트 엔드와 백 엔드 사이에 네트워크 대기 시간이 긴 경우에도 높은 시간을 사용할 수 있습니다.It can also be high if there is high network latency between the front end and the back end. 그렇다면 허용 되는 큐 대기 시간은 어떻게 됩니까?So what is acceptable queue latency?

12 초 이내에 프런트 엔드 서버는 백 엔드 서버에 대 한 제한 요청을 시작 합니다.At 12 seconds, the Front End Servers start throttling requests to the Back End Servers. 즉, 서버에서 서버 사용량이 많음-503 오류를 클라이언트에 게 반환 하기 시작 합니다.This means the servers start returning Server too busy – 503 errors to the clients. 정상 상태의 서버는 일정 한 상태에서 100 밀리초 DBStore 큐 대기 시간을 넘지 않아야 하지만 서버가 온라인 상태가 되 고 사용자가 동시에 모든 로그인 인 경우 해당 카운터가 매우 높아질 수 있으며,이 경우에는 시간이 너무 오래 걸릴 수도 있습니다.A healthy server should have less than 100 msec DBStore queue latencies at steady state, but during times where the server has just come online and users are all logging in at the same time, that counter can be very high and you may even see it hit multiple seconds.

부하 분산 구성을 사용 하 여 여러 프런트 엔드 서버로 배포 된 풀과 "최소 연결 수"에 대해 구성 된 부하 분산 장치를 사용할 수 있습니다.You may have a load-balanced configuration, where you have a pool deployed with multiple front-end servers and a load balancer that is configured for "least number of connections." 이 경우 프런트 엔드 서버를 다시 시작 하면 해당 서버는 다른 풀 구성원에 비해 연결이 더 적기 때문에 다시 연결 하려는 모든 사용자는 다시 시작 된 서버를 가리킵니다.In this case, if one front-end server is restarted, then all users who attempt to reconnect will be pointed to the restarted server, because that server will have fewer connections compared to the other pool members. 이 시간 동안에는 다른 풀 구성원이 아닌 경우 각 프런트 엔드 서버가 오버 로드 될 수 있습니다.During this time, the respective front-end server may be overloaded while the other pool members are not.

사용자가 동시에 서버에 연결 하기 위해 경쟁 하지 않을 때까지 시간이 오래 걸리는 경우에 유지 관리를 수행 하 여 성능에 미치는 영향을 줄이는 것이 좋습니다.We recommend that you perform maintenance during off-hours to reduce the performance affect as users will not all be competing to connect to the server at the same time.

이전의 두 성능 카운터가 높으면 SQL 백 엔드 서버에 병목 현상이 발생할 가능성이 높습니다.If the previous two performance counters are high, the most likely bottleneck is the SQL Back End Server. 다음으로 확인 해야 하는 구성 요소는 다음과 같습니다.The next components to confirm are as follows:

  • SQL Server CPU가 너무 높 습니까?Is the SQL Server CPU too high? 예를 들어, 80% 이상 입니까?For example, is it greater than 80 percent?

  • 디스크 대기 시간이 높 습니까?Is the disk latency high?

이상적인 세상에서 메모리에 RTC 및 RTCDYN 데이터베이스를 모두 포함할 수 있는 충분 한 RAM이 있는 경우In an ideal world, you have enough RAM to have both the RTC and RTCDYN databases in memory. 그런 다음 서버가 디스크에 액세스 하는 유일한 이유는 로그 파일에 쓰고 데이터베이스에 플러시하는 것입니다.Then, the only reason the server would be accessing the disk, is to write to the log files and flush to the databases. 테스트에서는 12gb RAM이 10만 사용자 배포에 충분 하다 고 표시 했습니다.Tests have shown that 12 GB of RAM is sufficient for 100 thousand user deployments. 이 경우 RTC 및 RTCDYN 데이터베이스 크기 합계가 12gb 미만인 것으로 가정 합니다.This assumes that the RTC and RTCDYN databases size totals less than 12 GB. 데이터베이스가 이보다 큰 경우에는 메모리가 추가로 필요할 수 있습니다.If your databases are larger than that, then you may need additional memory.

Sql server 버퍼 관리자 페이지 수명 액 성능 카운터를 검토 하 여 SQL 서버에 추가 RAM이 필요한 지 여부를 결정할 수 있습니다.You can determine whether your SQL Server requires additional RAM by reviewing the SQL Server Buffer Manager page life expectancy performance counter. 값이 3600 보다 작으면 메모리 압력을 나타냅니다.A value less than 3,600 indicates memory pressure. 또한 SQL Server가 데이터베이스에 써야 하는 경우에만 충분 한 메모리가 있는 경우 데이터베이스 드라이브에 읽기가 거의 없는 것을 볼 수 있습니다.You should also see little to no reads on your database drive if you have sufficient memory because SQL Server should only be writing to the database.

Lync Server 2013 프런트 엔드 서버에는 서버 처리 시간이 높으면 시작 되는 추가 제한 메커니즘이 있습니다.There is an additional throttling mechanism in a Lync Server 2013 Front End Server that starts if the server processing time is high. SQL Server에 대 한 대기 시간이 높으면 DBStore 대기 시간 제한은 사용 하도록 설정 됩니다.The DBStore latency throttling is only enabled if the latency to the SQL Server is high. 이러한 제한이 사용 되도록 설정 된 한 가지 예는 프런트 엔드 서버가 CPU에 연결 되어 있는 경우입니다.One example in which such throttling is enabled is if the front-end server is CPU-bound.

서버에서 들어오는 메시지에 대 한 평균 처리 시간 (LC: sip-07-7-부하 관리 \ SIP-000 평균 대기 시간) 이 6 초를 초과 하는 경우 서버는 제한 모드로 전환 되며 사용자에 게 클라이언트 연결당 하나의 해결 되지 않은 트랜잭션이 제공 됩니다.If the average processing time (LC:SIP-07-Load Management\SIP-000-Average Holding Time For Incoming Messages) on the server exceeds six seconds, then the server goes into throttling mode and only gives users one outstanding transaction per client connection. 처리 시간이 3 초까지 떨어지면 서버가 제한 모드를 해제 하 고 사용자에 게 클라이언트 연결당 최대 20 개의 해결 되지 않은 트랜잭션을 제공 합니다.Once the processing time drops to three seconds, then the server drops out of throttling mode and gives users up to 20 outstanding transactions per client connection. 특정 연결에 대 한 트랜잭션 수가 위의 임계값을 초과할 때마다 해당 연결이 흐름 제어로 표시 됩니다.Whenever the number of transactions on a specific connection exceeds the threshold above, the connection is marked as flow controlled. 따라서 서버에서 수신이 발생 하지 않으며 LC: SIP-01-피어 \ 흐름 제어 된 연결 카운터가 증가 합니다.The result is the server does not post any receives on it, and the LC:SIP-01-Peers\Flow Controlled Connections counter is incremented. 1 분 이상 동안 연결이 흐름 제어 상태에 남아 있으면 서버에서 해당 연결을 닫습니다.If a connection stays in a flow-controlled state for more than one minute, then the server closes it. 지연 됩니다.It does so lazily. 연결을 확인할 수 있는 경우에는 연결이 너무 오랫동안 제한 되었는지 확인 하 고 1 분이 넘으면이를 닫습니다.When it has an opportunity to check the connection, it determines whether it was throttled for too long and closes it if it has more than one minute.

두 가지 제한 메커니즘 및 서버가 수행 하는 제한 사항을 요약 하는 하나의 성능 카운터를 제공 합니다.These are the two throttling mechanisms and there is one performance counter that summarizes what, if any, throttling the server is performing.

LC: SIP-04-응답 \ sip-053-Local 503 응답/초LC:SIP-04-Responses\SIP-053-Local 503 Responses/sec

  • 이전 카운터에서 "Local" 이라는 용어는 로컬로 생성 된 응답을 나타냅니다.The term "Local" in the previous counter refers to locally generated responses.

  • 503 코드는 서버를 사용할 수 없는 상태 이며 정상 서버에 503 코드가 표시 되지 않습니다.The 503 code corresponds to server unavailable—where you should not see any 503 codes on a healthy server. 서버를 온라인으로 전환 하는 기간 동안 몇 가지 503 코드가 표시 될 수 있습니다.During the period after a server is just brought online, you may see some 503 codes. 모든 사용자가 로그인 하 고 서버가 안정적인 상태로 복원 되 면 추가 503 코드가 발생 하지 않습니다.When all of the users sign back in and the server returns to a stable state, there should no additional 503 codes.

LC: SIP-04-응답 \ sip-074-Local 504 응답/초LC:SIP-04-Responses\SIP-074-Local 504 Responses/sec

이 성능 카운터는 다른 서버와의 연결 문제를 나타내며 연결에 대 한 실패 또는 연결 지연을 나타낼 수 있습니다.This performance counter indicates connectivity issues with other servers and it can indicate failures to connect or delays in connecting. 504 오류가 표시 되는 경우에는 다음 성능 카운터를 확인 해야 합니다.If you are seeing 504 errors then the following performance counter should be checked.

LC: SIP-01-피어 \ sip-017-전송 중인LC:SIP-01-Peers\SIP-017-Sends Outstanding

이 카운터는 나가는 대기 된 요청 및 응답 수를 나타냅니다.This counter indicates the number of outgoing queued requests and responses. 이 카운터가 높으면 문제가 로컬 서버에 없을 가능성이 높습니다.If this counter is high then the issue is most likely not on the local server. 네트워크 대기 시간에 문제가 있는 경우이 카운터를 높게 설정할 수 있습니다.Note that this counter can be high if there are network latency issues. 또한 로컬 네트워크 어댑터에 문제가 있음을 나타낼 수도 있지만, 원격 서버에서 발생 하는 문제로 인 한 것일 수 있습니다.It could also indicate issues with the local network adapter, but is more likely caused by an issue on a remote server. 이 카운터는 통신을 시도 하는 풀이 오버 로드 된 경우 디렉터 서버에서 높은 가능성이 높습니다.This counter would most likely be high on a Director server when the pool it is trying to communicate with is overloaded. 이 카운터를 사용 하는 키는 합계 뿐 아니라 인스턴스를 확인 하는 것입니다.The key with this counter is to look at the instances, not just the total.