begin:vcard
fn:Bonghwan Kim
n:Kim;Bonghwan
email;internet:bonghwan.kim@sun.com
tel;work:82-2-2193-5225
tel;cell:82-16-325-9068
x-mozilla-html:FALSE
version:2.1
end:vcard
1.2Ghz의 U-III(12 cores)를 장착한 V1280 을 사용하던 한 사용자가 1.5Ghz의 U-IV+(24cores)가 장착된 시스템으로 업그레이드를 하게 되었습니다. 펌웨어라던가 다른 것들은 업그레이드 하지 않았구요(사실 펌웨어 업그레이드는 검토해보는 것이 좋습니다. 뭐 어쨌든) 애플리케이션도 그전에 있던 그대로 다시 재수행을 하게 되었는데, 그 해당 프로세스의 메모리 크기가 50% 정도 커졌읍니다.
왜 이런 일이 발생했을까요?
이것은 업그레이드 이전과 이후의 차이입니다.
업글 이전 :
Kbytes RSS Anon
total Kb 632800 497784 381176
업글 이후 :
Kbytes RSS Anon
total Kb 1021168 387720 299464
U-IV+는 솔라리스10 이후만을 지원합니다. 따라서, 운영체제가 업그레이드 되었죠. 애플리케이션은 전혀 손을 대지 않았구요. 일단 솔라리스10이 가진 변경된 피쳐를 간과한 것이 있습니다. 솔라리스 10은 스팍 시스템이 지원할 수 있는 페이지 사이즈를 여러개를 이용할 수 있도록 업그레이드 되어 있으며, 응용 프로그램에 맞추어 최적의 (자바 버추얼 머신의 경우에는 가장 큰) 페이지 사이즈를 자동적으로 이용할 수 있도록 되어 있습니다.
다음은 해당 프로세스의 pmap -x 를 본 결과 입니다.
업그레이드 이후
Address Kbytes RSS Anon Locked Mode Mapped File
FFFFFFFED5000000 524288 4096 4096 - rwx-- [ anon ]
FFFFFFFEFFC00000 233472 204800 204800 - rwx-- [ anon ]
업그레이드 이전
Address Kbytes RSS Anon Locked Mode Mapped File
FFFFFFFEE2C00000 262144 192512 192512 - rwx-- [ anon ]
FFFFFFFF0D800000 118784 106496 106496 - rwx-- [ anon ]
힙에 커다란 사이가 나는 것을 볼 수 있습니다. 그런데, 실제 메모리에 탑재되어 있는 영역은 얼마안됩니다.
이러한 차이는 두가지 이유가 있습니다. 솔라리스 10의 MPSS(Multiple Page size support)에 의해 이 프로세스에 가장 큰 페이지를 기준으로 할당을 하도록 함으로써 swap out된 메모리가 많이 할당되어 있게되었습니다. 페이지 사이즈가 커진다는 얘기는 페이징의 단위가 되는 메모리의 크기가 커졌다는 것을 의미합니다. 이것은 $pmap -xs <pid>로 확인할 수 있습니다. 따라서, 메모리 할당에 따른 조각(chunk)이 커짐에 따라 Fragmentation 커짐을 의미합니다.
참고 : man pagesize.1
