며칠 전 저는 Firefox 3.1 베타 3를 리뷰했습니다. 꽤 훌륭한 브라우저입니다. 향상된 자바스크립트 성능을 자랑하고, 새로운 사용성·개인정보 보호 기능을 갖추고 있으며, 미래의 HTML 멀티미디어 요소까지 지원합니다. 하지만 그 글에서 한 가지 언급하지 않은 것이 있었습니다. 바로 메모리 사용량입니다.
그 이유는 분명합니다.
애플리케이션의 메모리 사용량을 정확하게 측정하는 일은 무척 까다로운 작업입니다. 최선의 경우에도 어느 정도 추정과 짐작, 참고 지표에 불과하며, 대체로 주관적이고 너무 좁은 범위의 요소에 기반하기 때문에 거의 쓸모가 없습니다. 대부분의 사람들은 작업 관리자(Task Manager), Process Explorer, ps 같은 시스템 유틸리티가 보여주는 원시 수치를 메모리 사용량의 유일한 판단 기준으로 삼곤 합니다.
이 글에서는 두 가지를 다루려 합니다. 첫째, Firefox 3.1 베타가 기존 Firefox 릴리스보다 메모리를 더 많이/덜 사용하는지에 대한 솔직하고 간단한 답을 드리는 것. 둘째, 메모리 관리에 관한 몇 가지 꽤 기술적인 내용을 알려드리는 것입니다.
이 글은 주로 리눅스 환경에서의 메모리 사용량을 다룹니다. 이 운영체제에서는 문제의 본질까지 훨씬 깊이 들어가기 쉽기 때문입니다. 하지만 윈도우 사용자를 외면하지는 않겠습니다! 윈도우에서의 Firefox 메모리 사용량도 함께 살펴볼 것입니다.
그럼 시작해 보겠습니다.
간단한 답을 얻기 어려운 이유
운영체제는 매 순간 수천 개의 변수가 변하는 살아있는 존재이기 때문입니다. '사람은 하루에 공기를 얼마나 마시는가?'라고 묻는 것과 같습니다. 프로세서의 종류·클럭·아키텍처, 운영체제 종류, 현재 실행 중인 프로세스 수와 우선순위, 무결성 모니터나 파일 검사기, 백신 프로그램 같은 시스템 폴링 소프트웨어의 유무 등 수많은 요소에 따라 결과가 달라집니다. 컴퓨터 사용자마다 서로 다른 결과를 보고할 수밖에 없습니다.
따라서 여기서 진행하는 테스트는 많은 여유를 갖고 받아들여야 합니다. 무엇보다 절대적인 수치에는 의미가 없으며, 독자분께서는 필자가 보고하는 것과 정반대의 결과를 경험할 수도 있습니다. 이 리뷰/튜토리얼은 어디까지나 '어떻게 될 수 있는가'에 대한 좋은 참고 지표일 뿐, 상당한 오차를 감안해야 합니다.
실제 사례
예전 직장 중 한 곳에서는 회사 방침상 머신에 McAfee 백신을 설치해야 했습니다. 이것이 상당히 느린 원인이 되었는데, Firefox의 반응성 역시 시작 시와 탭을 열 때마다 눈에 띄게 저하되었습니다. 그 귀찮은 백신을 끄자 응답 시간이 최소 3분의 1로 줄어들었고, 메모리 사용량도 절반으로 떨어졌습니다. 알고 보니 그 백신이 웹 콘텐츠 필터 역할까지 겸하고 있어서, 열려는 모든 페이지를 검사하고 있었던 것입니다. 백신 프로그램, 방화벽, 콘텐츠 검사기, 웹 필터, 툴바, 플러그인 등은 모두 브라우저의 동작 방식을 달라지게 만듭니다.
따라서 여러분의 테스트(그리고 필자의 테스트)는 철저히 통제되어야 합니다. 애플리케이션의 동작을 검토하려면 단기 사용과 장기 사용, 탭을 하나만 연 경우와 여러 개 연 경우, 이미지 렌더링과 스크립트 실행 시 vs 정적 HTML 텍스트만 표시할 때, 12시간 방치 상태 vs 콜드 스타트, 다운로드 중일 때 등 다양한 조건으로 테스트해야 합니다. 그리고 각 버전별로 최소 두 번씩 반복하여 결과의 신뢰성을 확인하고 변동 폭을 가늠해야 합니다.
이 과제가 얼마나 무거운지 이해하셨기를 바랍니다. 이쯤에서 잡설은 그만두고 본격적으로 들어가 보겠습니다.
리눅스에서의 메모리 사용량
테스트 환경: Linux Mint 6 Felicia, Intel Core Duo 머신 위에서 가상화 실행, 게스트 OS에 512MB RAM 할당, Firefox는 기본 테마 외에 어떤 애드온도 설치하지 않은 상태. 먼저 시스템 모니터(System Monitor) 유틸리티를 열어 시스템이 알려주는 정보부터 살펴보겠습니다.
Firefox 3.0.3:
Firefox 3.1 베타 3:
기존 정식 버전이 사용하는 24.4MB에 비해 베타는 29MB를 차지합니다. 탭 하나를 연 콜드 스타트 기준으로, 대체로 약 19% 증가한 셈입니다.
이 숫자들이 말해주는 것은?
정답은 아무것도 아닙니다. 리눅스에서는 일반적으로 애플리케이션이 실제로 사용할 의도가 없더라도 메모리를 미리 잡아두는 경향이 있습니다. 특히 자바 기반 프로그램에서 두드러지는데, 미래에 쓸 메모리를 선점했다가 다른 프로세스가 요청하면 시간이 지나면서 반환합니다. 즉, 정적인 수치는 큰 의미가 없습니다. 남는 만큼 가져갔다가 다른 곳에서 필요로 하면 내어주는 것만으로 탐욕이라 부르긴 어렵습니다.
프로그램이 실제로 얼마나 사용하는지 보려면 남는 여유분을 모두 걷어내야 합니다. 이는 우리가 가진 전체 메모리 풀(여기서는 512MB)을 통째로 점거하는 것을 의미합니다. 하지만 단순히 프로그램을 수십 개 띄워서는 달성하기 어렵습니다. 최악의 경우 시스템이 메모리 부족을 감지하면 OOM(Out-of-Memory) 킬 루틴이 작동해 가장 문제가 되는 프로세스를 강제 종료해 버립니다. 따라서 메모리를 전부 차지했다가 다시 돌려주는 단기간의 메모리 호그(hog)가 필요합니다.
짐작하셨겠지만, 우리에게 필요한 것은 바로... memhog입니다.
Memhog
memhog는 방금 설명한 그대로의 일을 하는 아주 단순한 유틸리티입니다. 메모리를 차지했다가 되돌려줍니다. 이 과정에서 실행 중인 모든 프로세스는 사용하지 않는 여유분을 내어놓도록 강제되어, 꼭 필요한 최소한의 크기로 다듬어집니다.
Linux Mint 저장소에는 이런 유틸리티가 없지만 직접 만들 수 있습니다. C 코드를 내려받아 컴파일하면 됩니다. 방법은 다음과 같습니다.
gcc -Wall memhog.c -o memhog
유틸리티를 컴파일한 후에는 다음과 같이 실행합니다.
./memhog <memory>
실행 예시:
실행해 두면 몇 초, 어쩌면 1분 정도 걸립니다. 그 동안 시스템 반응이 다소 느려질 수 있습니다. 완료되면 테스트 대상 애플리케이션의 메모리 사용량을 측정하기 시작하면 됩니다.
즉, 테스트 프로그램을 두 번 실행하는데, memhog 실행 전에 한 번, 실행 후에 한 번입니다. 또한 시스템 사용량을 더 정확하게 확인하는 방법, 바로 명령행 ps 유틸리티를 활용합니다.
ps로 확인한 메모리 사용량 (memhog 적용)
ps 유틸리티는 다양한 옵션과 플래그를 제공하여 시스템 자원 사용 현황을 매우 세밀하게 검토할 수 있습니다. 여기서는 aux 플래그와 함께 실행하여 VSZ와 RSS 값을 확인합니다. 아래 스크린샷에서는 출력의 다섯 번째, 여섯 번째 열에 해당합니다.
VSZ(가상 크기)와 RSS(상주 집합 크기)의 세부 의미를 설명하는 것은 이 글의 범위를 벗어나므로 간단히만 짚겠습니다. RSS는 물리 메모리에서의 실제 점유량이며 VSZ 안에 포함됩니다. VSZ는 프로세스의 가상 크기, 즉 코드·데이터·스택의 합입니다. 그럼에도 두 값 모두 커널 스택처럼 프로세스 사용량의 일부는 포함하지 않지만, Firefox는 순수 사용자 영역 프로그램이므로 크게 걱정할 필요는 없습니다.
VSZ와 RSS에 관해서는 메모리 맵을 다룰 때 조금 더 언급하겠습니다. ps에 대해 더 알고 싶다면 man 페이지를 확인하세요. 이제 Firefox를 실행하고 사용량을 확인한 뒤, memhog를 실행하고 다시 사용량을 확인했을 때 무슨 일이 일어나는지 보겠습니다.
Firefox 3.0.3:
두 출력은 memhog 실행 전후를 나타냅니다. 콜드 스타트 시 전체 점유는 165MB, 실제 메모리는 65MB였습니다. memhog 실행 후에는 전체 점유가 거의 그대로인 반면 실제 메모리는 16.5MB로 떨어졌습니다.
Firefox 3.1 베타 3:
VSZ 값은 189MB이며, 실제 메모리는 memhog 실행 전 53MB, 실행 후 39MB였습니다. Firefox 3.1 베타 3는 시작 시 더 적은 메모리를 선점하는 것으로 보이며, 즉 '메모리 호그' 성향은 덜하지만 [원문 표현 유지], 실행을 위한 기본 요구량은 더 높습니다.
이는 당연한 결과입니다. Firefox 3.1은 Firefox 3보다 기능이 더 많고, 그 기능들을 어딘가에 수용해야 하기 때문입니다. 기능이 많으면 메모리도 많이 쓰지만, 탐욕스러운 정도는 오히려 덜합니다.
CPU 사용량을 보면 Firefox 3.1이 Firefox 3보다 적게 사용합니다. memhog 전 4.7% 대 7.7%, 후에는 3.3% 대 4.2%로, 27~64% 개선된 수치입니다. 이것도 중요한 의미를 갖습니다. Firefox 3.1이 실제 메모리는 더 많이 붙잡고 있음에도 시스템에 더 가볍게 작용하므로 반응 속도가 빨라야 한다는 뜻입니다. 이제 메모리 맵을 살펴보고 Firefox 3.1이 왜 더 많이 차지하는지 그 이유를 파악해 보겠습니다.
메모리 맵
메모리 맵은 /proc 의사 파일시스템에서 프로세스별로 확인할 수 있습니다. 먼저 프로세스 ID(ps로 구했습니다)를 찾은 뒤 /proc/<pid>/maps로 이동합니다.
Firefox 3.0.3:
maps 출력의 세부 내용까지 설명하기는 어렵지만, 극도로 요약하면 이렇습니다. 출력의 처음 몇 줄은 바이너리 코드(text), 데이터, 힙 세그먼트입니다. 그다음으로 해당 프로세스가 사용하는 공유 라이브러리들이 나옵니다. 출력을 따라가며 애플리케이션의 메모리 사용 패턴을 세부적으로 분석하고 그 동작을 이해할 수 있습니다.
지금은 훨씬 단순한 작업을 해보겠습니다. 프로세스가 차지하는 맵(map)의 총 개수를 확인하는 것입니다. 총 개수 455에 주목하세요.
Firefox 3.1 베타 3:
여기서는 472개입니다. Firefox 3.1이 더 많이 필요하다는 것, 당연한 결과 아니겠습니까?
부하 상태에서의 메모리 사용량
하지만 탭 하나를 열어 놓고 아무것도 하지 않는 상태로 테스트하는 것은 테스트라고 부르기 어렵습니다. 그래서 YouTube를 띄우고 Flash 처리 성능을 확인했습니다. 참고로 Flash Player는 Firefox의 서드파티 플러그인이며 Linux Mint에 번들로 포함되어 있습니다. 따라서 이 '스트레스' 테스트가 100% 의미 있다고 단언할 수는 없지만, 그래도 알아두실 만합니다. 지난 글에서 확인했듯이 Firefox 3.1은 자바스크립트 성능이 크게 향상되었다는 점도 유념하세요.
YouTube에서 Jan Hammer 음악이 재생되는 상황, 두 브라우저 모두 콜드 스타트, 테스트 직전에 memhog를 실행한 상태에서 ps가 약 5초 간격으로 사용량을 보고한 결과입니다.
Firefox 3.0.3:
메모리는 163MB(실제 40MB), CPU는 5.5%로 안정적입니다.
Firefox 3.1:
메모리는 194MB(실제 57MB), CPU는 약 11%입니다. 메모리 측면에서는 사실상 이전과 비슷한 수준입니다. YouTube 재생 시 CPU 사용률이 높은 것은 아마 베타가 아직 Flash 라이브러리를 최적으로 활용하도록 튜닝되지 않았기 때문일 것입니다. 엔진이 대폭 개편된 상황임을 고려하면 충분히 납득할 만한 결과입니다.
한 가지 더 언급할 점은 메모리와 CPU 사용량 모두 시스템에서 수행하는 작업에 따라 달라져서 정확한 결론을 내리기 어렵다는 것입니다. 하지만 이런 기술적인 내용들을 최대한 합리적으로 정리해 보겠습니다. 마지막으로 OOM(Out Of Memory) 스코어를 살펴보겠습니다.
OOM 스코어
OOM 스코어는 커널이 /proc 파일시스템을 통해 보고하는 또 다른 수치입니다. 각 프로세스의 점수를 시스템에 알려주어, 만약 최악의 상황에 시스템 메모리가 바닥난다면 어느 프로세스를 종료할지 결정하는 기준이 됩니다. 점수가 낮을수록 좋습니다.
OOM 스코어/킬이 작동하는 정확한 메커니즘은 중요하지 않습니다. 우리가 찾는 것은 구버전과 신버전 Firefox의 점수 비교입니다. 이 값은 /proc/<pid>/oom_score에서 추출할 수 있습니다. memhog 실행 전후의 수치를 확인했습니다.
Firefox 3.0.3:
memhog 실행 전후의 차이는 무시할 수 있는 수준으로, Firefox가 메모리를 꽤 지능적으로 사용한다는 것을 의미합니다.
Firefox 3.1 베타 3:
memhog 실행 후 결과입니다(첫 번째 결과도 유사).
두 버전 간 차이는 미미합니다. OOM 스코어는 정확한 숫자보다는 자릿수 단위에서만 의미가 있다는 점에 유의하세요. 즉, 시스템 입장에서는 두 버전이 사실상 동일하게 취급됩니다.
지금까지의 소결론: Firefox 3.1은 더 크고 기능이 많은 애플리케이션이기 때문에 확실히 더 많은 메모리를 필요로 합니다. 반면 HTML과 자바스크립트를 표시할 때는 더 적은 CPU를 사용하므로, 사용자는 대부분 더 빠르다고 느낄 것입니다. Flash 성능은 개선이 필요하지만, 이는 Adobe와 Mozilla 팀이 함께 풀어야 할 과제입니다. 이 베타용으로 만들어진 Flash Player가 아니라 배포판(및 브라우저)에 포함된 것을 사용했으니 이런 결과가 나온 것은 논리적입니다.
이것으로 리눅스 파트는 대체로 마무리됩니다. 이제 윈도우 파트를 확인해 보겠습니다.
윈도우에서의 메모리 사용량
테스트 환경: Windows XP SP3, AMD Athlon 3700+에서 가상화 실행, 가상 머신에 768MB RAM 할당, Embedded 테마 적용, Firefox 3.0.7에 확장 기능 없이 실행.
필자의 윈도우 해킹 실력이 나쁘지 않다고 해도 리눅스만큼은 아니기 때문에, 이 섹션은 다소 짧아질 것입니다. 게다가 윈도우 사용자들은 너무 많은 명령줄 작업을 보길 원하지 않으니 자제하겠습니다.
메모리 사용량을 확인하기 위해 두 가지 유틸리티를 사용합니다. 표준 작업 관리자와, Sysinternals가 만든 강력한 도구인 Process Explorer입니다.
작업 관리자
Firefox 3.0.7:
Firefox 3.1 베타 3:
메모리 사용량은 거의 동일하며, 현재 정식 버전이 3MB 정도 앞섭니다. 전체적으로 Firefox는 탭 하나를 연 상태에서 약 31~34MB를 사용하는 것으로 보입니다. 하지만 이것이 전부가 아니라는 것은 우리도 알고 있습니다.
Process Explorer
앞서 리눅스에서 본 VSZ와 RSS와 유사한 값들도 확인할 수 있습니다. Process Explorer가 기꺼이 보여줍니다.
Firefox 3.0.7:
중요한 수치는 Working Set(54MB), Virtual Size(114MB), Private Bytes(43MB)입니다. 대부분의 사용자가 주목해야 하는 것은 Private Bytes로, 애플리케이션이 정상적으로 동작하기 위해 반드시 확보해야 하는 기본량입니다. Working Set은 프로세스가 매핑한 가상 페이지를 포함하고, Virtual Size는 특정 시점에 애플리케이션이 갖는 전체 점유량입니다.
이제 Firefox 베타가 보여주는 수치를 보겠습니다.
Firefox 3.1 베타 3:
윈도우의 Firefox 3.1 베타 3는 더 적은 메모리를 사용합니다. 기본량은 25MB로 더 낮고, Working Set은 34MB, 가상 크기는 95MB입니다. 대략 전체적으로 20MB 정도 적습니다. 이 결과는 리눅스에서 얻은 것과 다른데, 그렇기에 더욱 흥미롭습니다.
결론
리눅스에서 Firefox 3.1 베타는 현재 버전보다 약간 더 많은 메모리를, 하지만 더 적은 CPU를 사용합니다. 즉, 반응이 더 빨라야 합니다. 윈도우에서는 Firefox 3.1 베타가 현재 버전보다 약 20MB 적게 사용합니다. 역시 더 빠를 것입니다.
하지만 다시 강조합니다. 이 수치들은 아무 의미가 없습니다!
윈도우와 리눅스는 메모리를 다루는 방식이 다릅니다. 리눅스는 통상 필요 이상으로 미리 할당한 뒤 반환하는 방식이고, 윈도우는 필요에 따라 메모리를 추가하는 방식입니다. 이는 두 운영체제의 전반적인 동작 방식과 잘 들어맞으며, 메모리 집약적 작업에서는 대체로 리눅스가 우위에 있습니다.
게다가 우리는 서로 다른 두 운영체제, 사실상 서로 다른 두 애플리케이션을 다루고 있으므로 직접 비교는 큰 의미가 없습니다. 두 운영체제의 작동 모델을 고려하면, 어느 쪽이든 Firefox 3.1 베타는 기존 Firefox 3보다 빠르게 동작할 것으로 기대됩니다. 전체적으로 점유량의 차이는 수십 MB 수준에 불과해 일상적인 사용에서는 큰 변화를 못 느낄 것입니다. 하지만 자바스크립트 성능 30% 향상은 체감될 것입니다. 더 낮은 CPU 사용률과 더해져, 여러분은 더 빠른 브라우저를 누리게 될 것입니다.
다만 리눅스에서의 Flash 활용은 아직 최적화가 덜 된 상태입니다.
이 결과를 '어떻게 될 수 있는가'에 대한 대략적인 추정치 이상으로 받아들이지 말기 바랍니다. 최대한 철저하게 진행하려 노력했지만, 이 테스트는 설계상 결함이 있고 한계가 있습니다. 배경 노이즈와 테스트 전체의 민감성 때문에 결과란 결국 즐거운 추측 이상의 것이 아닙니다.
그럼에도 여러분은 memhog, ps 유틸리티, maps 같은 기술적인 도구를 다루는 방법을 배웠으니, 이 튜토리얼이 부가 가치 없는 것은 아니기를 바랍니다. 오늘은 여기까지입니다. 즐겁게 실험해 보세요!
감사합니다.