위대한 비즈니스용 Skype 메모리 미스터리

• 적용 대상:

  Skype for Business

이 문서는 비즈니스용 Skype 에스컬레이션 엔지니어인 Kenn Guilstorf에 의해 작성되었습니다.

에스컬레이션 엔지니어로서 저는 고객에게 더 많은 "persnickety" 비즈니스용 Skype 문제를 지원합니다. 최근에 저는 "성능 기반"인 몇 가지 사례를 받았습니다. 기본적으로 비즈니스용 Skype 느리거나 느리거나, 애플리케이션 공유를 허용하지 않거나, 메모리를 너무 많이 사용하고 있다는 불만이 있습니다. 이러한 사례에 대한 조사에 따르면 사용자가 몇 주 동안 비즈니스용 Skype 실행하도록 허용했으며 시간이 지남에 따라 메모리가 성능에 영향을 줄 때까지 커진 것으로 표시됩니다. Skype를 오랫동안 실행하도록 할 때 직접 알아차렸습니다. 그래서, Skype는 무엇을하고 있으며, 왜 그렇게 많은 메모리를 보유하고 있습니까? (여기에 약간의 힌트가 있습니다 : 이것은 정상이며 의도적으로 설계되었습니다. 아무 문제도 없습니다. 모든 네이티브 프로그램이 실행됩니다.)

얼마나 많은 메모리를 통해 씹을 수 있습니까?

문제를 해결하는 첫 번째 단계는 문제를 이해하는 것이며, 문제를 이해하는 첫 번째 단계는 문제를 정의하는 것입니다. 이것은 소리만큼 쉽지 않습니다.

비즈니스용 Skype(SfB)가 처음 시작되면 메모리 사용량이 비교적 작습니다(100MB를 작게 계산할 수 있는 경우). 작업 관리자와 같은 여러 도구에서 이 문제가 발생하는 것을 확인할 수 있습니다.

그림 1: 속지 마세요. Lync.exe SfB의 프로세스 이름입니다(32비트 버전).

시간이 지남에 따라 프로세스에서 사용하는 메모리 양이 증가할 것입니다. 얼마나 커지는지는 Skype 사용량, 사용되는 내용 등에 따라 결정됩니다. 예를 들어 약 24시간 후에 동일한 클라이언트는 다음과 같습니다.

그림 2: 24시간 후 동일한 SfB

따라서 Skype는 24시간 동안 약 32MB를 소비했습니다. 그건 별로 아니에요, 맞죠? Skype가 24시간 동안 유휴 상태였다는 것을 설명할 때까지는 그렇지 않습니다. 기본적으로 컴퓨터에서 비즈니스용 Skype 시작하여 잠그고 잠금 해제하기 전에 약 24시간을 기다렸습니다. 특히 모임에 참가하고, 해당 모임에서 앱 공유 또는 데스크톱 공유를 사용하고, 메신저 대화를 사용한 경우, 통행료가 훨씬 더 높았을 것입니다. 비즈니스용 Skype 메모리 사용량이 하루에 300~500MB로 증가한 사례를 보았습니다. 특히 메모리가 제한된 32비트 클라이언트에서 1주 이상 사용 후 받아쓰기를 얻을 수 있습니다.

메모리 표시

메모리를 프로파일할 수 있는 많은 도구가 있습니다. 가장 인기 있는 것 중 하나(적어도 Microsoft)는 VMMap v3.26에서 사용할 수 있는 SysInternals 도구 VMMap입니다. 이를 사용하여 프로세스 메모리를 살펴보고 비즈니스용 Skype 메모리를 프로파일할 수 있는지 확인할 수 있습니다.

VMMap을 다운로드한 후 실행합니다. 시작되면 검사할 프로세스를 선택할 수 있도록 프로세스 목록이 열립니다. lync.exe 선택하고 확인을 클릭합니다.

그림 3: 시작 시 VMMap

다음으로 선택한 실행 파일에 대한 현재 메모리 프로필의 다중 색 표현인 그래픽이 Lync.exe 이 경우 표시됩니다.

그림 4: 최근에 시작된 Lync.exe VMMap 시작

여기에 많은 정보가 있으며, 모든 것을 설명하면 하나 이상의 블로그 게시물이 채워질 것입니다. 관심이 있는 경우 설명하는 데 도움이 되는 몇 가지 훌륭한 책과 온라인 기사가 있습니다. (개인적으로, 나는 제프리 리히터에 의해 "고급 Windows"를 권장 - 현재 인쇄에서하지만 여전히 메모리가 작동하는 방법을 설명하는 우수한. 즐겨 찾는 서점에서 사용된 복사본을 찾을 수 있습니다.)

볼 수 있듯이 작업 관리자 에 표시된 메모리는 VMMap의 범주와 일치하지 않습니다. 작업 관리자는 보다 일반화된 표현입니다. 그것은 정확, 그것은 단지 모든 것을 계산하지 않습니다. VMMap 은 훨씬 더 포괄적입니다.

다음은 24시간 대기 기간 이후의 Skype instance.

그림 5: 24시간 후 Skype용 VMMap

메모리는 어디에 있나요?

각 개별 범주를 비교하면 실제로 줄을 서는 것은 없습니다. 실제로 메모리를 사용하는 항목을 찾는 것은 개체 및 메모리 요청이 만들어지고 해제될 때 메모리 범주가 변동하고 메모리가 다양한 개체를 저장하기 위해 예약되고 커밋되기 때문에 수행하기가 어렵습니다. "지식의 커널"(이 블로그의 목적에 따라)은 "무료" 범주입니다. 이 예제에서 "free" 메모리는 Lync 실행 파일에 대해 "예약된" 사용 가능한 모든 공간입니다. 그러나 특정 유형의 "커밋된" 메모리만 작업 관리자에 표시됩니다. 예약된 메모리는 사용되지 않으므로 계산되지 않습니다.

그렇다면 메모리는 어디에 있나요? 메모리가 손실되지 않기 때문에 이를 정확히 파악하기가 어려워집니다. 대중적인 믿음과는 달리, Skype 팀은 데스크톱 메모리 제조업체에 의해 보조금을 받지 않았습니다. 고객이 시스템이나 메모리를 업그레이드하도록 하는 사악한 음모는 없습니다. 이것은 계획된 노후화의 경우도 아닙니다. 진실은 설명하기가 조금 더 어렵다.

좀 더 명확하게 하기 위해 역추적해 보겠습니다. 비즈니스용 Skype 클라이언트를 처음 시작할 때는 일반적으로 사용자 및 기타 오버헤드를 추적하는 연락처 수에 따라 상대적으로 메모리 공간이 100MB 정도입니다(위의 데이터에서 명확하게 확인할 수 있습니다). 며칠 후 이 발자국이 수십만 바이트에서 몇 메가바이트로 증가한다는 것을 알 수 있습니다. 특정 상황에서는 문제가 될 수 있지만 비즈니스용 Skype 자체에서 반드시 문제가 되는 것은 아닙니다. 오히려 Windows 프로그래밍 패러다임과 메모리를 기본적으로 처리하는 방식의 효과입니다.

Windows 프로그래밍 방법

여기서는 Windows 메모리를 간단하게 볼 수 있습니다. Windows 메모리는 할당 및 할당 해제라고 하는 고가의(컴퓨터 주기 및 리소스 측면에서) 절차를 통해 처리됩니다. 프로그램에 메모리가 필요한 경우 Windows에 할당하도록 요청합니다. 메모리를 사용하는 경우 프로그램은 Windows에 할당을 해제하도록 요청합니다. 내부적으로 Windows는 메모리 요청을 관리하기 위해 여러 프로세스를 진행합니다.

요청이 수행되면 Windows는 프로세스에 이미 커밋되었지만 프로세스가 사용되지 않는 메모리를 확인합니다. Windows는 사용할 수 있는 충분한 메모리 블록이 있는지 확인하려고 합니다. 있는 경우, 시스템은 그것을 사용 하 고 그것의 즐거운 방법에 간다. 없는 경우 예약된 메모리를 확인합니다. 예약된 메모리 블록이 충분히 큰 경우 커밋하고(운영 체제 정의 청크에서 "pages"라고 함) 변수를 저장합니다. 이제 메모리가 커밋되고 실행 파일의 메모리 공간이 증가했습니다.

요청을 처리하기에 예약된 메모리가 충분하지 않으면 어떻게 되나요? 운영 체제는 가능한 경우 더 많은 메모리를 예약하려고 합니다. 32비트 아키텍처와 64비트 아키텍처의 차이점이 여기에 있습니다. 32비트 프로세스는 최대 4GB의 메모리만 사용할 수 있습니다. 이는 4GB가 32비트 레지스터가 처리할 수 있는 최대 크기이기 때문입니다. (비트는 1 또는 0 - 이진만 보유할 수 있습니다. 따라서 32비트 는 2³² 가 허용되는 가장 높은 주소임을 의미합니다.) 32비트 아키텍처 덕분에 해당 메모리의 약 2GB만 프로세스 자체에 할당되고 나머지는 운영 체제에서 일반적인 DLL을 매핑하고 일반적인 커널 모드 개체를 처리하는 데 사용됩니다. 64비트 시스템에서 64비트 긴 레지스터는 2⁶⁴를 처리할 수 있으며, 이는 약 18 exabytes로 밝혀졌습니다. 그러나 Windows는 Windows 버전에 따라 2테라바이트에서 4TB(테라바이트) 사이로 예약할 수 있는 메모리 양을 인위적으로 제한합니다.

메모리가 예약된 후에는 커밋된 다음 이전과 같이 사용됩니다. 할당 해제 프로세스는 작지만 중요한 세부 정보 하나 또는 두 개만 제외하고 대부분 역방향입니다.

먼저 요청되지 않는 한 Windows는 메모리를 "지울" 수 없습니다. 메모리가 할당 해제되면 Windows 메모리 맵에서 사용 가능한 것으로 표시됩니다. 그것이 개최 무엇이든 여전히 거기에 있으며 다른 할당에 의해 덮어쓸 때까지 거기에 남아있을 것입니다. 다음으로, 요청되지 않는 한 Windows는 메모리를 거의 커밋 해제하지 않습니다. 앞서 말했듯이 메모리 작업은 상당히 리소스 비용이 많이 듭니다. 따라서 프로그램에 이전에 할당된 메모리가 필요한 경우 Windows는 해당 메모리가 다시 필요할 수 있다고 가정하고 반드시 필요할 때까지 메모리 커밋 해제를 보류합니다. 마지막으로 Windows는 메모리를 "병합"하지 않습니다. 즉, Windows에서 해제하는 메모리는 결코 "집계"되지 않으며, 사용 가능한 메모리 블록은 더 큰 사용 가능한 메모리 블록을 만들기 위해 "함께 이동"되지 않습니다. (이러한 모든 함수는 "가비지 수집"이라고 하는 범주로 함께 묶입니다. .NET Framework 유명한 몇 가지 가비지 수집 기능이 있습니다. 그러나 비즈니스용 Skype "네이티브" 또는 non-.NET 애플리케이션입니다.)

비즈니스용 Skype 항상 크기가 조정되는 많은 개체를 1초마다 처리합니다. 그것은 우리가 원하는 멋진 도구가되기 위해이 작업을 수행해야합니다. 연락처를 관리하고, 일정(모임), 친구, 친척 및 동료와 메신저 대화를 나누고, 음성 및 비디오, 데스크톱 또는 창 공유 등을 사용하여 대화하도록 요청합니다. 글쎄, 늦은 인용, 위대한 로버트 하인레인, 다른 사람의 사이에서: "무료 점심 같은 것은 없다."

이러한 서로 다르고 종종 가변적인 크기의 많은 개체를 관리하면 고정 크기 메모리 청크의 할당 및 할당이 해제됩니다. 시간이 지남에 따라 이로 인해 메모리 조각화(때로는 심각)가 발생하여 비즈니스용 Skype 메모리 공간이 증가합니다.

이 점을 더 잘 보여 주는 예제가 있습니다. Skype(또는 모든 네이티브 프로그램)가 각각 크기가 4K바이트인 64개의 개체(1-64)를 할당한다고 가정해 보겠습니다.

그림 6: 각각 4KB 메모리를 사용하는 64개 개체

이로 인해 256KB 메모리 할당 및 약정이 발생합니다. 이제 프로그램에 짝수 번호가 매겨진 개체가 필요하지 않으므로 해제한다고 가정해 보겠습니다.

그림 7: 짝수로 번호가 매겨진 모든 개체를 해제하면 128KB의 메모리가 확보됩니다.

VMMap 또는 유사한 도구를 사용하여 전체 메모리의 더 큰 그림을 보면 커밋된 열 중 하나( 힙 섹션에 있을 수 있지만 프로그램이 메모리를 요청한 방식에 따라 정확히 달라짐)가 128KB 더 적고 Free 섹션이 128KB 증가했음을 알 수 있습니다. 작업 관리자에서 프로그램은 이제 128KB 바이트의 메모리만 소유합니다.

다음으로, 프로그램에 저장해야 하는 단일 8KB 개체가 있다고 가정해 보겠습니다. 간단해야 합니다. 결국 128KB의 무료입니다. 그러나 해당 8KB 개체를 저장하려고 하면 128KB 사용 가능한 공간에 메모리를 저장하는 대신 새 메모리 예약이 생성됩니다. 메모리를 보면 여전히 4KB 청크로 분할된 것을 볼 수 있기 때문입니다. Windows에는 8KB 개체를 저장할 수 있는 충분한 메모리 블록이 없으므로 프로그램에 더 많은 메모리를 예약하고 커밋해야 합니다.

이는 다소 모순된 예제이지만 Skype 메모리 관리의 어려움을 보여 줍니다. Skype는 쉽게 정의할 수 없는 많은 수의 개체를 관리합니다. 이러한 개체는 모두 가변적으로 길이가 지정됩니다. 즉, 개체가 저장되고 해제되므로 특히 며칠 또는 몇 주와 같은 오랜 기간 동안 메모리 조각화가 심각해질 수 있으며 Windows에서 새 개체를 저장하기 위해 더 많은 메모리를 할당해야 하기 때문에 메모리 공간이 과도하게 증가합니다.

이로 인해 32비트 클라이언트에서 문제가 발생할 경우 64비트 및 32비트 아키텍처 덕분에 메모리가 훨씬 덜 제한되므로 64비트 클라이언트로 이동하는 것이 좋습니다. 그러나 다른 고려 사항 중에서도 과도한 메모리 증가는 64비트 클라이언트에서도 부진을 일으킬 수 있습니다. 이러한 다른 고려 사항에는 전체 시스템 메모리, 디스크 속도(프로그램 메모리가 일반적으로 Windows 페이징 파일의 가상 메모리에 의해 지원되기 때문), 열려 있는 다른 애플리케이션 수 등이 포함됩니다. 두 경우 모두 시간이 지남에 따라 비즈니스용 Skype 메모리 공간이 증가함에 따라 성능이 악화됩니다. 32비트 클라이언트의 경우 이로 인해 Skype에 필요한 더 큰 개체(예: 애플리케이션 공유를 위한 내부 버퍼)가 공간이 부족하고 오류가 발생할 수 있습니다.

공평하게 하기 위해 메모리는 시간이 지남에 따라 소비되는 하나의 리소스에 불과하지만 가장 분명 합니다. 사용량 처리가 증가하고, 시간이 지남에 따라 스레드가 증가하고, 페이징 풀 메모리가 증가하는 등의 작업을 수행할 수 있습니다. 이러한 각 증가는 프로세스 및 경우에 따라 전체 운영 체제에 영향을 미칠 수 있습니다. 이는 64비트 클라이언트의 경우에도 사용자가 매일(또는 적어도 매주) Skype를 종료하고 다시 시작하는 것이 좋습니다.

이에 대해 어떻게 해야 하며 Skype를 강제로 다시 시작할 수 있나요?

Skype를 강제로 다시 시작하는 방법에는 여러 가지가 있지만 가장 좋은 방법은 하나도 없습니다. 물론 한 가지 방법은 사용자 교육입니다. 사용자는 대부분의 경우 데스크톱 사용의 중재자이므로 하루 동안 떠날 때 로그아웃하고 Skype를 닫도록 가르치는 것이 실용적입니다. 사용자 지정 스크립트 또는 실행 파일을 작성한 다음 작업 스케줄러 작업으로 실행하여 필수 단계로 수행할 수도 있습니다. 이 방법은 약간 햄 주먹이며, "사용 중"인 경우에도 Skype가 순환할 수 있습니다(작업 스케줄러 조건을 통해 다소 완화될 수 있지만). 데스크톱 및 컴퓨터 관리, 잠재적 BIOS 옵션 등에 대한 타사 기회도 있습니다.

결론은 비즈니스용 Skype 매일 또는 적어도 매주 순환하는 것이 가장 좋습니다. 정기적으로 비즈니스용 Skype 재활용하도록 사용자를 학습시킬 수 있거나, 적어도 상황이 이상해지면 헬프데스크 통화 수가 훨씬 적고 더 행복한 사용자가 많을 것입니다.