반응형

- 출처

https://www.ibm.com/support/knowledgecenter/ko/SSYKE2_7.0.0/com.ibm.java.aix.70.doc/diag/problem_determination/aix_cmd_ps.html

https://www.ibm.com/support/knowledgecenter/ko/ssw_aix_71/com.ibm.aix.cmds4/ps.htm


프로세스의 ps 모니터링을 시작하려면 다음을 입력하십시오.


ps -fp <PID>


출력 내용은 다음과 같습니다.

UID     PID     PPID      C    STIME    TTY    TIME    CMD

user12  29730   27936    0    21 Jun   -      12:26   java StartCruise



이에 대한 설명은 다음과 같습니다.


UID

프로세스 소유자의 사용자 ID입니다. 로그인 이름은 -f 플래그 아래에 인쇄됩니다.


PPID

상위 프로세스 ID입니다.


PID

프로세스 ID입니다.


C

CPU 활용도로서, 프로세스가 실행 중이고 시스템 클럭 틱이 발생할 때마다 증분됩니다. 

스케줄러가 값을 매초 2로 나눠서 값이 줄어듭니다. 

sched_other 정책에서, CPU 활용도는 프로세스 스케줄링 우선순위를 결정하는 데 사용됩니다. 

큰 값이 CPU 집약적 프로세스를 나타내고 따라서 낮은 프로세스 우선순위를 갖는 반면, 작은 값은 입출력 집약적 프로세스를 나타내고 보다 높은 우선순위를 갖게 됩니다.

+

프로세스 또는 스레드의 CPU 사용량이며, 시스템 클럭이 째깍거리고 프로세스나 스레드가 실행 중임을 발견할 때마다 증가됩니다. 

값은 스케줄러에 의해 초당 2로 나뉘어져서 감소됩니다. sched_other 정책의 경우, CPU 사용량은 프로세스 스케줄링 우선순위를 판별하는 데 사용됩니다. 

큰 값은 CPU 집중 프로세스를 표시하며 결과적으로 프로세스 우선순위가 낮아지는 반면, 작은 값은 입출력 집중 프로세스를 표시하며 결과적으로 프로세스 우선순위가 높아집니다.



STIME

프로세스의 시작 시간입니다(시, 분, 초). 프로세스의 시작 시간은 ps 조회가 실행되기 24시간 이상 전에 시작됩니다(월, 일).


TTY

프로세스의 제어 워크스테이션입니다.


TIME

프로세스의 총 실행 시간입니다. 실행시간이 100분에 도달하면 시간이 mm:ss 또는 mmmm:ss 형식으로 표시되며, 이는 -o time 플래그를 사용할 때 표시된 형식과는 다릅니다


CMD

전체 명령 이름 및 해당 매개변수입니다.

아직 실행 중인 스레드를 확인하려면 다음을 입력하십시오







아직 실행 중인 스레드를 확인하려면 다음을 입력하십시오.


ps -mp <PID> -o THREAD


출력 내용은 다음과 같습니다.

    USER        PID   PPID     TID ST  CP PRI SC    WCHAN        F     TT BND COMMAND

    user12    29730  27936       - A    4  60  8        *   200001 pts/10   0 java StartCruise

           -      -      -   31823 S    0  60  1 e6007cbc  8400400      -   0 -

           -      -      -   44183 S    0  60  1 e600acbc  8400400      -   0 -

           -      -      -   83405 S    2  60  1 50c72558   400400      -   0 -

           -      -      -  114071 S    0  60  1 e601bdbc  8400400      -   0 -

           -      -      -  116243 S    2  61  1 e601c6bc  8400400      -   0 -

           -      -      -  133137 S    0  60  1 e60208bc  8400400      -   0 -

           -      -      -  138275 S    0  60  1 e6021cbc  8400400      -   0 -

           -      -      -  140587 S    0  60  1 e60225bc  8400400      -   0 -



이에 대한 설명은 다음과 같습니다.


USER

프로세스를 실행 중인 사용자의 이름입니다.


TID

각 스레드의 커널 스레드 ID입니다.


ST

다음과 같은 스레드의 상태입니다.


1) O - 존재하지 않습니다.

2) R - 실행 중입니다.

3) S - 휴면 상태입니다.

4) W - 스왑되었습니다.

5) Z - 취소되었습니다.

6) T - 중지되었습니다.


CP

스레드의 CPU 활용도입니다.


PRI

스레드의 우선순위입니다.


SC

일시중단 수입니다.


ARCHON

대기 채널입니다.


F

플래그입니다.


TAT

제어 중인 터미널입니다.


BAND

스레드가 바인드되는 CPU입니다.



반응형
반응형



참고 : http://webinformation.tistory.com/86



해당 오류는 패키지 dependency 에 대해 지우고 다시 설치하면 됩니다.


[root@localhost ~]# yum shell > remove [지워야 하는 패키지명] > install [다시 설치해야 하는 패키지명] > run



반응형
반응형

참고 : https://m.blog.naver.com/PostView.nhn?blogId=idrukawa&logNo=220870293694&proxyReferer=https:%2F%2Fwww.google.co.kr%2F


Yum update errno 14 http error 404: not found


yum 으로 update를 진행하다보면 해당 에러가 발생할 수 있는데 이런 경우에 아래의 경로에 모든 파일을 다른곳으로 이동하고
daum 의 repository 정보로 변경하여 진행하면 됩니다.

root]# cd /etc/yum.repos.d

root]# vi daum.repo


[base]

name=CentOS-$releasever - Base

baseurl=http://ftp.daum.net/centos/7/os/$basearch/

gpgcheck=1

gpgkey=http://ftp.daum.net/centos/RPM-GPG-KEY-CentOS-7

 

[updates]

name=CentOS-$releasever - Updates

baseurl=http://ftp.daum.net/centos/7/updates/$basearch/

gpgcheck=1

gpgkey=http://ftp.daum.net/centos/RPM-GPG-KEY-CentOS-7

 

[extras]

name=CentOS-$releasever - Extras

baseurl=http://ftp.daum.net/centos/7/extras/$basearch/

gpgcheck=1

gpgkey=http://ftp.daum.net/centos/RPM-GPG-KEY-CentOS-7

 

[centosplus]

name=CentOS-$releasever - Plus

baseurl=http://ftp.daum.net/centos/7/centosplus/$basearch/

gpgcheck=1

gpgkey=http://ftp.daum.net/centos/RPM-GPG-KEY-CentOS-7


// repo clear 후 로딩

// base, centosplus, extras, updates 가 출력되면 정상

// 위 리스트가 출력되지 않으면 daum.repo 만 남겨놓고 다른 repo는 삭제해보길 바람.


root]# yum clean all

...

Cleaning repos: base centosplus extras updates

Cleaning up everything


root]# ]# yum repolist all

반응형
반응형



1. 설치된 내역 확인 

# rpm -qa | grep ssh

openssh-server-6.61p1-31.el7.x86_64

openssh-client-6.61p1-31.el7.x86_64



2. 설치가 안되어 있으면 yum install 이나 rpm 으로 설치 진행

# yum install openssh*



3. ssh 설정 파일 수정 (해당 부분 주석 해제)

# vi /etc/ssh/sshd_config

Port 22 



4. ssh 서비스 구동

# systemctl start sshd.service



5. 방화벽 22번 포트 오픈 및 재시작

# firewall-cmd --zone=public -add-port=22/tcp --permanent

# firewall-cmd --reload

# systemctl restart firewalld.service



6. 포트 오픈 내역 확인

# netstat -na | grep tcp | grep 22






반응형
반응형


yum 을 통해 외부망에서 repository를 설정할 때.



1. yum 캐쉬 정보 삭제.

# yum clean all 


This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
>> 관련 내용 무시



2. EPEL repository 설정

wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm



rpm -ivh epel-release-latest-7.noarch.rpm 

> 경고 무시

> /etc/yum.repo.d 에 아래 내역들 추가 되었는지 확인

>> epel-testing.repo  epel.repo



3. REMI repository 설정

wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm


# rpm -Uvh remi-release-7.rpm 

/etc/yum.repo.d 

>> remi-php70.repo   remi-php71.repo  remi-safe.repo      remi.repo (파일 내역은 리눅스 버전에 따라 차이가 있는 것 같아 보임)



4. 필요한 패키지 yum install [패키지 명] 으로 설치 진행.





반응형
반응형

au-mallocdebug.zip


AIX에서 메모리 릭을 디텍팅 하기 위해서는 다양한 툴들을 사용할 수 있지만 아래의 방법도 있으니 참고.


출처 : http://ieggstory.blogspot.kr/2007/12/aix-memory-leak.html




환경변수를 이용하여 malloc, free 를 추적할 수 있다.


MALLOCDEBUG=report_allocations,output:/tmp/alloc_output.txt

ex)
export MALLOCTYPE=debug
export MALLOCDEBUG=report_allocations,stack_depth:5,output:/tmp/alloc_output.txt

프로그램이 실행되는 동안 위의 환경변수가 설정되어 있는 경우 /tmp/alloc_output.txt
파일로 alloc, free 되는 정보가 출력된다. 프로그램이 실행되는 동안은 alloc,
free 할때마다 그 기록을 메모리상에 가지고 있다가 종료가 되면 해제되지
않은 alloc 정보만 /tmp/alloc_output.txt 로 출력된다.

더 자세한 사항은 AIX 5L Version 5.3 General Programming Concepts: Writing
and Debugging Programs 에 나와 있다. 





출처 : http://www.ibm.com/developerworks/aix/library/au-mallocdebug.html#list3


useage : format_mallocdebug_op.sh alloc_output.txt


위에서 출력된 출력 파일을 사용하여 memory leak에 대해서 일반 사용자가 보기 편하게 변경해주는 쉘 스크립트가 있다(다운로드 가능)

또한 OS 환경 변수 뿐만 아니라 관련 옵션들에 대해서도 위의 출처에 자세히 나와있음.


사용해보도록 하자.

반응형
반응형



출처 : http://blog.naver.com/PostView.nhn?blogId=bumsukoh&logNo=110114643995






안녕하세요!  이번에는 IBM AIX의 내부적인 Memory 관리 방법(Not human but machine doing that)과 모니터링 방법(Not machine but human doing that)에 대해 설명드리도록 하겠습니다.

 

저의 경우 매번 시스템 튜닝이나 모니터링하면서도 항상 헤갈리게 하는 Memory Management 부분입니다. 아마 모니터링 툴마다 보여주는 수치들의 의미때문에 그런것 같은데요.

전혀 모르것도 아닌것이 그렇다고 아는것도 아닌것이 아무 애매모호한 경우가 너무 많아서 이번에 쫑찍어 볼려고 합니다.

위에서 제가 설명드린 "모니터링 툴마다 보여주는 수치들의 의미가 다른부분"의 대표적인 예가 이런 경우일 것 같은데요.

vmstat의 page in, page out과 topas의 page in, page out  부분일텐데요. 잘 아실지 모르지만 이 두개가 의미하는 내용은 완전히 다릅니다. 모르셨던 분들은 황당하실텐데요.

 vmstat의 page in, page out은 말그대로 paging space(swap이라 보시면 되겠네요)로의 page in, page out 입니다. 즉 프로세스의 메모리 정보가 file system으로 내려가거나, 다시 메모리로 로딩하거나 하는 것이지요.

그런데 topas의 page in, page out은 file system과 매핑된 즉 file과 매핑된 page들에 대한 page in, page out에 대한 부분입니다. 이 중에는 paging space로의 page in, page out은 제외됩니다.

즉 Memory segment중 Persistent segment와 Client segment에 대한 page들이 in, out 되는 것이죠.

이렇게 다른 내용을 같은 내용으로 이해 한다면 잘못된 판단을 할 수 있겠죠.

이러한 이유로 AIX 내부적으로 Memory를 관리하는 방법과 모니터링에 대한 정확한 방법을 한번 정리하는 것이 이번 포스트의 목적입니다.

 

자, 그럼 AIX 내부적인 Memory 관리 방법에 설명하도록 하겠습니다.

 

AIX 뿐 아니라 모든 Unix 시스템은 가용한 Physical memory 보다 더 많은 양의 메모리 address를 효율적으로 할당할 수 있도록 하기 위해 Virtual memory를 사용합니다. 이건 Unix 시스템에 대해 아시는 분들은 모두 아시는 부분입니다. 문제의 발단은 여기서 부터 시작됩니다.

Virtual Memory를 사용함으로써 이를 효과적으로 관리하기 위한 각종 효율적인 방법들이 필요하게 됩니다. 그러면서 굉장히 복잡한 Memory management mechanism이 생겨나게 됩니다.

 

AIX 내부적인 Memory를 관리하는 방법을 알기 위해서는 다음의 기능들에 대해 숙지하고 있어야 합니다.

- Paging space 란 ?

paging space는 현재 Virtual memory상에는 존재하지만 현재 access 되고 있지 않는 데이터를 저장하기 위해 disk 공간으로 할당된 logical volume입니다.

이러한 logical volume을 일반적으로 우리는 paging space또는 swap space라고 부릅니다.

paging space라는 용어의 개념을 잘 알고 있어야 뒤에 나오는 각종 내용들에 대해 혼란이 없게됩니다.

System의 Physical memory(RAM)의 여유공간의 양이 적으면, 현재 사용하고 있지 않은 프로그램(프로세스)이나 데이터는 다른 activity 작업에게 메모리를 할당하기 위해 paging space로 이동되게 됩니다. 뭐.. 이 내용은 우리가 잘 알고 있는 swap에 대한 내용이라 할 수 있습니다. 그래서 paging space가 작게되면 프로세스들이 유실되게 되고, 이렇게 되면 paging space가 고갈되게 되면 System panic이 발생할 수 있습니다.

 

이러한 문제를 감지하게 되면 새로운 volume을 생성하여 paging space로 할당하거나 기존의 volume의 크기를 증가시켜 문제를 해결 할 수 있습니다.

 

이러한 paging space에는 paging space를 할당하기 위한 다양한 정책(Late, Early, Deferred등)과 paging space의 부족 시 paging space회수를 위한 다양한 방법(npswarn, npskill,nokilluid등)등이 있습니다. 해당 부분들은 필요 시 설명하도록 하겠습니다.

 

예전에는 작은 Physical memory 시스템에 과중한 업무들을 구동하다 보니 paging space에 대한 page in, page out이 지속적으로 발생하여 성능상의 문제가 빈번히 있었지만,

 

요즘은 Physical memory의 가격보다 안정적인 시스템 운영을 위해 충분한 Physical memory를 처음부터 확보하고 시스템을 운영하기 때문에 Paging space가 부족하여 System에 크게 문제되는 경우는 별로 없는것 같습니다. 

 

- Memory Segments 란 ?

AIX는 다양한 memory segment간에 기능들이 구분됩니다.

AIX의 VMM을 이해하기 위해 persistent,working 그리고 client segment들간의 차이점을 이해하는 것이 중요합니다.

 

Persistent segment는 disk상의 permanent storage location을 가집니다. Data나 execution programe의 file은 persistent segment에 매핑됩니다.

 

Working segment는 프로세스가 사용하는 동알 존재하는 일시적인 것입니다. 따라서 permanent disk storage에 위치를 가지지 않습니다.

프로세스 stack, data 영역이 working segment와 shared library text segment에 매핑됩니다.

 

Client segment는 remote file system에 위치한 permanent location을 네트워크를 통해 저장됩니다. CD-ROM과 JFS2 page들은 client segment 입니다.

 

Memory segment는 private으로 유지되거나 processor간 공유될 수 있습니다.

 

- VMM(Virtual memory manager) 란 ?

VMM은 System과 application에서 요청하는 메모리를 할당하는 역할을 담당합니다.

VMM을 통해 할당되는 segment들의 단위를 page라고 부릅니다. 이러한 page는 Physical memory나 필요 시까지 disk(paging space)에 위치됩니다.

이렇게 Physical memory와 disk(paging space)에 저장된 page들을 VMM이 관리하게 됩니다. 그래서 virtual memory의 양은 system의 실제 physical 메모리의 크기를 넘어 사용될 수 있습니다.

VMM의 기능 측면에서는 다음과 같은 성능 향상을 위한 기능을 가지고 있습니다.

- paging으로 인한 processor의 사용과 disk bandwidth를 최소화함

- 프로세스의 paging으로 인한 응답속도 저하를 최소화홤

 

AIX에서는 virtual memory segment는 4kb(4096byte) 단위로 page로 나뉘어집니다.

VMM은 이러한 page들에 대해 사용가능한 free list를 유지 관리합니다.

VMM은 현재 Physical memory상의 page들에 대해 free list로 재할당해야 할 page들을 찾기 위해 page-replacement algorithm을 사용합니다.

이 page-replacement algorithm은 virtual memory segment인 working segment와 비교하여 persistent 존재 비율 및 repaging등을 고려해야 합니다.

 

VMM은 할당되지 않은 page들의 최소양을 유지하기 위해 free 공간을 늘리고 이 공간을 free list에 할당하기 위한 page out과 page steal을 사용합니다.

 

- Paging mechanism 에 대해

Paging mechanism은 VMM이 page들의 free list를 관리하기 위한 방법입니다. 위에서 VMM이 page-replacement algorithm을 사용한다고 말씀드렸는데요. 이러한 것들이 Paging mechanism에 대한 하나의 방법입니다.

 

VMM은 안정적인 page fault를 가능하게 하기 위해 free memory page frame의 리스트를 유지합니다. 이러한 list가 바로 우리가 알고 있는 free list입니다.

 

여기서 page fault는 virtual memory address는 가지고 있으나 현재 physical memory에 해당 page가 없을 경우 발생합니다.

이러한 page fault는 보통 다음과 같이 두가지 유형이 있습니다.

new page fault로써 가장 처음 참조되어 physical memory가 없는 경우와 이미 page out된 page인 경우입니다. 즉 page fault가 발생하면 free list가 있는 경우 자동으로 해당 page에 대한 메모리를 바로 할당하게 됩니다.

 

메모리의 free list page의 수가 작게되면 page stealer가 발생하게 됩니다.

이 page stealer는 steal 대상 page들을 찾기 위해 Page Frame Table(이하 PFT) entry들을 평가하는 mechanism입니다.

PFT는 참고되고 있는 page와 수정된 page들을 표시하는 flag들을 가지고 있습니다.

Page stealer가 참고되고 있는 PFT내의 page를 찾게되면 해당 page를 steal하지 않습니다.

오히려 참조 flag를 reset 하게 됩니다. 다음번에 page stealer가 PFT에서 해당 page를 검사할때 해당 page가 참조되고 있지 않다면 해당 page는 steal 됩니다.

그리고 page stealer가 처음부터 참조되지 않은 page들 만나게 되면 바로 해당 page들을 steal됩니다.

 

PFT의 page가 참조되지 않고 modify flag가 설정되어있으면 해당 page가 memory에 위치한 후 변경되었다는것을 page stealer에게 표시하게 됩니다. 이러한 경우는 page steal 전에 page out이 호출됩니다. Page들이 working segment의 부분이라면 pageing space에 기록될것이며, 반면에 persistent segment의 부분이라면 disk의 permanent 위치에 기록될것입니다.

 

프로세스가 종료하게 되면 해당 프로세스의 working storage는 해제되며 메모리의 page들도 free가 되어 free list로 반환됩니다.  반면 프로세스에 의해 open된 file들은 메모리에 남아 있을수 있습니다.

 

- Memory load control mechanism 에 대해

Active virtual memory page들의 수가 Physical memory page들을 초과할 경우, Physical memory page내에 위치할 수 없는 page들을 위해 paging space를 사용하게 됩니다.

Application이 page out된 page들에 접근하게 되면 VMM은 paging space로 부터 해당 page들을 physical memory page로 로드하게 됩니다.

이때, free physical memory page의 수가 작게되면 paging space에서 page로 로딩하기 전에 physical memory내의 다른 또 다른 free page가 필요하게 됩니다.

VMM이 free 대상의 page를 찾게되면, 강제로 해당 page들은 paging space로 page out됩니다.

심각한 경우 VMM은 paging space로 부터 physical memory로 다른 page를 로딩하기 전에 항상 paging space로 page를 page out 해야 할 필요가 생길 수 있습니다.

이러한 경우는 thrashing이라 부릅니다. 이러한 thrashing 상황에서는 프로세스들은 dispatche(run queue에서 cpu 할당받음)되자 마자 page fault에 직면하게 됩니다. 그러면 프로세스들은 어떠한 중요 절차도 수행하지 못하게 될뿐 아니라 system의 성능은 떨어지게 됩니다.

 

OS들은 이러한 thrashing 상황이 시작되는지에 대한 감지하기 위한 memory load control mechanism을 가지고 있습니다.

thrashing이 감지되면 system은 active process들을 suspend 시키기 시작하고 새로운 process의 시작을 지연시키게 되며 이러한 작용이 thrashing으로 빠지는 것을 방지합니다.

 

- Page replacement algorithm 에 대해

free list 상의 page 수가 설정한 값(minfree)보다 낮을 경우 page replacement algorithm은 physical memory page를 free 시키기를 시도하게 됩니다. 이러한 page replacement algorithm은 free list상의 page수의 최대값(maxfree+8)보다 free list의 page가 확보될때까지 지속됩니다.

이러한 page replacement algorithm 수행의 기준이 되는 minfree, maxfree값을 적정하게 설정하는 것을 중요한 부분입니다.

보통 minfree값의 기본은 maxfree보다 8 작은 값이거나 memory pool(보통 CPU당 메모리 SUBPOOL이 있음)만큼 작은 값입니다.

maxfree는 VMM의 page steal을 중지시키게 하는 기준을 결정합니다. maxfree값은 다음과 같이 결정될 수 있습니다.

maxfree = lesser of (number of memory pages / 128) --> IBM 가이드 문서 내용입니다.

이러한 값들은 system의 memory를 모니터링하여 필요 시 재설정을 통해 성능을 튜닝할 필요가 있습니다.

 

 

그럼 AIX 내부적인 Memory 관리 방법이 이해되었다면, 이제는 모니터링 하는 방법에 대해 알아보겠습니다.

주요하게 사용하는 Memory 모니터링 툴에 대해 설명하겠습니다.

 

- vmstat

가장 효과적으로 사용할 수 있는 툴입니다.

vmstat에 나오는 메모리 항목을 위주로 설명드리도록 하겠습니다.

vmstat은 크게 kthr, memory, page, faults, cpu 이렇게 5개 대항목으로 정보를 출력합니다.

이 중 Memory 관리와 관련된 부분은 memory, page 부분이 되겠습니다.

 


 

각 항목에 대해 알아보겠습니다.

- avm

Active Virtual Memory를 말하며, access되는 virtual page의 수를 표시합니다. 때로 이것을 available memory로 잘못알고 있는 경우가 있습니다.

- fre

free list의 크기를 표시합니다. 실제 physical memory의 많은 영역이 file system data를 cache로 활용되기도 합니다. 따라서 해당 크기가 작다고 해서 꼭 비정상적인 것은 아닙니다.

- re

초당 reclaime한 page수입니다. 해당 page가 free list에 있고, 재할당되지 않았을때 해당 page에 page fault는 초기화를 위한 신규 I/O request가 없으므로 reclaim이 고려됩니다.

- pi

page in request의 수입니다. page fault에 의해 paging space에 paging되어 있는 page가 physical memory로 page되는 수입니다.

초당 지속적으로 5 page 보다 많은 값이 보이면 문제가 있는 것으로 볼 수 있습니다.

- po

page out 처리된 page 수입니다. 초당 paging space로 이동한 page들의 수를 말합니다. 해당 page는 더 많은 memory가 요청될때 VMM에 의해 paging space로 page out됩니다. page out된 page는 필요 시 page in 될 수 있습니다.

page out이 높으면 minfree와 maxfree 값과 paging allocation policy값인 PSALLOC값을 확인할 필요가 있습니다.

- fr

free 된 page의 수입니다. VMM이 메모리를 필요로 할때 VMM의 page-replacement algorithm이 steal 대상 page들을 결정하기 위해 PFT(Page Frame Table)을 scan하도록 합니다. page들이 마지막 scan이후에 참조되지 않았다면 해당 page는 steal될 수 있습니다.

- sr

page-replacement algorithm에 의해 scan이 이루어진 page를 표시합니다. page steal이 발생하면 physical memory내의 page들은 page steal 대상인지를 확인하기 위해 scan됩니다.

메모리의 과대사용을 확인하기 위해 fr에 비해 sr의 비율이 높은지 확인해야함 높은 비율은 page stealer가 steal하기 위한 메모리를 찾기위해 작업 부하가 발생하는 것을 의미합니다.

- cy

page-replacement algorithm이 steal할 page를 찾기위해 PFT(Page Frame Table) 전체를 scan한 횟수를 나타냅니다.

이 값이 0 보다 크면 심각한 memory부족을 의미합니다.

page-replacement algorithm은 maxfree+8 값 만큼 free list page를 확보하기 위해 PFT를 scan하게 되는데 이때 PFT를 한번 모두 scan한 후에도 free list page의 수가 maxfree+8 보다 작으면 계속적으로 page steal을 위한 scan이 발생하며 이미 scan한 page들을 만나게 되면 cy값은 1씩 증가하게 됩니다.

이렇게 scan하다 maxfree+8 값만큼 steal이 발생하여 free list가 증가하면 그때 비로서 cy값이 0으로 설정됩니다.

 

- topas

topas도 시스템 모니터링을 위해 유용한 툴입니다. 처음에 말씀드렸듯이 memory에 관련해서는 그 항목이 vmstat과 조금 달라 확실히 의미하는 바를 알고 있어야 혼선이 없습니다.

 


 

항목 중 paging, memory, paging space 부분이 memory와 관련된 항목입니다.

- Faults

faults 수입니다.

- Steals

초당 VMM에 의해 steal된 page수입니다.

- PgspIn

Paging space로 부터 읽어들인 page 수입니다. (일반적인 page in 입니다.)

- PgspOut

Paging space로 write된 page 수입니다. (일반적인 page out 입니다.)

- PageIn

초당 읽어들인 page 수입니다. (paging space로부터의 page in을 제외한 모든 page in, persistent segment에 대한 page in이 포함됩니다.)

- PageOut

초당 write 된 page 수입니다. (paging space로 page out을 제외한 모든 page out, ㅔpersistent segment에 대한 page out이 포함됩니다.)

- Sios

VMM에 의해 발생된(page stealer) 초당 input/output page의 요청 수입니다.

- Real

Megabyte 단위의 실제 physical memory의 크기를 보여줍니다.

- %Comp

Computational page에 할당된 real memory 량입니다.

- %Noncomp

Non-computational page에 할당된 real memory 량입니다.

- %Client

Remotely mounted file들에 대해 cache로 사용되는 메모리의 량입니다.

 

- svmon

svmon은 현재 시스템의 메모리 사용량에 대한 정보를 상세하게 확인할 수 있습니다.



 

위와 같이 전체 시스템의 memory 사용율이 나오게 됩니다.

 

- memory
     real memory의 사용율에 대한 정보 출력됩니다.
     - size : real memory frame의 수입니다.
     - inuse : page들을 포함하고 있는 frame의 수입니다.
     - free : 모든 memory pool의 free frame의 수입니다.
     - pin : pinned page를 포함하고 있는 frame의 수입니다.
     - virtual : working segment를 위한 system virtual space에 할당된 page 수입니다.
   - pg space
     쉽게 swap 대한 정보 출력합니다.
     - size : 전체 paging 공간 크기입니다.
     - inuse : 사용중인 paging 공간입니다.
   - pin
     고정 영역에 대한 상세 정보입니다.
     - work : 작업 세그먼트 페이지를 포함하는 page 수입니다.
     - pers : 영구 세그먼트 페이지를 포함하는 page 수입니다.
     - clnt : 클라이언트 세그먼트 페이지를 포함하는 page 수입니다.

- vmo

vmo는 memory관련된 튜닝을 위해 VMM setting을 위한 툴입니다.

vmo 에는 다양한 tuning parameter가 있으며, 이러한 parameter를 활용하여 시스템에서 메모리 관리에 관련된 효과적인 방법을 제시할 수 있습니다.

 

 

굉장히 다양한 parameter들이 있습니다. 흔히 접하게 되는 값들로는 maxclient%, maxfree, maxperm%, maxpin%, minfree, minperm%등이 있습니다.

vmo의 값 parameter에 대해서는 따로 포스팅하기로 하겠습니다.

 

이렇게 기본적으로 AIX에서 내부적인 memory관리를 이해하기 위한 내용과 모니터링 부분에 대해 알아보았습니다.

위의 내용을 기본으로 좀더 세부적인 메카니즘을 알아가 보시는 것도 재미있을것 같습니다.

반응형
반응형


참조    : http://ssambback.tistory.com/entry/Unix-or-Linux-%EB%B3%84-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%A8-%EC%97%90%EB%9F%AC%EB%93%A4


프로그램 에러 시그널들 (SIGFPE, SIGILL, SIGSEGV, SIGBUS, SIGABRT) - 매우 중요 ★★★★★

다음의 시그널들은 심각한 프로그램의 에러가 운영체제나 컴퓨터 자체에 의해 검출되었을 때 발생 된다. 
일반적으로, 이들 시그널 모두는 당신의 프로그램이 심각하게 깨져있고, 에러가 포함된 그 실행을 계속할 아무런 방법이 없음을 지적한다.


어 떤 프로그램들은 프로그램의 에러 시그널로 인해서 종료되기전에 그들을 깨끗하게 처리한다. 예를 들어, 터미널 입력의 반향을 끈(tnun off) 프로그램들은 다시 반향을 켤 목적으로 프로그램 에러 시그널들을 처리할 것이다. 핸들러는 시그널을 위한 디폴트 동작을 정하고 그 동작을 함으로써 끝날 것이다. 만일 프로그램이 시그널 핸들러를 가지지 않았다면, 프로그램은 그 시그널로 인해서 종료될 것이다.

SIGFPE 시그널은 심각한 산술적 에러를 보고한다. 그 이름이 "floating-point exception"에서 유래된것이라 할지라도, 이 시그널은 실제로는 모든 산술적 에러들에 작용한다. 만일 어떤 프로그램이 어떤 위치에 정수 데이터를 저장하고 그 데이터에 플로팅-포인트 명령을 사용한다면, 이것은 그 프로세서가 데이터를 플로팅-포인트 수로써 인식할 수 없기 때문에 종종 "유용하지 않은 연산"의 원인이 된다.

SIGILL 시그널의 이름은 "비합법적인 명령(illegal instruction)"에서 유래되었다
그것은 쓸모없거나 특권이 부여된 명령어를 실행하려 했다는 의미이다. 
오직 유용한 명령어만이 발생된 C 컴파일러에서, SIGILL은 전형적으로 실행 가능 파일이 훼손되었거나, 당신이 데이터를 실행하려 시도했다는 것을 지적한다. 

후자의 상황이 발생되는 일반적 상황으로는 함수를 위한 포인터가 있을 것이라고 예상된 곳에서 유용하지 않은 오브젝트를 파싱하거나, 자동 배열의 끝을 넘어서 기록을 하고( 또는 자동 변수를 위한 포인터와 유사한 문제들) 스택 프레임의 반환 어드레스 처럼 스택에서 
다른 데이터의 훼손과 같은 문제들이 있다.

SIGSEGV 시그널은 할당된 메모리의 범위를 벗어나는곳에서 읽거나, 쓰기를 시도할 때 발생 된다. 
(실제로, 그 시그널들은 프로그램이 충분한 영역을 할당받지 못할 때 시스템 메모리 보호 메커니즘에 의해서 발생한다.) 

그 이름은 "segmentation violation"의 약자이다. 
SIGSEGV 상황이 발생되는 가장 일반적인 방법은 비참조 되는 널( defeferencing a null) 이나 초기화되지 않은 포인터에 의한 것이다. 

널 포인터는 주소 0으로 참조되고, 대부분의 운영체제는 이 주소가 정확하게 유용하지 않음을 확실히 
하기 때문에 
비참조 널 포인터는 SIGSEGV가 발생될 것이다. 
(어떤 운영체제는 주소가 0인 메모리도 유용하고, 비참조 널 포인터는 그들 시스템상에서는 시그널을 발생하지 않는다.) 
비초기화된 포인터에서는, 유용하지 않거나, 유용하더라도 임의의 주소들을 갖게된다. 
SIGSEGV 상황이 얻어지는 다른 일반적 방법은 배열에 포인터를 사용했을 때 그 배열의 끝을 체크하기를 실패했을 때이다. 

SIGBUS 시그널은 유용하지 않은 포인터가 비참조되었을 때 발생 된다. 
SIGSEGV 처럼, 이 시그널은 초기화되지 않은 포인터를 비참조 한 것의 결과이다. 
두 시그널의 차이점은 SIGSEGV는 유용한 메모리에서 유용하지못한 억세스를 지적하고, 
SIGBUS는 유용하지못한 주소를 억세스 하는 것을 지적한다. 
특별하게, SIGBUS 시그널은 4개로 나누어지지 않은 주소에 4-단어 정수로 참조하는것처럼, 
부적당한 포인터가 비참조 됨으로써 발생한다. 
(각종 시스템은 주소 정렬은 위한 자신만의 필요조건을 갖는다.) 이 시그널의 이름은 "bus error"의 약자이다.

SIGABRT 시그널은 프로그램 그 자체와 abort가 호출되었음을 보고함으로써 발생되는 에러를 지적한다.

2. 종료 시그널 (SIGHUP, SIGINT, SIGQUIT, SIGTERM, SIGKILL) - 중요 ★★★★

이들 시그널들은 이런 저런 방법으로 프로세스를 종료함을 알리기위해 사용된다. 
그들은 완전히 다른 목적을 위해 사용되기 때문에 다른 이름을 가졌고, 프로그램은 그들은 다르게 취급하기를 원할 것이다.
이들 시그널들은 처리하기 위한 이유는 보통 당신의 프로그램이 실제로 종료되기전에 적당하게 처리할 수 있도록 하기 위한 것이다. 
예를 들어, 당신은 상황정보를 저장하고, 임시 파일들을 지우고, 이전의 터미널 모드를 반환하기를 원할수도 있다. 
그와 같이 핸들러(handler)는 발생된 시그널을 위한 디폴트 동작을 지정하고 그리고 그 시그널을 다시 발생시킴으로써 종료할 것이다. 
이것은 만일 프로그램이 핸들러를 가지지 않았더라도, 그 시그널로 인해서 프로그램이 종료될 것이다.

SIGHUP ("hang-up") 시그널은 사용자 터미널의 단절을 보고하기 위해 사용되어지는데, 
아마도 네트웍이나 전화선 연결이 끊어졌기 때문이다. 

SIGINT("program interrupt") 시그널은 사용자가 INTR 문자를 (보통 C-c)을 입력했을 때 보내어진다. 

SIGQUIT 시 그널은 다른 키_QUIT 문자, 보통 C-\_에 의해서 제어된다는 것을 제외하고는 SIGINT와 유사하고, 그 프로세스가 종료 될 때 프로그램 에러 시그널처럼 코어 파일을 작성한다. 당신은 사용자에 의해 "검출된" 프로그램 에러 상황으로 이들을 생각할 수 있다. 

SIGTERM 시그널은 프로그램을 종료하는데 사용하는 포괄적인 시그널이다. SIGKILL과 달리, 이 신호는 블록되어진고, 처리되어지고 무시되어질 수 있다.

SIGKILL 시그널은 즉각적인 프로그램 종료를 일으키기 위해서 사용되어진다. 이 시그널은 처리되거나, 무시되거나 할 수 없고, 그 결과는 항상 치명적이 된다. 이 시그널은 블록하는것도 불가능하다. 

3. 알람 시그널 (SIGALRM, SIGVTALRM, SIGPROF) - 알아도 그만.. 몰라도 그만..  ^^;;

그들 시그널은 타이머의 경과를 지적하는데 사용되어진다. 
그들 시그널을 위한 디폴트 동작은 프로그램을 종료를 일으키는 것이다. 
이 디폴트 동작은 거의 유용하지 않다. 
그 들 시그널을 사용하는 대부분의 방법은 어느 경우에 맞는 핸들러 함수들을 요구하는 것이다.

SIGALRM 시그널은 전형적으로 실제또는 클럭 시간을 계산한 타이머의 경과를 지적한다. 
예를 들어 alarm 함수에의해 사용되어진다. 

SIGVTALRM 시그널은 전형적으로 현재 프로세스에 의해 사용된 CPU시간을 계산하는 타이머의 경과를 지적한다. 
그 이름은 "virtual time alarm"의 약자이다.

SIGPROF 시그널은 현재의 프로세스에 의해 사용된 CPU 시간과, 
프로세스를 대신하여 시스템에의해 사용된 CPU시간의 둘을 계산한 타이머의 경과를 지적하는데 사용된다. 
타이머가 자원의 프로파일링을 위한 도구로써 사용되어지므로, 시그널의 이름이 SIGPROF이다.

4. 비동기 입/출력 시그널 (SIGIO, SIGURG)

이 절에 설명된 시그널들은 비동기 입/출력 도구들과 함께 사용되어진다. 
당신은 어떤 특정한 파일 기술자가 그들 시그널을 발생시키도록 하기 위해서 fcntl을 호출함으로써 명백한 동작을 취하도록 해야한다.

SIGIO 시그널은 파일기술자가 입력 또는 출력을 수행할 준비가 되어있을 때 보내어진다. 
대부분의 운영체제에서, 터미널과 소켓만이 SIGIO를 발생시킬 수 있다. 
보통의 파일들을 포함한 다른 종류들은 당신이 그들에게 요청했을지라도 SIGIO신호를 발생시키지 않는다.

SIGURG 시그널은 소켓에 도착한 데이터가 "긴급"하거나 범위를 벗어 났을 때 보내어진다.

5. 작업 제어 시그널 (SIGCHLD, SIGCONT, SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) - 중요 ★★★★

이들 시그널은 작업 제어를 지원하기 위해서 사용되어진다. 
만일 당신의 시스템이 작업 제어를 지원하지 않는다면 시그널들은 발생되어지거나, 처리될 수는 없지만 매크로들은 정의되어있다. 
당신이 실제로 작업이 어떻게 제어되는지를 이해할 수 없다면 그들 시그널을 그대로 방치할 것이다.

SIGCHLD 시그널은 자식 프로세스들중의 하나라도 종료되거나 멈출 때마다 부모 프로세스에게 보내어진다. 
이 시그널을 위한 디폴트 동작은 그것을 무시하는 것이다. 

당신은 프로세스가 계속되도록 하기 위해서 SIGCONT 신호를 보낼 것이다.
SIGCONT 시그널을 위한 디폴트 동작은 만일 그 프로세스가 멈추었다면 그 프로세스를 계속하도록 만드는 것이고 
그렇지 않다면 그것을 무시하는 것이다. 
대부분의 프로그램에서는 SIGCONT를 처리할 아무런 이유가 없다. 
그들은 전에 멈추었었음을 인식함이 없이 계속 실행되고 있다고 가정한다. 

SIGSTOP 시그널은 프로세스를 멈춘다. 그것은 처리되거나, 무시되거나 블록될 수 없다.

SIGTSTP 시그널은 상호 작용하는 멈춤 신호이다. SIGSTOP와는 달리 이 신호는 처리되거나 무시되어질 수 있다. 
당신의 프로그램에서 프로세스가 멈추었을 때 파일이나 시스템 테이블을 안전한 상황으로 만들어놓을 특별한 필요가 있다면 
이 신호를 처리할 수 있다.

한 프로세스가 배경 작업으로써 실행되고 있는 동안 사용자의 터미널로부터 읽을 수 없다. 
배경 작업에 속한 어느 프로세스가 터미널로부터 읽으려 시도할 때, 그 작업에 속한 모든 프로세스는 SIGTTIN 신호를 받는다. 
이 시그널을 위한 디폴트 동작은 그 프로세스를 멈추는 것이다. 

SIGTTOU 시그널은 배경 작업에 속한 프로세스가 터미널에 출력하려 시도하거나 그 터미널 모드를 설정하려 시도할 때 발생 된다. 
다시 말하면 디폴트 동작은 그 프로세스를 멈추는 것이다. 
프로세스가 멈추어있을 동안, SIGKILL 시그널과 SIGCONT시그널을 제외하고는 어느 다른 시그널들은 배달되어질 수 없다.

SIGKILL 시그널은 항상 프로세스의 종료를 유발하고 블록되거나 무시될 수 없다. 
당신이 SIGCONT 시그널을 무시하거나 블록할 수 있지만, 그것은 만일 그 프로세스가 멈추어져있다면 프로세스가 계속되도록 한다. 
프로세스에게 보낸 SIGCONT 시그널은 아직 미해결인채로 남아있는 멈춤 시그널을 프로세스가 버리도록 한다. 
이와 비슷하게, 어떤 프로세스에서 아직 미해결인채로 남아있는 SIGCONT 시그널은 멈춤 시그널이 도착했을 때 버려진다. 
고아가 되어버린 프로세스 그룹에 있는 한 프로세스에게 SIGTSTP, SIGTTIN, 또는 SIGTTOU 시그널을 보내면 그것은 처리되지도 않고, 
그 프로세스는 멈추어 지지도 않는다. 
그것을 계속할 아무런 방법이 없는 부당하게 되어버린 프로세스를 멈추게 하라. 
운영체제에 의존하지 말고당신이 무언가를 사용해서 멈추게 하라. 어떤 시스템은 아무런 일도 하지 않을 것이다. 
다른 시스템들은 대신에 SIGKILL 또는 SIGHUP와 같은 시그널들을 배달할 것이다. 

6. 잡다한 시그널 (SIGUSR1 ~ SIGUSR22)

그들 시그널은 다양한 다른 상활들을 보고하기 위해서 사용되어진다. 이들의 디폴트 동작은 프로세스가 종료되도록 하는 것이다.

SIGPIPE 시그널은 읽는 프로세스가 없는 상황에서의 PIPE에 대한 쓰기시 발생한다.

SIGUSR1 과 SIGUSR22 시그널들은 당신이 원하는 어떤 방법을 사용하지 못하도록 한다. 그들은 프로세스간 통신을 위해서 유용하다. 

그들 시그널을 보통 심각하기 때문에 당신은 그 시그널을 받은 프로그램에서 그들은 위한 시그널 처리를 해야할 것이다.



출처: http://ssambback.tistory.com/entry/Unix-or-Linux-별-프로그램-에러들 [Rehoboth.. 이곳에서 부터]

반응형
반응형

출처 : http://www.sysnet.pe.kr/Default.aspx?mode=2&sub=0&detail=1&pageno=0&wid=964&rssMode=1&wtype=0


정말로 좋은 글이 또 퍼옴. 두고두고 공부할 때 읽을 예정...





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

사실, 처음 이 질문에 의문을 느꼈을 때 제 심중의 대답은 Port 수 제한이었습니다. unsigned short(2byte) 이니까 65535 일 텐데 그나마 시스템에서 사용하는 포트를 제외해야 하니 약 60K 정도는 생성할 수 있을 것이라는 계산이었습니다.

서버 한대에 6만 개의 클라이언트라면 그다지 나쁘지 않은 연결 수인 것 같았지만, 최근의 64비트 다중 코어/소켓을 장착한 고성능 서버들이 출현하는 상황에서 거의 무한대에 가까운 16byte 주소값을 갖는 IPv6에서도 포트를 나타내는 타입이 USHORT 인 것을 보고는 다소 놀랬습니다.

=== ws2ipdef.h ===
typedef struct sockaddr_in6 {
    ADDRESS_FAMILY sin6_family; // AF_INET6.
    USHORT sin6_port;           // Transport level port number.
    ULONG  sin6_flowinfo;       // IPv6 flow information.
    IN6_ADDR sin6_addr;         // IPv6 address.
    union {
        ULONG sin6_scope_id;     // Set of interfaces for a scope.
        SCOPE_ID sin6_scope_struct; 
    };
} SOCKADDR_IN6_LH, *PSOCKADDR_IN6_LH, FAR *LPSOCKADDR_IN6_LH;


여전히 미래에도 60K 동시 연결만을 제공한다는 걸까요?

도저히 그럴 수는 없다는 상식으로, 검색을 해보았습니다. 그런데... 꽤나 의외더군요. 이에 대한 의문을 갖는 사람도 별로 없었을 뿐더러, 대부분은 답변까지 포함해서 틀린 답들 뿐이었습니다. (일부 답변은 Windows 2000만 있었을 당시라서 그 때에는 맞는 답일 수 있습니다.)

이론상 접속 가능한 최대 인원은? 
; http://www.gpgstudy.com/forum/viewtopic.php?topic=5370

다시한번질문드립니다.소켓의 한계...한피씨의 서버용량은???
; http://www.borlandforum.com/impboard/impboard.dll?action=read&db=bcb_qna&no=15833

소켓 생성시 최대개수는..... 얼마나..  
; http://www.devpia.com/Maeul/Contents/Detail.aspx?BoardID=50&MaeulNo=20&no=206826&ref=206665

Windows에서 열 수 있는 Socket 수 얻는 방법
; http://bspfp.pe.kr/63

WSAAsyncSelect 로가능한 소켓갯수는...
; http://www.tipssoft.com/bulletin/board.php?bo_table=QnA&wr_id=16299


사실, 검색도 힘들었는데... 디아블로인가... ^^; 게임에서 제공되는 소켓 아이템이라는 동일 이름 때문이었습니다. (다시 한번 놀랬지만, 게임 유저들의 그 참여/공유 정신은 대단한 것 같습니다. ^^)

다음 차례로, 외국 자료가 남았군요. 검색을 해보니, 진단이 딱 나옵니다.

One Million TCP Connections...
; http://www.serverframework.com/asynchronousevents/2010/12/one-million-tcp-connections.html


윈도우상에서의 이론 상 한계는 "16,777,214" 이라고 합니다. 이 정도면 결국 실질적인 한계가 문제인데, 아래의 글에서 잘 정리해 주고 있습니다.

How to support 10,000 or more concurrent TCP connections
; http://www.serverframework.com/asynchronousevents/2010/10/how-to-support-10000-concurrent-tcp-connections.html


  • Data copies
  • Context switches
  • Memory allocation
  • Lock contention


즉, 서버 스펙도 따라야 하고, 해당 응용 프로그램의 메모리/로직에 따라서 천차만별이 된다는 것이죠. ^^

참고로, 아래는 일반적인 threshold 값들인데 아마도 Windows Server 2003 기준의 값인 것 같습니다. 운영체제마다 변경된 부분이 있을 테니 적용할 때는 적절하게 감안을 해주셔야 할 것입니다.

Configure the max limit for concurrent TCP connections 
; http://smallvoid.com/article/winnt-tcpip-max-limit.html





그런데, 아직... 의문이 안 풀린 분들이 있을 텐데요. 과연 어떻게 포트 번호 범위를 넘어서는 16,777,214 값이 나오게 된 걸까요? 이에 대한 설명은 위에서 소개한 "One Million TCP Connections..." 글의 댓글에서 글쓴이가 쉽게 설명해 주고 있습니다.

No, that's a common misconception. You're limited to the local ports when making outbound connections as each connection consumes a local port and they are limited to 65535 as you point out and when you take into account the number of ports already in use for other services and any connections currently in TIME_WAIT the maximum number of outbound ports is usually at most 50k.

Inbound ports are identified by a tuple that consists of the local ip and port and the remote ip and port and so are not limited in the same way. I've run tests whereby a simple server on very modest hardware supported more than 70,000 concurrent active connections - the test server and client that I used can be found here: http://www.lenholgate.com/archives/000568.html



오~~~ 역시 머리 좋은 사람들은 다르군요. ^^ 어차피 내부에서 해당 소켓을 식별만 하면 되는데 굳이 2바이트 정수로 제한할 필요없이 구분키의 범위를 연결을 시도한 측의 IP/Port를 함께 포함하니 자연스럽게 65,535 개의 한계가 없어져버립니다. 실제로 글쓴이는 760 MB 메모리만을 가진 Windows Server 2003 시스템으로 7만 개의 동시 연결을 테스트했다고 합니다.

재미있군요. 직접 테스트 해보실 분들 계신가요? 700 MB 정도에 7만 개면, 24 GB 메모리면 테스트에 사용한 동일한 서버 프로그램으로 210만 개는 무난하게 나온다는 얘기가 되는 군요. 그럼, 서버는 그 정도 사양으로 한 대 준비하면 될 것 같고. 반면에 클라이언트는 제법 준비를 해둬야 합니다. 왜냐 하면 클라이언트 측은 여전히 65,535 포트 범위 제한이 있기 때문에, 100만개 연결 테스트만 해도 20 대 정도가 넘게 필요합니다. Virtual NIC의 특별한 제한이 없다면 가상 PC를 20개 정도 마련해야 겠군요. (참고로, 가정용 무선 Access Point로는 네트워크 연결 테스트하지 마세요. ^^ 제 경우에는 천 개만 넘어도 네트워크가 멈춰버렸습니다.)

혹시, 환경 구성해서 테스트 하시는 분이 계시면 결과 좀 공유 부탁드리겠습니다. ^^

반응형
반응형

출처 : http://d2.naver.com/helloworld/47667


정말로 좋은 글이 있어서 천천히 두고두고 공부할려고 파왔음...





TCP/IP 없는 인터넷 서비스는 상상할 수 없습니다. 우리가 개발하고 사용하는 모든 인터넷 서비스는 TCP/IP라는 튼튼한 토대에 기반하고 있습니다. 어떻게 네트워크를 통해 데이터가 오가는지를 이해하면, 튜닝 등을 통한 성능 개선이나 트러블 슈팅, 신기술 도입 등에 많은 도움이 됩니다.

이 글에서는 Linux 운영체제와 하드웨어 레이어에서의 데이터 흐름과 제어 흐름을 바탕으로 네트워크 스택에 대한 전반적인 작동 방식을 알아보겠습니다.

TCP/IP의 중요한 성질

데이터의 순서가 바뀌지 않으면서 데이터가 유실되지 않도록 가급적 빠르게 데이터를 보내려면 네트워크 프로토콜을 어떻게 설계해야 할까? TCP/IP는 이런 고민 아래 설계된 것이다. 다음은 스택을 이해하는데 필요한 TCP/IP의 중요한 성질이다.


TCP와 IP

엄밀히 말해 TCP와 IP는 서로 다른 레이어의 것이라 분리해서 이해하는 것이 옳지만, 이해의 편의상 여기서는이 장에서는 둘을 분리하지 않고 설명한다.


1. Connection oriented

두 개 엔드포인트(로컬, 리모트) 사이에 연결을 먼저 맺고 데이터를 주고받는다. 여기서 'TCP 연결 식별자'는 두 엔드포인트의 주소를 합친 것으로, <로컬 IP 주소, 로컬 포트번호, 리모트 IP 주소, 리모트 포트번호> 형태이다.

2. Bidirectional byte stream

양방향 데이터 통신을 하고, 바이트 스트림을 사용한다.

3. In-order delivery

송신자(sender)가 보낸 순서대로 수신자(receiver)가 데이터를 받는다. 이를 위해서는 데이터의 순서가 필요하다. 순서를 표시하기 위해 32-bit 정수 자료형을 사용한다.

4. Reliability through ACK

데이터를 송신하고 수신자로부터 ACK(데이터 받았음)를 받지 않으면, 송신자 TCP가 데이터를 재전송한다. 따라서 송신자 TCP는 수신자로부터 ACK를 받지 않은 데이터를 보관한다(buffer unacknowledged data).

5. Flow control

송신자는 수신자가 받을 수 있는 만큼 데이터를 전송한다. 수신자가 자신이 받을 수 있는 바이트 수 (사용하지 않은 버퍼 크기, receive window)를 송신자에게 전달한다. 송신자는 수신자 receive window가 허용하는 바이트 수만큼 데이터를 전송한다.

6. Congestion control

네트워크 정체를 방지하기 위해 receive window와 별도로 congestion window를 사용하는데 이는 네트워크에 유입되는 데이터양을 제한하기 위해서이다. Receive window와 마찬가지로 congestion window가 허용하는 바이트 수만큼 데이터를 전송하며 여기에는 TCP Vegas, Westwood, BIC, CUBIC 등 다양한 알고리즘이 있다. Flow control과 달리 송신자가 단독으로 구현한다.

데이터 전송

이름이 설명하듯, 네트워크 스택에는 여러 레이어(layer)가 있다. 어떤 레이어가 있는지는 그림 2에서 알 수 있다.

여러 레이어가 있지만, 크게 유저(user) 영역, 커널(kernel) 영역, 디바이스로(device) 영역으로 나눌 수 있다. 유저 영역과 커널 영역에서의 작업은 CPU가 수행한다. 이 유저 영역과 커널 영역은 디바이스 영역과 구별하기 위해 호스트(host)라고 부른다. 여기서 디바이스는 패킷을 송수신하는 NIC(Network Interface Card)이다. 흔히 부르는 랜카드보다 더 정확한 용어이다.

networkstack1

그림 1 데이터 전송 시 TCP/IP 네트워크 스택의 각 레이어 별 동작 과정

유저 영역부터 밑으로 내려가 보자. 우선 애플리케이션이 전송할 데이터를 생성하고(그림 1에서 User data 상자), write 시스템 콜을 호출해서 데이터를 보낸다. 소켓(그림 2에서 fd)은 이미 생성되어 연결되어 있다고 가정한다. 시스템 콜을 호출하면 커널 영역으로 전환된다.

Linux나 Unix를 포함한 POSIX 계열 운영체제는 소켓을 file descriptor로 애플리케이션에 노출한다. 이런 POSIX 계열의 운영체제에서 소켓은 파일의 한 종류다. 파일(file) 레이어는 단순한 검사만 하고 파일 구조체에 연결된 소켓 구조체를 사용해서 소켓 함수를 호출한다.

커널 소켓은 두 개의 버퍼를 가지고 있다. 송신용으로 준비한 send socket buffer, 수신용으로 준비한 receive socket buffer이다. Write 시스템 콜을 호출하면 유저 영역의 데이터가 커널 메모리로 복사되고, send socket buffer의 뒷부분에 추가된다. 순서대로 전송하기 위해서다. 그림에서 옅은 회식 상자가 이미 socket buffer에 존재하는 데이터를 의미한다. 이 다음으로 TCP를 호출한다.

소켓과 연결된 TCP Control Block(TCB) 구조체가 있다. TCB에는 TCP 연결 처리에 필요한 정보가 있다. TCB에 있는 데이터는 connection state(LISTEN, ESTABLISHED, TIME_WAIT 등), receive window, congestion window, sequence 번호, 재전송 타이머 등이다.

현재 TCP 상태가 데이터 전송을 허용하면 새로운 TCP segment, 즉 패킷을 생성한다. Flow control 같은 이유로 데이터 전송이 불가능하면 시스템 콜은 여기서 끝나고, 유저 모드로 돌아간다(즉, 애플리케이션으로 제어권이 넘어간다).

TCP segment에는 TCP 헤더와 페이로드(payload)가 있다. 페이로드에는 ACK를 받지 않은 send socket buffer에 있는 데이터가 담겨 있다. 페이로드의 최대 길이는 receive window, congestion window, MSS(Maximum Segment Size) 중 최대 값이다.

그리고 TCP checksum을 계산한다. 이 checksum 계산에는 pseudo 헤더 정보(IP 주소들, segment 길이, 프로토콜 번호)를 포함시킨다. 여기서 TCP 상태에 따라 패킷을 한 개 이상 전송할 수 있다.

사실 요즘의 네트워크 스택에서는 checksum offload 기술을 사용하기 때문에, 커널이 직접 TCP checksum을 계산하지 않고 대신 NIC가 checksum을 계산한다. 여기서는 설명의 편의를 위해 커널이 checksum을 계산한다고 가정한다.

생성된 TCP segment는 IP 레이어로 이동한다(내려 간다). IP 레이어에서는 TCP segment에 IP 헤더를 추가하고, IP routing을 한다. IP routing이란 목적지 IP 주소(destination IP)로 가기 위한 다음 장비의 IP 주소(next hop IP)를 찾는 과정을 말한다.

IP 레이어에서 IP 헤더 checksum을 계산하여 덧붙인 후, Ethernet 레이어로 데이터를 보낸다.

Ethernet 레이어는 ARP(Address Resolution Protocol)를 사용해서 next hop IP의 MAC 주소를 찾는다. 그리고 Ethernet 헤더를 패킷에 추가한다. Ethernet 헤더까지 붙으면 호스트의 패킷은 완성이다.

IP routing을 하면 그 결과물로 next hop IP와 해당 IP로 패킷 전송할 때 사용하는 인터페이스(transmit interface, 혹은 NIC)를 알게 된다. 따라서 transmit NIC의 드라이버를 호출한다.

만약 tcpdumpWireshark 같은 패킷 캡처 프로그램이 작동 중이면 커널은 패킷 데이터를 프로그램이 사용하는 메모리 버퍼에 복사한다. 수신도 마찬가지로 드라이버 바로 위에서 패킷을 캡처한다. 대개 traffic shaper 기능도 이 레이어에서 동작하도록 구현되어있다.

드라이버는 NIC 제조사가 정의한 드라이버-NIC 통신 규약에 따라 패킷 전송을 요청한다.

NIC는 패킷 전송 요청을 받고, 메인 메모리에 있는 패킷을 자신의 메모리로 복사하고, 네트워크 선으로 전송한다. 이때 Ethernet 표준에 따라 IFG(Inter-Frame Gap), preamble, 그리고 CRC를 패킷에 추가한다. IFG, preamble은 패킷의 시작을 판단하기 위해 사용하고(네트워킹 용어로는 framing), CRC는 데이터 보호를 위해 사용한다(TCP, IP checksum과 같은 용도이다). 패킷 전송은 Ethernet의 물리적 속도, 그리고 Ethernet flow control에 따라 전송할 수 있는 상황일 때 시작된다. 회의장에서 발언권을 얻고 말하는 것과 비슷하다.

NIC가 패킷을 전송할 때 NIC는 호스트 CPU에 인터럽트(interrupt)를 발생시킨다. 모든 인터럽트에는 인터럽트 번호가 있으며, 운영체제는 이 번호를 이용하여 이 인터럽트를 처리할 수 있는 적합한 드라이버를 찾는다. 드라이버는 인터럽트를 처리할 수 있는 함수(인터럽트 핸들러)를 드라이브가 가동되었을 때 운영체제에 등록해둔다. 운영체제가 핸들러를 호출하고, 핸들러는 전송된 패킷을 운영체제에 반환한다.

지금까지 설명한 것은 애플리케이션에서 쓰기를 하였을 때 데이터가 커널과 디바이스를 거쳐 전송되는 과정이다. 그런데 애플리케이션이 쓰기 요청을 직접적으로 하지 않아도 커널이 TCP를 호출해서 패킷을 전송하는 경우가 있다. 예를 들어 ACK을 받아 receive window가 늘어나면 socket buffer에 남아있는 데이터를 포함한 TCP segment를 생성하여 상대편에 전송한다.

데이터 수신

이제 어떻게 데이터를 수신하는지 알아보도록 하자. 패킷이 외부에서 도착했을 때 어떻게 작동하는지에 대한 것이다. 그림 3에서 네트워크 스택이 수신한 패킷을 처리하는 과정을 알 수 있다.

networkstack2

그림 2 데이터 수신 시 TCP/IP 네트워크 스택의 각 레이어 별 동작 과정

우선 NIC가 패킷을 자신의 메모리에 기록한다. CRC 검사로 패킷이 올바른지 검사하고, 호스트의 메모리버퍼로 전송한다. 이 버퍼는 드라이버가 커널에 요청하여 패킷 수신용으로 미리 할당한 메모리이고, 할당을 받은 후 드라이버는 NIC에 메모리 주소와 크기를 알려 준다. NIC가 패킷을 받았는데, 드라이버가 미리 할당해 놓은 호스트 메모리 버퍼가 없으면 NIC가 패킷을 버릴 수 있다 (packet drop).

패킷을 호스트 메모리로 전송한 후, NIC가 호스트운영체제에 인터럽트를 보낸다.

드라이버가 새로운 패킷을 보고 자신이 처리할 수 있는 패킷인지 검사한다. 여기까지는 제조사가 정의한 드라이버-NIC 통신 규약을 사용한다.

드라이버가 상위 레이어로 패킷을 전달하려면 운영체제가 이해할 수 있도록, 받은 패킷을 운영체제가 사용하는 패킷 구조체로 포장해야 한다. 예를 들어, Linux의 sk_buff, BSD 계열 커널의 mbuf, 그리고 Microsoft Windows의 NET_BUFFER_LIST가 운영체제의 패킷 구조체이다. 드라이버는 이렇게 포장한 패킷을 상위 레이어로 전달한다.

Ethernet 레이어에서도 패킷이 올바른지 검사하고, 상위 프로토콜(네트워크 프로토콜)을 찾는다(de-multiplex). 이때 Ethernet 헤더의 ethertype 값을 사용한다. IPv4 ethertype은 0x0800이다. Ethernet 헤더를 제거하고 IP 레이어로 패킷을 전달한다.

IP 레이어에서도 패킷이 올바른지 검사한다. IP 헤더 checksum을 확인하는 것이다. 논리적으로 여기서 IP routing을 해서 패킷을 로컬 장비가 처리해야 하는지, 아니면 다른 장비로 전달해야 하는지 판단한다. 로컬 장비가 처리해야 하는 패킷이면 IP 헤더의 proto 값을 보고 상위 프로토콜(트랜스포트 프로토콜)을 찾는다. TCP proto 값은 6이다. IP 헤더를 제거하고 TCP 레이어로 패킷을 전달한다.

하위 레이어에서와 마찬가지로 TCP 레이어에서도 패킷이 올바른지 검사한다. TCP checksum도 확인한다. 앞서 언급했듯이 요즘의 네트워크 스택에는 checksum offload 기술이 적용되어 있기 때문에 커널이 checksum을 직접 계산하지 않는다.

다음으로 패킷이 속하는 연결, 즉 TCP control block을 찾는다. 이때 패킷의 <소스 IP, 소스 port, 타깃 IP, 타깃 port>를 식별자로 사용한다. 연결을 찾으면 프로토콜을 수행해서 받은 패킷을 처리한다. 새로운 데이터를 받았다면, 데이터를 receive socket buffer에 추가한다. TCP 상태에 따라 새로운 TCP 패킷(예를 들어 ACK 패킷)을 전송할 수 있다. 여기까지 해서 TCP/IP 수신 패킷 처리 과정이 끝나게 된다.

Receive socket buffer 크기가 결국은 TCP의 receive window이다. 어느 지점까지는 receive window가 크면 TCP throughput이 증가한다. 예전에는 socket buffer 크기를 애플리케이션이나 운영체제 설정에서 조절하고는 했다. 최신 네트워크 스택은 receive socket buffer 크기, 즉 receive window를 자동으로 조절하는 기능을 가지고 있다.

이후 애플리케이션이 read 시스템 콜을 호출하면 커널 영역으로 전환되고, socket buffer에 있는 데이터를 유저 공간의 메모리로 복사해 간다. 복사한 데이터는 socket buffer에서 제거한다. 그리고 TCP를 호출한다. TCP는 socket buffer에 새로운 공간이 생겼기 때문에 receive window를 증가시킨다. 그리고 프로토콜 상태에 따라 패킷을 전송한다. 패킷 전송이 없으면 시스템 콜이 종료된다.

네트워크 스택 발전 방향

지금까지 설명한 네트워크 스택 레이어가 하는 일은 가장 기본적인 기능이다. 1990년대 초반의 네트워크 스택은 이보다 약간 더 기능이 많은 정도였다. 하지만 요즘의 최신 네트워크 스택은 더 많은 기능을 가지고 있고, 따라서 네트워크 스택 구현체의 복잡성도 증가했다.

최신의 네트워크 스택을 목적에 따라 구분해 보면 다음과 같다.

패킷 처리 과정 조작 기능

Netfilter(방화벽, NAT 등), traffic control 같은 기능이다. 기본 처리 흐름에 사용자가 제어할 수 있는 코드를 삽입해서 사용자 설정에 따라 다양한 효과를 낸다.

프로토콜 성능

주어진 네트워크 환경에서 TCP 프로토콜이 달성할 수 있는 throughput, latency, stability 등의 개선을 목표로 한다. 다양한 congestion control 알고리즘들과 SACK 같은 TCP 추가 기능이 대표적인 예이다. 프로토콜 개선 사항은 이 글의 범위 바깥이라 여기서는 다루지 않겠다.

패킷 처리 효율

한 장비가 패킷을 처리하는데 소요되는 CPU cycle, 메모리 사용량, 메모리 접근 수 등을 줄여서 초당 처리할 수 있는 최대 패킷 수를 개선하는 것을 목표로 한다. 장비 내부에서의 레이턴시(latency)를 줄이는 것을 포함한 여러 시도가 있었다. 스택 병렬처리, header prediction, zero-copy, single-copy, checksum offload, TSO, LRO, RSS 등 여러 가지가 있다.

스택 내부 제어 흐름(control flow)

이제 Linux 네트워크 스택의 내부 흐름을 좀더 깊게 살펴보자. 네트워크 스택이 아닌 서브시스템과 마찬가지로, 네트워크 스택은 기본적으로 이벤트 발생에 반응하는 event-driven 방식으로 작동한다. 따라서 스택 수행을 위한 별도 스레드는 없다. 그림 2와 그림 3은 제어 흐름을 매우 단순화한 것이고, 그림 4에서 좀 더 정확한 제어 흐름을 볼 수 있다.

networkstack3

그림 3 스택 내부 제어 흐름

그림 3의 (1)은 애플리케이션이 시스템 콜을 호출하여 TCP를 수행(사용)하는 경우다. 예를 들어, read 시스템 콜과 write 시스템 콜을 호출하고 TCP를 수행한다. 하지만 패킷 전송은 없다.

(2)는 (1)과 같은데, TCP 수행 결과 패킷 전송이 필요한 경우다. 패킷을 생성해서 드라이버로 패킷을 내려 보낸다. 드라이버의 앞 부분에는 큐(queue)가 있다. 패킷은 우선 큐에 들어가고, 큐 구현체가 패킷이 드라이버로 전달되는 시점을 결정한다. Linux의 qdisc(queue discipline)가 이것이다. Linux traffic control 기능은 qdisc를 조작하는 것이다. 기본으로 사용하는 qdisc는 단순한 FIFO(first-in-first-out) 큐이다. 다른 qdisc를 사용하면 인위적인 패킷 유실, 패킷 지연, 전송 속도 제한 등 여러 가지 효과를 달성할 수 있다. (1), (2)에서는 애플리케이션의 프로세스 스레드가 드라이버까지 실행한다.

(3) 흐름은 TCP가 사용하는 타이머가 만료된 경우다. 예를 들어, TIME_WAIT 타이머가 만료되면 TCP를 호출해서 연결을 삭제한다.

(4) 흐름은 (3)과 같이 TCP가 사용하는 타이머가 만료된 경우인데, TCP 수행 결과 패킷 전송이 필요한 경우다. 예를 들어 재전송 타이머(retransmit timer)가 만료되면, ACK를 받지 못한 패킷을 전송한다.

(3), (4) 흐름은 타이머 인터럽트를 처리한 softirq가 실행되는 과정이다.

NIC 드라이버가 인터럽트를 받으면 전송된 패킷을 반환한다(free). 대개 여기서 드라이버 실행이 끝난다. (5) 흐름은 transmit queue에 패킷이 적체된 경우다. 드라이버가 softirq를 요청하고, softirq 핸들러가 transmit queue를 실행해서 적체된 패킷을 드라이버로 보낸다.

NIC 드라이버가 인터럽트를 받고 새로 수신된 패킷을 발견하면 softirq를 요청한다. 수신 패킷을 처리하는 softirq가 드라이버를 호출해서 수신된 패킷을 상위 레이어로 전달한다. Linux는 이와 같이 수신 패킷을 처리하는 것을 NAPI(new API)라고 부른다. 드라이버가 상위 레이어로 직접 전달하지 않고, 상위 레이어가 직접 패킷을 가져가기 때문에 polling과 유사하다. 실제 코드는 NAPI poll 혹은 poll이라 부른다.

(6)은 TCP까지 수행한 경우, (7)은 추가 패킷 전송이 필요한 경우를 보여준다. (5), (6), (7) 모두 NIC 인터럽트를 처리한 softirq가 실행한다.

인터럽트와 수신 패킷 처리

인터럽트 처리는 복잡하지만 패킷 수신 처리에 따른 성능 문제를 이해하기 위해 필요하다. 그림 4에서 인터럽트 처리 과정을 볼 수 있다.

networkstack4

그림 4 인터럽트, softirq, 그리고 수신 패킷 처리

CPU 0이 애플리케이션 프로그램(user program)을 실행하고 있다고 가정하자. 이때 NIC가 패킷을 수신하고 CPU 0을 인터럽트한다. CPU는 커널 인터럽트(흔히 irq라고 부른다) 핸들러를 실행한다. 이 핸들러가 인터럽트 번호를 보고 드라이버 인터럽트 핸들러를 호출한다. 드라이버는 전송된 패킷은 반환하고, 수신된 패킷을 처리하기 위해 napi_schedule() 함수를 호출한다. 이 함수가 softirq(소프트웨어 인터럽트)를 요청한다.

드라이버 인터럽트 핸들러의 실행이 종료되면 커널 핸들러로 제어권이 돌아간다. 커널 핸들러가 softirq에 대한 인터럽트 핸들러를 실행시킨다.

Interrupt context가 실행되었으니 softirq context가 실행될 차례이다. Interrupt context와 softirq context가 실행되는 스레드는 같다. 하지만 스택이 서로 다르다. 그리고 interrupt context는 하드웨어 인터럽트를 차단하지만, softirq context는 하드웨어 인터럽트를 허용한다.

수신 패킷을 처리하는 softirq 핸들러는 net_rx_action() 함수이다. 이 함수는 드라이버의 poll() 함수를 호출한다. poll() 함수는 netif_receive_skb() 함수를 호출해서 수신 패킷을 한 개씩 상위 레이어로 보낸다. softirq 처리가 종료되면, 애플리케이션은 시스템 콜을 요청하기 위하여 중단했던 지점부터 다시 수행을 재개한다.

따라서 인터럽트를 받은 CPU가 수신 패킷을 처음부터 끝까지 처리한다. Linux, BSD, Microsoft Windows 모두 기본으로 이와 같이 작동한다.

패킷 수신을 많이 하는 서버 CPU 사용률을 보면 한 CPU만 열심히 softirq를 실행하는 현상을 종종 확인할 수 있다. 지금까지 설명한 수신 패킷 처리 방식 때문에 발생하는 현상이다. 이 문제를 풀기 위해 multi-queue NIC, RSS, RPS가 나왔다.

데이터 구조체

중요한 데이터 구조체 몇 개를 살펴보고 실제 코드를 따라가 보자.

sk_buff 구조체

첫째, 패킷을 의미하는 sk_buff 구조체 혹은 skb 구조체가 있다. 그림 5는 sk_buff 구조체의 일부를 보여준다. 기능이 발전되면서 이보다 더 복잡해졌지만 기본적으로 필요한 기능은 누구나 생각할 수 있는 것들이다.

networkstack5

그림 5 패킷 구조체 sk_buff

패킷 데이터, 메타 데이터 포함

패킷 데이터를 구조체가 직접 포함하고 있거나, 포인터를 사용해서 참조하고 있다. 그림 5에서는 패킷 일부는 (Ethernet부터 buffer까지) 데이터 포인터를 이용해 참조하고 있고, 추가 데이터(frags)는 실제 페이지를 참조하고 있다.

메타 데이터 영역에는 헤더, 페이로드 길이 등 필요한 정보를 저장한다. 예를 들어, 그림 5에서 볼 수 있는 mac_header에는 Ethernet 헤더, network_header에는 IP 헤더, transport_header에는 TCP 헤더 시작 위치를 가리키고 있는 포인터 데이터가 있다. 이런 방식은 TCP 프로토콜 매우 편리하게 처리할 수 있게 한다.

헤더 추가, 삭제

네트워크 스택의 각 레이어를 왔다갔다하며 헤더를 추가, 삭제한다. 효율적으로 처리하기 위해 포인터들을 사용한다. 예를 들어, Ethernet 헤더를 제거하려면, head 포인터를 증가하면 된다.

패킷 결합, 분리

Socket buffer에 패킷 페이로드 데이터를 추가, 삭제, 또는 패킷 체인 같은 작업을 효율적으로 수행하기 위해 linked list를 사용한다. next, prev 포인터가 이 용도로 사용된다.

빠른 할당(allocation)과 반환(free)

패킷을 생성할 때마다 구조체를 할당하기 때문에 빠른 allocator를 사용한다. 예를 들어, 10 Gigabit Ethernet 속도로 데이터를 전송하면 초당 1백만 패킷 이상을 생성, 제거해야 한다.

TCP control block

둘째, TCP 연결을 대표하는 구조체가 있다. 앞서 추상적으로 TCP control block이라 불렀는데, Linux는 tcp_sock을 사용한다. 그림 7에서 file, socket과 tcp_sock 등이 어떤 관계에 있는지 알 수 있다.

networkstack6

그림 6 TCP 연결 구조체

시스템 콜이 발생하면 시스템 콜을 호출한 애플리케이션이 사용하는 file descriptor에 있는 file을 찾는다. Unix 계열 운영체제에서는 socket, 저장을 위한 일반 files system 용 file, 디바이스 등 여러 가지를 모두 file로 추상화한다. 따라서 file 구조체는 최소한의 정보만 포함한다. Socket의 경우 별도 socket 구조체가 소켓 관련 정보를 저장하고, file은 socket을 포인터로 참조한다. Socket은 다시 tcp_sock을 참조한다. tcp_sock은 sock, inet_sock 등으로 세분화되어 있는데, TCP 외의 다양한 프로토콜을 지원하기 위해서다. 일종의 폴리모피즘과 비슷하다고 보면 되겠다.

tcp_sock에는 TCP 프로토콜이 사용하는 모든 상태 정보를 저장한다. 예를 들어, 시퀀스 번호, receive window, congestion control, 재전송 타이머 등 정보가 모두 모여 있다.

Send socket buffer와 receive socket buffer는 sk_buff 리스트이고, tcp_sock을 포함한다. IP routing 결과물인 dst_entry도 참조해서 매번 routing하지 않도록 한다. dst_entry를 사용해서 ARP 결과, 즉 목적지 MAC 주소도 쉽게 찾는다. dst_entry는 routing table의 일부이다. routing table의 구조는 상당히 복잡해서 이 글에서는 다루지 않겠다. dst_entry를 사용해서 패킷 송신에 사용해야 하는 NIC를 찾는다. NIC는 net_device 구조체로 표현한다.

따라서 file만 찾으면 TCP 연결을 처리하는데 필요한 모든 구조체(file부터 드라이버까지)를 포인터로 쉽게 찾을 수 있다. 이들 구조체의 크기가 TCP 연결 하나가 사용하는 메모리의 양이다. 메모리의 양은 수 KB 정도(패킷 데이터 제외)다. 메모리 사용량도 기능이 추가되면서 꾸준히 증가했다.

마지막으로 TCP 연결 lookup table이 있다. 해시 테이블(hash table)인데, 수신된 패킷이 속하는 TCP 연결을 찾는데 사용한다. 해시 값은 패킷의 <소스 IP, 타깃 IP, 소스 port, 타깃 port>를 입력 데이터로 하고, Jenkins hash 알고리즘을 사용해서 계산한다. 해시 함수는 해시 테이블 공격에 대한 방어를 고려해서 선택했다고 한다.

코드 따라가기: 데이터 전송

실제 Linux 커널 소스 코드를 따라가며 스택이 수행하는 주요 작업을 알아보자. 자주 사용하는 경로 두 개만 살펴보겠다.

우선 애플리케이션이 write 시스템 콜을 호출할 때 데이터가 전송되는 경로를 보자.

SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf, ...)  
{
struct file *file;  
[...]
file = fget_light(fd, &fput_needed);  
[...] ===>
ret = filp->f_op->aio_write(&kiocb, &iov, 1, kiocb.ki_pos);

struct file_operations {  
[...]
ssize_t (*aio_read) (struct kiocb *, const struct iovec *, ...)  
ssize_t (*aio_write) (struct kiocb *, const struct iovec *, ...)  
[...]
};

static const struct file_operations socket_file_ops = {  
[...]
.aio_read = sock_aio_read,
.aio_write = sock_aio_write,
[...]
};

write 시스템 콜을 호출하면 커널이 파일 레이어의 write() 함수를 수행한다. 우선 file descriptor fd의 실제 file 구조체를 가져온다. 그리고 aio_write를 호출한다. 이것은 함수 포인터이다. file 구조체를 보면 file_operations 구조체 포인터가 있는데, 이 구조체는 흔히 부르는 function table이고, aio_read, aio_write등 함수 포인터를 포함한다. 실제 소켓용 table은 socket_file_ops이다. 소켓이 사용하는 aio_write 함수는 sock_aio_write이다. Function table은 Java 인터페이스와 유사한 용도로 사용한다. 커널이 코드 추상화나 리팩토링(refactoring)을 할 때 흔히 사용한다.

static ssize_t sock_aio_write(struct kiocb *iocb, const struct iovec *iov, ..)  
{
[...]
struct socket *sock = file->private_data;  
[...] ===>
return sock->ops->sendmsg(iocb, sock, msg, size);

struct socket {  
[...]
struct file *file;  
struct sock *sk;  
const struct proto_ops *ops;  
};

const struct proto_ops inet_stream_ops = {  
.family = PF_INET,
[...]
.connect = inet_stream_connect,
.accept = inet_accept,
.listen = inet_listen, .sendmsg = tcp_sendmsg,
.recvmsg = inet_recvmsg,
[...]
};

struct proto_ops {  
[...]
int (*connect) (struct socket *sock, ...)  
int (*accept) (struct socket *sock, ...)  
int (*listen) (struct socket *sock, int len);  
int (*sendmsg) (struct kiocb *iocb, struct socket *sock, ...)  
int (*recvmsg) (struct kiocb *iocb, struct socket *sock, ...)  
[...]
};

sock_aio_write 함수는 file에서 socket 구조체를 가져오고 sendmsg를 호출한다. 이것도 함수 포인터이다. Socket 구조체는 proto_ops function table을 포함한다. IPv4 TCP가 구현한 proto_ops는 inet_stream_ops이고, sendmsg는 tcp_sendmsg가 구현하고 있다.

int tcp_sendmsg(struct kiocb *iocb, struct socket *sock,  
struct msghdr *msg, size_t size)  
{
struct sock *sk = sock->sk;  
struct iovec *iov;  
struct tcp_sock *tp = tcp_sk(sk);  
struct sk_buff *skb;  
[...]
mss_now = tcp_send_mss(sk, &size_goal, flags);

/* Ok commence sending. */
iovlen = msg->msg_iovlen;  
iov = msg->msg_iov;  
copied = 0;  
[...]
while (--iovlen >= 0) {  
int seglen = iov->iov_len;  
unsigned char __user *from = iov->iov_base;

iov++;  
while (seglen > 0) {  
int copy = 0;  
int max = size_goal;  
[...]
skb = sk_stream_alloc_skb(sk,  
select_size(sk, sg),  
sk->sk_allocation);  
if (!skb)  
goto wait_for_memory;  
/*
* Check whether we can use HW checksum.
*/
if (sk->sk_route_caps & NETIF_F_ALL_CSUM)  
skb->ip_summed = CHECKSUM_PARTIAL;  
[...]
skb_entail(sk, skb);  
[...]
/* Where to copy to? */
if (skb_tailroom(skb) > 0) {  
/* We have some space in skb head. Superb! */
if (copy > skb_tailroom(skb))  
copy = skb_tailroom(skb);  
if ((err = skb_add_data(skb, from, copy)) != 0)  
goto do_fault;  
[...]
if (copied)  
tcp_push(sk, flags, mss_now, tp->nonagle);  
[...]
}

tcp_sengmsg는 socket에서 tcp_sock, 즉 TCP control block을 가져오고, 애플리케이션이 전송 요청한 데이터를 send socket buffer로 복사한다. 데이터를 sk_buff로 복사할 때 sk_buff 하나가 몇 바이트를 포함해야 할까? 실제 패킷을 생성하는 코드를 돕기 위해 sk_buff 하나가 MSS(tcp_send_mss) 바이트가 포함되도록 복사한다. MSS는 'Maximum Segment Size'로 TCP 패킷 한 개가 포함하는 최대 페이로드 크기다. TSO, GSO를 사용하면 sk_buff 한 개가 MSS보다 더 많은 데이터를 저장하는데, 이 부분은 다음 기회에 설명하겠다.

sk_stream_alloc_skb 함수가 새로운 sk_buff를 생성하고, skb_entail이 send_socket_buffer 꼬리에 새로운 sk_buff를 추가한다. skb_add_data 함수가 실제 애플리케이션 데이터를 sk_buff의 데이터 버퍼로 복사한다. 이 과정(sk_buff 생성, send socket buffer에 추가)을 여러 번 반복해서 모든 데이터를 복사한다. 결국은 MSS 크기의 sk_buff들이 send socket buffer에 리스트로 묶여 있는 모양이 된다. 끝으로 tcp_push를 호출해서 지금 전송할 수 있는 데이터를 패킷으로 만들어서 전송한다.

static inline void tcp_push(struct sock *sk, int flags, int mss_now, ...)  
[...] ===>
static int tcp_write_xmit(struct sock *sk, unsigned int mss_now, ...)  
int nonagle,  
{
struct tcp_sock *tp = tcp_sk(sk);  
struct sk_buff *skb;  
[...]
while ((skb = tcp_send_head(sk))) {  
[...]
cwnd_quota = tcp_cwnd_test(tp, skb);  
if (!cwnd_quota)  
break;

if (unlikely(!tcp_snd_wnd_test(tp, skb, mss_now)))  
break;  
[...]
if (unlikely(tcp_transmit_skb(sk, skb, 1, gfp)))  
break;

/* Advance the send_head. This one is sent out.
* This call will increment packets_out.
*/
tcp_event_new_data_sent(sk, skb);  
[...]

tcp_push 함수는 TCP가 허용하는 만큼 send socket buffer의 sk_buff를 차례대로 전송한다. 우선 tcp_send_head 호출해서 socket buffer의 가장 앞에 있는 sk_buff를 가져오고, tcp_cwnd_test, tcp_snd_wnd_test로 congestion window과 수신 TCP의 receive window가 새로운 패킷 전송을 허용하는지 확인한다. 그리고 tcp_transmit_skb 함수를 호출해서 실제 패킷을 생성한다.

static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb,  
int clone_it, gfp_t gfp_mask)  
{
const struct inet_connection_sock *icsk = inet_csk(sk);  
struct inet_sock *inet;  
struct tcp_sock *tp;  
[...]


if (likely(clone_it)) {  
if (unlikely(skb_cloned(skb)))  
skb = pskb_copy(skb, gfp_mask);  
else  
skb = skb_clone(skb, gfp_mask);  
if (unlikely(!skb))  
return -ENOBUFS;  
}

[...]
skb_push(skb, tcp_header_size);  
skb_reset_transport_header(skb);  
skb_set_owner_w(skb, sk);

/* Build TCP header and checksum it. */
th = tcp_hdr(skb);  
th->source = inet->inet_sport;  
th->dest = inet->inet_dport;  
th->seq = htonl(tcb->seq);  
th->ack_seq = htonl(tp->rcv_nxt);  
[...]
icsk->icsk_af_ops->send_check(sk, skb);  
[...]
err = icsk->icsk_af_ops->queue_xmit(skb);  
if (likely(err <= 0))  
return err;

tcp_enter_cwr(sk, 1);

return net_xmit_eval(err);  
}

tcp_transmit_skb은 주어진 sk_buff의 복사본(pskb_copy)을 만든다. 이때 애플리케이션 데이터 전체를 복사하지 않고, 메타데이터만 복사한다. 그리고 skb_push를 호출해서 헤더 영역을 확보하고, 헤더 필드 값을 기록한다. send_check은 TCP checksum을 계산한다. Checksum offload를 사용하면 페이로드 데이터는 계산하지 않는다. 마지막으로, queue_xmit를 호출해서 IP 레이어로 패킷을 보낸다. IPv4 용 queue_xmit은 ip_queue_xmit 함수가 구현한다.

int ip_queue_xmit(struct sk_buff *skb)  
[...]
rt = (struct rtable *)__sk_dst_check(sk, 0);  
[...]
/* OK, we know where to send it, allocate and build IP header. */
skb_push(skb, sizeof(struct iphdr) + (opt ? opt->optlen : 0));  
skb_reset_network_header(skb);  
iph = ip_hdr(skb);  
*((__be16 *)iph) = htons((4 << 12) | (5 << 8) | (inet->tos & 0xff));
if (ip_dont_fragment(sk, &rt->dst) && !skb->local_df)  
iph->frag_off = htons(IP_DF);  
else  
iph->frag_off = 0;  
iph->ttl = ip_select_ttl(inet, &rt->dst);  
iph->protocol = sk->sk_protocol;  
iph->saddr = rt->rt_src;  
iph->daddr = rt->rt_dst;  
[...]
res = ip_local_out(skb);  
[...] ===>
int __ip_local_out(struct sk_buff *skb)  
[...]
ip_send_check(iph);  
return nf_hook(NFPROTO_IPV4, NF_INET_LOCAL_OUT, skb, NULL,  
skb_dst(skb)->dev, dst_output);  
[...] ===>
int ip_output(struct sk_buff *skb)  
{
struct net_device *dev = skb_dst(skb)->dev;  
[...]
skb->dev = dev;  
skb->protocol = htons(ETH_P_IP);

return NF_HOOK_COND(NFPROTO_IPV4, NF_INET_POST_ROUTING, skb, NULL, dev,  
ip_finish_output,  
[...] ===>
static int ip_finish_output(struct sk_buff *skb)  
[...]
if (skb->len > ip_skb_dst_mtu(skb) && !skb_is_gso(skb))  
return ip_fragment(skb, ip_finish_output2);  
else  
return ip_finish_output2(skb);  

ip_queue_xmit 함수는 IP 레이어에서 필요한 작업을 한다. __sk_dst_check은 캐시(cache)한 route가 유효한지 확인한다. 캐시한 route가 없거나 유효하지 않으면 IP routing을 한다. 그리고 skb_push를 호출해서 IP 헤더 영역을 확보하고, IP 헤더 필드 값을 기록한다. 이후 함수 호출을 따라가면, ip_send_check가 IP 헤더 checksum을 계산하고, netfilter 함수도 호출한다. ip_finish_output 함수가 IP fragmentation이 필요하면 fragment를 만든다. TCP 사용시 fragmentation은 발생하지 않는다. 결국은 ip_finish_output2가 호출되고, 이것이 Ethernet 헤더를 추가한다. 이로써 패킷이 완성된다.

int dev_queue_xmit(struct sk_buff *skb)  
[...] ===>
static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q, ...)  
[...]
if (...) {  
....
} else
if ((q->flags & TCQ_F_CAN_BYPASS) && !qdisc_qlen(q) &&  
qdisc_run_begin(q)) {  
[...]
if (sch_direct_xmit(skb, q, dev, txq, root_lock)) {  
[...] ===>
int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q, ...)  
[...]
HARD_TX_LOCK(dev, txq, smp_processor_id());  
if (!netif_tx_queue_frozen_or_stopped(txq))  
ret = dev_hard_start_xmit(skb, dev, txq);

HARD_TX_UNLOCK(dev, txq);  
[...]
}

int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev, ...)  
[...]
if (!list_empty(&ptype_all))  
dev_queue_xmit_nit(skb, dev);  
[...]
rc = ops->ndo_start_xmit(skb, dev);  
[...]
}

완성된 패킷은 dev_queue_xmit 함수를 통해 전송된다. 먼저 qdisc를 거친다. 기본 qdisc를 사용하고 큐가 비어있으면 sch_direct_xmit 함수를 호출해서 큐를 거치지 않고 패킷을 바로 드라이버로 내려 보낸다. dev_hard_start_xmit 함수가 실제 드라이버를 호출하는데, 드라이버를 호출하기 전에 디바이스 TX 락을 잡는다. 여러 스레드가 동시에 디바이스 접근하는 것을 막기 위해서다. 커널이 락을 잡기 때문에, 드라이버 전송 코드는 별도 락이 필요 없다. 다음 기회에 설명할 병렬 처리와 밀접한 관계가 있다.

ndo_start_xmit 함수가 드라이버 코드를 호출한다. 바로 전에, ptype_all, dev_queue_xmit_nit가 보인다. ptype_all은 패킷 캡쳐 같은 모듈을 포함하는 리스트다. 캡쳐 프로그램이 작동 중이면, 여기서 해당 프로그램으로 패킷을 복사한다. 따라서 tcpdump가 보여 주는 패킷은 드라이버로 전달되는 패킷이다. Checksum offload, TSO 등을 사용하면 NIC가 패킷을 조작하기 때문에, tcpdump 패킷은 실제 네트워크 선으로 전송되는 패킷과 다르다. 패킷 전송이 완료되면 드라이버 인터럽트 핸들러가 sk_buff를 반환한다.

코드 따라가기: 데이터 수신

둘째로 흔히 수행하는 경로는 패킷을 수신해서 receive socket buffer에 데이터를 추가하는 작업이다. 드라이버 인터럽트 핸들러 수행 후 napi poll 핸들부터 따라가 보자.

static void net_rx_action(struct softirq_action *h)  
{
struct softnet_data *sd = &__get_cpu_var(softnet_data);  
unsigned long time_limit = jiffies + 2;  
int budget = netdev_budget;  
void *have;

local_irq_disable();

while (!list_empty(&sd->poll_list)) {  
struct napi_struct *n;  
[...]
n = list_first_entry(&sd->poll_list, struct napi_struct,  
poll_list);  
if (test_bit(NAPI_STATE_SCHED, &n->state)) {  
work = n->poll(n, weight);  
trace_napi_poll(n);  
}
[...]
}

int netif_receive_skb(struct sk_buff *skb)  
[...] ===>
static int __netif_receive_skb(struct sk_buff *skb)  
{
struct packet_type *ptype, *pt_prev;  
[...]
__be16 type;  
[...]
list_for_each_entry_rcu(ptype, &ptype_all, list) {  
if (!ptype->dev || ptype->dev == skb->dev) {  
if (pt_prev)  
ret = deliver_skb(skb, pt_prev, orig_dev);  
pt_prev = ptype;  
}
}
[...]
type = skb->protocol;  
list_for_each_entry_rcu(ptype,  
&ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
if (ptype->type == type &&  
(ptype->dev == null_or_dev || ptype->dev == skb->dev ||
ptype->dev == orig_dev)) {  
if (pt_prev)  
ret = deliver_skb(skb, pt_prev, orig_dev);  
pt_prev = ptype;  
}
}

if (pt_prev) {  
ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);

static struct packet_type ip_packet_type __read_mostly = {  
.type = cpu_to_be16(ETH_P_IP),
.func = ip_rcv,
[...]
};

앞서 설명했듯 net_rx_action 함수는 패킷을 수신하는 softirq 핸들러다. napi poll을 요청한 드라이버를 poll_list에서 가져와서 드라이버의 poll 핸들러를 호출한다. 드라이버는 수신한 패킷을 sk_buff로 포장하고, netif_receive_skb를 호출한다.

netif_receive_skb는 모든 패킷을 원하는 모듈이 있으면 그 모듈로 패킷을 전달한다. 패킷 전송 때와 같이 ptype_all 리스트에 등록된 모듈로 패킷을 전달한다. 패킷 캡처 작업은 여기서 수행된다.

그리고 패킷 종류에 따라 상위 레이어를 찾아 패킷을 전달한다. Ethernet 패킷은 헤더에 2 바이트 ethertype 필드를 포함한다. 이 값이 패킷 종류를 나타낸다. 이 값은 드라이버가 sk_buff에 기록한다(skb->protocol). 각 프로토콜은 자신만의 packet_type 구조체를 가지고, ptype_base hash table에 이 구조체의 포인터를 등록한다. IPv4는 ip_packet_type을 사용한다. Type 필드 값이 IPv4 ethertype (ETH_P_IP) 값이다. 따라서 IPv4 패킷은 ip_rcv 함수를 호출한다.

int ip_rcv(struct sk_buff *skb, struct net_device *dev, ...)  
{
struct iphdr *iph;  
u32 len;  
[...]
iph = ip_hdr(skb);  
[...]
if (iph->ihl < 5 || iph->version != 4)  
goto inhdr_error;

if (!pskb_may_pull(skb, iph->ihl*4))  
goto inhdr_error;

iph = ip_hdr(skb);

if (unlikely(ip_fast_csum((u8 *)iph, iph->ihl)))  
goto inhdr_error;

len = ntohs(iph->tot_len);  
if (skb->len < len) {  
IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INTRUNCATEDPKTS);  
goto drop;  
} else if (len < (iph->ihl*4))
goto inhdr_error;  
[...]
return NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING, skb, dev, NULL,  
ip_rcv_finish);  
[...] ===>
int ip_local_deliver(struct sk_buff *skb)  
[...]
if (ip_hdr(skb)->frag_off & htons(IP_MF | IP_OFFSET)) {  
if (ip_defrag(skb, IP_DEFRAG_LOCAL_DELIVER))  
return 0;  
}

return NF_HOOK(NFPROTO_IPV4, NF_INET_LOCAL_IN, skb, skb->dev, NULL,  
ip_local_deliver_finish);  
[...] ===>


static int ip_local_deliver_finish(struct sk_buff *skb)  
[...]
__skb_pull(skb, ip_hdrlen(skb));  
[...]
int protocol = ip_hdr(skb)->protocol;  
int hash, raw;  
const struct net_protocol *ipprot;  
[...]
hash = protocol & (MAX_INET_PROTOS - 1);  
ipprot = rcu_dereference(inet_protos[hash]);  
if (ipprot != NULL) {  
[...]
ret = ipprot->handler(skb);  
[...] ===>

static const struct net_protocol tcp_protocol = {  
.handler = tcp_v4_rcv,
[...]
};

ip_rcv 함수는 IP 레이어에서 필요한 일을 한다. 길이, 헤더 checksum 등 패킷 검사를 한다. netfilter 코드를 거치면 ip_local_deliver 함수를 수행한다. 여기서 필요하면 IP fragment들을 조립한다. 그리고 다시 netfilter 코드를 통해서 ip_local_deliver_finish를 호출한다. 이 함수는 __skb_pull을 사용해서 IP 헤더를 제거하고, IP 헤더의 protocol 값과 일치하는 상위 프로토콜을 찾는다. Ptype_base와 유사하게 각 트랜스포트 프로토콜은 inet_protos에 자신의 net_protocol 구조체를 등록한다. IPv4 TCP는 tcp_protocol을 사용하고, handler로 등록한 tcp_v4_rcv를 호출한다.

TCP 레이어로 들어오면 TCP 상태, 패킷 종류에 따라 패킷 처리 흐름이 다양하다. 여기서는 TCP 연결이 ESTABLISHED 상태에서 다음 예상하는 데이터 패킷을 받았을 때 처리 과정을 알아본다. 패킷 유실, 역전 현상이 없으면 데이터를 받는 서버가 자주 수행하는 경로다.

int tcp_v4_rcv(struct sk_buff *skb)  
{
const struct iphdr *iph;  
struct tcphdr *th;  
struct sock *sk;  
[...]
th = tcp_hdr(skb);

if (th->doff < sizeof(struct tcphdr) / 4)  
goto bad_packet;  
if (!pskb_may_pull(skb, th->doff * 4))  
goto discard_it;  
[...]
th = tcp_hdr(skb);  
iph = ip_hdr(skb);  
TCP_SKB_CB(skb)->seq = ntohl(th->seq);  
TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +  
skb->len - th->doff * 4);  
TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);  
TCP_SKB_CB(skb)->when = 0;  
TCP_SKB_CB(skb)->flags = iph->tos;  
TCP_SKB_CB(skb)->sacked = 0;

sk = __inet_lookup_skb(&tcp_hashinfo, skb, th->source, th->dest);  
[...]
ret = tcp_v4_do_rcv(sk, skb);  

우선 tcp_v4_rcv 함수는 받은 패킷이 올바른지 검사한다. 예를 들어, 헤더 크기가 데이터 오프셋보다 크면(th->doff < sizeof(struct tcphdr) / 4) 헤더 오류이다. 그리고 __inet_lookup_skb를 호출해서 TCP 연결 해시 테이블에서 패킷이 속하는 연결을 찾는다. 찾은 sock 구조체로부터 tcp_sock, socket 등 모든 필요한 구조체를 가져올 수 있다.

int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)  
[...]
if (sk->sk_state == TCP_ESTABLISHED) { /* Fast path */  
sock_rps_save_rxhash(sk, skb->rxhash);  
if (tcp_rcv_established(sk, skb, tcp_hdr(skb), skb->len)) {  
[...] ===>
int tcp_rcv_established(struct sock *sk, struct sk_buff *skb,  
[...]
/*
* Header prediction.
*/
if ((tcp_flag_word(th) & TCP_HP_BITS) == tp->pred_flags &&  
TCP_SKB_CB(skb)->seq == tp->rcv_nxt &&  
!after(TCP_SKB_CB(skb)->ack_seq, tp->snd_nxt))) {
[...]
if ((int)skb->truesize > sk->sk_forward_alloc)  
goto step5;

NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPHPHITS);

/* Bulk data transfer: receiver */
__skb_pull(skb, tcp_header_len);  
__skb_queue_tail(&sk->sk_receive_queue, skb);  
skb_set_owner_r(skb, sk);  
tp->rcv_nxt = TCP_SKB_CB(skb)->end_seq;  
[...]
if (!copied_early || tp->rcv_nxt != tp->rcv_wup)  
__tcp_ack_snd_check(sk, 0);  
[...]
step5:  
if (th->ack && tcp_ack(sk, skb, FLAG_SLOWPATH) < 0)  
goto discard;

tcp_rcv_rtt_measure_ts(sk, skb);

/* Process urgent data. */
tcp_urg(sk, skb, th);

/* step 7: process the segment text */
tcp_data_queue(sk, skb);

tcp_data_snd_check(sk);  
tcp_ack_snd_check(sk);  
return 0;  
[...]
}

tcp_v4_do_rcv 함수부터 실제 프로토콜을 수행한다. ESTABLISHED 상태는 tcp_rcv_esablished를 호출한다. ESTABLISHED 상태가 가장 흔하기 때문에 이 상태 처리를 별도로 떼어 내서 최적화한다. tcp_rcv_established는 header prediction 코드를 먼저 수행한다. Header prediction도 흔한 경우를 감지해서 빨리 처리한다. 여기서 흔한 경우는 보낼 데이터는 없고, 받은 데이터 패킷이 다음에 받아야 하는 패킷인 경우, 즉 시퀀스 번호가 수신 TCP가 기대하는 시퀀스 번호인 경우다. 데이터를 소켓 버퍼에 추가하고 ACK를 전송하면 끝이다.

좀 더 따라가 보면 truesize와 sk_forward_alloc을 비교하는 문장이 보인다. Receive socket buffer에 새로운 패킷 데이터를 추가할 여유 공간이 있는지 확인한다. 공간이 있으면 header prediction은 "hit" (prediction 성공)이다. __skb_pull를 호출해서 TCP 헤더를 제거하고, __skb_queue_tail을 호출해서 패킷을 receive socket buffer에 추가한다. 마지막으로, __tcp_ack_snd_check를 호출해서 ACK 전송이 필요하면 전송한다. 이것이 패킷 처리의 끝이다.

만약 여유 공간이 부족하면 느린 경로를 수행한다. tcp_data_queue 함수는 버퍼 공간을 새로 할당하고 데이터 패킷을 소켓 버퍼에 추가한다. 이때 가능하면 receive socket buffer 크기를 자동으로 증가한다. 빠른 경로와 다르게, tcp_data_snd_check를 호출해서 새로운 데이터 패킷을 전송할 수 있으면 전송하고, 끝으로 tcp_ack_snd_check 호출해서 ACK 전송이 필요하면 ACK 패킷을 생성해서 전송한다.

지금 따라가 본 두 경로가 수행하는 코드의 양은 많지 않다. 자주 발생하는 경우(common case)를 최적화한 덕분이다. 바꿔 말하면 예상하지 않은 경우(uncommon case)의 처리 과정은 눈에 띄게 느리다는 뜻도 된다. 패킷 역전(out-of-order delivery) 현상이 대표적인 예다.

드라이버와 NIC의 통신

드라이버와 NIC 사이의 통신은 스택 가장 밑단이고, 대개 신경 쓰지 않는다. 하지만 성능 문제를 해결하기 위해 NIC가 수행하는 일이 많아졌다. 기본적인 작동 방식을 이해하면 추가 기술을 이해하는 데 도움이 된다.

드라이버와 NIC는 비동기 방식으로 통신한다. 먼저 드라이버가 패킷 전송을 요청하고(호출), CPU는 응답을 기다리지 않고 다른 작업을 수행한다. 이후 NIC가 패킷을 전송하고 CPU에 이 사실을 알리면 드라이버가 전송된 패킷을 반환한다(결과 리턴). 수신도 이와 같이 비동기 방식으로 이루어진다. 먼저 드라이버가 수신 요청을 하고 CPU는 다른 작업을 수행한다(호출). 이후 NIC가 패킷을 받으면 CPU에 이 사실을 알리고, 드라이버가 받은 패킷을 처리한다(결과 리턴).

따라서 요청, 응답을 저장하는 장소가 필요하다. 대개 NIC는 링(ring) 구조체를 사용한다. 링은 일반 큐 구조체와 유사하다. 고정된 수의 엔트리를 가지고, 한 엔트리가 한 요청 혹은 응답 데이테를 저장한다. 이들 엔트리들을 차례대로 돌아가며 사용한다. 돌아가며 고정된 엔트리들을 재사용하기 때문에 흔히 링이란 이름을 사용한다.

다음 그림의 패킷 전송 과정을 따라가며 링을 어떻게 사용하는지 알아보자.

networkstack7

그림 7 드라이버-NIC 통신: 패킷 전송

드라이버가 상위 레이어로부터 패킷을 받고, NIC가 이해하는 전송 요청(send descriptor)을 생성한다. send descriptor에는 기본적으로 패킷 크기, 메모리 주소를 포함하도록 한다. NIC는 메모리에 접근할 때 필요한 물리적 주소가 필요하다, 따라서 드라이버가 패킷의 가상 주소를 물리적 주소로 변경한다. 그리고 send descriptor를 TX ring에 추가한다(1). TX ring이 전송 요청 링이다.

그리고 NIC에 새로운 요청이 있다고 알린다(2). 특정 NIC 메모리 주소에 드라이버가 직접 데이터를 쓴다. 이와 같이 CPU가 디바이스에 직접 데이터를 전송하는 방식을 PIO(Programmed I/O)라고 한다.

연락을 받은 NIC는 TX ring의 send descriptor를 호스트 메모리에서 가져온다(3). CPU의 개입 없이 디바이스가 직접 메모리에 접근하기 때문에, 이와 같은 접근을 DMA(Direct Memory Access)라고 부른다.

Send descriptor를 가져와서 패킷 주소와 크기를 판단하고, 실제 패킷을 호스트 메모리에서 가져온다(4). Checksum offload 방식을 사용하면 메모리에서 패킷 데이터를 가져올 때 checksum을 NIC가 계산하도록 한다. 따라서 오버헤드는 거의 발생하지 않는다.

NIC가 패킷을 전송하고(5), 패킷을 몇 개 전송했는지 호스트의 메모리에 기록한다(6). 그리고 인터럽트를 보낸다(7). 드라이버는 전송된 패킷 수를 읽어 와서 현재까지 전송된 패킷을 반환한다.

다음 그림에서는 패킷 수신 과정을 볼 수 있다.

networkstack8

그림 8 드라이버-NIC 통신: 패킷 수신

우선 드라이버가 패킷 수신용 호스트 메모리 버퍼를 할당하고, receive descriptor를 생성한다. receive descriptor는 기본으로 버퍼의 크기, 주소를 포함한다. send descriptor와 같이 DMA가 사용하는 물리적 주소를 descriptor에 저장한다. 그리고 RX ring에 descriptor를 추가한다(1). 결국 이것이 수신 요청이고, RX ring은 수신 요청 링이다.

드라이버가 PIO를 통해서 NIC에 새로운 descriptor가 있다고 알린다(2). NIC는 RX ring의 새로운 descriptor를 가져온다. 그리고 descriptor에 포함된 버퍼의 크기, 위치를 NIC 메모리에 보관한다(3).

이후 패킷이 도착하면(4), NIC는 호스트 메모리 버퍼로 패킷을 전송한다(5). Checksum offload 기능이 있다면 NIC가 이때 checksum을 계산한다. 도착한 패킷의 실제 크기와 checksum 결과, 그 외 다른 정보는 별도의 링(receive return ring)에 기록한다(6). Receive return ring은 수신 요청 처리 결과, 즉 응답을 저장하는 링이다. 그리고 NIC가 인터럽트를 보낸다(7). 드라이버는 receive return ring에서 패킷 정보를 가져와서 받은 패킷을 처리한다. 필요에 따라 새로운 메모리 버퍼를 할당하고 (1)~(2) 단계를 반복한다.

스택 튜닝이라고 하면 흔히 ring, interrupt 설정을 조절해야 한다고 이야기한다. TX ring이 크면 한 번에 많은 수의 전송 요청을 할 수 있다. RX ring이 크면 한 번에 많은 수의 수신을 할 수 있다. 패킷 송신, 수신 burst가 많은 워크로드에는 큰 링이 도움이 된다. 그리고 CPU가 인터럽트를 처리하는 오버헤드가 크기 때문에, 대개 NIC은 인터럽트 회수를 줄이기 위해 타이머를 사용한다. 패킷을 전송하고 수신할 때 매번 인터럽트를 보내지 않고 주기적으로 모아서 보낸다(interrupt coalescing).

스택 내부 버퍼와 제어 흐름(flow control)

스택 내부의 여러 단에서 flow control을 수행한다.

그림 9는 데이터를 전송할 때 사용하는 버퍼를 보여 준다. 우선, 애플리케이션이 데이터를 생성하고 send socket buffer에 추가한다. 공간이 없으면 시스템 콜이 실패하거나, 애플리케이션 스레드에 블로킹이 발생한다. 따라서 커널로 유입되는 애플리케이션 데이터의 속도는 socket buffer 크기 제한을 통해 제어하도록 한다.

networkstack9

그림 9 패킷 전송에 관계된 버퍼들

TCP가 패킷을 생성해서 드라이버로 보낼 때는 transmit queue(qdisc)를 통하도록 하고 있다. 기본적인 FIFO 큐 형태이고, 큐의 최대 길이는 ifconfig 명령어를 실행할 때 확인할 수 있는 txqueuelen의 값이다. 보통 수 천 패킷 정도이다.

드라이버와 NIC 사이에는 TX ring이 있다. 앞서 설명했듯, 전송 요청 큐로 보면 된다. 큐 공간이 없으면 전송 요청을 못하고 패킷은 transmit queue에 적체된다. 너무 많이 적체되면 패킷 드롭을 한다.

NIC는 내부 버퍼에 전송할 패킷을 저장한다. 이 버퍼에서 패킷이 빠져나가는 속도는 우선 물리적 속도에 영향을 받는다(예: 1 Gb/s NIC가 10 Gb/s 성능을 낼 수는 없다). 그리고 Ethernet flow control을 사용하면 수신 NIC 버퍼에 공간이 없을 때는 전송이 멈춘다.

커널이 전송하는 패킷 속도가 NIC가 전송하는 속도보다 빠르면, 우선 NIC 내부 버퍼에 패킷이 적체된다. 버퍼에 공간이 없으면 TX ring의 전송 요청 처리를 멈춘다. TX ring에 점점 많은 요청이 적체되고, 결국은 큐 공간이 없어진다. 드라이버는 전송 요청을 못하고 패킷은 transmit queue에 적체된다. 이와 같이 여러 버퍼를 통해 backpressure가 밑에서 위로 올라간다.

그림 10은 반대로 수신한 패킷이 거쳐가는 버퍼를 보여 준다. 패킷은 NIC 내부 수신 버퍼에 저장된다. Flow control 관점에서 보면 드라이버와 NIC 사이의 RX ring를 패킷 버퍼로 생각하면 된다. RX ring에 들어간 패킷은 드라이버가 꺼내서 상위 레이어로 보낸다. 서버 장비가 사용하는 NIC 드라이버는 기본으로 NAPI를 사용하기 때문에 드라이버와 상위 레이어 사이에 버퍼는 없다. 상위 레이어가 RX ring에서 직접 패킷을 가져간다고 생각하면 된다. 그리고 패킷의 페이로드 데이터는 receive socket buffer에 들어간다. 이후 애플리케이션이 socket buffer에서 데이터를 가져간다.

networkstack10

그림 10 패킷 수신에 관계된 버퍼들

NAPI를 지원하지 않는 드라이버는 backlog queue에 패킷을 넣고, 후에 NAPI 핸들러가 패킷을 꺼내간다. 따라서, backlog queue는 상위 레이어와 드라이버 사이 버퍼로 보면 된다.

커널의 패킷 처리 속도가 NIC로 유입되는 패킷 속도보다 느리면 RX ring 공간이 없어진다. 그리고 NIC 내부 버퍼 공간도 없어진다. Ethernet flow control을 사용하면 NIC가 송신 NIC에 송신 정지 요청을 보내거나 패킷 드롭을 한다.

TCP는 end-to-end flow control을 지원하기 때문에, receive socket buffer 공간 부족으로 인한 패킷 드롭은 없다. 하지만 UDP는 flow control을 지원하지 않기 때문에, 애플리케이션 속도가 느리면 socket buffer 공간 부족으로 패킷 드롭이 발생한다.

그림 9와 그림 10에서 드라이버가 사용하는 TX ring의 크기와 RX ring의 크기가 ethtool이 보여 주는 링의 크기다. 대개 throughput을 중요시하는 워크로드에는 링의 크기, socket buffer 크기를 늘리면 도움이 된다. 많은 패킷을 빠른 속도로 전송, 수신할 때 버퍼 공간 부족으로 인한 실패 확률이 줄어들기 때문이다.

끝으로

네트워크 프로그램, 성능 실험, 트러블슈팅에 도움이 될만한 것들만 설명하려 했는데 정리하고 보니 내용이 적지 않게 되었다. 네트워크 애플리케이션을 개발하거나 성능 모니터링을 할 때 도움이 되었으면 한다. TCP/IP 프로토콜 자체는 상당히 복잡하고 예외 케이스도 많다. 하지만 성능 이해와 현상 분석을 하기 위해 운영체제의 TCP/IP 관련 코드 한 줄 한 줄을 모두 이해하고 있을 필요는 없다. 큰 흐름만 알고 있어도 많은 도움이 된다.

장비 성능과 운영체제의 네트워크 스택 구현이 꾸준히 발전해서, 최신 서버는 10-20 Gb/s 정도의 TCP throughput은 무리 없이 달성하고 있다. TSO, LRO, RSS, GSO, GRO, UFO, XPS, IOAT, DDIO, TOE 등 alphabet soup 같이 성능 관련한 기술 종류들이 많아서 오히려 혼란스러울 정도이다.

다음 글에서는 성능관점에서 스택을 살펴보고, 이 기술들이 해결하려는 문제와 효과를 설명하겠다.

반응형
반응형

출처 : http://wonmaum.net/bbs/board.php?bo_table=AIX&wr_id=2



CPU
. %sys + %user 가 80% 이상이면 병목으로 판단
- sys : kernel 부분이 수행되는 영역, 프로세스 스케줄링, I/O, drive, network과 관련
- wait : 디스크 I/O 작업이 끝날 때가지 기다리는 idle time
- user : 사용자 프로세스, application, database등
- idle
. 모니터링 명령어
# sar 1 5 : 1초 5회 평균 CPU 사용율
# sar -P ALL 1 5 : 각 Processor 별 사용율
# sar -q 1 5 : 시스템에서 사용한 평균 queue 및 process 표시
- runq-sz : 수행되고 있는 kernel thread의 평균 수
- %runocc : queue 가 실행된 시간의 백분율
- swpq-sz : wait 상태인 kernel thread의 평균 수
- swpocc : swap 상태인 시간의 백분율
# vmstat 1 5 : cpu 및 memory 사용율
- r : 수행중인 kernel thread 수
- b : swap에 대기중인 kernel thread 수
# ps aux
- %CPU : 프로세스가 수행된 후 사용한 CPU 시간을 전체 경과시간으로 나눈 백분율
- %MEM : 프로세스가 수행될 때 사용한 실 메모리 백분율
- SZ : 프로세스의 data 영역을 위해 할당된 virtual page size로 1Kbyte 단위
- RSS : 프로세스의 실 메모리 크기 1Kbyte 단위
Memory
. paging space In/Out이 10 이상이거나 page fault가 1000번 이상 발행하면 병목으로 판단
. memory 부족인지 user application이나 file cache에 의한 것인지 고려
- free : file cache나 프로세스가 사용하고 있지 않는 영역
- fie cache : 사용 가능한 메모리를 파일 작업시 I/O 성능 향상을 위해 cache로 사용
- paging(4KB) : 실 메모리가 부족한 경우 발생, 실 메모리에서 사용되지 않았던 영역을 디스크로 옮기고
그 부분을 free 영역으로 전환하여 process를 처리
- page fault : kernel이 필요한 data나 process의 페이지를 실 메모리에서 찾지 못하는 횟수
- page In : 필요한 page만큼 virtual memory manager(VMM)에 의해 paging space에서 read하는 초당 횟수
page out 값에 따라 발생하는 real I/O 값
- page Out : 실 메모리 free 영역 확보를 위해 VMM이 paging space에서 read out하는 초당 회수
page in 값에 따라 발생하는 real I/O 값
- page space In : paging 영역에서만 발생하는 page read
- page space out : paging 영역에서만 발생하는 page out
. 모니터링 명령어
# vmstat 1 5
- avm : 프로세스가 수행되는 동안 paging 공간에 할당된 active virtual page
- fre : VMM이 필요시 사용할 수 있는 memory free list
- re : page input/output list
- pi : paging space에서 read in 된 page
- po : paging space에서 read out 된 page
- fr : paged freed(page replacement)
- sr : page-replacement 알고리즘에 따라 page 찾기
- cy : page-replacement 알고리즘에 따른 clock cycle
# svmon -G
- memory : 실 메모리 사용 통계
. size
. inuse : 프로세스나 file cache로 사용되는 메모리
. free
. pin : pinned 영역에서 사용되는 메모리
. virtual : virtual 영역에 할당된 메모리
- pg sapce : paging 영역의 사용 통계
. size
. inuse
- pin : pinned 영역의 사용 통계
. work : working(프로세스) 메모리 중 pinned 영역에서 사용되는 메모리
. pers : persistent(file cache) 메모리 중 pinned 영역에서 사용되는 메모리
. clnt : client(NFS, cd) 메모리 중 pinned 영역에서 사용되는 메모리
- in use : 실 메모리 사용 통계
. work
. pers
. clnt
DISK I/O
. %iowait가 40% 이상이거나 사용자 application에 의해 특정 disk의 %tm_act가 70%를 초과하는 경우 병목으로 판단
- read : 초당 read 하는 데이터 크기 1Kbyte 단위
- write
- busy% : 디스크에 작업한 시간을 경과 시간으로 나눈 백분율
. 모니터링 명령어
# iostat
- %tm_act : 물리적 디스크에서 작업한 시간의 백분율
일반적으로 40%를 초과하게 되면 I/O를 완료하는 시간이 길어져 응답시간이 증가
- Kbps : 초당 디스크에 이동된 데이터 양 Kbype 단위
- tps : 초당 디바이스 드라이브 단계에서 해당 물리적 디스크로 I/O를 요청하는 횟수
- Kb_read : 물리적 디스크에 read한 양 Kbyte 단위
- Kb_wrtn : 물리적 디스크에 write한 양 Kbypte 단위
Network Traffic
. network bandwidth의 30% 이상을 사용하는 경우 병목으로 판단
- read
- write
. 모니터링 명령어
# netstat -m
# netstat -v
# netstat -ni
topas 명령어를 이용한 모니터링

1. CPU
. Kernel : CPU의 현재 사용량, 70이 넘어가면 점검 필요
. User : 각 프로세스들이 사용하는 CPU 사용량
. Wait : 처리 대기중인 프로세스의 양(10미만)
. Idle :
2. Memory
. Real,MB : 메모리의 실제 크기(MByte)
. %Comp : 현재 메모리 사용율이며, 높을수록 좋다
. %Noncomp : file cache로 할당된 영역
. %Client : aix의 file system을 위한 영역
3. Paging Space
. Size,MB : Paging Memory로 할당된 크기
. %Used : 사용중인 양, 낮을수록 좋다
. %Free
=================================================
# uname –amML : 서버 정보 확인
# uname -L : 서버 시리얼넘버 확인
# oslevel –s : OS버전확인(TL SP확인)
# instfix –i |grep ML(and SP) : OS버전 확인
# ls –al .*Com* : 패치 확인
# lsattr –El mem0 : 메모리 용량 확인
# topas : 시스템(프로세스, 메모리, 네트워크) 체크.
# lsdev –Cc disk : 디스크 확인
# lspv : 디스크 활성상태확인
# lsvg –l [볼륨그룹명] : 볼륩그룹 확인
# ifconfig – a : ip정보확인
# netstat –rn : 라우트 정보 확인 (디폴트게이트웨이 확인)
# ping [IP or Host Name] : ip 접근확인
# lsdev –Cc if : 네트워크 인터페이스 확인
# lsdev –Cc adapter : 네트워크 카드 확인
# lsdev –Cc pci : pci슬롯 확인.
# lscfg –v : FRU 확인. (lsdev –Cc, lsdev –P)
# lsconf : 장치정보
# df –k : 파일시스템 용량체크 [ -k (kilo bytes), -m (mega bytes), -g (giga bytes) ]
# lsdev –Cc processor : 프로세tm 수 확인
# ps –ef | grep [ Process Name or Pid] : 실행중인 프로세스 검색
# du –sk * : 하위 디렉토리 및 파일 용량정보 출력
=================================================
****************** IBM bundles install. ****************************
#vi /usr/sys/inst.data/user_bundles/MyBundle.bnd
I:sysmgt.websm.security. // write the file which you want to install.
#smitty easy_install
// select Mybundle which you've made and Enter.
lslpp -Lb Mybundle // verify whethere bundle was installed successfully.
smitty list_installed // verify what is installed in server.
******************** AIX 용량 확장하기 ******************************
lsvg rootvg
chfs -a size=+100M /
******************** AIX 네트워크 설정하기 **************************
smit chgenet
smitty mktcpip -> N/W interface 선택
******************** 파일셋 및 fix(AIX) 설치 여부 확인 **************
lslpp -l bos.adt.base // 파일 셋 인스톨 여부 체크
instfix -i -k "IY4390" // fix 설치 여부 체크

******************** AIX 데몬 재시작 ********************************
refresh -s inetd
startsrc -g inetd
IBM filesets 설치

#oslevel -r // OS 레벨 확인
#instfix -i|grep ML // 파일셋 버전별 설치 현황
#instfix -icqk 5300-02_AIX_ML|grep :-: // 업데이트가 필요한 filesets
download site.
www.ibm.com/servers/eserver/support/pseries/aixfixes.html
***************************** cd mount ************************************
#mount -vcdrfs -oro /dev/cd0 /mnt
#geninstall -d/dev/cd0 bos.alt_disk_install.rte // install fileset in cd.
lspv // see hard-drive information.
#bootlist -m normal hdisk1 hdisk13 // select which disk you want to boot
# bootlist -m normal -o // see which disk is on.
hdisk13

반응형
반응형

출처 : http://ttend.tistory.com/112



ㅇ 실제 메모리 용량 확인

서버가 사용하고 있는 물리적 메모리의 양은 다음 명령어로 확인할 수 있다.

# lsattr -El sys0 -a realmem

# lsattr -El sys0 -a realmem

realmem 31457280 Amount of usable physical memory in Kbytes False

31457280은 KB이며 /1024/1024 해보면 30G임을 알 수 있다

제일 뒤 "false"는 명령을 통해 변경될 수 없다는 의미이다. 


ㅇ paging space

paging space는 물리적 RAM의 추가설치에 대한 경제적 대안이다. 즉 디스크의 일부분을 RAM처럼 사용하면서 프로그램의 활성부분은 RAM에 위치시키고 비활성 부분은 paging space에 위치시켜서 프로그램이 사용하는 RAM의 용량을 늘릴 수 있기 때문이다. 

RAM과 paging space는 페이지 프레임이라는 4KB 섹션으로 나뉘어 있다. RAM에 있는 모든 페이지 프레임에 대해, paging space의 하나 이상의 페이지 프레임이 하드 디스크 상에 존재한다. 시스템이 더 많은 RAM을 필요로 할 때, 정보의 페이지 프레임은 RAM에서 나와 하드 디스크로 이동한다. 이를 페이지 아웃(paging out)이라고 한다. 반대로 디스크에 있는 정보가 RAM으로 이동하는 것을 페이지 인(paging in)이라고 한다


ㅇ 가상 메모리 관리자(VMM)

가상 메모리 관리자(VMM)이 페이지의 이동을 관리한다. VMM은 최근에 사용되지 않은 페이지 프레임을 선택해서 디스크의 paging space으로 옮긴다


ㅇ 스래싱(thrashing)

VMM이 막 사용되려던 페이지 프레임을 페이지 아웃한 경우, VMM은 이 페이지 프레임을 곧바로 페이지 인해야 한다. 시스템이 하고자 하는 작업을 수행하는 대신 RAM에 페이지 프레임을 넣고 꺼내는 데(shuffling in/out) 더 많은 시간을 소비할 때, 이 시스템은 스래싱 중이라고 말한다. 물리 메모리의 양이 적으면 스래싱을 자주 일으킬 수 있다. (시스템이 스래싱 중이라면 시스템의 응답이 느려지고 디스크의 불이 끊임없이 반짝거릴 것이다)


ㅇ 사용가능한 paging space

시스템은 사용 가능한 paging space량을 모니터링하고 있다. 사용 가능한 paging space량이 임계값(paging space 경고 레벨이라고 함) 아래로 떨어지면, 시스템은 모든 프로세스(커널 프로세스 제외)에 SIGDANGER 신호를 보내고 이 신호는 프로세스에게 정상적으로 종결하도록 지시한다.

빈 paging space량이 두 번째 임계값(paging space kill 레벨) 아래로 더 떨어지면, 시스템은 대부분의 paging space을 사용 중인 프로세스에 SIGKILL 신호를 보내고, 이 신호는 프로세스에게 강제적으로 종결하도록 지시한다.


ㅇ 기본 paging space

AIX를 설치하면, 설치 디스크(일반적으로 하드 디스크 hdisk0) 상에 paging space을 자동으로 작성한다. 

이 paging space의 이름은 항상 hd6이다. 

더 많은 paging space가 필요한 경우, hd6의 크기를 증가시키는 대신 새로운 paging space을 작성해야 한다. 


ㅇ paging space 확인

명령어 lsps로 확인할 수 있다

# lsps -a

Page Space      Physical Volume   Volume Group    Size %Used Active  Auto  Type

hd6             hdisk0            rootvg       10240MB     2   yes   yes    lv

위 그림에서 paging space는 hdisk0에 위치하고 현재 2%를 사용하고 있음을 알 수 있다.

만약 paging space을 두 개 이상 사용하고 있다면 lsps -s 명령어로 전체 paging space의 크기와 사용률을 알 수 있다


ㅇ paging space 경고

페이지 공간이 계속 70% 이상을 사용하고 메모리가 부족하면 단말에 다음과 같은 메시지가 표시된다. 

- INIT: paging space가 부족함 

- 메모리가 충분하지 않음 

- Fork 기능 실패 

- Fork() 시스템 호출 실패 

- Fork할 수 없습니다. 프로세스가 너무 많습니다. 

- Fork 실패 사용할 수 있는 메모리가 충분하지 않음 

- Fork 기능을 지원하지 않음. 사용할 수 있는 메모리가 충분하지 않음 

- Fork할 수 없음. 공간이 충분하지 않음


ㅇ paging space 설정 팁

- 디스크 당 둘 이상의 paging space을 갖지 않는 것이 좋다. paging space는 라운드 로빈(round-robin) 방식으로 할당되어 모든 페이징 영역을 동등하게 사용하기 때문에 하나의 디스크에 두 개의 페이징 영역이 있으면, 더 이상 활동을 여러 디스크에 전개할 수 없다. 

- paging space에는 많은 활동을 하지 않는 디스크를 사용하는 것이 유리하다. paging space는 다른 활동들과 경쟁하지 않을 때에 최상의 성능을 발휘할 수 있다. 

- paging space는 대략 같은 크기여야 한다. 라운드 로빈(Round-robin) 기법을 사용하므로 같은 크기가 아닐 경우, 사용의 균형이 맞지 않게 된다

- paging space을 여러 실제 볼륨으로 확장하지 않는 것이 좋다. 페이징 영역(일반 논리 볼륨처럼)을 여러 디스크에 걸쳐 전개할 수 있더라도, 라운드 로빈 (round-robin) 기법은 이 페이징 영역을 단일 페이징 영역으로 취급하므로, 이 활동은 디스크에 고르게 전개되지 않기 때문이다. 


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

출처 : http://blog.boxcorea.com/wp/archives/1458



1.현재 paging device 확인



2. swap 사용량확인




3. swap 추가하기
여기서는 foxvg에 1GB swap을 추가한다. foxvg의 PP size는 256MB 이다. 따라서 1GB 추가하려면, 4개의 LP를 사용한다.



4. 추가한 swap 사용하기
paging space를 사용하려면, swapon 커맨드로 swap을 활성화해준다.



5. swap 삭제하기
삭제전, swap 을 사용하지 않도록 설정한다.


6. 기타
chps : paging space의 속성을 변경할 때 사용한다.
예) 재부팅했을때, ps 사용하기



paging space 관련 화일: /etc/swapspaces






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

pageSpace 확장법 : http://serendipity777.tistory.com/155

Physical 메모리 100% 사용안하는 경우 : http://cafe.naver.com/aix/13491

실제 메모리를 많이 쓰는것 같지 않은데 메모리 사용률이 높게 나올때 : http://blog.naver.com/lyg1019?Redirect=Log&logNo=90126726851






반응형
반응형

해당 내역은 차후 지속적으로 추가하기로 한다...

일단 본인이 알아볼 수 있을 정도로 적어놓고 포스팅 내용은 늘리는걸로..


참고 : https://access.redhat.com/documentation/ko-KR/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/lv_extend.html

참고 : http://pinglish.tistory.com/entry/LVM-%EB%85%BC%EB%A6%AC%EB%B3%BC%EB%A5%A8-%ED%99%95%EC%9E%A5



1. PV

1) pvdisplay -> 현재 디스크 용량 및 종류 확인.

-> 새로운 디크크가 추가되었을 때 확인. 


pvcreate /dev/sdb1 등으로 새로운 디스크를 물리 볼륨에 추가한다.

-> 가상머신의 경우 각 툴에 맞는 Disk Extend를 진행하여 디스크 크기 확장.



2. VG - GParted를 사용

1) vgdisplay -v 

현재 GParted를 사용하여 해당 볼륨 그룹의 크기에 대해 간단하게 확장 진행.

GParted로 볼륨그룹 크기 늘린후 FREE PE / SIZE 확인.



3. LV

1) lvdisplay

-> 현재 논리 볼륨 확인.


논리 뷸륨의 크기를 확장하려면 lvextend 명령을 사용.

lvextend -l 인수를 사용하여 논리 볼륨 크기를 확장할 익스텐드 수를 지정.

불륨 그릅의 퍼센트나 블륨 그룹에 남아 있는 여유 공간의 퍼센트도 지정할 수 있음.


ex) lvextend -l +100%FREE /dev/vg_9rh656/lv_root


4. 논리 볼륨 확장 후 해당 파일 시스템의 크기를 확장

ex) resize2fs /dev/vg_9rh656/lv_root


4-1. lvm 파일 시스템(/etc/fstab에서 확인할 시 xfs)의 경우 resize2fs 가 아닌 xfs_growfs 를 사용하도록 한다.



5. 이후 df -h 등으로 용량 변화된것 확인.











반응형
반응형

출처 : http://www.sysnet.pe.kr/Default.aspx?mode=0&sub=0&pageno=7&detail=1&wid=269



영문 윈도우를 설치하는 분들이 가끔 겪는 문제이죠. 어떤 경우에는 한글 윈도우도 초기 윈도우 셋업시에 키보드 설정을 호기심때문에 다른 것으로 선택한 경우에도 이런 문제가 나타나곤 하는데요.

이번엔 Windows 7에서 XP 모드 VPC를 설치한 경우에 동일한 현상이 발생했습니다. Windows 7에서 구동시킬 XP 모드 VPC를 역시 영문으로 다운로드 받아서 사용하는데 우측 ALT키(한/영변환키)로 한영 전환이 안되는 문제가 발생하였습니다.

물론, 웹을 검색해 보면 해답이 나오지요. ^^

windows xp 한영 변환 오류
; http://www.ntech.in/v2/bbs/board.php?bo_table=2_window2003&wr_id=15&sfl=&stx=&sst=wr_datetime&sod=desc&sop=and&page=1


정리해보면 레지스트리 편집기에서 값을 다음과 같이 바꿔주고 재부팅하시면 됩니다.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]
"LayerDriver KOR"="KBD101A.DLL"
"OverrideKeyboardIdentifier"="PCAT_101AKEY"
"OverrideKeyboardType"=dword:00000008
"OverrideKeyboardSubtype"=dword:00000003


반응형
반응형

 

출처 : http://bwhite.tistory.com/entry/Linux-%ED%95%98%EB%93%9C%EC%9B%A8%EC%96%B4-%EC%A0%95%EB%B3%B4-%ED%99%95%EC%9D%B8%ED%95%98%EA%B8%B0-dmidecode-lshw

 

 

 

 

1. lshw 를 사용하여 하드웨어 상세 정보 확인(링크 참조)

- lshw 는 rpm 패키지를 별도로 설치해야됨

참고글 : http://jonnychoe.egloos.com/5549359

2. dmidecode 
- 설치할 필요없음
- dmidecode 명령은 서버 하드웨어, 바이오스 정보를 system DMI 테이블에서 읽어온다.
시스템의 현재 configuration 상태뿐만 아니라 최대 지원가능한 설정 정보까지도 불러온다.
예를 들어, 시스템의 현재 RAM 정보와 최대 확장가능한 RAM 정보까지도 확인할 수 있다.

dmidecode 의 output 형태는 다음과 같다.
Record Header: Handle {record id}, DMI type {dmi type id}, {record size} bytes
Record Value: {multi line record value}
  • record id: Unique identifier for every record in the DMI table.
  • dmi type id: Type of the record. i.e BIOS, Memory etc.,
  • record size: Size of the record in the DMI table.
  • multi line record values: Multi line record value for that specific DMI type.

dmidecode 명령의 output 예 :

# dmidecode | head -15

# dmidecode 2.9
SMBIOS 2.3 present.
56 structures occupying 1977 bytes.
Table at 0x000FB320.

Handle 0xDA00, DMI type 218, 11 bytes
OEM-specific Type
        Header and Data:
                DA 0B 00 DA B0 00 17 03 08 28 00

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
        Vendor: Dell Computer Corporation
        Version: A07
        Release Date: 01/13/2004

DMI 테이블의 레코드 갯수를 보기위해서는 

# dmidecode | grep ^Handle | wc -l
56

(or)

# dmidecode | grep structures
56 structures occupying 1977 bytes.

DMI Types

시스템의 CPU 정보를 보기위해서는 type id 4 옵션을 dmidecode 명령과 함께 준다.

# dmidecode -t 4
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0400, DMI type 4, 35 bytes
Processor Information
        Socket Designation: Processor 1
        Type: Central Processor
        Family: Xeon
        Manufacturer: Intel
        ID: 29 0F 00 00 FF FB EB BF
        Signature: Type 0, Family 15, Model 2, Stepping 9
        Flags:
                FPU (Floating-point unit on-chip)
                VME (Virtual mode extension)
                DE (Debugging extension)
                PSE (Page size extension)
                TSC (Time stamp counter)
                MSR (Model specific registers)

DMI type 은 아래와 같다.

Type   Information
       ----------------------------------------
          0   BIOS
          1   System
          2   Base Board
          3   Chassis
          4   Processor
          5   Memory Controller
          6   Memory Module
          7   Cache
          8   Port Connector
          9   System Slots
         10   On Board Devices
         11   OEM Strings
         12   System Configuration Options
         13   BIOS Language
         14   Group Associations
         15   System Event Log
         16   Physical Memory Array
         17   Memory Device
         18   32-bit Memory Error
         19   Memory Array Mapped Address
         20   Memory Device Mapped Address
         21   Built-in Pointing Device
         22   Portable Battery
         23   System Reset
         24   Hardware Security
         25   System Power Controls
         26   Voltage Probe
         27   Cooling Device
         28   Temperature Probe
         29   Electrical Current Probe
         30   Out-of-band Remote Access
         31   Boot Integrity Services
         32   System Boot
         33   64-bit Memory Error
         34   Management Device
         35   Management Device Component
         36   Management Device Threshold Data
         37   Memory Channel
         38   IPMI Device
         39   Power Supply

또한, type id 를 입력하는 대신에 키워드를 사용할 수도 있다.

다음은 사용가능한 키워드이다.

       Keyword     Types
       ------------------------------
       bios        0, 13
       system      1, 12, 15, 23, 32
       baseboard   2, 10
       chassis     3
       processor   4
       memory      5, 6, 16, 17
       cache       7
       connector   8
       slot        9

type id 2 와 10 에 대한 정보를 보기 위해 키워드 baseboard 를 사용한 예

# dmidecode -t baseboard
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0200, DMI type 2, 9 bytes
Base Board Information
        Manufacturer: Dell Computer Corporation
        Product Name: 123456
        Version: A05
        Serial Number: ..CN123456789098.

Handle 0x0A00, DMI type 10, 14 bytes
On Board Device 1 Information
        Type: SCSI Controller
        Status: Enabled
        Description: LSI Logic 53C1030 Ultra 320 SCSI
On Board Device 2 Information
        Type: SCSI Controller
        Status: Enabled
        Description: LSI Logic 53C1030 Ultra 320 SCSI
On Board Device 3 Information
        Type: Video
        Status: Enabled
        Description: ATI Rage XL PCI Video
On Board Device 4 Information
        Type: Ethernet
        Status: Enabled
        Description: Broadcom Gigabit Ethernet 1
On Board Device 5 Information
        Type: Ethernet
        Status: Enabled
        Description: Broadcom Gigabit Ethernet 2


dmicode 를 사용하여 RAM(Physical Memory) 에 대한 정보 확인하기

시스템에서 지원가능한 최대 RAM 크기는 얼마인가? 
아래 예는 최대 RAM 크기가 8GB 임을 보여준다.

# dmidecode -t 16
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x1000, DMI type 16, 15 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: Multi-bit ECC
        Maximum Capacity: 8 GB
        Error Information Handle: Not Provided
        Number Of Devices: 4

메모리를 얼마나 확장할 수 있는지 를 확인하기 위해 /proc/meminfo 명령을 사용하여 현재 메모리 총량을 확인할 수 있다.

# grep MemTotal /proc/meminfo
MemTotal:      1034644 kB

위 예는 현재 시스템이 1 GB 메모리를 가지고 있음을 확인할 수 있지만, 이것이 1GB 1개인지, 512MB 2개인지, 256MB 4개인지는 알 수가 없다.

dmidecode 명령을 사용하여 memory 슬롯에서 각각 사용되고 있는 RAM  크기를 알 수 있다.

아래 예는 memory slot  이 4개이며, 현재 슬롯 1,2 에 512 MB RAM 이 각각 장착되어 있음을 확인할 수 있다.

# dmidecode -t 17
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x1100, DMI type 17, 23 bytes
Memory Device
        Array Handle: 0x1000
        Error Information Handle: Not Provided
        Total Width: 72 bits
        Data Width: 64 bits
        Size: 512 MB  [Note: Slot1 has 512 MB RAM]
        Form Factor: DIMM
        Set: 1
        Locator: DIMM_1A
        Bank Locator: Not Specified
        Type: DDR
        Type Detail: Synchronous
        Speed: 266 MHz (3.8 ns)

Handle 0x1101, DMI type 17, 23 bytes
Memory Device
        Array Handle: 0x1000
        Error Information Handle: Not Provided
        Total Width: 72 bits
        Data Width: 64 bits
        Size: 512 MB [Note: Slot2 has 512 MB RAM]
        Form Factor: DIMM
        Set: 1
        Locator: DIMM_1B
        Bank Locator: Not Specified
        Type: DDR
        Type Detail: Synchronous
        Speed: 266 MHz (3.8 ns)

Handle 0x1102, DMI type 17, 23 bytes
Memory Device
        Array Handle: 0x1000
        Error Information Handle: Not Provided
        Total Width: 72 bits
        Data Width: 64 bits
        Size: No Module Installed [Note: Slot3 is empty]
        Form Factor: DIMM
        Set: 2
        Locator: DIMM_2A
        Bank Locator: Not Specified
        Type: DDR
        Type Detail: Synchronous
        Speed: 266 MHz (3.8 ns)

Handle 0x1103, DMI type 17, 23 bytes
Memory Device
        Array Handle: 0x1000

        Error Information Handle: Not Provided
        Total Width: 72 bits
        Data Width: 64 bits
        Size: No Module Installed [Note: Slot4 is empty]
        Form Factor: DIMM
        Set: 2
        Locator: DIMM_2B
        Bank Locator: Not Specified
        Type: DDR
        Type Detail: Synchronous
        Speed: 266 MHz (3.8 ns)


BIOS information 확인하기

# dmidecode -t bios
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
        Vendor: Dell Computer Corporation
        Version: A07
        Release Date: 01/13/2004
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 4096 kB
        Characteristics:
                ISA is supported
                PCI is supported
                PNP is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                ESCD support is available
                Boot from CD is supported
                Selectable boot is supported
                EDD is supported
                Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
                5.25"/360 KB floppy services are supported (int 13h)
                5.25"/1.2 MB floppy services are supported (int 13h)
                3.5"/720 KB floppy services are supported (int 13h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                CGA/mono video services are supported (int 10h)
                ACPI is supported
                USB legacy is supported
                LS-120 boot is supported
                BIOS boot specification is supported
                Function key-initiated network boot is supported

Handle 0x0D00, DMI type 13, 22 bytes
BIOS Language Information
        Installable Languages: 1
                en|US|iso8859-1
        Currently Installed Language: en|US|iso8859-1


장비의 Manufacturer, Model 과 Serial number 확인하기

# dmidecode -t system
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0100, DMI type 1, 25 bytes
System Information
        Manufacturer: Dell Computer Corporation
        Product Name: PowerEdge 1750
        Version: Not Specified
        Serial Number: 1234567
        UUID: 4123454C-4123-1123-8123-12345603431
        Wake-up Type: Power Switch

Handle 0x0C00, DMI type 12, 5 bytes
System Configuration Options
        Option 1: NVRAM_CLR:  Clear user settable NVRAM areas and set defaults
        Option 2: PASSWD:  Close to enable password

Handle 0x2000, DMI type 32, 11 bytes
System Boot Information
        Status: No errors detected

 

반응형
반응형
처리되지 않은 예외: System.InvalidOperationException: 이 구현은 Windows 플랫폼의 FIPS 유효성을 검사한 암호화 알고리즘의 일부가 아닙니다.

메모

  • 사용 하거나 사용 하지 않도록 설정 된 시스템 암호화: 암호화, 해시, 서명에 사용 FIPS 호환 알고리즘 보안 설정, 다시 시작 해야 응용 프로그램을 Internet Explorer 같은 새 설정이 적용 되려면.
  • 이 보안 설정은 Windows Server 2008 및 Windows Vista에서 다음 레지스트리 값:
    HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled
    이 레지스트리 값은 현재 FIPS 설정을 반영합니다. 이 설정을 사용 하는 값은 1입니다. 이 설정을 사용 하지 않으면 값은 0입니다.
  • 이 보안 설정은 Windows Server 2003에서 및 Windows XP에서 다음 레지스트리 값:
    HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy
    이 레지스트리 값은 현재 FIPS 설정을 반영합니다. 이 설정을 사용 하는 값은 1입니다. 이 설정을 사용 하지 않으면 값은 0입니다.


반응형
반응형

출처 : http://faq.hostway.co.kr/Linux_ETC/4258




프로세스의 PID를 확인 후

# cat /proc/PID/status | grep VmSize

VmSize:     7224 kB

 

/proc/PID/status 만 입력 시 항목 설명

 

VmSize: 전체 할당된 가상 메모리의 크기
VmRSS:
실제 물리적 메모리가 할당된 크기
VmLck:
스왑아웃 될수 없는 메모리의 크기

VmData: Heap 영역
VmStk: Stack
영역
VmExe:
실행코드 영역 (전역변수 및 실행코드)
VmLib:
동적으로 연결된 라이브러리 영역

반응형
반응형

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

가져온 곳 : 
블로그 >System engineer
|
글쓴이 : bonnie_clyde| 원글보기




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

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

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

다시 정리하고자 한다.

 

* 보통은 ~~

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

* 요기선~

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

 

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

 

 

 

 

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

 

 

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

1)  fdisk -l 하여 LVM 설정할 하드드라이브 (디스크)의 디바이스명을 확인

(fdisk -l /dev/sda 이런 식으로 하면 /dev/sda 의 파티션 내용을 확인하는 것이고, 생략하면 모든 하드드라이브의 파티션을 보여준다.)

ex) fdisk -l 실행화면

 

이런 식으로, fdisk -l /dev/sda 를 하면 sda 하드 드라이브의 논리적 파티션들의 정보가 보여진다.

df -h 를 하게 되면 , /dev/sda 인 하드드라이브가 보이는 것이 아니라 sda1, sda2... 이런 파티션들의 정보가 보여진다. sda는 안 보인다.

2)  fdisk를 사용하여 LVM 타입으로 파티션을 생성한다.

# fdisk /dev/hdb

n 엔터 (새 파티션 추가)

-> p 엔터 (primary partition (1-4)) ; 주파티션이면 p, 확장파티션이면 e

-> 1 엔터 (파티션 넘버 입력)

-> 엔터 (First cylinder 1-1792, default 1:)

-> 엔터 (last cylinder)

-> t 엔터 (change a partition's system id)

-> l 엔터 (type L to list codes)

-> 8e (linux LVM이 8e다)

-> w 엔터 (write table to disk and exit)

# fdisk /dev/hdc , hdd 위와 동일하게 설정

3)  fdisk -l 하여 LVM 타입으로 파티션이 설정되었음을 확인

 

2. 물리볼륨 생성

1) pvcreate 로 물리볼륨을 생성

 

[root@localhost ~]# pvcreate /dev/hdb1

Physical volume "/dev/hdb1" successfully created

 

(윗단계에서 fdisk /dev/hdb 했으니깐... 이 디스크가 hdb1, hdb2 ... 이런 식으로 쪼개졌을 거란 말이지. 근데 위에선 그냥 한 디스크를 통으로 한 파티션으로 생성..한듯.)

 

[root@localhost ~]# pvcreate /dev/hdc1

[root@localhost ~]# pvcreate /dev/hdd1

 

2) pvdisplay하여 물리볼륨 확인

 

 

3. 볼륨그룹 설정

1) vgcreate 하여 볼륨그룹 설정 (위에서 생성했던 물리볼륨들을)

[root@localhost ~]# vgcreate myvg /dev/hdb1 /dev/hdc1 /dev/hdd1

               Volume group "myvg" successfully created

2) vgdisplay 하여 볼륨그룹을 확인

 

4. 논리볼륨 생성

1) lvcreate 하여 논리볼륨을 두 개 (하나는 7GB , 하나는 나머지 공간) 생성

  (여기서 소문자 l을 쓰면 pe 의 개수로 용량을 지정하게 된다. 상세  LVM 내용은 다음 포스트 참조.)

 

[root@localhost ~]# lvcreate -n dtlv -L 7GB myvg

Logical volume "dtlv" created

[root@localhost ~]# lvcreate -n bklv -l 100%FREE myvg

Logical volume "bklv" created

 

2) lvdisplay 하여 논리볼륨 확인

 

 

 

 

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

 

이제서야 포맷을 하게 된다~!

 

1) 위에서 생성한 논리볼륨을 파일시스템 포맷

 

[root@localhost ~]# mkfs.ext3 /dev/myvg/dtlv

....

[root@localhost ~]# mkfs.ext3 /dev/myvg/bklv

 

2) 마운트

 

[root@localhost ~]# mkdir /mnt/data

[root@localhost ~]# mkdir /mnt/back

[root@localhost ~]# mount -t ext3 /dev/myvg/dtlv /mnt/data

[root@localhost ~]# mount -t ext3 /dev/myvg/bklv /mnt/back

 

3) df -l 하여 마운트 확인

 

4) 부팅 시 자동으로 디스크를 읽어줄 수 있게 fstab 설정

#vi /etc/fstab

/dev/myvg/dtlv         /mnt/data         ext3      defaults     0    0

 

 

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.

반응형

'OS > HP-UX::' 카테고리의 다른 글

HP-UX depot 패키지 설치  (0) 2014.06.11
HP-UX 11.11 gcc 설치  (0) 2014.06.11
HP-UX Thread dump 및 프로세스 분석 툴 Glance  (0) 2012.08.22
HP-UX 컴파일러 관련 정보  (0) 2011.12.01
반응형

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



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

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

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

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

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


# svmon
1.
                   size               inuse               free           pin            virtual
memory          1831616        2028009           5412         391022       1082699
pg space         526500           5021

2.
               work               pers                   clnt
pin          390788             0                        234
in use      1082491           0                         945518

3.
PageSize       PoolSize         inuse           pgsp           pin                virtual
s   4 KB              -               1947705        4781           349758          1002187
m  64 KB             -                5019             25               2579               5032


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


svmon -G
시스템 전체 메모리 사용량 통계 확인

전체 메모리 사이즈는 1831616*4096byte/1024/1024 = 127MB.
Free Memory는 5412*4096/1024/1024 = 41MB


svmon -U root -d
root 사용자가 사용하는 메모리의 내역


svmon -C inetd
inetd 데몬에 의해 사용되는 메모리의 통계


svmon -P (pid)
프로세스 메모리 사용량 통계




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

#!/usr/bin/csh
 
# Swap 점검
/usr/sbin/swap -l | /usr/bin/tail -1 |sed 's/MB//g' |awk '{printf"%0.0f\n",100-(($5/$4)*100)}'
 
# Real Memory 점검
# 계산방법: 100 - ( ( FreeSize / TotSize ) * 100
svmon -G |grep memory |perl -ane 'printf"%0.1f \n", 100 - ( ( $F[3] / $F[1] ) * 100 ) '
  • 위의 스크립트를 보면  awk처리와 perl 처리를 두가지 버전으로 만들어 봤다.
  • 둘다 장단점은 있지만 확실히 perl로 하는 것이 더 좋다는 생각이 든다.




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

반응형
반응형

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



제  목 : 유용한 find 명령어 예 모음
작성자 : 좋은진호(truefeel, http://coffeenix.net/ )
작성일 : 수시로 추가했음

아래는 제가 자주 쓰는 find 명령인데, 유용할 듯 해서.
지금까지 적어뒀던 것과 아주 보편적이라고 생각되는 것입니다.
계속 추가됩니다. ^^

-------------------------------------------------------
1. 현재 디렉토리( . ) 이하에 확장자가 .html( -name "*.html" ) 인 파일만 ( -type -f )

find . -name "*.html" -type f -ls

2. 파일 크기

# 파일 크기가 300KB 이상( -size +300k )인 파일만 
# (호스팅되는 홈피내에 큰 사이트의 파일이 있는지 찾을 때 유용)
find . -size +300k -ls

# 파일 크기가 500bytes 이하( -size -500c )인 파일만  
find . -size -500c -ls 

3. 수정일

# 수정한지 20일 이상( -mtime +20 )된 파일과 디렉토리
find . -mtime +20 -ls 

# 수정한지 20일 이상된 파일만
find . -mtime +20 -type f -ls

# 수정한지 20일 이상된 파일만 삭제 ( -exec rm {} \; ) 
# (정기적으로 20일이 지난 파일을 삭제할 때 유용)
find . -mtime +20 -type f -ls -exec rm {} \;

# 수정한지 3일 이내( -mtime -3 )의 파일만 (백업할 때 유용)
find . -mtime -3 -type f -ls

# 수정한지 30분 이내( -mmin -30 )의 파일만
find . -mmin -30 -type f -ls

4. 퍼미션 및 파일 소유

# 파일시스템 전체( / )에서 SUID/SGID가 설정된 모든 파일 목록을 얻음
find / -type f \( -perm -04000 -o -perm -02000 \) -ls

# 소유자가 없는 파일 목록을 얻음 (사용자는 이미 삭제했는데, 파일이 남은 경우)
find / -nouser -o -nogroup

5. 출력 형식 지정

# 출력 형식을 printf로 만들어서 (출력 결과를 다른 프로그램에서 받아서 쓸 때 유용)
# %h = 경로, %f = 파일명, %k = KB, %s = Bytes

# 형식 : <경로/파일명> <파일크기KB>
find . -printf "%h/%f \t %kKB \n"
... 생략 ...
./public_html/phps/icon/type/pcx.gif      4KB
./public_html/phps/icon/type/ra.gif       4KB
./public_html/phps/icon/type/sound.gif    4KB
./public_html/phps/icon/type/text.gif     4KB

# 형식 : <경로/파일명> <파일크기Bytes>
find . -printf "%h/%f \t %sKB \n"
... 생략 ...
./public_html/phps/icon/type/movie.gif    912Bytes
./public_html/phps/icon/type/mp3.gif      958Bytes
./public_html/phps/icon/type/pcx.gif      897Bytes
./public_html/phps/icon/type/ra.gif       903Bytes
./public_html/phps/icon/type/sound.gif    932Bytes

6. 홈페이지 포팅할 때 퍼미션 안 맞는 경우 유용한 것

# 확장자가 .htm* .gif, .js, .css 인 것만 퍼미션을 644(rw-r--r--)로
find . -name "*.htm*" -o -name "*.gif" -o -name "*.js" -o -name "*.css" -exec chmod 644 {} \;

# 파일은 퍼미션을 644로
find . -type f -exec chmod 644 {} \;

# 디렉토리는 퍼미션을 701로
find . -type d -exec chmod 701 {} \;

# 하위의 모든 퍼미션을 바꾸지 않고 depth를 지정하여 제한을 둘 때
# 옵션 : -maxdepth 숫자  (1=현재디렉토리만, 2=현재디렉토리 포함하여 한단계 하위디렉토리까지만)
find . -maxdepth 1 -type d -exec chmod 701 {} \;

※ -maxdepth는 -type나 -perm 등의 조건연산자가 아닌 옵션이다. 
   따라서 조건연산자보다 먼저 사용해야한다. (다른 명령처럼 옵션을 먼저쓰는 것으로 이해하면 됨)
   find . -type -d -maxdepth 1 과 같이 사용하는 것은 옳지 않다.


반응형
반응형
출처 : http://blog.daum.net/hogi2271/10

AIX 5에서 공유 라이브러리 메모리 크기


   

난이도 : 초급

George Cross, 선임 소프트웨어 개발자, Business Objects Americas

옮긴이: 박재호 이해영 dwkorea@kr.ibm.com

2008 년 9 월 16 일

IBM® AIX®에서 공유 라이브러리 메커니즘과 메모리 크기에 대해 배워봅시다. 이 기사는 서버 코드를 작성하는 개발자와 AIX 시스템을 실제 운영하는 관리자에게 필요한 지식을 핵심만 간추려 설명합니다. 이 기사는 개발자와 관리자에게 명령어와 기법을 설명하고 AIX에서 서버 프로세스의 메모리 요구 사항을 분석하는 데 필요한 지식을 제공합니다. 이 기사는 또한 개발자와 관리자가 ps나 topas와 같은 표준 실시간 분석 도구로 파악하기 어려운 자원 부족을 회피하는 방법을 설명합니다. 이 기사는 시스템 관리자와 AIX용 응용 프로그램 개발자를 대상으로 작성했습니다.

소개

이 기사는 다음 명령어를 시연하면서 32비트 AIX 5L™(5.3)에서 공유 라이브러리가 메모리를 차지하는 방법을 살펴본다.

  • ps
  • svmon
  • slibclean
  • procldd
  • procmap
  • genkld
  • genld

이 기사는 커널 공유 라이브러리 세그먼트는 물론이고 프로세스의 가상 메모리 공간을 설명하며, 가상 메모리를 살펴보는 방법, 위에서 언급한 다양한 진단 도구가 제공하는 출력 결과 해석 방법도 다룬다. 이 기사는 또한 커널 공유 세그먼트가 꽉 찬 상황을 진단하며 이런 상황을 해결하기 위해 가능한 접근 방법도 설명한다.

이 기사에서 사용하는 예제로 소프트웨어 제품인 Business Objects Enterprise Xir2®에서 따온 프로세스를 사용한다. 이는 임의로 든 예며, 여기서 소개하는 개념은 AIX 5L에서 동작하는 모든 프로세스에 적용할 수 있다.




위로


검토

이제 무엇을 할지 공감했으니, 32비트 아키텍처를 조금 검토해보자. 검토 과정에서 아주 유용한 'bc' 명령행 계산기를 사용하겠다.

32비트 프로세서에서 레지스터는 2^32개의 가능한 값을 담을 수 있다.

	$ bc
	2^32
	4294967296
	obase=16
	2^32
	100000000


이 범위는 4기가바이트다. 이는 시스템에서 동작하는 프로그램이 0에서 2^32 - 1 범위 내에서 함수나 자료 주소에 접근할 수 있음을 의미한다.

	$ bc
 	2^32 - 1 
	FFFFFFFF
	obase=10
	2^32 - 1 
	4294967295


이미 알고 있듯이, 운영체제는 잠재적으로 수백 개에 이르는 프로그램을 동시에 돌릴 수 있다. 응용 프로그램 각각이 4GB 메모리 범위에 접근이 가능할지라도, 개별 프로그램마다 물리 RAM을 4GB만큼 할당 받는다는 뜻은 아니다. 이렇게 하기란 비현실적이다. 그 대신 운영체제는 적당한 물리 RAM과 스왑(또는 페이징) 영역으로 지정된 파일 시스템 사이에서 코드와 자료를 스와핑하는 복잡한 정책을 구현했다. 또한 각 프로세서가 4GB라는 메모리 영역에 접근이 가능할지라도, 대다수 프로세서는 이 영역을 완전히 사용하지 않는다. 따라서 운영체제는 특정 프로세스마다 요구하는 코드와 자료를 올리고 스왑하기만 하면 된다.


그림 1. 가상 메모리를 개념으로 설명하는 도식
가상 메모리 관리

이런 방법은 종종 가상 메모리나 가상 주소 공간으로 부른다.

실행 파일이 동작할 때, 운영체제에 들어있는 가상 메모리 관리자는 파일을 구성하는 코드와 자료를 살펴서 어느 부분을 램으로 올리고 어느 부분을 스왑으로 올리고 어느 부분을 파일 시스템에서 참조할지 결정한다. 동시에, 운영체제는 몇몇 구조체를 만들어 4GB 범위 내에서 물리 영역을 가상 영역으로 사상한다. 이 4GB 범위는 (종종 VMM 구조와 함께) 프로세스의 이론적인 최대 범위를 표현하며, 프로세스의 가상 주소 공간으로 알려져 있다.

AIX에서 4GB 가상 공간은 256메가바이트짜리 세그먼트 16개로 나뉜다. 세그먼트에는 미리 정해진 기능이 있다. 몇 가지를 정리해보았다.

  • 세그먼트 0: 커널 관련 자료
  • 세그먼트 1: 코드
  • 세그먼트 2: 스택과 동적 메모리 할당
  • 세그먼트 3: 사상된 파일을 위한 메모리, mmap으로 설정한 메모리
  • 세그먼트 d: 공유 라이브러리 코드
  • 세그먼트 f: 공유 라이브러리 자료

반면에 HP-UX®에서 주소 공간은 4분면으로 나뉜다. 3사분면과 4사분면은 +q3p enable과 +q4p enable 옵션을 켜서 chatr 명령을 내릴 경우 공유 라이브러리 사상 목적으로 사용이 가능하다.




위로


공유 라이브러리가 메모리에 올라오는 위치

당연한 이야기지만, 공유 라이브러리는 공유할 목적으로 만들어졌다. 좀 더 구체적으로 말하자면, 코드("텍스트"로 알려진)와 읽기 전용 자료(상수 자료, 기록 시점에서 복사 가능한 자료)를 포함한 이진 파일 이미지에서 읽기 전용 영역을 물리적인 메모리에 올리고 나면 이를 요구하는 프로세스에 여러 번 사상할 수 있다.

이를 확인하기 위해, AIX가 동작하는 기계를 구해 현재 메모리에 올라온 공유 라이브러리를 살펴보자.

> su 
# genkld
Text address     Size File

    d1539fe0    1a011 /usr/lib/libcurses.a[shr.o]
    d122f100    36732 /usr/lib/libptools.a[shr.o]
    d1266080    297de /usr/lib/libtrace.a[shr.o]
    d020c000     5f43 /usr/lib/nls/loc/iconv/ISO8859-1_UCS-2
    d7545000    161ff /usr/java14/jre/bin/libnet.a
    d7531000    135e2 /usr/java14/jre/bin/libzip.a
.... [ lots more libs ] ....
d1297108 3a99 /opt/rational/clearcase/shlib/libatriastats_svr.a
[atriastats_svr-shr.o]
    d1bfa100    2bcdf /opt/rational/clearcase/shlib/libatriacm.a[atriacm-shr.o]
    d1bbf100    2cf3c /opt/rational/clearcase/shlib/libatriaadm.a[atriaadm-shr.o]
.... [ lots more libs ] ....
    d01ca0f8     17b6 /usr/lib/libpthreads_compat.a[shr.o]
    d10ff000    30b78 /usr/lib/libpthreads.a[shr.o]
    d00f0100    1fd2f /usr/lib/libC.a[shr.o]
    d01293e0    25570 /usr/lib/libC.a[shrcore.o]
    d01108a0    18448 /usr/lib/libC.a[ansicore_32.o]
.... [ lots more libs ] ....
    d04a2100    fdb4b /usr/lib/libX11.a[shr4.o]
    d0049000    365c4 /usr/lib/libpthreads.a[shr_xpg5.o]
    d0045000     3c52 /usr/lib/libpthreads.a[shr_comm.o]
    d05bb100     5058 /usr/lib/libIM.a[shr.o]
    d05a7100    139c1 /usr/lib/libiconv.a[shr4.o]
    d0094100    114a2 /usr/lib/libcfg.a[shr.o]
    d0081100    125ea /usr/lib/libodm.a[shr.o]
    d00800f8      846 /usr/lib/libcrypt.a[shr.o]
    d022d660   25152d /usr/lib/libc.a[shr.o]

관찰 결과에 따르면, 현재 Clearcase와 자바(Java™)가 동작하고 있다. 여기서 libpthreads.a라는 공통 라이브러리 중 하나를 찍어보자. 라이브러리를 탐색해서 구현 함수 내역을 살핀다.

# dump -Tv /usr/lib/libpthreads.a | grep EXP
[278]   0x00002808    .data      EXP     RW SECdef        [noIMid] pthread_attr_default
[279] 0x00002a68 .data EXP RW SECdef [noIMid]
 pthread_mutexattr_default
[280]   0x00002fcc    .data      EXP     DS SECdef        [noIMid] pthread_create
[281]   0x0000308c    .data      EXP     DS SECdef        [noIMid] pthread_cond_init
[282]   0x000030a4    .data      EXP     DS SECdef        [noIMid] pthread_cond_destroy
[283]   0x000030b0    .data      EXP     DS SECdef        [noIMid] pthread_cond_wait
[284]   0x000030bc    .data      EXP     DS SECdef        [noIMid] pthread_cond_broadcast
[285]   0x000030c8    .data      EXP     DS SECdef        [noIMid] pthread_cond_signal
[286]   0x000030d4    .data      EXP     DS SECdef        [noIMid] pthread_setcancelstate
[287]   0x000030e0    .data      EXP     DS SECdef        [noIMid] pthread_join
.... [ lots more stuff ] ....

음, 흥미롭다. 이제 시스템에서 현재 메모리에 올라와 있는 동작 중인 프로세스를 살펴보자.

# for i in $(ps -o pid -e | grep ^[0-9] ) ; do j=$(procldd $i | grep libpthreads.a); \
	if [ -n "$j" ] ; then ps -p $i -o comm | grep -v COMMAND; fi  ; done
portmap
rpc.statd
automountd
rpc.mountd
rpc.ttdbserver
dtexec
dtlogin
radiusd
radiusd
radiusd
dtexec
dtterm
procldd : no such process : 24622
dtterm
xmwlm
dtwm
dtterm
dtgreet
dtexec
ttsession
dtterm
dtexec
rdesktop
procldd : no such process : 34176
java
dtsession
dtterm
dtexec
dtexec

멋지다! 이제 똑같은 작업을 하되, 중복을 없애보자.

# cat prev.command.out.txt | sort | uniq 
       
automountd
dtexec
dtgreet
dtlogin
dtsession
dtterm
dtwm
java
portmap
radiusd
rdesktop
rpc.mountd
rpc.statd
rpc.ttdbserver
ttsession
xmwlm

현재 동작 중이면서 libpthreads.a를 메모리에 올린 이진 파일 목록을 깔끔하게 분리해서 정리해보자. 이 시점에서 시스템에 더 많은 프로세스가 떠 있음에 주의하자.

# ps -e | wc -l 	
      85

이제 각 프로세스가 libpthreads.a를 어디에 올렸는지 살펴보자.

# ps -e | grep java
 34648      -  4:13 java
#
# procmap 34648 | grep libpthreads.a
d0049000         217K  read/exec      /usr/lib/libpthreads.a[shr_xpg5.o]
f03e6000          16K  read/write     /usr/lib/libpthreads.a[shr_xpg5.o]
d0045000          15K  read/exec      /usr/lib/libpthreads.a[shr_comm.o]
f03a3000         265K  read/write     /usr/lib/libpthreads.a[shr_comm.o]
#
# ps -e | grep automountd
 15222      -  1:00 automountd
 25844      -  0:00 automountd
#
# procmap 15222 | grep libpthreads.a
d0049000         217K  read/exec      /usr/lib/libpthreads.a[shr_xpg5.o]
f03e6000          16K  read/write     /usr/lib/libpthreads.a[shr_xpg5.o]
d0045000          15K  read/exec      /usr/lib/libpthreads.a[shr_comm.o]
f03a3000         265K  read/write     /usr/lib/libpthreads.a[shr_comm.o]
d10ff000         194K  read/exec         /usr/lib/libpthreads.a[shr.o]
f0154000          20K  read/write        /usr/lib/libpthreads.a[shr.o]
#
# ps -e | grep portmap              
 12696      -  0:06 portmap
 34446      -  0:00 portmap
#
# procmap 12696 | grep libpthreads.a
d0045000          15K  read/exec      /usr/lib/libpthreads.a[shr_comm.o]
f03a3000         265K  read/write     /usr/lib/libpthreads.a[shr_comm.o]
d10ff000         194K  read/exec         /usr/lib/libpthreads.a[shr.o]
f0154000          20K  read/write        /usr/lib/libpthreads.a[shr.o]
#
# ps -e | grep dtlogin
  6208      -  0:00 dtlogin
  6478      -  2:07 dtlogin
 20428      -  0:00 dtlogin
#
# procmap 20428 | grep libpthreads.a
d0045000          15K  read/exec      /usr/lib/libpthreads.a[shr_comm.o]
f03a3000         265K  read/write     /usr/lib/libpthreads.a[shr_comm.o]
d0049000         217K  read/exec      /usr/lib/libpthreads.a[shr_xpg5.o]
f03e6000          16K  read/write     /usr/lib/libpthreads.a[shr_xpg5.o]

각 프로세스는 libpthreads.a를 매번 동일 주소에 올린다는 사실에 주목하자. 라이브러리를 구성하는 목록에 현혹되지 말자. AIX에서는 동적 공유 라이브러리(보통 .so 파일)는 물론이고 아카이브 라이브러리(보통 .a 파일)도 공유할 수 있다. 이런 공유 기능은 전통적인 링크와 마찬가지로 링크 시점에서 심볼을 결정하지만 최종 이진 파일로 구성 목적 파일(아카이브에서 .o 파일) 복사가 필요하지 않다. 그렇기 때문에 동적 공유 라이브러리(.so/.sl 파일)와는 달리 동적(실행 중) 심볼 결정을 수행하지 않는다.

또한 read/exec로 표시된 libpthreads.a 코드 영역은 세그먼트 0xd에 올라왔다는 사실에 주목하자. 이 세그먼트는 앞서 언급한 바와 같이 공유 라이브러리를 위한 세그먼트로 AIX에서 지정되어 있다. 다시 말해 커널은 공유 라이브러리의 공유 가능한 세그먼트를 동일한 커널에서 동작 중인 모든 프로세스가 공유하는 영역에 올린다.

자료 섹션 역시 동일한 세그먼트(공유 라이브러리 세그먼트 0xf)에 위치한다는 사실을 눈치챘을지도 모르겠다. 하지만 이는 각 프로세스가 libpthreads.a의 자료 섹션까지 공유함을 의미하지는 않는다. 조금 느슨하게 정의해 보자면, 이런 배치는 동작하지 않는다. 각 프로세스 별로 다른 이름으로 다른 자료 값을 유지할 필요가 있기 때문이다. 물론 가상 메모리 주소는 동일할지 몰라도 세그먼트 0xf는 libpthreads.a를 사용하는 각 프로세스마다 다르다.

svmon 명령어는 프로세스에 대한 Vsid(가상 메모리 관리자에서 세그먼트 ID)를 보여준다. 공유 라이브러리 코드 세그먼트는 Vsid가 같지만, 공유 라이브러리 자료 세그먼트는 Vsid가 제각각이다. 유효 세그먼트 ID인 Esid는 프로세스의 주소 공간 범위 내에서 세그먼트 ID를 의미한다(그냥 용어 설명이므로 혼동하지 말기 바란다).

# svmon -P 17314

-------------------------------------------------------------------------------
     Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd  16MB
   17314 dtexec           20245     9479       12    20292      N     N     N

    Vsid      Esid Type Description              PSize  Inuse   Pin Pgsp Virtual
       0         0 work kernel segment               s  14361  9477    0 14361 
   6c01b         d work shared library text          s   5739     0    9  5786 
   19be6         f work shared library data          s     83     0    1    87 
   21068         2 work process private              s     56     2    2    58 
   18726         1 pers code,/dev/hd2:65814          s      5     0    -     - 
    40c1         - pers /dev/hd4:2                   s      1     0    -     - 
#
# svmon -P 20428

-------------------------------------------------------------------------------
     Pid Command          Inuse      Pin     Pgsp  Virtual 64-bit Mthrd  16MB
   20428 dtlogin          20248     9479       23    20278      N     N     N

    Vsid      Esid Type Description              PSize  Inuse   Pin Pgsp Virtual
       0         0 work kernel segment               s  14361  9477    0 14361 
   6c01b         d work shared library text          s   5735     0    9  5782 
   7869e         2 work process private              s     84     2   10    94 
                   parent=786be
   590b6         f work shared library data          s     37     0    4    41 
                   parent=7531d
   6c19b         1 pers code,/dev/hd2:65670          s     29     0    -     - 
   381ae         - pers /dev/hd9var:4157             s      1     0    -     - 
    40c1         - pers /dev/hd4:2                   s      1     0    -     - 
   4c1b3         - pers /dev/hd9var:4158             s      0     0    -     - 




위로


산수 놀이

공유 세그먼트 0xd에서 얼마나 많은 메모리를 차지하는지 살펴보자. 다시 한번 bc 계산기를 써보자. 정신 바짝 차리고, 세그먼트 0xd 크기를 비교해보자.

# bc    
ibase=16
E0000000-D0000000
268435456
ibase=A
268435456/(1024^2)
256

여기까지는 좋아 보인다. 위에서 언급한 내용처럼 각 세그먼트는 256MB다. 좋다. 이제 현재 사용 중인 메모리 용량을 살펴보자.

$ echo "ibase=16; $(genkld | egrep ^\ \{8\} | awk '{print $2}' | tr '[a-f]' '[A-F]' \
	|  tr '\n' '+' ) 0" | bc
39798104
$
$ bc <<EOF
> 39798104/(1024^2)
> EOF
37

현재 사용 중인 메모리는 37MB라고 알려준다. XIr2를 시작한 다음에 비교해보자.

$ echo "ibase=16; $(genkld | egrep ^\ \{8\} | awk '{print $2}' | tr '[a-f]' '[A-F]' \
	|  tr '\n' '+' ) 0" | bc
266069692
$
$ bc <<EOF
> 266069692/(1024^2)
> EOF
253

이제 253MB를 사용 중이다. 이는 256MB 한계에 아주 근접한 값이다. WIReportServer와 같은 프로세스를 임의로 골라 공유 영역으로 얼마나 많은 공유 라이브러리를 밀어넣었으며 얼마나 많은 라이브러리를 내부적으로 사상했는지 살펴보자. 공유 세그먼트 시작 주소가 0xd000000라는 사실을 알고 있으므로, procmap 결과에서 필터링해보자. 단지 코드 섹션만 세그먼트 0xd에 사상된다는 사실을 기억하자. 따라서 read/exec 행만 살펴보면 된다.

$ procmap 35620 | grep read/exec | grep -v ^d
10000000       10907K  read/exec         boe_fcprocd
31ad3000       14511K  read/exec
/crystal/sj1xir2a/xir2_r/bobje/enterprise115/aix_rs6000/libEnterpriseFramework.so
3167b000        3133K  read/exec
/crystal/sj1xir2a/xir2_r/bobje/enterprise115/aix_rs6000/libcpi18nloc.so
3146c000        1848K  read/exec
/crystal/sj1xir2a/xir2_r/bobje/enterprise115/aix_rs6000/libBOCP_1252.so
31345000         226K  read/exec
/crystal/sj1xir2a/xir2_r/bobje/enterprise115/aix_rs6000/btlat300.so

위에 나타난 네 가지 라이브러리는 공유 세그먼트로 사상될 수 없는 듯이 보인다. 필연적으로 네 가지 라이브러리는 mmap() 루틴을 호출해 할당한 범용 메모리로 쓰이는 내부 세그먼트 0x3에 사상되었다.

공유 라이브러리를 32비트 AIX에서 내부적으로 강제로 사상하기 위해서는 몇 가지 조건이 필요하다.

  • (위에서 발생한 상황처럼) 공유 세그먼트 0xd 영역이 꽉 차 있다.
  • 그룹과 다른 사람에 대한 실행 권한이 공유 라이브러리에 없다. 이런 문제를 해결하려면 접근 허가를 rwxr-xr-x로 지정하면 된다. 하지만 개발자들은 자신에게만 접근 허가를 주기를 원하므로(예: rwx------), 테스트 목적으로 공유 라이브러리를 컴파일해 배포할 때마다 sibclean을 돌릴 필요가 없다.
  • 몇몇 문서는 nfs 위에서 공유 라이브러리를 메모리에 올리면 이렇게 된다고 말한다.

AIX 커널은 동일한 라이브러리라도 다른 위치에서 시작했다면 공유 메모리에 두 번 올릴 것이다.

sj2e652a-chloe:~/e652_r>genkld | grep libcplib.so
        d5180000    678c6 /space2/home/sj2e652a/e652_r/lib/libcplib.so
        d1cf5000    678c6 /home/sj1e652a/xir2_r/lib/libcplib.so




위로


뭔가 잘못되었을 때

다른 디렉터리에 설치된 XIr2 인스턴스를 다시 한번 돌린다면, 프로세스 메모리 크기에 상당한 차이가 난다.

$ ps -e -o pid,vsz,user,comm | grep WIReportServer
28166 58980   jbrown WIReportServer
46968 152408 sj1xir2a WIReportServer
48276 152716 sj1xir2a WIReportServer
49800 152788 sj1xir2a WIReportServer
50832 152708 sj1xir2a WIReportServer

'jbrown' 계정에서 돌리는 인스턴스가 첫 번째로 시작했으며, 'sj1xir2a' 계정에서 돌리는 인스턴스가 두 번째로 시작했다. 두 번째 인스턴스를 돌리기 앞서 bobje/setup/env.sh 파일에서 적절한 위치에 다음과 같은 항목을 설정해 뭔가 조금 이상한 작업을 했다면

    LIBPATH=~jbrown/vanpgaix40/bobje/enterprise115/aix_rs6000:$LIBPATH

메모리 사용량이 정규화된 상태를 확인할 것이다(이 LIBPATH 테스트에서는 WIReportServer를 시동할 수 없기에 프로세스 boe_fcprocd를 사용했다).

$ ps -e -o pid,vsz,user,comm | grep boe_fcprocd   
29432 65036   jbrown boe_fcprocd
35910 67596   jbrown boe_fcprocd
39326 82488 sj1xir2a boe_fcprocd
53470 64964 sj1xir2a boe_fcprocd

그리고 기대한 바와 같이 procmap은 ~jbrown에서 올라온 파일을 보여준다.

53470 : /crystal/sj1xir2a/xir2_r/bobje/enterprise115/aix_rs6000/boe_fcprocd
-name vanpg 
10000000       10907K  read/exec         boe_fcprocd
3000079c        1399K  read/write        boe_fcprocd
d42c9000        1098K  read/exec
/home7/jbrown/vanpgaix40/bobje/enterprise115/aix_rs6000/libcrypto.so
33e34160         167K  read/write
/home7/jbrown/vanpgaix40/bobje/enterprise115/aix_rs6000/libcrypto.so
33acc000        3133K  read/exec
/home7/jbrown/vanpgaix40/bobje/enterprise115/aix_rs6000/libcpi18nloc.so
33ddc697         349K  read/write
/home7/jbrown/vanpgaix40/bobje/enterprise115/aix_rs6000/libcpi18nloc.so




위로


정리

응용 프로그램이 종료되었다면, 공유 라이브러리는 여전히 공유 세그먼트 0xd에 남아있을지도 모른다. 이런 경우에는 'slibclean' 유틸리티를 사용해 더 이상 참조하지 않는 공유 라이브러리를 메모리에서 내린다. 이 유틸리티에는 인수가 필요없다.

slibclean

또한 -l 옵션을 추가하면 procmap과 비슷한 결과를 보여주는 genld라는 유틸리티는 현재 시스템에 존재하는 모든 프로세스를 보여준다.

genld -l

종종 slibclean을 돌린 다음에도 공유 라이브러리 복사가 여전히 불가능할 경우가 있다. 예를 들면 다음과 같다.

$ cp /build/dev/bin/release/libc3_calc.so   /runtime/app/lib/
cp: /runtime/app/lib/libc3_calc.so: Text file busy

이미 slibclean을 돌렸기 때문에 'genld -l'은 이 라이브러리가 메모리에 올라온 프로세스를 보여주지 않는다. 하지만 시스템은 여전히 이 파일을 보호하고 있다. 이런 문제점을 극복하려면 우선 목표 위치에 있는 공유 라이브러리를 지운 다음에 새로운 공유 라이브러리를 복사하면 된다.

$ rm /runtime/app/lib/libc3_calc.so
$ cp /build/dev/bin/release/libc3_calc.so   /runtime/app/lib/

공유 라이브러리 개발 과정 동안, 컴파일, 링크, 실행, 예제 실행을 반복한다면 단지 소유주(r_xr__r__)만 실행 가능한 공유 라이브러리를 만드는 방법으로 매 주기마다 slibclean 명령을 내리지 않아도 된다. 이렇게 하면 테스트 목적으로 사용하는 프로세스를 메모리에 올려 공유 라이브러리를 내부적으로 사상할 것이다. 하지만 궁극적으로는 모든 사람이 실행 가능하도록 주의해야 한다(즉, 제품 배포 시점에서 r_xr_xr_x이 되어야 한다).




위로


요약

공유 라이브러리가 메모리를 차지하는 방법과 이를 검사하기 위해 사용된 유틸리티에 대한 방법을 자세히 살펴봤으리라 믿는다. 이 기사를 통해, 응용 프로그램이 요구하는 메모리 크기 조건을 평가하고 AIX 시스템에서 돌아가는 프로세스에 대한 메모리 사용량 구성 요소를 분석할 수 있을 것이다.



반응형

+ Recent posts