8GB 메모리 시스템에 우분투서버14.04를 설치했습니다.
free -mlt 해서 보니까 메모리 사용량이 이렇게 나오네요.
total used free shared buffers cached
7868 677 7191 6 33 392
8GB 메모리면 8192MB인데 왜 총메모리양이 7868MB 밖에 안나올까요?
같은 명령 free -mlt를 가상머신으로 설치한 페도라20에서 해봤습니다.
가상머신이라 사용량은 적지만 일단 총메모리양이 7961MB으로 100MB 정도 많네요.
total used free shared buffers cached
7961 196 7765 0 11 61
왜 이런 차이가 생기는지? 총메모리양을 늘릴 수 있을까요?
제가 이해하고 있는 바를 말씀드립니다. 제가 틀릴 수 있고 이 글은 소설일 수도 있습니다. 제 무식이 뽀록나는 것이 아닌가하여 조심스럽긴 한데요. 틀린 부분이 있다면 다른 분이 가르쳐주세요. 제가 안다고 장담할 수 없는 사안이 있어서, pdh0710님이 발제하시고, 제가 토론의 첫번째로 참가한다는 마음으로 씁니다.
이 문제는 두 가지 원인이 섞여서 일어나고 있는 것으로 보입니다.
(1) 주 원인은 memory mapped I/O 때문입니다.
(2) 부수적인 원인은 단위 (Mega bytes, Kilo bytes 등)의 혼란 때문입니다.
Memory mapped I/O부터 말씀드리죠. 학교 다닐 때, micro-processor 혹은 컴퓨터 구조론을 들으셨다면, 컴퓨터의 I/O 장치의 레지스터에 접근하는 방식이 두 가지가 있다는 것을 아실 것입니다. 하나는 memory mapped I/O이고 다른 하나는 port mapped I/O (혹은 I/O mapped I/O)입니다. I/O 디바이스 (비디오 카드, 사운드 카드, PCI controller 등)에 있는 레지스터에 데이터를 쓰고 읽기 위해서는 그 레지스터들에 주소를 부여하여 구분해야 합니다. 그 주소를 부여할 때, 메모리 주소의 일부를 떼어내어 주소를 부여하는 것을 memory mapped I/O라고 부르고, 메모리는 그대로 놓아두고 따로 I/O 장치용 주소를 사용하는 것을 port mapped I/O라고 부르죠. x86 processor와 그 아류의 경우 port mapped I/O의 대표적인 예로 들고, 대부분의 다른 processor는 memory mapped I/O의 대표적인 예로 듭니다.
memory mapped I/O의 장점으로 보통 드는 것이 memory instruction (MOV, ADD, …)과 addessing mode들을 I/O에도 그대로 사용할 수 있어서 다양한 프로그래밍이 가능하고 속도가 빠르다는 점을 들고, 단점은 memory space의 일부를 I/O에 사용하기 때문에 설치된 memory의 일부를 사용할 수 없다는 점이죠. port mapped I/O의 장단점은 거꾸로 생각하면 되겠습니다.
그런데 시스템 메모리가 커지면서, I/O에 일부 메모리 주소를 빼았겨서 사용할 수 없다는 memory mapped I/O의 유일한 단점이 희석되었습니다. 그래서 x86 CPU를 사용하는 컴퓨터에서도 memory mapped I/O가 일반화 되고 말았죠. 그래서 요즘 사용하는 컴퓨터들은 모두 memory mapped I/O를 사용한다고 볼 수 있을 것입니다. free command를 사용했을 때, 설치된 memory의 전부가 나타나지 않는 것은 이런 이유 때문으로 저는 이해하고 있습니다. 죽, 메모리 주소의 일부를 I/O에서 사용하기 때문에 설치된 메모리 모두를 사용할 수 없다는 것이죠.
두번째, 단위의 혼란이란 Mega bytes (MB)와 Mebi bytes (MiB)의 차이를 의미합니다. Giga bytes (GB)와 Gibi bytes (GiB)의 경우도 같습니다. Mega bytes란 1,000,000 bytes를 곱해서 나오는 단위입니다. 반면, Mebi bytes는 2**20 (2의 20승) bytes, 즉, (1024x1024=1,048,576)를 곱해서 나오는 단위입니다. 따라서, 시스템이 설치된 8 Giga bytes 메모리란 사실은 정확한 표현이 아니고 8 Gibi bytes이죠.
8 GiB = 8x1024x1024x1024 bytes = 8,589,934,592 bytes = 8589 MB = 8x1024 MiB = 8192 MiB 입니다.
"free" command에서 나오는 숫자는 manual page에는 Giga, Mega Kilo bytes라고 이야기하고 있지만, 실제로는 Gibi, Mebi, Kibi bytes인 것으로 추정됩니다. -m, -k, -b 옵션을 주고 크기를 한번 살펴보세요. Gibi, Mebi, Kibi bytes가 아니라면 설명이 안됩니다. 따라서, 예를 드신 7868은 7868 MB가 아니고 7868 MiB로 해석하는 것이 맞는 것으로 생각됩니다. 즉, 7868x1024x1024 = 8250 MB (Mega bytes)로 해석된다는 것이죠. 말을 바꾸면, 8589 MB (8192 MiB)의 address space 중에서 8250 MB (7868 MiB)가 실제 메모리로 쓰이고 나머지는 I/O address에 사용되고 있는 것으로 보입니다.
그렇다면, 왜 Fedora 가상 머신에서는 다르게 나오느냐? 이 부분은 제 추정인데요. 네, "추정", 즉, 제 "짐작"입니다. 결론부터 이야기하자면 "마더 보드가 달라서"라는 것입니다. Memory mapped I/O에서 얼마 만큼이 실제로 memory에 사용되고, 얼마 만큼이 I/O에 사용 되느냐… 이것은 마더 보드 설계에 달렸다고 보는 것입니다. 업계에서 사용하는 표준이 있겠지만, 구체적인 것은 마더 보드 설계에 달려있는 것이 아닌가하고 추정하는 것이죠. 따라서, 가상 머신의 가상 마더 보드와 실제 PC의 마더 보드는 다르잖아요? 그러니, 다르게 나온다고 추정합니다. 이 부분은 확인된 것이 아니니, 검색하셔서 공부해 보시고 제가 틀리면 알려 주세요.
아무튼 제가 틀린 것이 있으면 알려주세요. 좀 망신스럽긴 하지만, 이를 통해 배우는거죠, 뭐…
간단히 적으면 제 글에서 단위는 MiB, KIB로 보면 별 문제가 없겠구요.
Memory mapped I/O도 제가 설치한 system이 우분투서버이고 64bit OS라서 별 관계가 없을 것 같네요.
(64bit OS에 8GB physical memory가 설치되었다면, physical memory area와 충돌하지 않도록
memory mapped I/O area를 설정할 수 있을테니까요)
OS마다 사용자 프로그램이 사용할 수 없도록 메모리 영역을 미리 점유하는 경우가 많은데
그것 때문에 free 명령으로 볼 수 있는 최대 메모리양이 달라지는 것 같기는 합니다.
그래도 같은 리눅스 계열인데 우분투와 페도라가 많이 차이나서, 왜 차이가 많이 나는가,
차이를 줄여서 최대 사용 가능한 메모리양을 늘릴 수는 있는가, 이런 의문이 들어 질문을 올렸던 겁니다.
위 댓글에서도 언급했듯이 가용 메모리 양의 문제는 기본적으로 하드웨어 문제입니다. OS가 미치는 영향이 있는지 모르겠지만, 큰 영향을 끼치는 주 원인은 아닐것입니다. 저는 사실 소프트웨어가 총 메모리양에 간여한다는 것은 이해가 되지 않습니다. 하드웨어적으로 주어진 메모리를 free command가 [b:2yyqqddu]총[/b:2yyqqddu] 메모리에서 제외할 리가 있나요.
[quote="pdh0710":2yyqqddu](64bit OS에 8GB physical memory가 설치되었다면, physical memory area와 충돌하지 않도록
memory mapped I/O area를 설정할 수 있을테니까요)[/quote:2yyqqddu]
Memory mapped I/O area를 설정할 수 있다는 이야기는 저는 처음 듣는 이야기라서요. 이것을 어떻게 하는 것인지 가능한 자세하게 설명해 주시면 감사하겠습니다. 혹은 어딘가에 이 문제에 대한 문서가 있다면 링크해 주시면 감사하겠습니다. pdh0710님을 귀찮게 하지 않고 해결해 보려고 구글 검색을 해보았지만, 찾을수가 없네요. 감사합나다.
[b:2yyqqddu]Update[/b:2yyqqddu] : 제 짐작으로는…, 위 댓글에서 말씀드린 것처럼 이 부분이 확실하지 않아서, 또 "짐작"입니다. 문서를 찿지 못하겠으니…ㅠㅠ
제 짐작으로는 32-bit에서 사용하는 I/O를 위한 memory area를 64-bit라 하여 위로 밀어올리는 것이 그리 쉽지 않습니다. 왜냐하면 x86_64가 x86과 호환되어야 하기 떄문입니다. 가능한 호환성을 유지하도록 하는 원칙으로 설계되었다는 이야기를 들은 적도 있고요. 또하나는 실제로 지원하는 address bit가 CPU/OS에 따라 다를 수 있으므로 (64비트 CPU라고 해서 어드레스 라인이 64개는 아니죠), 어디로 옮길지가 확실하지 않습니다. 비슷한 문제가 x86에도 있었습니다. 소위 640K barrier라는 것인데요. 초기 IBM-PC가 640K~1M 영역을 I/O에 사용했죠. 그런데, 16비트에서 32비트가 되면서도 이 영역을 밀어올리지 못해서 32비트 x86에 그대로 남아있습니다. 주요 원인은, 역시 호환성 때문이었죠. 그래서 32비트 x86의 I/O area는 640K~1M 그리고 3~4G 영역에 존재하는 것으로 알고 있습니다. x86-64에서 640K~1M의 영역을 어떻게 했는지도 사실은 궁금한 점입니다.
그러나 제가 틀릴지 모릅니다. 말씀대로 설정을 할 수 있을 가능성도 있죠. 이 경우 I/O 하드웨어 소프트웨어 호환성을 모두 포기했다는 이야기겠죠. 그래서 혹시 근거 자료를 보신적이 있는가 여쭙습니다.
[url:2yyqqddu]http://superuser.com/questions/564605/centos-6-3-x86-64-3-3gb-memory-available-4gb-memory-installed[/url:2yyqqddu]
Mebi byte로 표기된 것을 Giga byte로 읽었을 가능성입니다.
대부분의 하드디스크나 램, 플래시메모리(USB메모리)등은 Gi/Mi 바이트 표기가 아닌 G/M 바이트로 표기합니다.
이것은 1000의 배수라 인간적인 것도 있지만, Gi/Mi바이트로 표시할 때 보다 용량이 더 크게 보이는 효과도 있기 때문입니다.
아시다 시피 컴퓨터는 2진법이고, 그 최소단위가 비트입니다.
모든것은 2의 배수일때 가장 정확하고, 빠르게 계산되기 때문에 (1000=공약수 2와 5) 보다
공배수가 2이고 1000에 가장 가까운 수인 2의10승 1024로 표기하는 것이 컴퓨터에게는 유리합니다.
그렇지만, 이게 킬로바이트가 아닌 기가 테라바이트 단위까지 진행되면, 표기상 제법크게 차이가 납니다.
그리고, 물리적 메모리에 실질적으로 영향을 미칠 수 있는 것이, 공유 비디오 메모리가 있습니다.
이것은 비디오 카드가 자체 메모리를 사용하는 것이 아니라, 시스템에 장착된 램을 공유해서 사용하는 것으로
이 경우, 32비트 트루칼라로 표현되고, 해상도가 높은 경우, 비디오 메모리가 차지하는 램영역이 커집니다.
그러나, 그렇다고 해서, 표시되는 전체 메모리량에 차이가 나지는 않습니다.
왜냐면, 롬바이오스 시스템 정보 영역에는 올바르게 보고되기 때문이죠.
또한, 가상머신에서는 다르게 표시될 가능성이 있습니다. 가상머신 자체가 롬바이오스를 가짜로 꾸미고,
부트영역도 가짜로 꾸미기 때문에, 가상머신이 자체적으로 사용하는 메모리가 포함될 여지도 있지요.
그리고, 기본메모리(Real memory<=640K), 상위메모리(640K~1M),연속확장메모리(EMS), 확장메모리(XMS)등의 용어는
16비트 도스시절 16비트에서 표기될 수 있는 영역의 한계는 65536으로 64K에 해당되고, 이것을 세그먼트라고 불러,
메모리블럭을 접근하던 시절의 한계에 의한 것입니다.
상위메모리는 콘트롤라인을 이용해서 어드레스라인을 확장한 것이구요.
요새 운영체제는 메모리를 거의 무한대로 사용할 수 있습니다.(단 운영체제가 32비트면 32비트 주소한계를 갖게
되겠지만요-이로 인해 4G이상의 램을 인식하니, 4G이상을 파티션할 수 없으니 하는 얘기가 나오는 것입니다.)
64비트 어드레스버스를 가질 경우, 접근할 수 있는 영역은, 2의 64승 바이트로,
17179869184Gi(Gibi/Giga) = 16777216Ti(Tebi/Tera) = 16384Pi(Pebi/Peta) = 16Ei(Exbi/Exa)
바이트까지 표현이 가능하기 때문에, 사실 한동안은 제약이 없습니다.
64비트 파일시스템 역시 마찬가지구요.
진전이 없네요
저는 여러가지 리눅스 설치하다 보면 당연히 가질 수 있는 의문이라고 생각해서 간단히 적었는데,
엉뚱하게 메모리 표시단위 이야기가 나오고 memory mapped I/O 이야기도 나와서 좀 황당했는데요,
혹시 설치 환경이 하나는 real machine으로 설치했고 다른 하나는 virtual machine으로 설치해서
혼동하셨나 해서 확실히 적어 드립니다.
제가 virtualbox에서 각 virtual machine에 8192MiB(=8GiB)의 메모리를 주고, 비디오메모리 양 등 다른
조건도 모두 똑같게 설정해서 3가지 리눅스를 설치해 봤습니다.
[1] Ubuntu14.04 server , [2] CentOS7 , [3] Fedora20
모두 64bit 버전이고, gnome이나 kde 등 GUI desktop 같은 것도 설치하지 않았고, ssh로 로그인해서
" free -mlt " 명령을 실행해 봤습니다. 혼동을 유발할 수 있는 거 생략하고 적으면…
[1] Ubuntu14.04 server
total used free
7983 144 7839
[2] CentOS7
total used free
7822 257 7565
[3] Fedora20 update
total used free
7961 196 7765
거의 같은 조건에서 설치했는데 3가지 리눅스를 비교해 보면 메모리 사용에서 차이가 확연하죠.
사용한 메모리양(used)가 차이나는 거야 기본 실행되는 프로그램들이 다를테니 당연할텐데,
왜 사용할 수 있는 총메모리양(total)이 저렇게 많이 차이 나느냐는 것이 제 의문이었고, 사용가능한
총메모리양을 늘릴 수는 있는 것인지 알고 싶었던 것입니다.
(여러가지 리눅스를 설치하다 보면 이런 의문들 한두번씩 가져보셨을 것 같네요. 더 이상 메모리
표기 단위 가지고 의문 갖지 않으시길 바랍니다. memory mapped I/O는 저도 일부 혼동한 부분이
있기는 한데, 64bit OS라면 총메모리양에 영향을 주지않는다는 의미였습니다.)
그런 이유 때문이었군요. 상세한 설명 감사드립니다