'메모리'에 해당되는 글 2건

  1. 2008.12.15 Google Chrome 의 Multi Process & Memory Usage
  2. 2008.04.09 Javascript Application(RIA) Memory Management (2)
Google Chrome 의 다중 프로세스와 메모리 사용


사용자 삽입 이미지

최근 Beta Tag를 구글의 크롬 브라우저 다른 브라우저에 비해 장점보다 단점이 더 많겠지만 일단 브라우저가 갖춰야 할 기능에 있어서는 상당히 만족스러운 느낌입니다.

렌더링속도와 브라우징 속도, 어플 수행속도 면에서 매우 안정적으로 변했습니다.
“헉 크롬이 다운되었습니다.” 라는 경고창은 자주 보였던 베타버젼 이후에는 아직까지 본 경우가 없습니다.

베타 첫 출시일에 JavaScript 지원여부와 벤츠마크에 대한 테스트를 해보고 그다지 만족하지 않아 그간 사용하던 FireFox를 사용해 왔었는데 부쩍 느려진 느낌이 들어 웹 서핑때에는 크롬을 사용중인데 그때와 많이 달라져 보이지 않지만 상대성인지 지금은 대단히 만족히 사용하고 있습니다.

크롬의 JavaScript 엔진인 V8 엔진은 이번 릴리즈 노트에서도 평균 1.4배 정도의 향상을 시켰다는 내용이 포함되어 있었고 다양한 부분에 있어서 향상과 안정성을 높인 것 같습니다.

이중 멀티 프로세스 모델과 메모리 사용에 대한 좋은 소개 내용이 있어 간단히 조사해 보았습니다.

크롬은 Firefox와 같은 브라우저에 비해 비교적 많은 메모리를 소모합니다.  바로 멀티 프로세스 아키텍처는  브라우저와 렌더링 엔진을 서로 다른 프로세서에서 동작시키는 원리로 동작하여 더 많은 메모리를 소모하게 됩니다.

크롬의 멀티 프로세스에 대한 설명은 Google Chrome Memory Usage – Good and Bad 이곳을 참고

위의 포스팅에 보면 간단한 메모리 사용에 대한 측정 방법에 대한 방법을 제시하고 있는데 Windows의 Task Manager(작업 관리자)를 통해서 측정한다면 실제 사용하는 메모리에 비해서 30%에서 40%정도 더 많은 사용률을 보일 수 있다고 합니다.  

이것은 멀티 프로세스 아키텍쳐만의 장점으로 크롬이 사용하는 공유 메모리까지 크롬의 메모리 사용률로 측정 될 수 있기 때문입니다.  그렇기 때문에 정확한 사용량을 측정하려면 크롬의 about:memory 를 통해서 확인하시는 것이 가장 정확한 방법입니다.

아래의 모습은 각 브라우저의 초기 페이지를 about:blank로 설정하고 띄운 상태에 메모리 사용률을 체크해 보았습니다. 


사용자 삽입 이미지


크롬이 채택한 이 멀티프로세스 아키텍쳐는 싱글 프로세스 브라우저에 비해 메모리 사용량이 늘어 날 수 밖에 없는 구조입니다.  하지만 반면에 관리에 있어 매우 정확히 동작하기 때문에 더 나은 방법일 수 있다는 생각을 합니다.

만약 메모리 공간을 시스템 프로세스에서 분리하기 위해 보안 취약점이 발생하면 다른 브라우저에까지 영향을 줄 수 있기는 하지만 분리된 렌더링 엔진 프로세스가 종료하면(예를 들자면 같은 도메인에 접속중인 모든 탭을 닫을 경우) 메모리는 운영체제의 수준으로 메모리는 반환되어 메모리 사용량이 증가하기도 쉽지만 사용량을 줄이는 것도 안정적으로 처리 될 수 있게 됩니다.

반면 Single 프로세서의 경우에는 한번 확보한 메모리를 비우거나 사용량을 줄이게 하는 것은 대단한 작업입니다.  FireFox의 경우에는 FreeBSD에서 개발된 jemalloc을 통합하여 사용하며 메모리 조각의 발생을 줄이는 방식으로 활용되고 프로세스 종료 시 메모리를 반환하게 되는 구조입니다.


사용자 삽입 이미지
출처 Stualrt Pavlov씨의 블로그

 구글 크롬의 경우가 메모리 반환의 구조는 더욱 단순해 보입니다.  브라우저는 웹 사이트를 보기 위해서 사용한 만큼 사용자의 메모리 리소스를 사용하고 그 사이트에 대한 정보를 브라우저에서 더 이상 사용하지 않을 때 모든 메모리를 반환한다.  

국내 고급형 PC의 보급률로 볼때면 리소스가 뒷 받침해주니 이런 방식이 더 낫지 않을까?   개인적으로는 단순하면서 더 깔끔하다는 느낌을 받습니다. 

사용자의 브라우징 유형에 따라서 크롬이 더 낫거나 파이어폭스가 더 나을 수도 있다는 느낌도 듭니다.


Chromium Developer DocumentationMulti-process Architecture
신고
Posted by Rhio.kim
부제 : garbage collection in javascript
자바스크립트 어플리케이션 메모리 관리라기 보다 가비지 컬랙션(Gabege Collection)과 클로져(closure)와 순환참조(circular reference) 의 관계에 대한 글에 가깝습니다.


중간 중간 정리하면서 가비지 컬랙션에 대한 참조한 블로그가 있었는데 까묵었습니다. ^-^;


간단 명료하게 결론부터 정리합니다.
Javascript RIA 개발 시 간과해서는 안되는 중요한 부분중에 한가지 입니다. 
바로 메모리 관리 Memory Management입니다.


  이미 여러 javascript로 RIA 개발 경험이 있는 개발자라면 뼈저리게 느끼고 있을 것입니다.
못느꼇다면 꼭 한번 브라우저를 띄우고 개발해 놓은 요소들을 메모리 테스트를 해보시기 바랍니다.

  그리고 윈도우 어플리케이션 개발자라면 이 메모리 관리에 대해서 매우 예민한 부분이 아닐 수 없습니다.  윈도우 어플리케이션도 아닌데 메모리 관리를 해줘야 한다니 그냥 웃고 넘어갈 분들도 계시겠지만 RIA 개발하려는 모든 분들께 메모리 관리에 대한 중요성을 전달해 주고 싶습니다.


가비지 컬랙션(Garbage Collection) ?
 힙heap영역에 할당된 더 이상 사용되지 않는 메모리인 가비지garbage를 가비지 컬랙터garbage collector가 다른 객체가 사용할 수 있도록 정리하는 것을 말합니다.

객체가 가리키는 참조 변수가 null이 지정되거나 객체가 더 이상 참조하지 않게 되었을 때 가비지 컬랙터의 후보가 되며 이러한 객체들은 가비지 컬랙터에 의해 메모리를 반환하게 됩니다.


가비지 컬랙션의 대상
1. 객체에 null 값이 대입되었을 때
    e.g.   var dat = new Date();
                  dat = null;
2. 참조변수에 다른 객체가 대입될 때
    e.g.   var dat = document.getElementById(‘rhio’);
                  dat = 29;
3. 메소드의 수행이 끝났을 때
    e.g.   function func() {
            var dat = document.getElementById(‘rhio’);
            //do something
          }

가비지 컬랙션과 순환참조에 대한 좋은 글  옷장수님 블로그#가비지 컬렉션의 이해

사용자 삽입 이미지
자바의 가비지 컬렉션은 자바가상머신Java Vitural Machine에서 알아서 처리하지만 개발자에 의해 직접 가비지 컬랙션을 수행 요청을 할 수 있습니다.  하지만 javascript의 경우에는 따로 개발자에 의해 가비지 컬랙션의 작업 수행 요청할 수 있는 매커니즘이 존재하지 않습니다.

Javascript는 주기적으로 가비지 컬랙션의 대상에 대한 리소스 반환 작업을 수행하게 됩니다.

IE 브라우저의 경우 순환참조Circular Reference 발생과  클로져 형성으로 메모리 누수에 대한 심각한 문제가 시작됩니다.   Javascript에서의 순환참조(Circular Reference)라 함은 Javascript 객체가 DOM 객체에 대한 레퍼런스를 포함하고 그 DOM 객체가 javascript 객체의 레퍼런스를 포함할 때를 말합니다.

위의 문단이 자바스크립트에만 순환참조가 있다라는 글로 오해될 수 있을 것 같아 살짝 수정 및 아래 내용을 추가합니다.  일반적인 순환참조(circular refrenece)에 대한 설명이 더욱 필요할 것 같네요.  (옷장수님이 의견 주셨습니다.)

일반적인 순환참조(Circular Reference)란?
참고 :
    http://en.wikipedia.org/wiki/Circular_reference
    http://en.wikipedia.org/wiki/Reference_counting


사용자 삽입 이미지

위의 예제는 흔히 우리가 알고 있는 javascript의 순환참조가 발생되면서 메모리 누수현상을 단편적으로 설명할 수 있는 예시가 됩니다.

div는 DOM 객체의 레퍼런스를 담고 있습니다. 이 DOM 객체를 outerFn 가 첫번째 인자로 취하여 DOM 객체에 func라는 프로퍼티property  javascript의 익명함수anonymous function 를 참조reference하게 합니다.

이 자체가 메모리 누수라 할 수는 없지만, 위와 같은 패턴은 경우에 따라(위와 같은 작업이 반복 적으로 수행될 때) 심각한 누수 현상을 발생할 수 있습니다.  이 말은 곧 가비지 컬랙션에 의해서 메모리 반환을 하지 못하는 상황에 빠지게 됩니다.

  Javascript의 가비지 컬랙터의 경우 클로져가 형성된 것들을 관리하며 혼돈하지 않아 가비지 컬랙션에 대해 메모리 반환을 하지만 불행히 IE의 경우 DOMJScript가 관리하지 않아 위의 예시와 같은 순환참조와 클로져에 대해 몹시 둔감합니다.  그만큼 메모리 누수 현상이 매우 심각합니다.

 
이번 IE8이 릴리즈 되면서 그에 대한 마이그레이션 팁이 나왔습니다. 그 역시 DOM과 Javascript의 순환참조에 대한 이슈를 대부분 언급하고 있습니다.  그에 대한 테스트와 테스트 결과에 대해서 다음에  간단한 포스팅을 하도록 하겠습니다.


참고
http://www.crockford.com/javascript/memory/leak.html
http://www-128.ibm.com/developerworks/web/library/wa-memleak/

신고
Posted by Rhio.kim