며칠 전 파이어폭스 3.1 베타 3 리뷰를 했습니다. 상당히 사랑스럽습니다. 개선된 Javascript 성능을 자랑하며 새로운 유용성 및 개인 정보 보호 기능이 제공되며 미래의 HTML 멀티미디어 요소를 지원합니다. 하지만 그 기사 어디에도 메모리 사용량에 대해 언급하지 않았습니다.
좋은 이유가 있습니다.
애플리케이션의 메모리 사용량을 정확하게 측정하는 것은 매우 까다로운 작업입니다. 기껏해야 추측, 추정, 표시가 있을 수 있지만 일반적으로 이러한 것들은 주관적이며 거의 쓸모가 없는 제한된 범위의 요소에 기반합니다. 대부분의 사람들은 다양한 시스템 유틸리티(예:작업 관리자, 프로세스 탐색기, ps)에서 보고된 원시 수치를 메모리 사용 요구에 대한 유일한 중재자로 사용합니다.
이 기사에서 나는 두 가지 일을 할 것입니다. 첫째, Firefox 3.1 Beta가 현재 Firefox 릴리스보다 더 많거나 적은 메모리를 사용하는지 여부에 대한 간단하고 직접적인 답변을 제공하려고 합니다. 두 번째로, 메모리 관리에 대한 괴짜 몇 가지를 가르쳐 드리겠습니다.
이 기사는 주로 Linux의 메모리 사용에 관한 것입니다. 이 운영 체제의 핵심을 깊이 파고드는 것이 훨씬 쉽기 때문입니다. 하지만 Windows 사용자도 가만히 두지 않겠습니다! Windows Firefox 메모리 사용량에 대해서도 살펴보겠습니다.
시작합시다.
더 간단한 답변을 얻는 것이 어려운 이유
운영 체제는 매 순간 바뀌는 수천 개의 매개 변수가 있는 살아있는 것이기 때문입니다. 사람이 숨쉬는 공기의 양을 묻는 것과 같다. 프로세서 유형, 클럭 및 아키텍처, 운영 체제, 현재 실행 중인 프로세스 수, 프로세스 우선 순위, 무결성 모니터, 파일 검사기, 안티 바이러스 프로그램 및 기타 및 기타 많은 것들. 모든 컴퓨터 사용자는 다른 결과를 보고합니다.
이것은 여기서 내 테스트가 소금 한 꼬집과 함께 수행되어야 함을 의미합니다. 가장 중요한 것은 절대 수치는 아무 의미가 없다는 것입니다. 둘째, 내가 여기서 보고하는 것과 완전히 반대되는 것을 경험할 수 있습니다. 기껏해야 이 리뷰/튜토리얼은 꽤 잘 생긴 오류가 무엇인지에 대한 좋은 표시입니다.
실제 사례
이전 작업장 중 한 곳에서 내 컴퓨터에 McAfee 안티바이러스를 실행해야 했습니다. 이로 인해 모든 탭을 시작할 때와 열 때 Firefox의 반응성을 포함하여 속도가 상당히 느려지는 것 같습니다. 성가신 바이러스 백신을 끄자 응답 시간이 3분의 2 이상 단축되고 메모리 사용량이 절반으로 줄었습니다. 바이러스 백신도 일종의 웹 콘텐츠 필터가 되려고 했기 때문에 내가 보려고 하는 모든 페이지를 확인하고 있었습니다. 바이러스 백신 프로그램, 방화벽, 콘텐츠 검사기, 웹 필터, 도구 모음, 플러그인 등이 브라우저를 다르게 작동하게 합니다.
따라서 테스트(및 광산)를 엄격하게 제어해야 합니다. 응용 프로그램의 동작을 검사하려면 이미지를 렌더링하고 스크립트를 실행할 때와 정적인 HTML 텍스트를 실행할 때, 12시간 동안 유휴 상태일 때와 콜드 상태일 때 단일 및 여러 탭을 연 상태에서 장단기 사용을 테스트해야 합니다. 보고된 결과가 올바른지 확인하고 변형을 측정하기 위해 각 버전에 대해 이 작업을 적어도 두 번 수행합니다.
당면한 업무의 중대함을 이해하시기 바랍니다. 이제 말도 안되는 소리로 시작하겠습니다.
Linux에서의 메모리 사용량
테스트 케이스:게스트 운영 체제에 할당된 512MB RAM이 있는 Intel Core Duo 시스템에서 가상화된 Linux Mint 6 Felicia, 추가 기능이 없는 Firefox는 기본 테마를 저장합니다. 먼저 시스템 모니터 유틸리티를 열어 시스템이 알려주는 내용을 살펴보겠습니다.
파이어폭스 3.0.3:
파이어폭스 3.1 베타 3:
기존 프로덕션 버전에서 사용하는 24.4MB보다 베타가 29MB를 차지하는 것을 볼 수 있습니다. 이것은 하나의 탭이 열려 있는 콜드 스타트에 있습니다. 전반적으로 19% 증가한 것 같습니다.
이 수치는 우리에게 무엇을 말합니까?
답은 아무것도 없습니다. 일반적으로 Linux에서 응용 프로그램은 사용하지 않으려는 경우에도 메모리를 가져오는 경향이 있습니다. 나중에 사용할 수 있도록 메모리를 미리 할당한 다음 다른 프로세스에서 요청하면 시간이 지남에 따라 해제하는 경향이 있는 Java 기반 프로그램의 경우 특히 그렇습니다. 따라서 정적 수치는 거의 의미가 없습니다. 사용할 수 있는 것보다 더 많이 가져갔다가 다른 사람이 요구할 때 놓아주는 것은 거의 탐욕이 아닙니다.
프로그램이 실제로 얼마나 많은 시간을 차지하는지 확인하려면 초과분을 모두 제거해야 합니다. 이것은 우리가 가지고 있는 전체 메모리 풀(이 경우 512MB)을 독차지하는 것을 의미합니다. 그러나 이것은 수많은 프로그램을 실행하는 것만으로는 달성하기 어렵습니다. 최악의 경우 시스템이 부족하다고 느끼면 메모리 부족(OOM) 종료 루틴이 시작되어 가장 문제가 되는 프로세스를 종료합니다. 따라서 모든 것을 가져간 다음 다시 돌려주는 단기 기억 돼지가 필요합니다.
당신이 맞다고 생각하세요, 우리는 ... memhog가 필요합니다.
메모그
이것은 방금 설명한 것을 수행하는 매우 간단한 유틸리티입니다. 기억을 가져간 다음 다시 돌려줍니다. 이 과정에서 실행 중인 모든 프로세스가 사용되지 않은 예비를 포기하도록 강제하여 필요에 따라 슬리밍합니다.
Linux Mint의 저장소에는 그러한 유틸리티가 없지만 직접 만들 수 있습니다. C 코드 조각을 다운로드하고 컴파일합니다. 방법은 다음과 같습니다.
gcc -벽 memhog.c -o memhog작은 유틸리티가 컴파일되면 다음과 같이 실행합니다.
./memhog <메모리>예:
그것을 실행하자. 몇 초, 어쩌면 1분 정도 걸릴 것입니다. 해당 기간 동안 시스템이 매우 반응하지 않습니다. 완료되면 테스트 애플리케이션의 메모리 사용량 측정을 시작할 수 있습니다.
이는 테스트 프로그램을 memhog 이전에 한 번, 이후에 한 번, 두 번 실행하는 것을 의미합니다. 또한 시스템 사용량을 확인하는 보다 정확한 방법인 명령줄 ps 유틸리티를 사용할 것입니다.
ps에서 보고한 메모리 사용량(memhog 사용)
ps 유틸리티에는 많은 옵션과 플래그가 있으므로 사용된 시스템 리소스를 매우 철저하게 검사할 수 있습니다. 보조 플래그로 실행하고 VSZ 및 RSS 값을 확인합니다. 아래 스크린샷에서 이들은 각각 출력의 다섯 번째 및 여섯 번째 열이 됩니다.
VSZ(가상 크기) 및 RSS(실제 집합 크기) 값의 의미에 대한 자세한 설명은 이 기사의 범위를 벗어나지만 간단하게 설명하겠습니다. RSS는 물리적 메모리의 실제 공간이며 VSZ에 포함되어 있습니다. . VSZ는 프로세스, 즉 코드, 데이터 및 스택의 가상 크기입니다. 그럼에도 불구하고 이 두 값은 커널 스택을 포함하여 프로세스 사용의 일부를 계산하지 않지만 Firefox는 사용자 영역 프로그램일 뿐이므로 크게 걱정할 필요는 없습니다.
메모리 맵을 다룰 때 VSZ와 RSS에 대해 조금 더 언급하겠습니다. ps에 대한 자세한 내용은 man 페이지를 확인하십시오. 이제 우리가 Firefox를 실행할 때 어떤 일이 발생하는지 살펴보겠습니다. 사용법을 살펴보고 memhog를 실행한 다음 사용법을 다시 살펴보겠습니다.
파이어폭스 3.0.3:
두 출력은 memhog 실행 전과 후를 나타냅니다. 전체 공간은 165MB이며 콜드 스타트 시 실제 메모리는 65MB입니다. memhog를 실행한 후 전체 공간은 거의 동일하게 유지되지만 실제 메모리는 16.5MB로 떨어집니다.
파이어폭스 3.1 베타 3:
VSZ 값은 189MB이며 memhog 실행 전 53MB, 실행 후 39MB의 실제 값입니다. Firefox 3.1 베타 3은 시작할 때 더 적은 메모리를 미리 할당하는 것 같습니다. 즉, 메모리를 적게 차지해야 하지만 실행하려면 더 높은 기준선이 필요합니다.
이것은 Firefox 3.1이 Firefox 3보다 더 많은 기능을 가지고 있기 때문에 이유가 있습니다. 그리고 이것들은 어딘가에 설명되고 수용되어야 합니다. 더 많은 기능, 더 많은 메모리, 더 적은 욕심.
CPU 사용량을 보면 파이어폭스 3.1이 파이어폭스 3보다 덜 걸립니다. 이전 7.7% 대비 4.7%, 4.2% 대비 3.3%, 27~64% 향상되었습니다. 이것은 또한 중요합니다. 즉, Firefox 3.1은 시스템에서 더 가벼워 실제 메모리를 더 많이 차지하지만 이벤트에 더 빠르게 응답해야 합니다. 이제 메모리 맵을 살펴보고 Firefox 3.1이 더 많은 것을 차지하는 이유를 알아봅시다.
메모리 맵
메모리 맵은 각 프로세스에 대해 개별적으로 /proc 의사 파일 시스템에서 볼 수 있습니다. 먼저 프로세스 ID를 찾은 다음(ps로 이 작업을 수행함) /proc/
파이어폭스 3.0.3:
지도가 보고하는 내용에 대해 자세한 내용을 설명할 수는 없지만 가장 작은 요컨대 다음과 같은 결과를 얻을 수 있습니다. 이 출력의 처음 몇 줄은 이진 코드(텍스트), 데이터 및 힙 세그먼트입니다. 그런 다음 프로세스에서 사용하는 공유 라이브러리가 있습니다. 출력을 검토하면서 애플리케이션의 메모리 사용량을 자세히 연구하고 해당 동작을 이해하려고 시도할 수 있습니다.
지금은 훨씬 더 간단한 것을 할 것입니다. 프로세스가 수행하는 전체 맵 수를 살펴보겠습니다. 총 455개를 살펴보세요.
파이어폭스 3.1 베타 3:
여기에 472개가 있습니다. Firefox 3.1에 더 많은 것이 필요하다는 것은 당연합니다.
그러나 아무것도 하지 않고 단일 탭을 연 상태에서 프로그램을 테스트하는 것은 거의 테스트가 아닙니다. 그래서 Youtube에 전원을 공급하고 응용 프로그램이 Flash를 얼마나 잘 처리하는지 확인했습니다. Flash Player는 Firefox용 타사 플러그인이며 Linux Mint에 번들로 제공됩니다. 따라서 내 "스트레스" 테스트가 어떤 의미가 있는지 100% 확신할 수는 없지만 여전히 알고 싶을 수 있습니다. Firefox 3.1은 이전 기사에서 본 것처럼 Javascript 성능이 훨씬 향상되었습니다.
YouTube에서 Jan Hammer를 재생할 때 ps 보고 사용량은 대략 다음과 같습니다. 테스트 직전에 실행되는 memhog를 사용하여 콜드 스타트 시 두 브라우저에서 5초마다.
파이어폭스 3.0.3:
메모리는 163MB(실제 40MB)로 안정적이고 CPU는 5.5%입니다.
파이어폭스 3.1:
메모리는 194MB(실제 57MB)이고 약. CPU 11%. 이것은 기억이 현명하다는 것을 의미합니다. 모든 것이 이전과 거의 같습니다. Youtube를 실행할 때 더 높은 CPU 사용률은 베타가 아직 Flash 라이브러리를 최대한 활용하도록 최적화되지 않았다는 사실을 나타냅니다. 상당히 개선된 엔진을 감안할 때 이는 당연한 일입니다.
한 가지 더 주목할 가치가 있는 것은 시스템에서 수행되는 작업에 따라 메모리와 CPU 사용량이 모두 다르기 때문에 정확한 판단이 어렵다는 것입니다. 마지막으로 메모리 부족(OOM) 점수를 살펴보겠습니다.
OOM 점수는 /proc 파일 시스템을 통해 커널이 보고하는 또 다른 숫자입니다. 시스템에 각 프로세스의 점수를 알려줍니다. 푸시가 발생하고 시스템의 메모리가 부족할 경우 어떤 프로세스를 종료해야 하는지 알려줍니다. 점수가 낮을수록 좋습니다.
OOM 점수/사살이 작동하는 정확한 메커니즘은 중요하지 않습니다. 우리가 찾고 있는 것은 이전 Firefox와 새 Firefox 간의 점수 비교입니다. 숫자는 /proc/
파이어폭스 3.0.3:
memhog 실행 전과 후의 차이는 무시할 수 있습니다. 즉, Firefox는 메모리를 현명하게 사용합니다.
파이어폭스 3.1 베타 3:
여기서 우리는 memhog가 실행된 후의 결과를 볼 수 있습니다(첫 번째 결과는 비슷합니다).
두 버전의 차이는 미미합니다. OOM 점수는 정확한 숫자가 아니라 크기 순서로만 의미가 있음을 유의하십시오. 따라서 시스템은 두 버전을 거의 동일하게 취급합니다.
지금까지 간략한 결론:Firefox 3.1은 더 많은 기능을 갖춘 더 큰 응용 프로그램이기 때문에 더 많은 메모리가 필요합니다. 반면에 HTML 및 Javascript를 표시할 때 CPU를 덜 사용하므로 더 빠르다고 느낄 가능성이 큽니다. Flash 성능은 개선이 필요하지만 이는 Adobe와 Mozilla 팀이 함께 작업해야 할 사항입니다. Flash Player는 이 베타용이 아니며 배포판(및 브라우저)에 포함되어 있으므로 이러한 결과를 얻은 것이 논리적으로 보입니다.
이것으로 Linux 부분을 거의 마칩니다. 이제 Windows 부분을 확인하겠습니다.
테스트 사례:AMD Athlon 3700+에서 가상화된 Windows XP SP3, 가상 머신 전용 768MB RAM, 확장 없이 Embedded 테마 및 Firefox 3.0.7 실행.
이 섹션은 내 Windows 해킹 기술이 괜찮은 반면 Linux보다 다소 적기 때문에 조금 더 짧을 것입니다. 게다가 Windows 사용자는 너무 많은 명령줄 핵을 보고 싶어하지 않으므로 자제하겠습니다.
메모리 사용량을 확인하기 위해 두 가지 유틸리티인 표준 작업 관리자와 Sysinternals에서 만든 강력한 도구인 Process Explorer 유틸리티를 사용하겠습니다.
파이어폭스 3.0.7:
파이어폭스 3.1 베타 3:
메모리 사용량은 현재 버전에서 3MB 약간 앞선 것을 제외하고는 거의 동일합니다. 전반적으로 Firefox는 단일 탭이 열린 상태에서 31-34MB를 사용하는 것으로 보입니다. 그러나 우리는 이것이 전체 이야기가 아니라는 것을 압니다.
앞서 Linux에서 보았던 VSZ 및 RSS와 유사한 값을 살펴볼 수도 있습니다. 프로세스 익스플로러는 이를 기꺼이 보고할 것입니다.
파이어폭스 3.0.7:
중요한 수치는 Working Set(54MB), Virtual Size(114MB) 및 Private Bytes(43MB)입니다. Private Bytes는 대부분의 사용자가 참조하기를 원하는 것으로 애플리케이션이 제대로 작동하기 위해 필요한 기준입니다. Working Set에는 프로세스가 매핑하는 가상 페이지가 포함됩니다. 가상 크기는 주어진 순간에 애플리케이션이 가지고 있는 전체 공간입니다.
Firefox 베타가 보고하는 내용을 살펴보겠습니다.
파이어폭스 3.1 베타 3:
Windows의 Firefox 3.1 베타 3은 메모리를 덜 사용합니다. 기준선은 25MB로 낮고 작업 집합은 34MB이며 가상 크기는 95MB입니다. 대략적으로 이것은 전체적으로 20MB 적습니다. 이러한 결과는 Linux에서 얻는 결과와 다르기 때문에 더욱 흥미로워집니다.
Linux에서 Firefox 3.1 베타는 현재 버전보다 약간 더 많은 메모리를 사용하지만 더 적은 CPU를 사용하므로 더 빠르게 응답해야 합니다. Windows에서 Firefox 3.1 베타는 약 걸립니다. 현재 버전보다 20MB 적습니다. 다시 말하지만 더 빠릅니다.
그러나 이 수치는 다시 한 번 아무 의미가 없습니다!
Windows와 Linux는 메모리를 처리하는 방법이 다릅니다. Linux는 일반적으로 필요 이상으로 미리 할당한 다음 해제하고 Windows는 필요에 따라 더 많은 메모리를 추가합니다. 이는 두 운영 체제의 전반적인 동작과 잘 일치하며, 일반적으로 메모리 집약적인 작업에서는 Linux가 이깁니다.
게다가 우리는 본질적으로 두 개의 서로 다른 운영 체제, 두 개의 서로 다른 응용 프로그램에 대해 이야기하고 있으므로 직접적인 비교는 거의 의미가 없습니다. 두 경우 모두 Firefox 3.1 Beta는 두 운영 체제의 작동 모델을 고려할 때 기존 Firefox 3보다 더 빠르게 수행될 것으로 예상됩니다. 전반적으로 풋 프린트는 약간만 다릅니다. 수십 MB 정도이며 일상적인 사용에서는 크게 변하지 않을 것입니다. 그러나 Javascript 성능이 30% 향상되는 것을 느낄 수 있습니다. 더 적은 CPU 사용률과 함께 더 빠른 브라우저를 즐기게 될 것입니다.
그러나 Linux에서 Flash 사용은 현재 최적화되지 않았습니다.
이 결과를 대략적인 추정치 이상으로 받아들이지 마십시오. 가능한 한 철저하게 시도했지만 테스트에 결함이 있고 설계상 제한적입니다. 그러나 전체 테스트의 배경 소음과 섬세함으로 인해 결과는 유쾌한 추측에 지나지 않습니다.
그러나 memhog, ps 유틸리티, 지도 및 기타 등등과 같은 괴상한 물건을 가지고 노는 방법을 배웠으므로 튜토리얼에 추가 가치가 없는 것은 아닙니다. 지금은 그게 다야, 재미있게 보내!
건배. 스트레스 하에서의 메모리 사용량
OOM 점수
Windows에서의 메모리 사용량
작업 관리자
프로세스 탐색기
결론