1) CPU

o Processor\ % Processor Time : 80% 이하로 유지

  : 별도로 설명하진 않겠습니다.


2) Memory

메모리 항목의 경우 가장 중요한 관리포인트가 되지만 OS 메모리 세팅에 좌우됩니다. 즉, /3GB /Userva=3030 옵션등으로 커널의 메모리 사용량이 변경되면 관리 용량도 변경이 되어야 합니다. 아래 표를 참조하세요. (32bit System 내용입니다)

Perfmon Counter               Max.     3GB Max.       default            3GB
=====================================================================
Non-Paged Pool             256MB      128MB           220MB          110MB

Paged Pool                    356MB      245MB           320MB           220MB

Free- PTE                     300,000      24,000            3,500             3,500
======================================================================


o Memory\ NonPoolPaged Bytes : 220MB (110MB - 3GB) 이하로 유지

- System 부팅시 메모리 영역에 올라와서 꺼지기 전까지 상주하는 메모리입니다. 보통 드라이버들이죠.
   이 항목이 꽉차면 System 은 반드시 Hang이 걸리고 리부팅 되기 전까지 풀리지 않습니다. (Event 2022)

o Memory\ Poolpaged Bytes : 320MB (220MB - 3GB) 이하로 유지

- 이부분도 커널영역 메모리 입니다만, Paging이 일어나도 되는것들과 API를 통해 커널메모리 영역을 차지하는
   APP들이 있는 경우에 사용되곤 합니다.
   이 항목이 꽉차면 해당 APP Hang 상태가 되거나 Process 들이 중지됩니다. (Event 2019)

o Memory\ Free System Page Table Entries : 3500 이상 유지

- Paging 할 목록을 가지고 있는 Table 입니다. 역시나 PTE가 없으면 더이상 메모리를 사용하지 못합니다.
   Network I/O를 포함한 모든 동작이 중지되고, 서버는 리부팅을 해야 됩니다.

o Memory\ Available MBytes : 300MB 이상 유지

- 서버에서 User Mode를 포함하여 사용하는 4GB의 메모리중 남은 총량입니다. 적당히 서버별로 판단하되 계속 줄면
   어떤 프로그램인지 찾아내야 합니다.


3) Disk

요즘은 CPU가 좋아져서 Disk가 못따라가는 경우가 많이 생깁니다. 중요한 관리 포인트중에 하나죠.
물리적 디바이스, 논리적 디바이스를 함께 생각해보시면 됩니다. 단, Disk의 경우는 당장 서버가 죽는것은 아니기 때문에
시스템의 중요성이나 사용량을 고려하셔야 하겠습니다. 예를들어 60 이상인 상태로 몇초정도 지속되는 경우는
서비스에 심각한 영향이 있을 것으로 생각됩니다.

Excellent   <  15 Msec
Good        <  30 Msec
Fair          <  60 Msec
Poor         <  90 Msec

o PhysicalDisk\ Avg. Disk sec/Reads

o PhysicalDisk\ Avg. Disk sec/Writes
 
o LogicalDisk\ Avg. Disk sec/Reads

o LogicalDisk\ Avg. Disk sec/Writes
신고
Posted by hotpoto

Process의 이해

Process는 Schedular나 Memory Management와 같은 Subsystem에 의해 운영되는 실행중인 Program을 말한다.

image

프로세스는 크게 Text (실행가능한 Code), Data, Stack등과 같은 Context 집합으로 구성되어 있다. HP-UX는 Thread Based System이라고 많이 생각하는데 이러한 부분을 이해하기 위해서는 Process에 대한 개념정립이 중요한 부분을 차지하게 된다. 프로세스는 hierarchical하게 운영되며, parent-child 관계로 되어 있다.(fork() 개념) 프로세스가 생성될 때는 Unique한 integer number인 Process ID를 부여받은데 parent인 Process ID를 PPID라고 부른다.

프로그램이 프로세스를 실행할때 (이때 child Process로 fork()과정이 발생) Kernal은 Process Table을 생성한다. 이때까지 Process의 상태는 idle 상태가 되며 사용가능한 Resource 를 기다리게 된다(SIDL). 실행가능한 Resource 를 얻는 경우 process는 queue에 실행상태로 들어가게 된다.(SRUN) 만약 기존에 실행중인 Process가 존재하였다면 SIGSTOP(정지신호)를 받게 되며 처리가 다 수행된 경우에는 SIGCONT를 받아 다시 queue 상태로 들어가 계속 프로그램을 실행하게 된다. 또 다른 과정인 프로세스가 semaphore나 I/O 요청에 의해 잠시 대기해야 하는 상태가 된다면 sleep queue상태로 들어가게 된다.(SSLEEP) 이때 Resource를 다시 받는다면 실행상태로 갈 것이며, 그렇지 않을 경우 일단 Swap되어 대기하였다가 다시 요청이 들어왔을 경우에는 실행상태(SRUN)로 들어가게 된다. 이후 Process가 최종으로 작업을 수행하였다면 Zombie state가 되어(SZOMB) Process의 수명을 마무리 하게 된다.

Process Context

Process를 이루고 있는 Context은 다음과 같은 구성요소로 이루어져 있다.

l text : 실행가능한 Code를 가지고 있으며 maxtsiz 값으로 최대값 조절

l Data : Text에 의해 초기화 되는 Data로 프로그램에서 사용되는 전역변수, maxdsiz값으로 최대값 조절

l bss : 초기화 되지 않는 Data

l heap space : malloc(3) fuction에 의해 호출되서 Process에서 사용가능하게 하는 정의되지 않는 공간

l mmap : private memory mapped file (VAS와 Mapping)

l User and Kernel Stack : thread가 User mode에서 변수 or subroutine을 저장하는 공간을 말하며, maxssiz값으로 최대값을 조절

image

Process structure layout, showing context and space use

Thread Model

HP-UX는 thread기반의 OS이다. 결국 Process 동작을 이해하기 위해서는 thread가 Process에 어떠한 영향을 미치는지 알아보아야 할 필요가 있다. thread도 결국 프로그램의 한 부분이 된다. 뒤의 Model부분에 설명이 나오지만 thread의 개념은 Concurrent하고 Parallel하게 Process 를 수행할 수 있는 핵심 개념이다.

thread는 Process의 Resource 중 Working Directory, Global 변수값등을 share하며, 스케줄링 정책 및 priority, Signal mask등과 같은 resource는 thread만이 고유하게 가지고 있는 Resource 값이다.

l User Space Threads (Mx1)

image

위 모델은 초창기 10.x Thread Model로 User space에서 thread의 create, terminate, synchronize, schedule등의 action이 thread library에 의해 실행된다. 위와 같은 구조는 한 개의 thread에서 kernel thread를 blocking 할 경우 나머지 전체 thread들이 자동적으로 blocking 되에 parallel한 action에는 취약한 구조이다.

l Kernel Space Thread (1x1)

image

1:1구조에서는 각각의 Thread들이 Kernel에 의해 독립적으로 수행이 가능한 구조이다. 위 구조와는 반대로 한 개의 thread가 kernel을 blocking 할 경우에 나머지 thread의 실행상태는 정상적으로 수행가능 하게 된다. 이러한 구조는 uniprocessor system에서 좀더 효율적인 성능을 발휘하여 더 낳은 performance 를 제공하게 된다.

l User Space and Kernel Space Threads (MxN)

image

11.23 Version 이후도 도입된 개념이다. User space 개념과 Kernel Space 개념을 도입함으로써 Thread 처리에 대한 성능을 높인 처리구조이다. 복잡한 처리를 하는 구조로 변하기 때문에 Debugging하기는 어렵다.

신고

'Unix Solution > HP-UX Management' 카테고리의 다른 글

APA구성 시 주의점  (0) 2007.12.14
HP-UX Internal Disk Mirroring 방법  (0) 2007.11.01
Unix서버 시간 동기화 방법  (0) 2007.10.26
HP-UX Process Management -#1  (0) 2007.09.26
HP-UX Kernel Service  (0) 2007.09.11
HP-UX Process Management Structures  (1) 2007.09.02
Posted by hotpoto

Kernel 동작이 시작되는 System Call Interface 흐름도이다.

image

System Call Interface가 Windows로 말하면 DLL의 역활을 하는 곳이라고 해야하나?? 암튼 구조는 복잡

하지만 내용을 보면 그리 어려운 내용을 아닐것이란 생각이 든다. 왜냐하면 지금은 기본기를 다지는 시기니까!

● System Call Flow

1. User Mode – High Level

  -  User Program 이 System Call 을 호출 하게 되면, System Call Sutb 이라는 어셈블리 언어 Sutb 을 통과하게

     된다. C 라이브러리를 참조하여 일어난다. System Call Stub 은 System call 의 entry point가 정의되어 있는

     데, 아규먼트로서 system call number를 가지고 gateway page와 연결된다.

2. User Mode – Low Level

  -  Gateway page 는 들어온 Call의 우선순위를 할당하고, 커널의 System Call 초기화 루틴을 호출한다. 이때,

     미리 정의된 Light weight calls 처리는 초기화 없이 기존 정의된 루틴에 따라 처리된다.

3. Kernel Mode – Low Level

  - Low-Level 초기화 루틴을 수행하는 단계로, 이 단계에서는 응답을 주기 위한 Stack 구조와, 관련된 user 의

   상태를 저장하고, System Call 을 처리하기 위한 적절한 커널 환경을 Setting 을 수행 한다.

4. Kernel Mode – High Level

  - 실제적인 Kernel 이 이해할 수 있는 코드(High-Level system code)를 만들어 Kernel 루틴을 수행한다.

    이는 최종 Code이다.

5. Return

  - System Call 에 대한 응답은 요청의 반대로 이루어진다.

Kernel Timeout Service

HP-UX Kernel 의 event를 scheduling 하기 위해 Timeout Service를 제공한다. System Call 이 을 요청하면,

callout table 에 List를 올려서 관리하고, 요청이 끝나면 callout table 에서 제거함으로써 Scheduling을 관리한다.

HP-UX 의 커널은 10ms 단위로 tick 을 가져간다.

Timeout 진행

1. 커널은 반드시 요청에 대해서 응답한다.(이는 커널이 응답하지도 않을 수 있는 negative Kernel 에 대한

   고려는 하지 않음)

2. spinlock 을 획득한다.

3. free list의 callout entry 를 획득한다.

4. function, argument, spu, flag등을 포함한 callout entry를 초기화 한다.

5. ticks_since_boot 값과 entry 의 time을 동일 하게 setting 하고, timeout tick 을 추가 한다.

6. 적절한 bucket 에 넣고, hashchain 을 설정 한다. interval timer가 수행되는 동안 들어온 event는 queue 에

   저장된다.

7. spinlock 을 release 한다.

신고

'Unix Solution > HP-UX Management' 카테고리의 다른 글

APA구성 시 주의점  (0) 2007.12.14
HP-UX Internal Disk Mirroring 방법  (0) 2007.11.01
Unix서버 시간 동기화 방법  (0) 2007.10.26
HP-UX Process Management -#1  (0) 2007.09.26
HP-UX Kernel Service  (0) 2007.09.11
HP-UX Process Management Structures  (1) 2007.09.02
Posted by hotpoto

출처 : http://docs.hp.com/en/5965-4642/5965-4642.pdf

Process Management System 은 Kernel`s scheduling subsystem과 IPC(Interprocess communication) subsystem

으로 구성된다. Process Subsystem은 Memory Subsystem과 큰 연관이 있다. 아무래도 Process 실행되기전에

Memory에 있는 값이 File로 Writing 되는 상호 작용때문에 연관성이 큰것 같다. 결국 Windows에서 말하는

Paging, 즉 Virtual Memory 값을 말하는 것이다.

프로세스간의 통신은 Shared Memory나 System Call을 통해 이루어 진다. 뭐 동작하는 모드로는

asynchronous or synchronous 모드가 있다고 하지만... 자세한 Mechanism은 뒤에서 설명하기로 하고 Pass

System Call은 간단히 말하면 Kernel 단에서 Prcoess 사용을 위한 Interrupt를 제공하는 기능인거 같다.

모든 Process는 Kernel Process Table을 보유하고 있으며, 이러한 구조체를 uarea라고 부른다.

Process Management Code는 External 부분과 Internal한 부분으로 나뉘며, proc_iface.h에 Access functions,

external interface type등을 정의해 놓구 있으며 proc_private.h에는 internal fuction, types, macros등의 내용을

포함하고 있다. 또한 kernel threads code는 kthread_iface.h와 kthread_private.h에 포함되어 있다.

image

  • Proc table : 초기 부팅시에 할당이 되며 Swap 되지 않는 공간, 모든 Process에 대한 상태, signal, size, kernal thread에의해 공유되는 process 정보들을 가지고 있는 구조체 이다.

image

  • kthread  : kernal thread에 대한 cpu 사용량, 상태정보, priority 정보들을 담고 있는 구조체

image

  • vas : Process`s virtual space 에 대한 모든 정보를 가지고 있으며 필요시 동적으로 할당 가능

image

  • pregion : text, data, stack, shared memory, page count등의 vas에서 사용되는 process나 thread에 대한 정보를 가지고 있는 구조체

image

image

  • uarea : swap이 가능한 구조체

image

신고

'Unix Solution > HP-UX Management' 카테고리의 다른 글

APA구성 시 주의점  (0) 2007.12.14
HP-UX Internal Disk Mirroring 방법  (0) 2007.11.01
Unix서버 시간 동기화 방법  (0) 2007.10.26
HP-UX Process Management -#1  (0) 2007.09.26
HP-UX Kernel Service  (0) 2007.09.11
HP-UX Process Management Structures  (1) 2007.09.02
Posted by hotpoto

티스토리 툴바