출처 : http://shaharear.blogspot.kr/2013/06/recover-database-from-ora-00333-redo.html

아래의 step을 차근차근 따라하면 해소된다. 

빨간 글씨는 직접 입력 내용이다.

파란 글씨는 출력 내용중 핵심 내용이다.

In development environment, it is very common scenario that we have multiple databases in a single machine by using VMware (i.e, each VMware contains one database). Again those machines doesn't have consistant power backup. Therefore we have to face power failure or VMware hang-up. So, we are forced to restart the machine while databases are still up & running. After restarting the machine, we have mostly got he following error:

SQL> startup
ORACLE instance started.
Total System Global Area ***** bytes
Fixed Size               ***** bytes
Variable Size            ***** bytes
Database Buffers         ***** bytes
Redo Buffers             ***** bytes
Database mounted.
 
 ORA-00333: redo log read error block *Number* count *Number*

Step 1: As the Db is in mount mode, We can query v$log & v$logfile to identify the status of log file group and their member.

 SQL> select l.status, member from v$logfile inner join v$log l using (group#); 

 STATUS  MEMBER
 ------------- --------------------------------------
 CURRENT /oracle/fast_recovery_area/redo01.log
 INACTIVE /oracle/fast_recovery_area/redo02.log
 INACTIVE /oracle/fast_recovery_area/redo03.log

Step 2: Recover the database using ackup controlfile.

 SQL> recover database using backup controlfile;

ORA-00279: change  generated at  needed for thread 1
ORA-00289: suggestion : /oracle/fast_recovery_area/archivelog/o1_mf_1_634_%u_.arc
ORA-00280: change  for thread 1 is in sequence #
Specify log: {=suggested | filename | AUTO | CANCEL}

Step3: Give 'CURRENT' log file member along with location as input. If it does not work give other log file members along with location in input prompt. In our case we give (위의 step 1의 current log 파일을 입력하면 됨)

/oracle/fast_recovery_area/redo01.log

Log applied.
Media recovery complete.

Step 4: Open the database with reset logfile

SQL> alter database open resetlogs;

Database altered.

출처 : http://blog.daum.net/99lib/9

글쓴이 : bonnie_clyde| 원글보기

파일시스템 개념을 잡고 가야할듯..

ext4 가 확장성이 있고 ext3는 확장성이 없다는데, 내 기억으로는 LVM을 확장해줬던 기억이 있어서 갑자기 혼란스러웠다.

파일시스템 자체를 확장하는 것이 아니라 논리볼륨을 더 확장한 것 뿐이라서 결국엔 아닌 것이었으나 내가 본론적으로 잘 이해를 못하고 있음을 깨달아

다시 정리하고자 한다.

* 보통은 ~~

디스크를 붙이고 -> 파티션을 생성하고 -> 해당 파티션을 포맷하고(파일시스템을 만들고) -> 마운트

* 요기선~

디스크를 붙이고 -> 파티션을 LVM타입으로 생성하고 -> 물리볼륨을 만들고 -> 볼륨그룹을 만들고 -> 볼륨그룹에서 논리볼륨을 만들고 -> 포맷 -> 마운트

우선 LVM을 만드는 순서부터 살펴보자면,

1. 하드디스크를 LVM을 만들 수 있게 파티션 생성
2. 물리볼륨 생성 (pvcreate)
3. 위 물리볼륨들을 볼륨그룹을 생성하여 묶는다. (vgcreate)
4. 위 볼륨그룹을 원하는 크기대로 나눠 논리볼륨 생성 (lvcreate)
5. 파일시스템으로 포맷

1. 하드디스크를 LVM 타입으로 파티션 생성 .. (이라는데 굳이 그럴 필욘 없는듯..) 

2. 물리볼륨 생성

3. 볼륨그룹 설정

4. 논리볼륨 생성

5. 파일시스템 포맷 및 마운트

fdisk 해서 나중에 -l 치면 나오는 애들은.... list known partition types 이다. 파일시스템 리스트가 아니라 파티션 타입~!

/proc/filesystems는 파일시스템 타입이고..

즉, 처음에 내가 가졌던 의문,

기본적으로 fdisk해서 만들었던 파티션들이 df -T 하면 나오는 파일시스템 타입에는 왜 ext3가 있느냐,

fdisk 해서 l로 치면 나오는 타입에는 ext3가 없는데?

라는 우문에는, 파티션 타입이라 다른거고..

기본적으로 fdisk로 해서 만든 파티션을 만든 후 반드시 포맷하고 마운트를 시켜야 한다.

나는 fdisk하면 바로 포맷이 되서 쓸 수 있는 건줄 착각하고 있었다....ㅋㅋ

+) 그런데 굳이 물리볼륨을 만들 필요 없이 바로 파티션을 볼륨그룹으로 묶을 순 없는건가?

왜 굳이 물리볼륨을 중간에 추가적으로 만들어서 (그냥 파티션을 그것도) 작업을 한번 더하는거지?..

+) dmc-emass 이관 작업시, cx4-80 스토리지의 디스크를 추가로 할당하여 붙여줄 ?,

스토리지 엔지니어가 미리 파티션까지 다 할당해놓았었다...

나는 이 때 파티션을 LVM  타입으로 만들어야 했는데 엔지니어가 말도 없이 그냥 리눅스 타입으로 해서 당황스러웠었다 ㅋㅋㅋ

LVM이 잘 생성되긴 했었는데...

그런데 fdisk -l 하면 파티션 테이블이 존재하지 않는다는 메시지가 뜬다.

나는 여튼 이미 엔지니어가 파티션까지 다 만들어버렸으니 바로 물리볼륨그룹 작업으로 들어갔었는데...

----------------------------------------------------------------------------------------

출처 : http://attiadmin.guyweb.co.kr/linux/lvm.html

1. LVM이란?
 (1) 개요: 리눅스 설치시나 하드디스크 추가시에 파티션이라는 것을 나누고 공간을 할당한다. 이 
          때 한번 설정한 공간을 고정이 되어 변경이나 추가가 불가능하다. LVM(Logical Volume 
          Manager)은 파티션을 원하는 대로 추가하거나 제거하고 그 크기도 조절할 수 있도록 
          해주는 방법이다.
 (2) 관련용어
   1) 물리적 볼륨(PV:Physical Volume): 실제로 나눈 파티션을 말한다. 즉 /dev/hda8, /dev/hdb1 등
                                      을 말한다. LVM에서는 이러한 물리적 볼륨을 하나의 구성원
                                      으로 받아 들이는 형식이다.
   2) 물리적 확장(PE:Physical Extents): 일종의 블럭같은 것으로 실제 데이터가 저장되는 공간을 
                                       말한다. 보통 1PE가 약 4MB정도 차지한다.
   3) 볼륨그룹(VG:Volume Group): 물리적 볼륨이 모여서 하나의 VG를 이룬다. 이것은 더 크게 말하
                                면 지정한 크기의 PE가 모여 생성되는 하나의 큰 덩어리라고 할 수
                                있다.
   4) 논리적볼륨(LV:Logical Volume): 이 논리적 볼륨이 우리가 흔히 쓰는 정규파티션과 같다. 실제
                                    만들어서 사용하는 것이 바로 이 LV이다.

2. LVM 설정하기
 (1) 설명: /dev/hda8(약 800MB)과 /dev/hda9(약 800MB)을 lvm이라는 볼륨그룹으로 생성하고 1.2GB는
          /data라는 디렉토리로 400MB는 /backup으로 구성해보자. 여기서 /data는 처음에 1GB로 
          할당하고 추가로 영역을 200MB 확장하는 형태로 구성한다.
 (2) 설정1 : 1000MB의 /data 로 구성
   1) fdisk를 이용하여 파티션 속성을 변경: fdisk /dev/hda 실행후에 t, 해당 파티션 선택, 8e, w 
                                          을 누르고 재부팅한다.
   2) 디스크에 있는 볼륨그룹을 검색하고 /etc/lvmtab 파일 생성
     [root@www root]# vgscan
   3) 물리적 볼륨(PV:Physical Volume) 생성
     [root@www root]# pvcreate /dev/hda8
     pvcreate -- physical volume "/dev/hda5" successfully created

     [root@www root]# pvcreate /dev/hda9
     pvcreate -- physical volume "/dev/hda8" successfully created
   4) 생성된 PV를 특정한 볼륨그룹(lvm)에 추가시킨다.
     [root@www root]# vgcreate lvm /dev/hda8 /dev/hda9
     vgcreate -- INFO: using default physical extent size 4 MB
     vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
     vgcreate -- doing automatic backup of volume group "lvm"
     vgcreate -- volume group "lvm" successfully created and activated
   5) 생성된 볼륨그룹 검사한다.
     [root@www root]# vgdisplay -v lvm
     --- Volume group ---
     VG Name               lvm
     VG Access             read/write
     VG Status             available/resizable
     VG #                  0
     MAX LV                256
     Cur LV                0
     Open LV               0
     MAX LV Size           255.99 GB
     Max PV                256
     Cur PV                2
     Act PV                2
     VG Size               1.66 GB
     PE Size               4 MB
     Total PE              424
     Alloc PE / Size       0 / 0
     Free  PE / Size       424 / 1.66 GB
     VG UUID               RBimFr-2W6o-O6Wr-E4Ox-egs1-z87V-cha1DA

     --- No logical volumes defined in "lvm" ---


     --- Physical volumes ---
     PV Name (#)           /dev/hda8 (1)
     PV Status             available / allocatable
     Total PE / Free PE    212 / 212

     PV Name (#)           /dev/hda9 (2)
     PV Status             available / allocatable
     Total PE / Free PE    212 / 212
   6) 논리적 볼륨(LV:Logical Volume) 생성
     [root@www root]# lvcreate -L 1000M -n data lvm
     lvcreate -- doing automatic backup of "data"
     lvcreate -- logical volume "/dev/lvm/data" successfully created
   7) LV생성확인
     [root@www root]# lvscan
     lvscan -- ACTIVE            "/dev/lvm/data" [1000 MB]
     lvscan -- 1 logical volumes with 1000 MB total in 1 volume group
     lvscan -- 1 active logical volumes
   8) VG 확인
     [root@www root]# vgdisplay -v lvm
     --- Volume group ---
     VG Name               lvm
     VG Access             read/write
     VG Status             available/resizable
     VG #                  0
     MAX LV                256
     Cur LV                1
     Open LV               0
     MAX LV Size           255.99 GB
     Max PV                256
     Cur PV                2
     Act PV                2
     VG Size               1.66 GB
     PE Size               4 MB
     Total PE              424
     Alloc PE / Size       250 / 1000 MB
     Free  PE / Size       174 / 696 MB
     VG UUID               RBimFr-2W6o-O6Wr-E4Ox-egs1-z87V-cha1DA

     --- Logical volume ---
     LV Name                /dev/lvm/data
     VG Name                data
     LV Write Access        read/write
     LV Status              available
     LV #                   1
     # open                 0
     LV Size                1000 MB
     Current LE             250
     Allocated LE           250
     Allocation             next free
     Read ahead sectors     1024
     Block device           58:0
     

     --- Physical volumes ---
     PV Name (#)           /dev/hda8 (1)
     PV Status             available / allocatable
     Total PE / Free PE    212 / 0

     PV Name (#)           /dev/hda9 (2)
     PV Status             available / allocatable
     Total PE / Free PE    212 / 174
      => 논리적 볼륨부분이 나타나고 물리적 볼륨에서 /dev/hda8은 모두 사용중인 것으로 나타난다.
   9) 파일시스템 생성
     [root@www root]# mkfs -t ext3 /dev/lvm/data
   10) 마운트하여 사용한다.
      [root@www root]# mount -t ext3 /dev/lvm/data /data
 (3) 참고
   1) 설명: LVM을 시스템 재부팅후에도 사용하려면 /etc/fstab파일에 등록하면 된다.
   2) 예
     /dev/lvm/data              /data                ext3    defaults        0 0
 (4) 설정2: /data 디렉토리 200MB 추가하기
   1) 설명: lvextend 명령을 이용하여 공간을 늘리고 lvscan명령으로 확인하도록 한다.
   2) 방법
    ㄱ. [root@www root]# lvextend -L +200M /dev/lvm/data
          => 기존의 용량에 추가로 200MB를 할당한다.
    ㄴ. [root@www root]# lvscan
 (5) 설정2: 남은 공간(약 400MB)를 /backup 디렉토리로 사용하기
   1) 설명: 남은 공간을 확인하려면 vgdisplay -v 명령을 내려서 Free PE값을 확인하고 해당 PE값을
           할당하는 것이 좋다. lvcreate 로 남은 PE값을 지정하고 Logical Volume을 생성한다.
   2) 방법
    ㄱ. [root@www root]# lvcreate -l 124 -n backup lvm
         => lvm이라는 볼륨그룹에 backup 이라는 Logical Volume을 생성하고 크기는 약 124PE
          (약 496MB)를 할당한다.
    ㄴ. [root@www root]# mkfs -t ext3 /dev/lvm/backup
         => 파일시스템을 생성한다.
    ㄷ. [root@www root]# mount -t ext3 /dev/lvm/backup /backup
         => 마운트하여 사용한다.

3. LVM 관련명령어
 (1) vgscan
   1) 설명: 디스크에 있는 볼륨그룹(VG:Volume Group)를 검색하여 /etc/lvmtab 파일을 생성한다. 
           fdisk를 이용하여 파티션을 속성을 LVM으로 지정한 후에 이 명령을 사용한다.
   2) 사용법
     vgscan
 (2) pvcreate
   1) 설명: 물리적 볼륨(PV:Physical Volume)을 생성하는 명령어이다. fdisk를 이용하여 파티션을 
           분할하고 LVM 속성으로 지정한 뒤에 해당 파티션을 PV로 만들 때 사용하는 명령이다.
   2) 사용법
     pvcreate 디바이스명
   3) 사용예
     pvcreate /dev/hdb1
 (3) vgcreate
   1) 설명: 볼륨그룹을 생성하는 명령어로 생성된 PV를 지정한 볼륨그룹에 포함시키면서 생성한다.
   2) 사용법
     vgcreate 볼륨그룹명 디바이스명 디바이스명
   3) 사용예
     vgcreate lvm /dev/hda7 /dev/hdb1
      => lvm 이라는 볼륨그룹을 생성하고 /dev/hda7, /dev/hdb1 이라는 PV를 포함시킨다.
 (4) vgdisplay
   1) 설명: 볼륨그룹의 속성과 정보를 보여주는 명령어이다.
   2) 사용법
     vgdisplay [option] [볼륨그룹명]
   3) option
     -v: 좀 더 자세히 보여주는 옵션으로 Volume Group이외에 gical Volume과 Physical Volume도
        같이 보여준다.
   4) 사용예
    ㄱ. [root@www root]# vgdisplay
         => Volume Group의 내용을 보여준다. 
    ㄴ. [root@www root]# vgdisplay -v lvm
         => lvm이라는 볼륨그룹의 내용을 자세히 보여준다.
 (5) lvcreate
   1) 설명: 볼륨그룹안에 LV(Logical Volume)을 생성하는 명령이다.
   2) 사용법
     lvcreate 옵션 볼륨그룹명
   3) option
     -L: LV의 사이즈를 지정하는 옵션으로 K(kilobytes), M(megabytes), G(gigabytes), T(terabyt
        es) 단위를 붙여 지정가능하다.
     -l: LV의 사이즈를 지정하는 옵션으로 pe의 개수로 용량을 지정한다. 참고로 보통 1pe당 4MB
        이다.
     -n: LV의 이름을 지정하는 옵션이다. 
   4) 사용예
    ㄱ. [root@www root]# lvcreate -L 2000M -n backup lvm
         => lvm이라는 볼륨그룹에 backup라는 이름으로 2Gigabytes 용량으로 LV을 생성한다.
    ㄴ. [root@www root]# lvcreate -l 250 -n data lvm
         => lvm이라는 볼륨그룹에 data라는 이름으로 250pe(약 1GB)용량으로 LV을 생성한다.
 (6) lvscan
   1) 설명: 디스크에 있는 Logical Volume을 찾아준다.
   2) 사용법
     lvscan [option]
   3) option
     -v: 정보를 자세히 보여준다.
   4) 사용예
     lvscan
 (7) lvdisplay
   1) 설명: Logical Volume의 정보를 보여준다.
   2) 사용법
     lvdisplay [option] LV명
   3) option
     -v: 정보를 자세히 보여준다.
   4) 사용예
     [root@www root]# lvdisplay -v /dev/lvm/data
       => /dev/lvm/data라는 LV의 정보를 자세히 보여준다.
 (8) vgextend
   1) 설명: 미리 생성된 Volume Group에 추가로 Phycical Volume을 추가할 때 사용한다.
   2) 사용법
     vgextend 볼륨그룹명 새PV명
   3) 사용예
     [root@www root]# vgextend lvm /dev/hdc1
       => lvm이라는 볼륨그룹에 /dev/hdc1을 추가한다.
 (9) vgreduce
   1) 설명: 볼륨그룹에 있는 Physical Volume을 삭제하는 명령이다.
   2) 사용법
     vgreduce 볼륨그룹명 PV명
   3) 사용예
     [root@www root]# vgreduce lvm /dev/hdc1
       => lvm이라는 볼륨그룹에서 /dev/hdc1을 삭제한다.
 (10) lvextend
   1) 설명: Logical Volume의 용량을 확장하는 명령이다.
   2) 사용법
     lvextend 옵션 [볼륨그룹명] LV명
   3) option
     -l +사이즈: 지정한 PE수만큼 용량을 늘린다.
     -L +사이즈[kmgt]: 지정한 사이즈만큼 용량을 늘린다. 단위를 표시하지 않으면 기본 Megabytes
                      단위이다.
   4) 사용예
     [root@www root]# lvextend -L +200M /dev/lvm/data
       => 기존의 용량에 추가로 200MB를 할당한다.
 (11) lvreduce
   1) 설명: Logical Volume의 용량을 줄이는 명령이다.
   2) 사용법
    lvreduce 옵션 [볼륨그룹병] LV명
   3) option
     -l -사이즈: 지정한 PE수만큼 용량을 줄인다.
     -L -사이즈: 지정한 사이즈만큼 용량을 줄인다. 단위를 표시하지 않으면 기본 단위는 Megabytes
                이다.
   4) 사용예
     [root@www root]# lvreduce -L -500 /dev/lvm/data
      => /dev/lvm/data의 용량을 500MB 줄인다.
 (12) vgchange
   1) 설명: 볼륨그룹을 속성을 변경하는 명령으로 볼륨그룹을 사용가능여부, 최대 LV 갯수등을 변경
           할 수 있다.
   2) 사용법
     vgchange 옵션 볼륨그룹명
   3) option
     -a y|n : 볼륨그룹의 사용여부를 지정한다.
     -l 갯수: 해당 볼륨그룹에 생성할 수 있는 최대 Logical Volume수를 지정한다.
   4) 사용예
    ㄱ. [root@www root]# vgchange -a y lvm
         => lvm이라는 볼륨그룹을 활성화시킨다.
    ㄴ. [root@www root]# vgchange -a n lvm
         => lvm이라는 볼륨그룹을 비활성화시킨다.
    ㄷ. [root@www root]# vgchange -l 100 lvm
         => lvm이라는 볼륨그룹을 최대 Logical Volume수를 100개로 지정한다.
 (13) vgremove 
   1) 설명: 볼륨그룹을 제거하는 명령이다.
   2) 사용법
     vgremove 볼륨그룹명
   3) 사용예
     [root@www root]# vgremove lvm
      => lvm이라는 볼륨그룹을 삭제한다.

- rename 

To rename an existing logical volume, use the lvrename command. 			 
				 Either of the following commands renames logical volume lvold in volume group vg02 to lvnew. 			 
lvrename /dev/vg02/lvold /dev/vg02/lvnew
lvrename vg02 lvold lvnew

Take a look at document #A4678152 ("Comparing page size for vmstat, top, glance, ps -el").

1. Top reports free memory in 1kb chunks so to get them to match you must divide tops free amount by 4 to get the true number of 4kb pages free and have it match vmstat. In other words, top reports in 1kb pages so these numbers must be multiplied by 4 to get 4kb kernel pages numbers.

2. For vmstat, avm (active virtual pages) and free (size of the free list) memory are reported in 4kb pages sizes.

3. Glance reports 1kb page sizes. This number will often be significantly different from ps -el since glance reports usage of shared memory also.

From the Glance help window for RSS (* PROC_MEM_RES): The number of KB of resident memory for the process. This consists of text, data, stack, as well as the process' portion of shared memory. This value is similar to the SZ field of the ps -el command, except that the ps command shows only data, stack, and text areas, and it reports their sizes in page units rather than KB. On some systems ps reports the virtual rather than
resident size.

4. ps -el reports in 4kb kernel page sizes.

vsz = The size in kilobytes (1024 byte units) of the core image of the process. See column sz, above.
sz = The size in physical pages of the core image of the process, including text, data, and stack space.

Glance RSS = RSS(* PROC_MEM_RES): The number of KB of resident memory for the process. This consists of text, data, stack, as well as the process' portion of shared memory. This value is similar to the SZ field of the ps -el command, except that the ps command shows only data, stack, and text areas.

Home-Page : http://valgrind.org/
Manual : http://valgrind.org/docs/manual/manual.html
Download : http://valgrind.org/docs/download_docs.html

1. Valgrind 설치

wget http://www.valgrind.org/downloads/valgrind-3.3.0.tar.bz2
tar xvfj valgrind-3.3.0.tar.bz2
cd valgrind-3.3.0
./configure
make
make install

2. Valgrind 테스트
valgrind --leak-check=yes main

3. 간단 실행법
valgrind --tool=memcheck --leak-check=full --show-reachable=yes --log-file=memcheck.txt [프로그램] [실행인자들...]

--leak-check=full : 메모릭에러가 날 경우 소스파일명과 라인위치 출력

               이 옵션을 사용할려면 디버깅컴파일을 해야합니다. (컴파일시 -g 옵션)
--log-file : 체크결과를 저장할 로그파일명

출처 : http://community.snu.ac.kr/blog/blog.log.view.screen.do?blogId=145&logId=333

시스템의 메모리는 항상 거의 다 채워진 상태로 사용된다. 현재 실행되는 프로그램이 모든 메모리를 사용하고 있지 않을지라도 운영체제는 이전에 실행된 프로그램의 텍스트나 파일들을 메모리에 보관하고 있다. 이렇게 보관하는 것으로 인한 시스템 부하는 없다. 왜냐하면, 어쨌든 메모리가 사용되고 있는 것이 아니기 때문이다. 메모리에 보관되고 있는 프로그램이나 파일들이 다시 사용되게 될 때, 추가적인 디스크 I/O를 줄일 수 있는 장점이 있다.

ꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏ

Determining How Much Memory Is Being Used

vmstat

  현재 시스템의 모든 프로세스가 사용하고 있는 가상 메모리(active virtual memeory)와 free list에 등록된 실 메모리의 여유공간을 보여준다.

  시스템의 메모리가 부족한지 튜닝이 필요한지는 vmstat 명령을 여러번 일정한 간격으로 실행하여 pi, po 필드의 값을 검사하여 지속적으로 1이상의 값이 나오면, 메모리가 성능의 제약이 되고 있다고 볼 수 있다. 가끔씩 1 이상의 값이 나오는 것은 무시해도 된다.

  높은 wa와 b 필드값이 동시에 표시되는 경우는 페이징 스페이스에 대한 I/O 때문인 경우가 대부분이다.

kthr     memory             page              faults        cpu

----- ----------- ------------------------ ------------ -----------

 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa

 1  1 37636  1757   0   0   0   2    9   0 468  320 348  0  0 99  0

 0  0 37642  1751   0   0   0   0    0   0 454 1354 357  0  0 99  0

 0  0 37642  1751   0   0   0   0    0   0 452 1301 345  0  0 99  0

 0  0 37643  1750   0   0   0   0    0   0 453 1302 349  0  0 99  0

 0  0 37643  1750   0   0   0   0    0   0 452 1298 345  0  0 99  0

 0  0 37643  1750   0   0   0   0    0   0 453 1299 343  0  0 99  0

VMM과 관련된 성능 문제를 확인하기 위해서는 memory, page 부분을 검사한다.

․ memory

  - avm(active virtual memory)

디폴트 정책인 deferred page space policy를 사용하는 경우에는 이 값이 사용되는 페이징 공간의 크기보다 클 수 있다. 이 값에 file page를 포함되지 않는다.

  - fre

4KB 단위의 사용가능한 실 메모리 페이지 수. free list의 최소유지 값은 vmtune의 minfree 파라미터에 의해서 결정된다. 응용 프로그램이 실행 종료되면, 모든 working page는 즉시 free list에 등록되지만, file page는 메모리에 남게 된다. 만일, 해당 파일이 지워지게 되면, file page도 free list에 등록된다. 이와 같은 이유 때문에 fre 필드의 값이 실제로 시스템의 가용 메모리를 나타낸다고 할 수 없는 것이다.

․ page

  - re

4 버전 이상에서는 더 이상 의미가 없다.

  - pi

페이징 공간에서부터 메모리로 읽혀진 페이지 수. 페이징 공간은 디스크에 존재하며, 메모리에 여유 공간이 없을 경우, 사용된다. pi 필드 값이 존재한다면, 이전에 po 필드에 해당하는 페이지가 out된 기록이 있게 된다. 초당 5이상의 값이 일반적인 기준으로 사용되며, 환경에 따라 달라진다. 절대적인 기준이란 있을 수 없다.

  - po

메모리 부족으로 인해 페이징 공간으로 out된 페이지 수.

  - fr/sr

vmtune의 minfree 파라미터 값 이하로 fr 컬럼의 페이지 수가 감소하게 되면, 페이지 교체 알고리즘이 적용된다. 따라서, VMM은 필요한 메모리를 확보하기 위해서 PFT(page frame table)을 검사하여 할당 해제할 페이지를 찾는다. maxfree 값까지 free 메모리 페이지를 확보할 때까지 페이지를 검사하는데, 이 때 검사한 페이지 수를 sr 필드에 표시하며, 결과적으로 할당 해제된 페이지 수를 fr 필드에 표시하게 된다. 메모리에 사용되지 않는 file page가 많다면, 할당 해제할 페이지를 쉽게 찾을 수 있을 것이며, 이때, sr값이 fr보다 별로 크지 않을 것이다. fr:sr의 비가 높을수록 메모리가 부족하다는 의미다. 1:4(fr:sr) 이라면, 하나의 여유 메모리를 확보하기 위해서  4개의 페이지를 검사해야만 한다는 뜻이다.

  - cy

페이지 교체를 위해서 PFT를 scan한 초당 횟수. 보통, PFT를 다 검사하는 경우는 없으므로 이 필드 값은 보통 0으로 표시된다. 만약, 이 필드 값이 0이 아니다면, 페이지 교체를 위해서 PFT를 검사하는데, 다 검사하도록 원하는 페이지를 얻을 수 없었다는 의미로 시스템의 메모리가 거의 모두 사용되고 있다는 의미다.

  시스템의 RAM이 어느 정도가 필요하나를 대략적으로 추정하는 방법은 vmstat의 avm의 최대값이 얼마인가를 보는 것이다. 이상적으로는 avm 값이 메모리보다 작아야 한다. 이 2값의 차이만큼 페이징이 발생했다는 것을 의미한다. avm이 RAM양 보다 적은데도 페이징 공간에 대한 페이징이 발생한다면, 실 메모리가 file page로 많이 사용되기 때문이다. 이러한 경우에는 minperm/maxperm 파라미터 값을 조절할 수 있다.

vmstat -I

  kthr      memory             page              faults        cpu

-------- -----------   ------------------------ ------------ -----------

 r  b  p   avm    fre    fi  fo  pi  po  fr  sr   in   sy     cs  us sy id wa

 2  1  0 1490301  1396   3   2   0   0   1    4 2719 141591 49393 10 12 78  1

 p 필드는 raw device에 대한 I/O를 기다리는 쓰레드로 파일 시스템에 대한 것은 포함되지 않는다. fi/fo는 file page에 대한 페이징이다.

vmstat -s

  시스템이 부팅된 이후부터의 누적된 통계치를 보여준다. 메모리 사용에 대한 정보를 얻기 위해서는 이 명령을 주기적으로 수행하여 결과치의 차이를 보아야 한다.

ps

  ps v PID 명령을 통해서 각 프로세스마다의 메모리 사용을 알 수 있다.

# ps v 52930

   PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND

 52930      - A     7:17  484  2424   208    xx   370    24  0.0  0.0 ./ns-admi

PGIN

    페이지 폴트로 인해 발생한 page in 수

    모든 페이지 폴트는 I/O 유발하므로 I/O 규모 측정에 사용될 수 있다.

SIZE

    프로세스의 데이터 부분의 가상 크기(페이징 공간), KB 단위

    프로세스의 working segment pages 수와 동일하다.

    다른 플래그의 SZ 필드와 동일하다.

    일부 페이지가 page-out 된 경우에는 사용하고 있는 실 메모리 양보다 크게 표시됨

    private segment, shared-library data segment를 포함하고 있다.

RSS

    프로세스의 실 메모리 크기, KB 단위

    working segment + code segment

    code segment는 프로그램의 모든 인스턴스에 의해서 공유된다.

TSIZ

    프로그램의 text section 크기.

    프로그램의 text section은 touch 될 경우에만 메모리로 로드된다.

    이 값은 active memory 사용량에는 영향을 주지 않는다.

    dump -ov 명령을 통해서 알아낼 수 있다.

TRS

    resident set of text size, number of code segment pages

    인스턴스가 많은 프로그램의 경우, 메모리 사용량을 과장해서 보여준다.

    TSIZ 보다 크게 나오는데, 그 이유는 다른 헤더 정보 등이 추가되기 때문이다.

%MEM

    프로그램이 사용하는 메모리를 전체 메모리로 나눈 것.

    RSS처럼 메모리 사용이 과장되게 나올 수 있다.

※ ps 명령은 shared memory segment나 memory-mapped segment에 의해서 사용되는 메모리는 포함하고 있지 않다. 따라서, 보다 정확한 정보를 보기 위해서는 svmon 명령을 사용해야 한다.

svmon

  현재 메모리에 대한 snapshot을 잡은 것이지만, 사용자 인터럽트를 사용하는 것이므로 진정한 의미의  snapshot이라 할 수 없다.

How Much Memory is in Use

# svmon -G

               size      inuse       free        pin    virtual

memory      2359296    2357650       1646     398806    1492391

pg space    1589248     163665

               work       pers       clnt      lpage

pin          398806          0          0          0

in use      1402168          0     955482          0

․ memory

    size : total size of memory(4KB)

    inuse = size - free

    free : free list 의 페이지 수

    pin : RAM에 pinned된 페이지 수

․ in use / pin

    work : working pages

    pers : persistent pages

    clnt : client pages(remote file pages)

Who is Using Memory?

# svmon -Put 10

-------------------------------------------------------------------------------

     Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd LPage

   16952 atmsvcd           7482     2485     2011     9152      N     N     N

    Vsid      Esid Type Description              LPage  Inuse   Pin Pgsp Virtual

       0         0 work kernel seg                   -   3901  2483 1593  4576

    f01e         d work shared library text          -   2723     0   34  3573

    9d33         2 work process private              -    611     2  381   992

    2084         - pers /dev/hd2:10282               -    126     0    -     -

    c999         - pers /dev/hd2:10303               -     40     0    -     -

     1a0         1 pers code,/dev/hd2:5656           -     31     0    -     -

    508a         - pers /dev/hd2:10287               -     17     0    -     -

    708e         - pers /dev/hd2:10288               -      9     0    -     -

    60cc         - pers /dev/hd4:4120                -      6     0    -     -

    dd3b         f work shared library data          -      4     0    3    11

    50ca         - pers /dev/hd4:4123                -      4     0    -     -

    606c         - pers /dev/hd2:10283               -      3     0    -     -

    21c4         - pers /dev/hd2:10304               -      3     0    -     -

    . . . .

  결과는 요약부분과 상세 설명 부분으로 나뉘며, 메모리 사용량이 많은 프로세스부터 상위 10개를 보여준다.

  segment는 여러 프로세스에 의해서 공유될 수 있는데, 그런 세스먼트에 속하는 페이지는 여러 프로세스에 중복되어 나타날 수 있다. 따라서, inuse 필드 값을 다 더하면, 실 메모리 양보다 많아지게 된다.

  segment id=2084 는 persistent segment이며, /dev/hd2, 즉, /usr 파일시스템에 속하는 파일이며, 126페이지가 실 메모리에 있으며, 페이징 공간에 페이징 되지는 않은 상태이다.

  segment id=60cc는 / 파일시스템에 속하며, 해당 파일의 inode 값은 4120이다.

# ncheck -i 4120 /

4120    /etc/objrepos/CuAt

# find / -xdev -inum 4120 -print

/etc/objrepos/CuAt

Vsid는 virtual segment ID, Esid는 effective segment ID이고 해당 페이지에 접근하는데 사용되는 segment register를 반영한다.

Detailed Information on a Specific Segment ID

# svmon -D 9d33 -b

Segid: 9d33

Type:  working

LPage: N

Address Range: 0..995 : 65312..65535

Size of page space allocation: 381 pages (  1.5 MB)

Virtual: 992 frames ( 3.9 MB)

Inuse: 611 frames ( 2.4 MB)

           Page      Frame    Pin        Ref        Mod  ExtSegid    ExtPage

          65339      80707     Y          Y          Y         -          -

          65340      80708     Y          Y          Y         -          -

          65314      80374     N          Y          Y         -          -

             26      80413     N          Y          Y         -          -

          65338      78852     N          Y          Y         -          -

          65341      81922     N          Y          Y         -          -

          65337      82007     N          Y          Y         -          -

             25      80174     N          Y          Y         -          -

  2개 페이지가 메모리에 pinned 되어 있으며, 대부분의 페이지가 현재 참조되고 있고 변경되어 있다는 것을 알 수 있다. 이는 working segment 이기 때문이다.

※ -D 옵션을 사용하면, 성능에 영향을 주므로 주의해서 사용해야 한다.

List of Top Memory Usage of Segments

# svmon -Sut 10

    Vsid      Esid Type Description              LPage  Inuse   Pin Pgsp Virtual

    4e00         - pers /dev/backup:17               -  71465     0    -     -

    780f         - work kernel heap                  -   7214  3787  329  7245

    8c38         - pers /dev/backup:27               -   6025     0    -     -

    700e         - work misc kernel tables           -   4886     0  673  4886

       0         - work kernel seg                   -   3901  2483 1593  4576

    f01e         - work                              -   2718     0   34  3573

    19ea         - pers large file /dev/hd9var:247   -   2237     0    -     -

    8010         - work page frame table             -   1899  1899    0  1899

    fa56         - pers /dev/backup:24               -   1766     0    -     -

    8831         - work                              -   1665  1665    0  1665

svmon and vmstat

  vmstat free 필드 = svmon memory free 필드

  vmstat avm 필드 = svmon memory virtual 필드

svmon and ps

# svmon -P 9088

-------------------------------------------------------------------------------

     Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd LPage

    9088 bash              6882     2485     1627     8277      N     N     N

    Vsid      Esid Type Description              LPage  Inuse   Pin Pgsp Virtual

       0         0 work kernel seg                   -   3901  2483 1593  4576

    f01e         d work shared library text          -   2718     0   34  3573

    748e         1 pers code,/dev/hd10opt:2421       -    135     0    -     -

    4a80         2 work process private              -     91     2    0    91

    5a82         f work shared library data          -     37     0    0    37

    6de5         - pers /dev/hd2:12307               -      0     0    -     -

# ps v 9088

   PID    TTY STAT  TIME PGIN  SIZE   RSS   LIM  TSIZ   TRS %CPU %MEM COMMAND

  9088  pts/0 A     0:00    2   512  1052 32768   498   540  0.0  0.0 bash

SIZE = virtual size in KB of data section of the process in paging space

      = number of working segment pages of the process have been touched

      = svmon의 private, lib data에서 Virtual 필드 값

      = 91 + 37 pages = 128 × 4 KB = 512

RSS = real memory size in KB of the process

     = sum of the number of working and code segment pages in memory

     = 91 + 37 + 135 pages = 263 × 4 KB = 1052

TRS = size of real memory of text

     = number of code segment pages(not include the shared text of the process)

     = 135 pages = 135 × 4 KB = 540

Calculating Minimum Memory Requirement of a Program

  total memory = T + ( N × ( PD + LD ) ) + F

    T : Number of pages for text(shared by all users)

    N : Number of instance of program

    PD : working segment pages in process private segment

    LD : shared library data pages used by the process

    F : file pages (shared by all users)

예) # svmon -P 8956

-------------------------------------------------------------------------------

     Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd LPage

    8956 cron              6796     2485     1627     8260      N     N     N

    Vsid      Esid Type Description              LPage  Inuse   Pin Pgsp Virtual

       0         0 work kernel seg                   -   3901  2483 1593  4576

    f01e         d work shared library text          -   2718     0   34  3573

    91d2         2 work process private              -     65     2    0    65

    92d2         f work shared library data          -     46     0    0    46

    3ac7         - pers large file /dev/hd9var:21    -     46     0    -     -

    7acf         1 pers code,/dev/hd2:4256           -      8     0    -     -

    88b1         - pers /dev/hd2:6144                -      5     0    -     -

    70ae         - pers /dev/hd2:4099                -      3     0    -     -

    80b0         - pers /dev/hd2:2                   -      1     0    -     -

    18e3         - pers /dev/hd9var:17               -      1     0    -     -

      a0         - pers /dev/hd4:4103                -      1     0    -     -

    4088         - pers /dev/hd3:2                   -      1     0    -     -

    52ca         - pers /dev/hd2:78282               -      0     0    -     -

   T : 7acf = 8

   PD : 91d2 = 65

   LD : 92d2 = 46

   F : 88b1, 70ae, 80b0, 18e3, a0, 4088, 52ca = 12

ꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏ

Finding Memory-Leaking Programs

  memory leak은 프로그램 에러로 인해 메모리 해제를 하지 않고 계속 할당해서 사용함으로써 메모리가 부족하게 되는 현상이다. svmon 명령을 반복적으로 실행해서 프로세스의 working segment 영역이 계속해서 증가하는가를 검사한다. kernel segment의 leak은 mbuf leak이나 device driver, kernel extention, kernel 등에 의해서 발생할 수 있다.

  문제가 되는 서브루틴이나 코드의 줄을 구분하는 것은 매우 어려운 일이다. realloc()은 실제로 에러가 아닌 경우에도 memory leak과 같은 현상을 발생시키게 된다. realloc을 자주 사용하게 되면, 프로세스의 working segment가 점점 증가하게 된다.

  private working segment의 Inuse, Pgspace, Address Range 필드 값이 계속해서 증가할 경우, memory leak을 의심해야 한다.

ꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏ

RMSS simulation

  rmss(Reduced-Memory System Simulator)는 시스템의 메모리 보드를 교체하지 않고도 시스템의 메모리를 감소시킨 상황을 시뮬레이션할 수 있는 도구이다. 시스템의 메모리를 감소시키면서 시스템의 상황 변화를 모니터링 할 수 있다. rmss는 다음과 같은 질문에 답을 얻을 수 있는 자료를 제공한다.

  “일정한 성능을 얻기 위해 필요한 시스템의 메모리는 몇 MB인가?”

  “특정 메모리 양을 가지고 동시에 몇 명의 사용자에게 서비스를 할 수 있는가?”

  rmss는 capacity plan tool로 부하를 감당하기 위해 필요한 메모리 양을 산출하는데 이용되며, problem determination tool로도 사용될 수 있다.

2 Sytles of Using rmss

  - to change the memory size and exit

주어진 메모리 크기에서 응용 프로그램의 실행 상황을 살핀다. 응용 프로그램이 복잡하여 하나의 명령으로 실행할 수 없을 경우 또는 프로그램이 다수의 인스턴스로 실행되는 환경에서 사용한다.

  - as a driver program

응용 프로그램을 메모리 크기를 변화시켜 가면서 실행한다.

※ rmss 명령을 실행하기 전에, memory load control을 off로 설정해야 한다.

        /usr/samples/kernel/schedtune -h 0

to change the memory size and exit

  단위는 MB이며, 8MB에서 시스템 메모리 사이의 값을 줄 수 있다. 시스템의 환경에 따라서 어느 값이하로는 설정할 수 없을 수 있다. 그런 경우에는 에러 메시지를 보여준다.

  rmss는 free page frame의 페이지들을 unusable frame pool에 보관하는 방식으로 메모리를 줄이며, 메모리 크기를 원상태로 하면, pool에서 페이지들을 free list에 추가한다. 또한, rmss는 메모리 크기에 따라 자동적으로 시스템 환경변수와 데이터 구조를 변경한다. 변경하는데 걸리는 시간은 줄이는 메모리 크기에 비례한다.

  # rmss -c 128      memory size = 128 MB

  # rmss -p           current memory size

  # rmss -r           reset to total system memory size

※ rmss 명령은 실제로 사용 가능한 메모리 크기를 보여준다. 따라서, 메모리에 불량 부분이 있으면, 원래 값보다 적게 나온다. 성능에 대한 정보를 따로 제공하지 않기 때문에 다른 도구를 이용하여 성능을 측정하여야 한다.

as a driver program

  # rmss -s 시작메모리 -f 최소메모리 -d 변화량 -n 반복횟수 -o 결과파일 프로그램

  예) rmss -s 16 -f 8 -d 1 -n 1 -o rmss.out foo

Hostname:  widgeon.austin.ibm.com

Real memory size:   16.00 Mb

Time of day:  Thu Jan  6 19:04:04 2000

Command:  foo

Simulated memory size initialized to  16.00 Mb.

Number of iterations per memory size = 1 warm-up + 1 measured = 2.

Memory size  Avg. Pageins  Avg. Response Time    Avg. Pagein Rate

(megabytes)                     (sec.)           (pageins / sec.)

-----------------------------------------------------------------

16.00            115.0           123.9                 0.9

15.00            112.0           125.1                 0.9

14.00            179.0           126.2                 1.4

13.00             81.0           125.7                 0.6

12.00            403.0           132.0                 3.1

11.00            855.0           141.5                 6.0

10.00           1161.0           146.8                 7.9

9.00            1529.0           161.3                 9.5

8.00            2931.0           202.5                 14.5

Avg. Pageins : 프로그램 실행 동안 발생한 모든 page in

Avg. Response Time : 프로그램 실행 시간

Avg. Pagein Rate : Pageins의 평균 비율

  위의 예에서는 14MB까지는 성능에 별다른 영향이 없으나, 13MB 부터는 성능이 점점 저하되는 것을 볼 수 있다. 현재 16MB에서의 성능치가 만족할 수 없다고 메모리를 추가하는 것은 성능에 이점이 없다는 것을 보여준다.

ꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏ

Tuning VMM Memory Load Control

h parameter

  memory load control에 의해서 프로세스가 suspend되는 시점을 정의한다. 임계값을 측정하는데는 po, fr 2가지 값이 사용된다.

  h = 0으로 설정되면, 사용하지 않겠다는 의미이다. 메모리가 128MB 이상이라면 디폴트 값은 0이고, 그렇지 않으며, 6이다. 메모리가 128MB 이상인 경우에는 보통 memory load control을 사용하지 않은 경우가 thrashing 상황을 더 잘 처리한다.

  시스템 설정에 관계없이 po/fr 값이 낮으면, thrashing 상태가 아니다.

        # /usr/samples/kernel/schedtune -h 4

        # /usr/sbin/schedo -o v_repage_hi=4

p parameter

  중지시킬 프로세스를 선택하는 기준으로 사용된다.

  r : number of repages         f : number of page faults

  디폴트 값은 4이다. 따라서, r/f 값이 0.25 이상이면 프로세스가 thrashing 현상을 발생시키고 있다고 볼 수 있다.

        # /usr/samples/kernel/schedtune -p 6

        # /usr/sbin/schedo -o v_repage_proc=6

m parameter

  멀티 프로그램의 최소 한계로, 이 값은 active process 수로 지정된다. 실행되고 있거나 페이지 I/O를 기다리는 프로세스는 active process 이고, 이벤트를 기다리거나 중지된 프로세스나 wait 프로세스는 제외된다.

  memory load control이 실행되더라도 m개의 active process가 실행되고 있도록 하는 것이다.

w parameter

  중지된 프로세스가 기다려야 할 시간.

e parameter

  한 번 중지된 프로세스는 지정한 시간 동안은 다시 중지되지 않는다.

ꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏ

Tunning with vmtune

minfree and maxfree

  free list를 관리하는 파라미터로 minfree 값이하로 free list가 감소하면, 페이지 스틸이 발생하여 maxfree 값이 될 때까지 페이지 스틸이 이루어진다. 미리 free memory page를 확보함으로써 메모리 할당 요청에 대비하며, 불필요한 I/O 발생을 제거한다.

  디폴트 값은 다음과 같다.

        minfree = maxfree - 8

        단, (maxfree - minfree) >= maxpgahead

  memory pool이 하나 이상인 경우에는 각각의 memory pool에 대해서 파라미터 값을 지정할 수 있으며, vmtune에 표시되는 값은 모든 풀의 값을 더한 값이다.

  minfree 페이지는 그 만큼 메모리를 낭비하는 것이다. minfree는 미래의 메모리 할당 요청에 대해 대비하는 것으로 응용 프로그램의 종류와 메모리 사용하는 방식에 대해서 알면, 효과적으로 대처할 수 있다. minfree 값을 설정할 때, 주요 프로그램이 사용하는 메모리를 svmon으로 확인하여 필요한 만큼의 메모리를 minfree로 지정할 수 있다. 이 때의 어려움은 프로그램이 한 번에 많은 메모리를 요구하지 않을 수 있기 때문에 불필요하게 메모리를 낭비하는 결과를 가져올 수도 있기 때문이다.

  minfree = 120 × # of CPUs

  maxfree = minfree + 8 × # of CPUs

  maxfree - minfree <= 100

memory pool

        # vmtune -m N

        # vmo -r -o mempools=N

  시스템 부팅시 메모리 풀 수를 변경하게 된다. 이 값은 커널 설정 파일에 기록된다. 디폴트로는 /usr/lib/boot/unix_mp 파일이며, vmtune은 변경 이전의 파일을 .sav 로 저장한다.

lrubucket

        # vmtune -l N

        # vmo -o lrubucket=N

  대량의 메모리를 가진 시스템에서 LRU 알고리즘에 따른 메모리 스캔의 부하를 감소시키기 위해서 lrubucket 파라미터를 조절할 필요가 있다.

  LRU 알고리즘에 따라 메모리를 스캔하면서 참조비트가 off인 페이지를 스틸하고 참조비트를 리셋한다. 이 과정에서 메모리가 큰 경우에는 많은 페이지를 스캔해야 한다. 따라서, 메모리 frame을 bucket으로 나누어서 관리한다. LRU 알고리즘은 하나의 bucket을 스캔하고 필요한 만큼의 메모리를 확보하지 못하면, 다른 bucket을 스캔하기 전에, 2번째 스캔을 하게 된다.

  디폴트 값은 131072 또는 512 MB 이다.

minperm / maxperm

        # vmtune -p n -P N

        # vmo -o minperm%=n

        # vmo -o maxperm%=N

  numperm : number of file pages in memory

        ․ numperm > maxperm,         steal only file pages

        ․ maxperm > numperm > minperm, repage 비율에 따라서 steal

        ․ numperm < minperm,          page 종류를 가리지 않고 아무거나 steal

  파일 I/O가 주요한 성능 제한 사항인지, computational page를 메모리에 유지하는 것이 중요한지 등에 따라서 설정 값을 변경할 수 있다. 특히, NFS를 사용하는 시스템에서는 보다 많은 file pages를 메모리에 보관할 수 있도록 하는 것이 성능향상에 도움이 된다.

w  File System으로 구성된 Oracle : minperm  10%, maxperm  30%

w  SAP R3(File System Oracle) : minperm  5%, maxperm  10%

strict_maxperm

        # vmtune -h 0|1

        # vmo -o strict_maxperm=0|1

  persistent file cache 에 대한 hard limit을 설정할 것인가? 1로 설정되면, maxperm 값이 hard limit으로 설정되며, 이 값 이상으로 file pages가 증가하게 되면, LRU 알고리즘에 따라 페이지 교체가 file pages 에 대해서 실행된다.

※ 사용할 때, 주의해서 사용하지 않으면, 예기치 않은 결과를 가져올 수 있다.

maxclient

        # vmtune -t N

        # vmo -o maxclient%=N

  JFS2 파일 시스템은 buffer cache로 client pages라는 메모리 페이지를 이용한다. 이 페이지들은 maxperm, minperm 임계값의 영향을 받지 않는다. 이 client pages에 대한 최대값을 지정하는 파라미터가 maxclient 이다.

  사용량이 maxclient 설정값에 도달하면, LRU는 client pages를 스틸한다. client pages를 스틸하고도 모자라면 다른 종류의 페이지도 스틸하게 된다. maxclient 값을 줄임으로써 LRU가 working segment pages를 스틸하지 못하도록 해야 할 필요가 있다. 또한, maxperm 이하로 값을 설정해야 한다.

ꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏ

Tuning Paging Space

´페이징 스페이스 부족과 관련된 에러 메시지는 다음과 같다.

"INIT: Paging space is low"

          "ksh: cannot fork no swap space"

      "Not enough memory"

          "Fork function failed"

          "fork () system call failed"

          "Unable to fork, too many processes"

          "Fork failure - not enough memory available"

          "Fork function not allowed. Not enough memory available."

          "Cannot fork: Not enough space"

npswarn

        # vmtune -w N

        # vmo -o npswarn=N

  페이징 공간의 가용한 페이지 수가 N이하로 줄어들면, OS는 프로세스에게 SIGDANGER 시그널을 보내게 된다. 프로세스는 이 시그널을 무시하거나, 종료하거나, disclaim()을 사용하여 메모리를 해제한다.

  디폴트 값은  max( 512, 4×npskill )

npskill

        # vmtune -k N

        # vmo -o npskill=N

  페이징 공간의 가용한 페이지 수가 N이하로 줄어들면, OS는 프로세스에게 SIGKILL 시그널을 보내고 강제로 종료시키기 시작한다. SIGDANGER 시그널에 응답한 프로세스나 early 할당 정책을 사용하는 프로세스는 영향을 받지 않는다.

  디폴트 값 = max(64, NumberOfPagingSpacePages/128)

nokilluid

        # vmtune -n N

        # vmo -o nokilluid=N

  uid가 N 이하인 사용자 프로세스는 npskill 파라미터의 영향을 받지 않는다.

fork() retry interval

  페이징 공간 부족으로 새로운 프로세스를 fork하지 못할 경우, 스케줄러는 5번 재시도한다. 이 때, 재시도 간격은 10clock tick이 디폴트이다.

        # schedtune -f N (clock tick)

ꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏ

Page Space Allocation Method

LPSA(Late Page Space Allocation)

  ․ allocated when actually touched(the page was modified somehow)

  ․ 페이지는 프로세스가 page-out 될 때, 할당된다.

  ․ 프로세스가 page-out될 가용한 공간을 항상 보장할 수 없다.

EPSA(Early Page Space Allocation)

  ․ paging space pages reserved when processes use malloc()

  ․ 프로세스가 페이징 공간 부족으로 kill되지 않는 것을 보장한다.

  ․ PSALLOC=early

DPSA(Deferred Page Space Allocation)

  ․ allocation delayed until necessary to page out the page

  ․ additional overcommitment of paging space

  ․ 한 번 page-out 페이지가 다시 RAM에 page-in 되더라도 그 공간은 reserved 됨.

  ․ 다음 경우에 할당된 페이지가 해제된다.

    - working segment로 page-in된 페이지

    - 쓰레드가 할당을 해제한 경우

    - thread exit

# vmtune -d 0|1      (DPSA=1)

# vmo -o deffps=0|1

  vmstat(avm), ps(SIZE, SZ) 등의 도구들은 DPSA 정책에 따라 실제로 access된 가상 메모리 크기를 보여준다. 반면에 svmon은 실제로 사용된 페이징 공간 크기를 보여주므로, 이 값은 vmstat의 avm 값보다 작게 출력된다.

  lsps -a는 실제로 사용되는 페이징 공간만을 보여준다, 그러나. lsps -s는 사용되지 않고 있지만, reserve된 페이징 공간도 고려해서 보여준다. 따라서, lsps -s 명령을 사용하는 것이 좀 더 정확하다고 할 수 있다.

ꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏ

Shared Memory

  shmat(), mmap()을 사용하여 파일들을 명시적으로 메모리에 매핑시킬 수 있다. 이렇게 함으로써 버퍼링과 시스템 콜로 인한 부하를 피할 수 있다. 이러한 메모리 영역을 shared segments라 한다. 4.2.1 버전 이후부터 32비트 응용 프로그램에만 적용된다. 11개의 shared memory segments 제공된다. 각 segment는 256MB 크기다. 응용 프로그램은 이러한 공유메모리 세그먼트에 read/write 함으로써 파일에 대한 read/write을 수행할 수 있다. 또한, 세그먼트에 대한 포인터를 사용하기 때문에 read/write system call로 인한 부하를 피할 수 있다.

  파일과 데이터는 다수의 프로세스에 의해서 공유될 수 있는데, 공기화 문제는 응용 프로그램에서 해결해야 한다. 전형적인 예로는 데이터베이스 프로그램이 공유 세그먼트를 데이터 베이스 버퍼 캐쉬로 사용한다.

  shared memory segments에 대한 페이징 공간도 할당된다.

EXTSHM(Extended Shared Memory)

  각 shared memory region은 크기에 관계없이 256MB 크기의 메모리 공간을 사용한다. 4.2.1 버전부터는 EXTSHM을 통해서 1바이트에서 256MB까지 크기를 지정할 수 있다.

  EXTSHM을 통해서 11개 세그먼트의 제한은 사라지게 되었다. EXTSHM을 사용하기 위해서는 프로그램의 환경 설정에 EXTSHM=ON으로 설정하면 사용할 수 있다. 프로세스가 사용할 수 있는 segment의 수에 대한 제한은 없으며, 사용하는 메모리 공간의 크기는 여전히 256MB 의 배수이다.

ꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏꠏ

Memory Affinity Support

  POWER 기반의 SMP 장비들은 다수의 MCM을 포함하고 있다. 시스템 메모리는 이러한 MCM에 부착되어 있다. 모든 프로세서가 어떤 메모리에도 접근할 수 있지만, 자신의 MCM에 부착되어 있는 메모리에 접근하는 것이 제일 빠르다.

  따라서, page fault를 발생시킨 프로세서의 MCM에 부착된 메모리에서 page fault를 해결하도록 하는 것이 memory affinity support이다.

        # vmtune -y 0|1

        # vmo -r -o memory_affinity=0|1

    ※ bosboot, reboot를 반드시 해줘야만 효과가 있다.

  응용 프로그램에서 이 기능을 사용하기 위해서는 환경 변수를 설정해야 한다.

        # export MEMORY_AFFINITY=MCM

출처 : http://estenpark.tistory.com/133

사실 여러가지 방법으로 메모리 확인 방법을 생각 해봤다.
ps -ef -o rssize,comm 으로 전체의 합을 전체 메모리를 나눠서 계산하는 방법을 했지만 정확한 데이터가 나오지 않았다.

관제 대상을 가지고 있는 어떠한 툴로 사용하면 좀 더 정확한 UI형식의 결과물을 볼 수 있을 수 있을 것이다.

소개하려는 명령어는  svmon 명령어 이다.
메모리의 현재 상태에 관련하고 실제 메모리의 스냅샵을 구성하는 것이 아니라 명령어의 인터럽트가 가능한 사용자 레벨에서 수행 가능 하다. 즉 root 권한만 수행 할 수 있는 명령어라고 할 수 있다.

중요한 개념을 잡아야 하는데 그 이유는  svmon명령어는 페이지 별로 통계 해준다는 것이다.

• 1페이지 가상 메모리의 4K 블록
• 1프레임은 실제 메모리의 4K 블록
• 어떠한 명시가 없다면 기본적으로 통계는 4096바이트 메모리 페이지 단위
  

• 1번의 실제 메모리 사용 설명
  
• 전체 사이즈 [ size ] : 1831616
• 페이지 포함 프레임 수 [ inuse ] : 2028009
• 모든 메모리 중 남은 공간(프레임수) [ free ] : 5412
• 고정 페이지의 프레임 수 [ pin ] : 391022
• 가상 영역의 할당된 페이지 수 [ virtual ] : 1082699
• 2번의 실제 메모리의 서브세트
  
• 작업 세그먼트 페이지를 포함하는 프레임 수 [ work ] : 390788
• 영구 세그먼트 페이지를 포함하는 프레임 수 [ pers ] : 0
• 클라이언트 세그먼트 페이지를 포함하는 프레임 수 [  clnt ] : 234
• in use ( 사용중인 실제 메모리의 서브세트)
• pin(고정된 페이지가 있는 실제 메모리의 서브세트)
  
• 3번 페이지 공간의 사용을 설명하는 통계
  

메모리 스왑/실제 메모리 통계 스트립트

• 위의 스크립트를 보면  awk처리와 perl 처리를 두가지 버전으로 만들어 봤다.
• 둘다 장단점은 있지만 확실히 perl로 하는 것이 더 좋다는 생각이 든다.
  

참고한 자료
http://www.sung-ho.pe.kr/index.php?p=20391

출처 : http://coffeenix.net/board_view.php?bd_code=36

출처 : http://kuaaan.tistory.com/trackback/142

delete와 delete[], new와 new[]를 구분해서 사용해야 하는 이유 :

delete를 사용하든 delete[]를 사용하든 메모리는 정상적으로 해제된다. 하지만 4바이트 INT 타입의 10개짜리 Array를 메모리해제할 경우 delete[]를 사용하면 4바이트씩 10번 해제하지만 delete를 사용하면 40바이트짜리 메모리를 한번 해제한다. 

new 실패에 따른 프로세스 종료원인을 찾다가 좋은 정보를 찾았습니다.

블로깅...

출처 : http://kuaaan.tistory.com/123

동적 메모리를 다음과 같이 사용하였습니다. 어디가 틀렸을까요?

LPINT lpInt = NULL; lpInt = (LPINT)malloc(sizeof(INT)); *lpInt = 4; printf("Value : %d\r\n", *lpInt); free(lpInt); LPINT lpInt = NULL; lpInt = (LPINT)malloc(sizeof(INT)); if (lpInt == NULL) { printf("Fail to alloc memory!!\r\n"); return FALSE; } *lpInt = 4; printf("Value : %d\r\n", *lpInt); free(lpInt); LPINT lpInt = NULL; INT nTotalBytes = 0, nAllocByte = 10000000; while(TRUE) { lpInt = NULL; lpInt = new INT[nAllocByte]; nTotalBytes += nAllocByte * sizeof(INT); if (lpInt == NULL) { printf("Fail to alloc memory!!\r\n"); break; } printf("Alloc Success!! (%d)\r\n", nTotalBytes); } // blah~ blah~ 말하자면, new 연산자가 메모리 할당에 실패했을 경우, C++ 스탠다드에 따라 std::bad_alloc Exception을 throw한다는 의미입니다. exception이 throw되었기 때문에 넘겨받은 포인터가 NULL인지 체크하는 부분까지 진행되지도 않고 프로그램이 종료된 것입니다.

음. 그렇다면 다음과 같이 코딩하면 메모리 할당 예외처리가 가능하겠군요.

view plaincopy to clipboardprint?

1. try  
2. {  
3.     LPINT   lpInt = NULL;  
4.     INT nTotalBytes = 0, nAllocByte = 10000000;  
5.   
6.     while(TRUE)  
7.     {         
8.         lpInt = NULL;  
9.   
10.         lpInt = new INT[nAllocByte];  
11.         nTotalBytes += nAllocByte * sizeof(INT);  
12.   
13.         printf("Alloc Success!! (%d)\r\n", nTotalBytes);  
14.     }  
15. }  
16. catch ( exception e )  
17. {  
18.     printf("%s\r\n", e.what( ));  
19. }  

try { LPINT lpInt = NULL; INT nTotalBytes = 0, nAllocByte = 10000000; while(TRUE) { lpInt = NULL; lpInt = new INT[nAllocByte]; nTotalBytes += nAllocByte * sizeof(INT); printf("Alloc Success!! (%d)\r\n", nTotalBytes); } } catch ( exception e ) { printf("%s\r\n", e.what( )); }

코드를 위와 같이 수정하고 실행시키면 다음과 같이 동작하게 됩니다.

종료되기 직전 부분을 보면 제대로 Exception Handling이 되었다는 것을 알 수 있습니다.

그런데, 동적메모리 할당할 때마다 이와 같이 try ~ catch를 해주려면 너무 귀찮죠. 성능 문제로 try ~ catch를 사용하시지 않는 경우도 있구요. 더 좋은 방법은 "new handler"를 등록해주는 것입니다.

MSDN을 좀 더 검색해보면 "new handler"에 관한 내용이 나와 있습니다.

If the attempt is successful, the function returns a pointer to the allocated storage. Otherwise, the function calls the designated new handler. If the called function returns, the loop repeats. The loop terminates when an attempt to allocate the requested storage is successful or when a called function does not return.

The required behavior of a new handler is to perform one of the following operations:

• Make more storage available for allocation and then return.

• Call either abort or exit(int).

• Throw an object of type bad_alloc.

The default behavior of a new handler is to throw an object of type bad_alloc. A null pointer designates the default new handler.

The order and contiguity of storage allocated by successive calls to operator new(size_t) is unspecified, as are the initial values stored there.

위의 내용을 요약해보면 다음과 같습니다.

1. new 연산자가 메모리 할당에 실패한 경우 "new handler"로 지정된 함수가 호출된다. 이 함수가 리턴한 다음에 메모리 할당이 실패한 시점부터 계속 실행된다.

2. "new handler" 는 다음의 세가지 작업 중 한가지를 수행해야 합니다.

1) 메모리를 확보한 후 return한다.

2) 프로세스를 종료시킨다.

3) bad_alloc 을 throw한다.

3. Default "New Handler"는 bad_alloc 을 throw 한다.

음, new 연산자가 메모리 할당에 실패했을 때 bad_alloc이라는 exception이 throw 되는데, 이것은 사실은 Default로 등록된 "new handler"에서 하는 일이라는 것을 알 수 있네요.

그렇다면, 이 내가 원하는 함수를 "new handler"로 등록하려면 어떻게 해야 할까요??

new_handler set_new_handler(
   new_handler _Pnew
) throw( );

출처 : google "가상 메모리 관리 (AIX Virtual Memory Management) 검색 결과의 Doc 문서.

가상 메모리 관리 (AIX Virtual Memory Management)


Virtual Address Space

Virtual address space란 프로세스가 참조하는 어드레스 범위이며, AIX에서는 16개의 Segment와 각 segment당 256MB로 구성된다. 따라서 최대 4GB의 virtual address space를 가지고 있다. Kernel의 경우 virtual address space를 모두 사용할 수 있지만, Process의 경우에는 제한된 공간만 참조할 수 있다.

Demand Paging

Data는 참조되는 순간에만 실제 Page(Real Memory 최소 관린 단위)에 복사되며, Mapping은 사용자가 인식할 수 없는 순간에 수행된다.

Data는:
    A page from the page space.
    A page from a file on disk.

AIX에서는 kernel 또한 페이징을 사용하며, 페이징되지 않는 영역을 'pinned'라고 한다. 하지만, 대부분의 Kernel 영역은 페이징 영역을 사용하고 있다. Pager daemon은 실제 Page(Real Memory 최소 관린 단위)를 pool로 유지하기 위해, 사용 가능한 page 개수가 high-water mark 이하이면 low-water mark에 도달할 때 까지 가장 오래된 pager를 삭제하게 된다(LRU 알고리즘).

Memory Management Definitions

• Page - 고정된 Memory의 최소단위(Size : 4096 bytes for AIX)
• Paging Space - Inactive 상태인 메모리 페이지를 유지하기 위해 memory manager에 의해 사용되는 disk 공간
• Real Memory - 시스템 내부에 장착된 실제 메모리
• Virtual Memory - system memory manager에 의해 프로그램 및 프로세스에 주어진 메모리
• Address Space - 메모리를 접근하는 프로그램에서 활용하는 address set

Virtual Memory

Virtual Memory 개념을 도입함으로써, 연속적인 address space를 가지는 사용자 프로그램이 대용량 메모리를 사용할 수 있으며 시스템의 physical memory 크기보다 큰 공간도 할당할 수 있다.

• 
  Virtual Memory Mapping은 H/W에 의해 이루어지며, 보통 실 메모리와 paging space에 펼쳐진다.
• H/W & S/W에 의해 관리되는 최소 단위는 1Page 이며, Page Fault 발생시 Virtual Memory Manager는 virtual memory address를 사용하는 프로그램 및 프로세스에 page fault 발생한 내용을 보내기 위해 작업을 시작한다.

Hardware Address Translation

32bit virtual address

• Segment register : 가장 앞 단의 4 bit( segment ID를 포함 )
• Virtual page index : segment register이후의 16bit( segment page )
• Byte offset : 마지막 12 bit( page offset )

2^4 = 16 ( 가장 앞 단위 4bit은 16개의 segment register중 하나를 선택한다. )
2^28 = 256 MB( 각 segment는 256 MB로 구성: virtual page index + byte offset )
2^12 = 4K( 각 page 단위는 4K )
16 segment * 256 MB/segment = 4 GB
2^32 = 4GB( 32 bit virtual address space )


    T=0 - Always 0 for memory space
    Ks - Supervisor-state protection key
    Kp - User-state protection key
    N - No-execute protection

64-bit Segment Table




Memory Segments

1.     각각의 Segment는 page 단위로 분리된다.

o    Segment는 프로세스간에 공유될 수 있다.

o    추가의 virtual page가 Segment에 mapping 될 수 있다.

o    이미 사용중인 segment는 프로세스로 지정될 수 도 있고 분리될 수 도 있다.

o    신규 segment는 프로세스에 의해 할당되거나 제거된다.

2.     Virtual address는 segment register로 구성된다.

3.     Segment type

o    Working: 프로그램 실행동안 stack/data 영역으로 사용되는 temporary memory

o    Persistent: Local file system을 위해 file data를 저장하는 memory

o    Client: NFS or CD-ROM과 같이 client file system를 위해 사용되는 memory

o    Log: Journalling 작업동안 file system이 쓰고 읽는데 사용되는 memory

o    Mapping: Application이 동일한 memory segment에 여러 object를 배치하도록 mmap() interface를 지원하기 위해 사용

4.     Virtual Page는 실제 memory page 또는 disk drive와 같은 이차 저장매체와 연관되어 있다.

5.     Memory Segment 종류

o    Kernel

o    User Text

o    Shared Library Text

o    Shared Data

o    Process Private

o    Shared Library Data

Segment Register Map in 32-bit User Mode

Segment

-----------------------------------------------------

 0x0         Kernel Segment (only parts visible)

 0x1         User Text

 0x2         User Data, Initial User Thread Stack

 0x3         Available for User (shmat, mmap)

 0x4-0xb     Available for User (shmat, mmap)

 0xc         Available for User (shmat, mmap)

 0xd         System Shared Library Text Segment

 0xe         Available for User (shmat, mmap)

 0xf         Pre-Process Shared Library Data Segment

Large Address Space Model in 32-bit

AIX에서는 user data 영역으로 256MB 이상을 지원하며, 이 경우 maxdata binder option을 지정하여야 한다. 또한 Large user data 프로그램은 segment 3에서 malloc를 수행하여, 최대 8개의 segments(1020*1024*256*8, 2GB) 사용할 수 있다. 하지만 이 경우에도 여전히 segment 1의 user text 및 User Stack인 segment 2는 256MB로 제한되며, segment 11 및 12는 large address space model에 의해 사용할 수 없다.

Large Address Model Compile Option

기본 option으로 Compile을 하는 경우 하나의 Segment가 가질 수 있는 256MB 이상을 참조할 수 없다. 그래서 Large Address가 필요한 프로그램의 경우 아래와 같은 Option을 주어야 가능하다.

cc sample.o -bmaxdata:0x80000000 -> 필요에 따라 segment 개수를 변경할 수 있으며, 최대 8개의 segment를 지정할 수 있음.

-----------------------------------------------------------------------------------------------------------------

출처 : https://www.spec.org/mpi2007/flags/IBM-AIX.html

그렇다면 AIX 관련 컴파일 옵션 및 관련 설명을 보도록 하자.

IBM AIX: Environment Settings and Utilities

IBM AIX 5L V5.3

IBM AIX V6

Last updated: 04-Aug-2008

System and Other Tuning Information

• drmgr -r -c cpu
Deconfigures one core from the active partition. Use it N times to deconfigure N cores.
• smtctl -m on|off -w now|boot

Controls the enabling and disabling of processor simultaneous multi-threading mode.
• vmo -r -o lgpg_regions=n -o lgpg_size=16777216

Sets the size of large pages to 16M, and set the number to use, with -r, takes effect on the next IPL.
• bosboot -q

Regenerates the IPL boot to set the options specified with smtctl and vmo.
• ulimit

Controls resources allowed to be used by processes. All resource are set to unlimited, of primary importance is the "stack" and "data/heap" settings for SPEC CPU2006 and MPI2007.
• chsyscfg -m system -r prof -i name=profile,lpar_name=partition,lpar_proc_compat_mode=POWER6_enhanced

This command enables the POWERPC architecture optional instructions supported on POWER6.

Usage: chsyscfg -r lpar | prof | sys | sysprof | frame
                -m <managed system> | -e <managed frame>
                -f <configuration file> | -i "<configuration data>"
                [--help]

Changes partitions, partition profiles, system profiles, or the attributes of a
managed system or a managed frame.

    -r                        - the type of resource(s) to be changed:
                                  lpar    - partition
                                  prof    - partition profile
                                  sys     - managed system
                                  sysprof - system profile
                                  frame   - managed frame
    -m <managed system>       - the managed system's name
    -e <managed frame>        - the managed frame's name
    -f <configuration file>   - the name of the file containing the
                                configuration data for this command.
                                The format is:
                                  attr_name1=value,attr_name2=value,...
                                or
                                  "attr_name1=value1,value2,...",...
    -i "<configuration data>" - the configuration data for this command.
                                The format is:
                                  "attr_name1=value,attr_name2=value,..."
                                or
                                  ""attr_name1=value1,value2,...",..."
    --help                    - prints this help

The valid attribute names for this command are:
    -r prof     required: name, lpar_id | lpar_name
                optional: ...
                          lpar_proc_compat_mode (default | POWER6_enhanced)

• bindprocessor $$ <n>

The next program is to be bound to the specified processor.

Environment variables set before the run:

• MEMORY_AFFINITY=MCM

Cause the OS to alloc memory "closest" to the chip that first requests it.
• XLFRTEOPTS=intrinthrds=1

Causes the Fortran runtime to only use a single thread.
• MALLOCOPTIONS=POOL

Selects the OS malloc option that allocates/frees small objects very quickly.

Using static and shared libraries across platforms

I produced hereafter some information about shared libraries on different systems. However, this information is probably very sparse on details and may even not be up-to-date. Actually, keeping track of changes is nearly impossible.
The definitive information usually comes from the operating system docs. (e.g. HP's "HP-UX Linker and Libraries User's Guide", Sun's "Linker and Libraries Guide", SGI's "MIPSpro Compiling and Performance Tuning Guide", IBM's "AIX Linking and Loading Mechanisms", etc.), where there is often advice on the best options for performance.
GNU libtool offers an abstraction layer to shared library management.

Feedback is welcome.

Adapted from:
Cross platform development, Using Shared Libraries across Platforms, Shah, Amal ; Xiao, Hong, C/C++ Users Journal, May 1998, Volume 16 Number 5

Notes:

• cells with xxxx implies that the OS does not support that particular feature. ?? means I don't know.
• some compilers offer some extensions to control how symbols are exported. For instance, gcc (4.0 and later) implements "__attribute__((visibility("hidden")))" for ELF targets.
• papers related to versioning
• How to write shared libraries, Ulrich Drepper

Acknowledgments

Juan Altmayer Pizzorno, Wolfgang Haefelinger, Per Losenborg, Anil E. Sahukar, Andrew Stalewski, Pirasenna Velandai Thiyagarajan, Nathan Stratton Treadway, Stephan Weber, Bo Xie

1. prstat -s rss

   '-s' sorts prstat output by rss column (see man page for other columns). Also try '-a' option for a per user accumulation.

2. ps -eo pid,pmem,vsz,rss,comm | sort -rnk2 | head

   Top 10 RAM consumers. '-o pmem' displays percentage of resident memory i.e. RAM used by process.

3. ls -lh /proc/{pid}/as

   Easy way to show total address space (vsz) of a process. Useful in combination with pgrep to accumulate by user, pattern, ... e.g.:

   for pid in `pgrep -U webserver`; do ls -lh /proc/$pid/as; done

UNIX 및 Linux 운영 체제에서 ulimit 값 설정

출처 : http://no1rogue.blog.me/30097158983

* 메모리 맵 - mmap() <파일 혹은 디바이스를 메모리와 대응>

; 파일(리눅스에서는 디바이스도 파일로 처리하므로 디바이스도 메모리 맵으로 연결 가능)을 처리하기 위해서는 보통 저수준으로는 파일 디스크립터를 이용하고, 고수준으로 접근하기 위해서는 파일 구조체 포인터를 이용하여 접근하게 된다. 하지만 이런 방식을 이용하면 버퍼를 거쳐서 실제 입출력을 하게된다. 하지만 mmap()을 이용하여 메모리 맵 방식으로 파일을 연결하게 되면 버퍼를 이용하는 것이 아니라 '페이지(page)'를 이용하여 데이터 처리가 가능해진다. 상대적으로 크기가 작은 버퍼에 비해 보통 4KB의 크기를 가지는 페이지를 이용하면 처리 가능한 크기와 처리 속도가 향상된다. 그렇기 때문에 데이터 크기가 크거나 빠른 처리를 해야하는 경우 메모리 맵 방식을 종종 사용하게된다. 메모리 맵을 사용하면 처리 속도가 빨라지는 예가 바로 처리하는 데이터가 큰 동영상을 볼 때이다. 그리고 실제 실행 파일도 윈도우든 리눅스든 실행 할 때 페이지로 분할되므로 메모리 맵 방식으로 매핑된다. 대표적으로 코드 영역은 데이터의 변경이 없기 때문에 메모리 맵을 이용해 맵핑하면 처리 속도는 물론이고 메모리 낭비도 없다. 

* 특징

1. 생성된 메모리 맵을 포인터를 이용하여 쉽게 사용 가능하다.

2. 파일로 연결하여 사용시 메모리-파일 사이의 동기화가 편하다.

3. IPC(프로세스간 통신)로 활용 가능하다.

4. 대용량의 데이터를 사용할 시 성능이 향상된다.

* 주의점

- 메모리 맵은 바로 파일의 처리하는게 아니라 가상 메모리로 활용되는 페이지에 맵핑하는 방식이다. 그러므로 파일과 해당 메모리 맵이 된 페이지가 다른 공간이다. 그러므로 커널에 의해 여유 시간에 동기화(둘의 데이터가 같아지는..)가 될 때까지 서로 다른 데이터를 가질 수 있다. 그러므로 동기화에 대한 주의를 할 필요가 있다. <개발자가 직접 커널에 동기화를 명령 할 수 있는 함수도 있다. - fsync()>

 IPC로 사용 할 때에도 프로세스간 동기화에 대한 주의도 필요하다.

* 2가지 방식

1. 공유 메모리 맵 방식 (Shred Memory-Map)

; 메모리 맵 변경 시 원본 파일과 데이터가 동기화가 되는 방식

2. 복사 메모리 맵 방식 (Private Memory-Map)

; 처음 메모리 맵에 매핑 될때 파일의 내용을 읽어와서 복사하고 그 이후 동기화 하지 않는 방식.

* 메모리 맵 생성 함수 - mmap()

void* mmap(void *state, size_t length, int prot, int flags, int fd, ott_t offset);

- void *state

; 할당받기 원하는 메모리 주소. 보통 0을 써서 커널이 적합한 공간을 임의로 할당해 주소를 받을 수 있고, 직접 입력하여 사용해도된다. 하지만 직접 입력하는 경우 해당 시스템의 페이지 (배수)단위로 주소 값을 설정해줘야 한다.

- size_t length

; 메모리 맵을 할 크기. 바이트 단위로 설정한다.

- int prot

; 메모리 보호 메커니즘. 플래그 형식이므로 비트 연산으로 복수 속성으로 지정 가능하다.

 + PROT_EXEC; 해당 페이지 실행 가능.

 + PROT_READ; 해당 페이지 읽기 가능.

 + PROT_WRITE; 해당 페이지 쓰기 가능.

 + PROT_NONE; 해당 페이지 접근 불가.

 => 매핑할 파일 디스크립터와 속성이 같아야한다.

- int flags

 + MAP_SHARED; 공유 메모리 맵 방식.

 + MAP_PRIVATE; 복사 메모리 맵 방식.

 + MAP_FIXED ; 메모리 시작 번지 지정시 사용.

 =>MAP_SHARED/MAP_PRIVATE 둘 중에 한개만 지정해야된다.

- int fd

 ; 메모리 맵 방식을 사용할 파일 디스크립터.(파일 혹은 디바이스)

- ott_t offset

 ; 해당 파일 디스크립터에서 메모리 맵을 시작할 오프셋 값.

; 메모리 맵핑이 이루어진 가상 메모리 주소. 실패시 MAP_FAILED가 발생하고 errno에 해당 상황에 대한 값이 설정된다.

* 메모리 맵 해제 - munmap()

; 메모리 맵을 사용하고 자원을 해제 할 때 사용한다.

int munmap(void *start, size_t length);

- void *start

; 메모리 맵핑이 시작된 주소. mmap()의 반환 값을 넣으면된다.

- size_t length

; 메모리 맵을 한 길이. mmap() 사용시 size_t length 인자와 크기를 주면된다.

+ return value

;성공 0, 실패 -1

* 메모리 맵과 파일의 동기화 - fsync()

; 메모리 맵에 데이터를 갱신해도 바로 파일과 동기화가 이루어지는 것은 아니다. 커널이 여유 있을 때 동기화를 수행한다. 그러므로 개발자가 직접 동기화를 보장하고 싶을 때 사용한다. 그리고 munmap()을 하여 메모리 맵을 해제 할때에도 동기화를 해주면 데이터가 보장된다.

int msync(void *start, size_t length, int flags);

- void *start

; mmap()를 통해 리턴 받은 메모리 맵의 시작 주소.

-  size_t length

; 동기화를 할 길이. 시작 주소로 부터 길이를 지정하면 된다.

- int flags

 + MS_ASYNC

 ; 비동기 방식. 동기화(Memory->File)하라는 명령만 내리고 결과에 관계 없이 바로 리턴.

   그렇기 때문에 동기화가 된 건지 알수 없다.

 + MS_SYNC

 ; 동기 방식. 동기화(Memory->File)가 될때까지 블럭 상태로 대기한다.

 + MS_INVALIDATE

 ; 현재 메모리 맵을 무효화하고 파일의 데이터로 갱신. 즉 File->Memory

===================================================================================

       ...

#define MMAP_FULENAME "test_mmap"

#define MMAP_SIZE 64

       ...

int main()

{

     int fd;

     char *p_mmap;      //메모리 맵으로 사용할 데이터 타입

       ...

     fd = open(MMAP_FILENAME, O_RDWR|O_CREAT, 0664);

       ...

     p_mmap = (char*)mmap((void*)0, MMAP_SIZE, PROT_READ|PROT_WRITE,

                                                                     MAP_SHARED, fd, 0);

     //공유 메모리 방식을 사용한다. 읽기/쓰기 가능

       ...

     //memcpy(); 등으로 메모리 맵 데이터 갱신.

       ...

     msync(p_mmap, MAP_SIZE, MS_SYNC);

       ...

     munmap(p_mmap);

     return 0;

}

=> 메모리 맵 할 파일 이름만 같으면 IPC도 된다.

------------------------------------------------------------

출처 : http://hsnote.tistory.com/141

윈도우의 경우는 아래의 자료를 참고.

[메모리 매핑파일]

HANDLE CreateFileMapping(HANDLE hFile,    // (1)
   LPSECURITY_ATTRIBUTES lpAttributes, //(2)
   DWORD flProtect,  // (3)
   DWORD dwMaximumSizeHigh,  // (4)
   DWORD dwMaxImumSizeLow,  // (5)
   LPCTSTR lpName   //(6)
   );

위의 함수가 매모리매핑 파일을 만드는 함수이다..

위의 함수 사용시 매모리맵파일이 생성은 되지만 실제로 매모리에 연결되어 있진않다. 

연결을 하려면 MapViewOfFile 이라는 함수를 써야지 그 때부터 메모리에 연결이 된다.

일단위 함수의 설명을 들어보자

목적 및 하는 일 : MMF라는 커널 객체를 만들고 그 핸들을 리턴한다.
                         메모리매핑파일을 만들수있는 기본정보들을 갖고 있는 커널객체를 만들고 그 핸들을 리턴한다.

인자설명 : 
 (1) hFile  : CreateFile 함수로 해당파일을 열고 리턴받은 값.. (CreaqteFile 의 리턴값  파일핸들) 파일핸들을 인자로 넘겨준다.. , (어떤파일을 파일매핑할건지 정하는거다.)
 
 (2) lpAttributes : 솔직히 잘 모르겠는데 .. 보통 이값은 NULL로 줬다. (아시는 분은 좀 알려주세여^^)

 (3) flProtect : 읽기 전용으로 할건지 읽기 쓰기를 할건지 설정하는 옵션이다. ex) PAGE_READONLY, PAGE_READWRITE 등등

 (3) dwMaximumSizeHigh : 매핑할 범위를 지정하는 상위 4바이트 (용량이 작은 범위라면 이곳에 0을 주고 그 다음 인자에 파일크기 및 원하는 범위를 지정한다.)
 
 (4) dwMaximumSizeLow : 매핑할 범위 지정하는 하위 4바이트

 (5) lpName : 파일매핑 객체이기 때문에 객체에 이름을 부여할때 쓴다. 보통   NULL을 주고 이름을 붙이도 다른곳에서 참조할때는 이름을 문자열로 이름을 지정한다.

사용예제 ) CreateFileMapping(hSource, NULL, PAGE_READONLY, 0, dwFileSize, NULL);
 
 CreateFileMapping(hTarget, NULL, PAGE_READWRITE, 0, dwFileSize, NULL);

------------------------------------------------------------------------------------------------------------------------------

LPVOID MapViewOfFile(HANDLE hFileMappingObject, // (1)
   DWORD dwDesiredAccess,  // (2)
   DWORD dwFileOffsetHigh,  //(3)
   DWORD dwFileOffsetLow,   // (4)
   SIZE_T dwNumberOfBytesToMap   // (5)
  );

목적 및 하는 일 : CreateFileMapping 함수로 만든 MMF 객체를 대상으로 실제 메모리번지에 연결을 하여 메모리 매핑파일을 만든다.
  메모리 매핑파일 만들고 그 메모리의 시작번지를 리턴한다.

인자설명 :
 (1) hFileMappingObject : CreateFileMapping 함수로 리턴받은 핸들값을 인자로 준다.

 (2) dwDesireAccess : 접근권한을 설정하는 것으로 FILE_MAP_READ, FILE_MAP,WRITE 등으로 옵션을 준다.

 (3) dwFileOffsetHigh :  메모리 주소가 연결될 크기 상위 4바이트

 (4) dwFileOffsetLow : 메모리 주소가 연결될 크기 하위 4바이트

 (5) dwNumberOfBytesToMap : 오프셋으로 부터 원하는 크기를 정한다.

사용예제 ) MapViewOfFile(hMapSource, FILE_MAP_READ, 0, dwAs, dwLen);

 MapViewOfFile(hMapTarget, FILE_MAP_WRITE, 0, dwAs, dwLen);

------------------------------------------------------------------------------------------------------------------------------

해당함수들을 사용후에는 해제 해주어야 하는데

CreateFileMapping 함수 같은 경우 파일 핸들을 리턴함으로

CloseHandle(리턴값); 으로 해제하고

MapViewOfFile 함수 같은 경우는 메모리 주소를 리턴함으로

UnmapViewOfFile(리턴값); 으로 해제한다.

------------------------------------------------------------------------------------------------------------------------------ 

아래의 명령어를 쳐서 설정으로 들어가자

AIX는 smitty라는걸로 OS설정을 꽤나 많이 하는 것 같다.

#smitty  tcpip

----------------------------------------------------------

Move cursor to desired item and press Enter.

  Minimum Configuration & Startup

  Further Configuration

  Use DHCP for TCPIP Configuration & Startup

  IPV6 Configuration

  Quality of Service Configuration & Startup

  Configure IP Security (IPv4)

  Configure IP Security (IPv6)

----------------------------------------------------------

위와 같은 설정들을 할 수 있다.

ifup이나 ifdown 같은것도 안 먹고 게이트 웨이 설정이나 dns 설정 어디서 하는건지 헤매다가 찾음...

CUI로 되어 있으며 방향키와 esc+명령 등으로 손쉽게 네트워크 관련 설정을 할 수 있다.

실제로 설정하다가 esc와 6키를 누르면 실제 해당 명령은 cmd 창에서 어떻게 명령어로 처리할 수 있는지도 나온다.

친절도 하셔라.... 설정하다가 안되면 에러 내용도 다양하게 확인할 수 있으니 참고!

라우팅 테이블 정보는 아래와 같이 확인할 수 있다.

netstat -rn

[root@/etc]#netstat -rn

Routing tables

Destination        Gateway           Flags   Refs     Use  If   Exp  Groups

Route Tree for Protocol Family 2 (Internet):

default              xx.xx.xx.xx        UG        0             991 en0      -      -

xx.xx.xx.xx         xx.xx.xx.xx         UHSb      0               0 en0      -      -   =>

.

.

.

Route Tree for Protocol Family 24 (Internet v6):

::1%1               ::1%1              UH         1       71496 lo0      -      -

===================================================================================================

[gcc 컴파일]

1) gcc 파일명(*.c) : Default로 out 파일이 생성된다. (ex a.out)

2) gcc -c 파일명(*.c) : 오브젝트 파일을 생성한다.

3) gcc -c 오브젝트_파일명(*.o) 파일명(*.c)

   gcc -o 실행파일명(*.out) 오브젝트_파일명(*.o)

4) gcc -o 실행파일 파일명(*.c) : 실행 파일을 만든다. (3번을 한줄로...)

===================================================================================================

[gcc 옵션]

1. -Wall 옵션 : 모든 모호한 코딩에 대해서 경고를 보내는 옵션

2. -W 옵션 : 합법적이지만 모호한 코딩에 대해서 경고를 보내는 옵션

3. -W -Wall 옵션 : 아주 사소한 모호성에 대해서도 경고가 발생

4. O2 옵션 : 최적화 레벨 2로 설정. (대부분의 최적화를 시도)

5. -E 옵션 : 전처리 과정의 결과를 화면에 보이는 옵션 

             (전처리과정 중 발생한 오류를 검증)

    ※ enhanced Tip: --save-temps 옵션 

6. -S 옵션 : cc1으로 전처리된 파일을 어셈블리 파일로 

             컴파일까지만 수행하고 멈춘다. (*.s)

7. -c 옵션 : as에 의한 어셈블까지만 수행하고 링크는 수행하지 않는다.

8. -v 옵션 : gcc가 컴파일을 어떤 식으로 수행하는지를 화면에 출력한다.

9. --save-temps 옵션 : 컴파일 과정에서 생성되는 중간 파일인 

                       전처리 파일(*.i)과 어셈블리 파일(*.s)을 지우지 않고,

                       현재 디렉토리에 저장한다. (오류 분석에 사용)

===================================================================================================

[cpp0 옵션]

: 소스내에서 사용된 헤더 파일과 define 매크로와 관련된 옵션들이다.

  전처리 과정에서 오류가 발생한다면 cpp0 옵션들을 점검해야 한다.

1) -l 옵션 : 전처리 과정에서 헤더 파일을 탐색하는 기본 디렉토리를 추가할 때 사용하는 옵션

2) -include 옵션 : 헤더 파일을 소스내에 추가할 때 사용한다.

3) -D[매크로] 옵션 : 매크로를 외부에서 define 할 때 사용한다.

4) -D[매크로]=[매크로 값] 옵션 : 소스 내에 #define [매크로] [매크로 값] 옵션을 추가한 것과 

                                 동일하다.

5) -U[매크로] 옵션 : -D와 반대로 소스 파일 내에 #undef[매크로] 옵션을 추가한 것과 

                     동일하다.

6) -M / -MM 옵션 : -M 옵션 - make를 위한 소스 파일의 모든 종속 항목을 출력

                   -MM 옵션 - 기본 include 디렉토리에 있는 헤더 파일은 빼고 종속 항목을

                              출력한다.

7) -nostdinc 옵션 : 디폴트 include 디렉토리(usr/include)에서 헤더 파일을 탐색하지 않고,

                    -l 옵션으로 추가한 디렉토리에서만 헤더 파일을 찾는다.

8) -C 옵션 : -E 옵션과 함께 사용하며, 전처리 과정에서 주석을 제거하지 않는다.

9) -Wp,[옵션들] 옵션 : 만약 cpp0와 gcc의 옵션이 같은 것으로 중복되면 gcc 옵션으로 

                       해석되므로... gcc의 해석을 거치지 않고 바로 cpp0 옵션으로 전달하고 

                       싶을 때 사용한다.         

===================================================================================================

[cc1 옵션]

: "C언어 옵션, 경고 옵션, 최적화 옵션, 디버깅 옵션"의 4가지 종류

  "경고 수위 조절 or 최적화 수위 조절"을 하고 싶을 때 사용한다.

1. C언어 옵션 : C언어 종류와 표준에 관련된 옵션

   1) -ansi 옵션 : ANSI C 표준에 부합하는 소스를 작성하고자 할 때 사용하는 옵션

   2) -std=[C 표준들] 옵션 : 기타 다른 표준들을 지정하고자 할 때 사용한다.

   3) -traditional 옵션 : 오래된 Traditional C 문법으로 문법을 검사한다.

   4) -fno -asm 옵션 : gnu89 문법을 바탕으로 asm, inline, typeof 키워드를 사용하지 않기를

                       원할 때 사용한다.

2. 경고 옵션 : cc1의 옵션을 조정하여 경고 수위를 조절할 수 있다.

   1) -W / -Wall 옵션 (gcc 옵션 참고)

   2) -w(소문자) 옵션 : 모든 경고 메시지를 제거한다.

   3) -Werror 옵션 : 모든 경고를 컴파일을 중단하는 오류로 취급한다.

                     (경고가 하나만 나와도 컴파일이 중단된다.)

   4) -pedantic 옵션 : ANSI C89 표준에서 요구하는 모든 경고 메시지를 표시한다.

   5) -pedantic-errors 옵션 : ANSI C89 표준에서 요구하는 모든 오류 메시지를 표시한다.

   6) -Wtraditional 옵션 : 소스가 ANSI C와 K&R C 간에 서로 다른 결과를 가져올 수 있는

                           부분이 있다면 경고한다.

3. 최적화 옵션 : ⓐ 실행 파일의 크기를 줄여 메모리와 하드디스크의 사이즈를 절약 (큰 의미 X)

                 ⓑ 실행 파일의 크기를 줄여 실행 속도를 향상시키는 것.

   1) -O0 옵션 : 최적화를 수행하지 않는다.

   2) -O1 옵션 : -O0보다는 조금 낫다. 

   3) -O2 옵션 : 가장 많이 사용하는 옵션. 일반 응용 프로그램이나 커널을 컴파일 할 때 사용

                 (거의 대부분의 최적화를 수행한다.)

   4) -O3 옵션 : 가장 높은 레벨의 최적화. 모든 함수를 인라인 함수와 같이 취급한다.               

                 (Call 인스트럭션은 사용 X. but, 되도록이면 사용하지 않는 것이 좋다. 

                   → 너무나 많은 소스의 변경이 가해지기 때문에 왜곡이 발생할 위험이 있다.)

   5) -O5 옵션 : 사이즈 최적화를 실행한다. (공간이 협소한 곳에서 사용 - 임베디드 시스템)

4. 디버깅 옵션

   1) -g 옵션 : gdb에게 제공하는 정보를 바이너리에 삽입한다.

                (-g 옵션을 사용하지 않고 gdb로 디버깅하면, 역어셈 → 어셈블리 코드로만 디버깅 가능)

   2) -pg 옵션 : 프로파일을 위한 코드를 삽입한다. 

                 (-pg 옵션으로 컴파일 → gmon.out(프로파일 정보) → gprof로 gmon.out 파일 분석)

===================================================================================================

[as의 옵션]

: gcc는 as의 옵션에 대해서는 알지 못한다. -Wa,[as 옵션들] 형식으로 gcc를 거치지 않고 

  바로 전달해야 한다. -Wa, -al, -as와 같은 형식으로 사용하면 as에게 -al -as 옵션이 같이 전해진다.

-Wa,[as 옵션들]

1) -al 옵션 : 어셈블된 인스트럭션을 보인다.

2) -as 옵션 : 정의된 심볼을 보인다.

3) -l[패스] 옵션 : include 디렉토리를 지정한다. 어셈블리 소스 내에서 사용된 include 지정자가 

                   지정하는 헤더파일을 찾고자 할 때 사용한다.

4) -W / --no-warn : 경고 메시지를 출력하지 않는다.

5) -march=[아키텍처 문자열] : 해당 어셈블리

===================================================================================================

[collect2 / ld 옵션]

: 링크 옵션

1) -L[라이브러리 디렉토리] 옵션 : 라이브러리를 찾을 디렉토리를 지정한다.

2) -l 옵션 : 같이 링크할 라이브러리를 지정한다.

3) -shared 옵션 : 공유 라이브러리와 정적 라이브러리가 같이 있을 경우, 공유 라이브러리를 우선하여

                  링크한다. (아무 옵션을 주지 않아도 공유 라이브러리를 우선으로 링크한다.)

4) -static 옵션 : 정적 라이브러리와 공유 라이브러리가 같이 있다면, 정적 라이브러리를 우선하여

                  링크한다. (속도는 빠르지만 파일 사이즈가 커진다는 점 고려할 것!)

5) -nostdlib 옵션 : 링크시에 표준 C 라이브러리를 사용하지 않는다. 

                    (OS, 부트로더와 같은 프로그램을 컴파일 할 때 사용)

6) -nostartfiles 옵션 : crt1.o 등과 같은 start up 파일을 링크하지 않는다.

                    (OS, 부트로더와 같은 프로그램을 컴파일 할 때 사용)

7) -Wl,[링크 옵션들] 옵션 : gcc를 거치지 않고 바로 링크에게 옵션을 정해주고자 할 때 사용한다.

                            (사용법은 -Wa와 동일한다.)

   < 유용한 링크 옵션들 >

   ① -s 옵션 : 실행 파일에서 심볼 테이블을 제거

   ② -x 옵션 : 출력 파일에서 로컬 심볼 제거

   ③ -n 옵션 : 텍스트 영역을 읽기 전용으로 만듬

   ④ -r 옵션 : 추후 링크가 가능하게 오브젝트를 만듬

   ⑤ -e [name] 옵션 :  시작 심볼을 name 심볼로 사용 (default 시작심볼 : _start 심볼)

   ⑥ -M 옵션 : 심볼들의 정보를 자세하게 출력

   ⑦ oformat [format] 옵션 : 주어진 형식의 오브젝트 파일을 생성

===================================================================================================

출처 : http://lvzuufx.blogspot.kr/2014/09/gnu-make-gcc-auto-dependency-makefile.html

Autotools, CMake, qmake 같은 빌드 도구나 Open Watcom 의 wmake 같은 경우에는 자체적으로 auto-dependency 를 지원하거나 이를 위한 지시자를 제공한다. 하지만 GNU Make 의 경우에는 이러한 기능을 자체적으로 지원하지도 않고, 이를 위한 지시자를 제공하지도 않는다.

하지만, 다행히도 gcc 를 이용해서 이 기능을 구현할 수 있다. 우선 이에 필요한 gcc 의 기능부터 살펴보자. 

-M 옵션 : 해당 소스 파일의 의존성을 GNU Make 의존성 규칙에 맞추어 출력한다. 시스템 헤더 파일들도 포함된다.

예를 들어, 다음과 같은 hello.c 를 생각해보자.

• gcc -M hello.c

이를 실행한 결과는 이렇다.

• hello.o: hello.c f:/lang/gcc/usr/include/stdio.h \
•   f:/lang/gcc/usr/include/sys/cdefs.h \
•   f:/lang/gcc/usr/include/sys/gnu/cdefs.h \
•   f:/lang/gcc/usr/include/features.h f:/lang/gcc/usr/include/sys/_types.h \
•   f:/lang/gcc/usr/include/machine/_types.h \
•   f:/lang/gcc/usr/include/386/_types.h

-MM 옵션 : -M 옵션과 비슷한데, 시스템 헤더 파일은 제외한다.

• gcc -MM hello.c 

다음은 실행 결과이다.

•  hello.o: hello.c

 -MP 옵션 : -M 또는 -MM 옵션과 함께 쓰일 때, 헤더 파일들에 대한 phony 타겟을 만든다. 이는 헤더 파일이 지워졌을 때, 오류가 발생하는 것을 방지한다.

•  gcc -M -MP hello.c

다음은 실행 결과이다.

•  hello.o: hello.c f:/lang/gcc/usr/include/stdio.h \
•   f:/lang/gcc/usr/include/sys/cdefs.h \
•   f:/lang/gcc/usr/include/sys/gnu/cdefs.h \
•   f:/lang/gcc/usr/include/features.h f:/lang/gcc/usr/include/sys/_types.h \
•   f:/lang/gcc/usr/include/machine/_types.h \
•   f:/lang/gcc/usr/include/386/_types.h
• f:/lang/gcc/usr/include/stdio.h:
• f:/lang/gcc/usr/include/sys/cdefs.h:
• f:/lang/gcc/usr/include/sys/gnu/cdefs.h:
• f:/lang/gcc/usr/include/features.h:
• f:/lang/gcc/usr/include/sys/_types.h:
• f:/lang/gcc/usr/include/machine/_types.h:
• f:/lang/gcc/usr/include/386/_types.h: 

-MT 옵션 : -M 또는 -MM 옵션과 함께 쓰일 때, 타겟의 이름을 바꾼다.

• gcc -M -MT hello_MT.o hello.c

다음은 실행 결과이다.

• hello_MT.o: hello.c f:/lang/gcc/usr/include/stdio.h \
•   f:/lang/gcc/usr/include/sys/cdefs.h \
•   f:/lang/gcc/usr/include/sys/gnu/cdefs.h \
•   f:/lang/gcc/usr/include/features.h f:/lang/gcc/usr/include/sys/_types.h \
•   f:/lang/gcc/usr/include/machine/_types.h \
•   f:/lang/gcc/usr/include/386/_types.h

-MF 옵션 : -M 또는 -MM 옵션과 함께 쓰일 때, 출력 결과를 해당 장치 또는 파일로 보낸다.

• gcc -M -MF hello.d hello.c

이 때 실행 결과는 표준 출력 장치에 나타나는 것이 아니라 hello.d 라는 파일에 저장된다.

바로 이 옵션들을 통해서 auto-dependecy Makefile 파일을 만들 수 있다. 문제는 이 내용을 Makefile 파일에서 어떻게 활용할 것인가이다.

의존성 파일부터 만들어 보자. 의존성 파일을 만들기 위한 기본적인 형태는 다음과 같다.

• hello.d : hello.c
•     gcc -M -MP -MF $@ $<

이제는 이렇게 만들어진 의존성 파일을 포함시켜야 한다. GNU Make는 이를 위해 include 지시자를 지원한다.

• include hello.d

이때 hello.d 가 없다면 주어진 생성 규칙을 통해서 새로이 만들거나 갱신한다. 그럼에도 불구하고 hello.d 를 만들 수 없다면, GNU Make 는 오류를 보고하고, 중지한다.

마지막으로 실행 파일의 의존성 규칙을 추가해주면 된다.

•  hello.exe : hello.o

물론 다음과 같은 기본적인 내용이 Makefile 앞 부분에 더 추가되어야 한다.

• .SUFFIXES : .c .o .exe
•  
• .PHONY : all
•  
• all : hello.exe

완성된 Makefile 의 모습은 이렇다.

이제 make 를 실행하면, hello.c 자체가 수정되거나 hello.c 가 포함하는 헤더 파일이 수정되면 새롭게 빌드된다.

그런데 문제는 hello.d 파일 자체는 한 번 만들어지면 hello.c 가 수정되지 않는 이상, 다시 갱신되지 않는다. 왜냐하면 hello.d 파일에 대한 의존성은 hello.c 밖에 없기 때문이다. 이 문제는 hello.d 의 의존성을 hello.o 의 의존성과 동일하게 만들어주면 된다. 위 8번째 줄을 아래와 같이 바꾸자.

• gcc -M -MP -MT "$(@:.d=.o) $@" -MF $@ $<

GNU Make 의 다중 대상 기능을 이용한 것으로. 타겟이 "hello.o" 에서 "hello.o hello.d" 로 된다.

GNU Make 를 실행하다보면 hello.d 가 지워진 경우에,  다음과 같은 오류 메세지가 출력된다.

• Makefile:10: hello.d: No such file or directory

이 오류 메세지가 나오더라도 중단되지는 않지만, 뭔가 꺼림칙하다. 어떻게 없앨 수 없을까 ? 바로 -include 를 쓰면 된다.

이 예제의 경우에는 소스 파일이 하나에 불과해서 이 정도이지만, 소스 파일이 여러 개일 경우에는 해당 소스 파일마다 일일이 추가해줘야 한다. 그리고 다른 프로젝트에 쓰기에도 수정해야 할 것이 많다. 이 얼마나 불편한가 ? 이를 개선해 보자.

우리가 고려할 것은 실행 파일과, 소스 파일이다. 다른 모든 것들은 이들로부터 변형될 수 있다. 이들을 위한 변수를 도입하자. PROGNAME 과 SRCS 에 실행파일과 소스 파일을 담자.

• PROGNAME := hello.exe
• SRCS := hello.c

이제 의존성 파일 변수와 실행 파일을 만들기 위한 목적 파일 변수를 도입하자.

• PROGNAME_DEPS := $(SRCS:.c=.o)
• DEPS := $(SRCS:.c=.d)

이 내용들을 반영하면 위 Makefile 은 다음과 같이 쓰여질 수 있다.

위 내용을 보면 특정 이름 대신에 변수를 사용한 것 외에도 몇 가지 달라진 점이 있는데, 하나는 16번째 줄에 있는 암묵적 규칙이고, 14번째 줄에 있는 $^ 이다. 암묵적 규칙은 여러개의 파일에 대해 동일한 규칙을  적용하기 위한 것이고, $^ 은 모든 의존 파일들을 뜻한다. 반면에 $< 은 첫번째 의존 파일을 뜻한다.
이렇게 해 두면, 다른 프로젝트에 적용을 한다든지 또는 소스가 변경되었다든지 할 때, PROGRAM 과 SRCS 만 바꾸어주면 된다. 소스 파일을 더 추가하고 싶다면 빈 칸을 사이에 두고 파일 이름을 적어주면 된다. 예를 들어 hello.c 외에 world.c 가 추가되었다면 2번째 줄을 이렇게 바꾸면 된다.

• SRCS := hello.c world.c

이외에도 여러가지 컴파일 플래그나 링커 플래그, 컴파일러나 링커를 위한 여러 변수들을 도입하면 훨씬 더 유연한 Makefile 이 될 것이다.

그리고 기회가 된다면 추후에 여러 개의 실행 파일과 DLL 등을 한꺼번에 빌드할 수 있는 Makefile 에 대해서도 글을 쓰도록 하겠다. 

출처 : http://moonsungju.tistory.com/32

-----------------------------------------------------------------------------------------------

SUN Studio 12 버전 별로 정리해보았습니다. 다들 알고 있으시겠죠?? 모르시는 분들을 위해~ㅋㅋㅋㅋ

Solaris 10u10 기준이며, OS release 따라 약간 다를 수도 있습니다. 이 부분은 다들 알고 계시기 때문에 PASS~

해당 설치 방법은 제가 전에 On-site 때 실행했던 방법이며, 혹시 다른 방법으로 설치하시는 분이 있다면 그 방법으로 하시면 됩니다.  참고만 하시면 될 듯 싶네요.

1.     현재까지 나온 Sun Studio 12

l  SunStudio 12

l  SunStudio 12.1

l  SunStudio 12.2

l  SunStudio 12.3

2.     압축 풀기

bzcat download_directory/[File Name]-[OS]-[PLATFORM]-[FORMAT]-ML.tar.bz2 | /bin/tar -xf -

ex) bzcat SolarisStudio12.3-solaris-sparc-pkg.tar.bz2| /bin/tar -xf -

3.     설치/삭제 옵션

4.     C로 컴파일 예제

컴파일링 하는 방법은 다들 아시죠? cc를 통해 진행하시면 됩니다.  굳이 여기까지 테스트는 안 하셔도 되나 그래도 심심풀이로 하시고 싶으신 분~~~ 각자의 소스코드로 진행하시면 됩니다. 위에 코드는 가장 많이 테스트 하시는 hello.c 코드 입니다. 그냥 moonsungju로 바꾼 것 외에 다른 수정사항은 없습니다.(gcc도 동일)

1.패치실행

2.스튜디오실행

output-device=virtual-console

input-device=virtual-console

eeprom "output-device=screen"

eeprom "input-device=keyboard"

/usr/dt/bin/dtlogin start

/usr/dt/bin/dtconfig -e

1. 출처 : http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/System_management/ZFS

-------------------------------------------------------

3.1 opensolaris 설치

솔라리스는 ZFS를 기본 파일 시스템으로 하고 있다. 이렇게 된거 x86기반의 opensolaris를 설치해서 ZFS를 경험해 보기로 했다. VirtualBox를 이용 해서 가상으로 올렸다.

• hypervisor : VirtualBox VirtualBox 와 opensolaris 모두 Oracle에서 개발하고 있으니, 궁합이 잘 맞을 거란 생각이 든다.
• OpenSolaris
  • opensolaris 다운로드 사이트
  • 버전 : OpenSolaris 2009.06 (x86 LiveCD)

설치는 윈도우보다 간단하다. 설치 과정은 생략.

솔라리스를 마지막으로 써본게 아마 9년전 쯤인것 같다. 2002년이던가 ? 당시만 해도 상당히 투박한(하지만 왠지 멋져 보이긴 했음) CDE 화면이었는데, 지금은 gnome이 뜬다. 예쁘다.

보낸 사람 Linux

# format
AVAILABLE DISK SELECTIONS:
       0. c7d0 <DEFAULT cyl 2085 alt 2 hd 255 sec 63>
          /pci@0,0/pci-ide@1,1/ide@0/cmdk@0,0
       1. c9t0d0 <ATA-VBOX HARDDISK-1.0-2.00GB>
          /pci@0,0/pci8086,2829@d/disk@0,0
       2. c9t1d0 <ATA-VBOX HARDDISK-1.0-2.00GB>
          /pci@0,0/pci8086,2829@d/disk@1,0

# zpool create tank c9t0d0 c9t1d0

# zpool list
NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
rpool  15.9G  3.80G  12.1G    23%  ONLINE  -
tank   3.97G   232K  3.97G     0%  ONLINE  -

# zfs list
NAME                         USED  AVAIL  REFER  MOUNTPOINT
rpool                       4.16G  11.5G  77.5K  /rpool
rpool/ROOT                  3.16G  11.5G    19K  legacy
rpool/ROOT/opensolaris      3.16G  11.5G  3.02G  /
rpool/dump                   511M  11.5G   511M  -
rpool/export                5.04M  11.5G    21K  /export
rpool/export/home           5.02M  11.5G    21K  /export/home
rpool/export/home/yundream     5M  11.5G     5M  /export/home/yundream
rpool/swap                   512M  11.8G   137M  -
tank                        74.5K  3.91G    19K  /tank

# zfs create tank/music
# zfs create tank/movie
# zfs create tank/source
# zfs list
NAME                         USED  AVAIL  REFER  MOUNTPOINT
...
tank                         154K  3.91G    23K  /tank
tank/movie                    19K  3.91G    19K  /tank/movie
tank/music                    19K  3.91G    19K  /tank/music
tank/source                   19K  3.91G    19K  /tank/source

# zfs set quota=1g tank/movie
# zfs list | grep tank
tank                         154K  3.91G    23K  /tank
tank/movie                    19K  1024M    19K  /tank/movie
tank/music                    19K  3.91G    19K  /tank/music
tank/source                   19K  3.91G    19K  /tank/source

# df -h /tank/movie
Filesystem            Size  Used Avail Use% Mounted on
tank/movie            1.0G   19K  1.0G   1% /tank/movie

------------------------------------------------------------------------------------------------------------

zfs 파일 시스템의 관련 블로그들의 대부분은 

spl-0.6.0-rc6.tar.gz, zfs-0.6.0-rc6.tar.gz를 가이드했지만 내가 이 블로그를 쓰는 시점은 0.6.3을 받았다. 버전별로 리눅스 커널 지원이 다르다.

관련 패키지 정보는 ZFS 관련 공식 사이트인 아래 링크에 들어가서 받도록 하자.

http://zfsonlinux.org/

------------------------------------------------------------------------------------------------------------

2. 출처 : http://blog.lovetonight.net/m/post/164

------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------

출처 : https://github.com/zfsonlinux/pkg-zfs/wiki/HOWTO-install-Ubuntu-to-a-Native-ZFS-Root-Filesystem

HOWTO install Ubuntu to a Native ZFS Root Filesystem

Note: These instructions were originally created for older version of Ubuntu (12.04). Some required resource (e.g. grub ppa) is not available on newer versions, thus can lead to errors. If you use Ubuntu 14.04 or newer, see this page instead, which also allows things like raidz root, boot from snapshot, zfs-only setup (no need for separate /boot/grub), and lz4 compression.

These instructions are for Ubuntu. The procedure for Debian, Mint, or other distributions in the DEB family is similar but not identical.

System Requirements

• 64-bit Ubuntu Live CD. (Not the alternate installer, and not the 32-bit installer!)
• AMD64 or EM64T compatible computer. (ie: x86-64)
• 8GB disk storage available.
• 2GB memory minimum.

Computers that have less than 2GB of memory run ZFS slowly. 4GB of memory is recommended for normal performance in basic workloads. 16GB of memory is the recommended minimum for deduplication. Enabling deduplication is a permanent change that cannot be easily reverted.

Recommended Version

• Ubuntu 12.04 Precise Pangolin
• spl-0.6.3
• zfs-0.6.3

Step 1: Prepare The Install Environment

1.1 Start the Ubuntu LiveCD and open a terminal at the desktop.

1.2 Input these commands at the terminal prompt:

$ sudo -i
# apt-add-repository --yes ppa:zfs-native/stable
# apt-get update
# apt-get install debootstrap spl-dkms zfs-dkms ubuntu-zfs

1.3 Check that the ZFS filesystem is installed and available:

# modprobe zfs
# dmesg | grep ZFS:
ZFS: Loaded module v0.6.3-2~trusty, ZFS pool version 5000, ZFS filesystem version 5

Step 2: Disk Partitioning

This tutorial intentionally recommends MBR partitioning. GPT can be used instead, but beware of UEFI firmware bugs.

2.1 Run your favorite disk partitioner, like parted or cfdisk, on the primary storage device. /dev/disk/by-id/scsi-SATA_disk1 is the example device used in this document.

2.2 Create a small MBR primary partition of at least 8 megabytes. 256mb may be more realistic, unless space is tight. /dev/disk/by-id/scsi-SATA_disk1-part1 is the example boot partition used in this document.

2.3 On this first small partition, set type=BE and enable the bootable flag.

2.4 Create a large partition of at least 4 gigabytes. /dev/disk/by-id/scsi-SATA_disk1-part2 is the example system partition used in this document.

2.5 On this second large partition, set type=BF and disable the bootable flag.

The partition table should look like this:

# fdisk -l /dev/disk/by-id/scsi-SATA_disk1

Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device    Boot      Start         End      Blocks   Id  System
/dev/sda1    *          1           1        8001   be  Solaris boot
/dev/sda2               2        1305    10474380   bf  Solaris

Remember: Substitute scsi-SATA_disk1-part1 and scsi-SATA_disk1-part2 appropriately below.

Hints:

• Are you doing this in a virtual machine? Is something in /dev/disk/by-id missing? Go read the troubleshooting section.
• Recent GRUB releases assume that the /boot/grub/grubenv file is writable by the stage2 module. Until GRUB gets a ZFS write enhancement, the GRUB modules should be installed to a separate filesystem in a separate partition that is grub-writable.
• If /boot/grub is in the ZFS filesystem, then GRUB will fail to boot with this message: error: sparse file not allowed. If you absolutely want only one filesystem, then remove the call to recordfail() in each grub.cfg menu stanza, and edit the /etc/grub.d/10_linux file to make the change permanent.
• Alternatively, if /boot/grub is in the ZFS filesystem you can comment each line with the text save_env in the file /etc/grub.d/00_header and run update-grub.
  

Step 3: Disk Formatting

3.1 Format the small boot partition created by Step 2.2 as a filesystem that has stage1 GRUB support like this:

# mke2fs -m 0 -L /boot/grub -j /dev/disk/by-id/scsi-SATA_disk1-part1

3.2 Create the root pool on the larger partition:

# zpool create -o ashift=9 rpool /dev/disk/by-id/scsi-SATA_disk1-part2

Always use the long /dev/disk/by-id/* aliases with ZFS. Using the /dev/sd* device nodes directly can cause sporadic import failures, especially on systems that have more than one storage pool.

Warning: The grub2-1.99 package currently published in the PPA for Precise does not reliably handle a 4k block size, which is ashift=12.

Hints:

• # ls -la /dev/disk/by-id will list the aliases.
• The root pool can be a mirror. For example, zpool create -o ashift=9 rpool mirror /dev/disk/by-id/scsi-SATA_disk1-part2 /dev/disk/by-id/scsi-SATA_disk2-part2. Remember that the version and ashift matter for any pool that GRUB must read, and that these things are difficult to change after pool creation.
• If you are using a mirror with a separate boot partition as described above, don't forget to edit the grub.cfg file on the second HD partition so that the "root=" partition refers to that partition on the second HD also; otherwise, if you lose the first disk, you won't be able to boot from the second because the kernel will keep trying to mount the root partition from the first disk.
• The pool name is arbitrary. On systems that can automatically install to ZFS, the root pool is named "rpool" by default. Note that system recovery is easier if you choose a unique name instead of "rpool". Anything except "rpool" or "tank", like the hostname, would be a good choice.
• If you want to create a mirror but only have one disk available now you can create the mirror using a sparse file as the second member then immediately off-line it so the mirror is in degraded mode. Later you can add another drive to the spool and ZFS will automatically sync them. The sparse file won't take up more than a few KB so it can be bigger than your running system. Just make sure to off-line the sparse file before writing to the pool.
  

3.2.1 Create a sparse file at least as big as the larger partition on your HDD:

# truncate -s 11g /tmp/sparsefile

3.2.2 Instead of the command in section 3.2 use this to create the mirror:

# zpool create -o ashift=9 rpool mirror /dev/disk/by-id/scsi-SATA_disk1-part2 /tmp/sparsefile

3.2.3 Offline the sparse file. You can delete it after this if you want.

# zpool offline rpool /tmp/sparsefile

3.2.4 Verify that the pool was created and is now degraded.

# zpool list
NAME       SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool     10.5G   188K  10.5G     0%  1.00x  DEGRADED  -

3.3 Create a "ROOT" filesystem in the root pool:

# zfs create rpool/ROOT

3.4 Create a descendant filesystem for the Ubuntu system:

# zfs create rpool/ROOT/ubuntu-1

On Solaris systems, the root filesystem is cloned and the suffix is incremented for major system changes through pkg image-update or beadm. Similar functionality for APT is possible but currently unimplemented.

3.5 Dismount all ZFS filesystems.

# zfs umount -a

3.6 Set the mountpoint property on the root filesystem:

# zfs set mountpoint=/ rpool/ROOT/ubuntu-1

3.7 Set the bootfs property on the root pool.

# zpool set bootfs=rpool/ROOT/ubuntu-1 rpool

The boot loader uses these two properties to find and start the operating system. These property names are not arbitrary.

Hint: Putting rpool=MyPool or bootfs=MyPool/ROOT/system-1 on the kernel command line overrides the ZFS properties.

3.9 Export the pool:

# zpool export rpool

Don't skip this step. The system is put into an inconsistent state if this command fails or if you reboot at this point.

Step 4: System Installation

Remember: Substitute "rpool" for the name chosen in Step 3.2.

4.1 Import the pool:

# zpool import -d /dev/disk/by-id -R /mnt rpool

If this fails with "cannot import 'rpool': no such pool available", you can try import the pool without the device name eg:

    # zpool import -R /mnt rpool

4.2 Mount the small boot filesystem for GRUB that was created in step 3.1:

# mkdir -p /mnt/boot/grub
# mount /dev/disk/by-id/scsi-SATA_disk1-part1 /mnt/boot/grub

4.4 Install the minimal system:

# debootstrap trusty /mnt

The debootstrap command leaves the new system in an unconfigured state. In Step 5, we will only do the minimum amount of configuration necessary to make the new system runnable.