Linux Tuxedo 튜닝

1.운영체제(Operating System) 확인

 

  운영 중인 Tuxedo 운영서버의 linux 2.6.32-573.el6.x86_64를 기준으로 OS Patch에 따른 서비스 팩(Service Pack)이 정확하게 적용되었는지 확인을 해야 한다. GNU 홈페이지에서 지원을 하지 않는 부분에 대해서는 정확한 검증이 없었음을 의미한다.

 

1.1 운영체제 버전 확인 및 최신 패치 적용

 

  최신 버전에 모든 패치가 적용된 운영체제를 사용하는 것이 성능향상 및 보안문제에 있어서 유리하나, 그렇다고 새로 적용한 패치로 인해 새로운 버그(Bug)가 생겨나는 경우도 있으므로 주의해야 한다. 패치를 적용하기 전 해당 패치에서 새로이 적용된 변경사항을 확인하고, 패치 적용 후에는 즉시 성능을 확인하도록 해야 한다.

 

[cv_tux] /home/cv_tux > uname -a Linux UATAPP01 2.6.32-573.el6.x86_64 #1 SMP Thu Jul 23 15:44:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux   [cv_tux] /home/cv_tux > free total       used       free     shared    buffers     cached Mem:       3906036    3134124     771912      18552     199564    2142180 -/+ buffers/cache:     792380    3113656 Swap:      8388604      45472    8343132   [cv_tux] /home/cv_tux > getconf WORD_BIT 32

 

 

1.2 운영시스템 Kernel parameter

 

  Linux에서 대표적으로 프로세스간 통신(Inter Process Communication)에 사용되는 자원(System Resource)으로는 메시지 큐(Message Queue), 공유 메모리(Shared Mmory)와 세마포어(Semaphore) 등이 있으며, 이 자원들은 네트워크(Network), 미들웨어(Middleware), 데이터베이스(Database), 응용프로그램(Application) 등과 같이 사용하는 환경에 따라 시스템 자원의 값을 계산하고 이를 수용할 수 있을 정도로 조정하여 커널 파라미터(Kernel parameter)에 설정해 주어야 한다.

 

예) 프로세스의 자원 한도 확인

[cv_tux] /home/cv_tux > ulimit -Sa core file size          (blocks, -c) 0 data seg size           (kbytes, -d) unlimited scheduling priority             (-e) 0 file size               (blocks, -f) unlimited pending signals                 (-i) 15149 max locked memory       (kbytes, -l) 64 max memory size         (kbytes, -m) unlimited open files                      (-n) 1024 pipe size            (512 bytes, -p) 8 POSIX message queues     (bytes, -q) 819200 real-time priority              (-r) 0 stack size              (kbytes, -s) 10240 cpu time               (seconds, -t) unlimited max user processes              (-u) 1024 virtual memory          (kbytes, -v) unlimited file locks                      (-x) unlimited

 

예) 프로세스의 자원 항목 설명

항목	Soft한도	Hard한도	설명
core file size (blocks, -c)	0	unlimited	코어 파일의 최대크기
data seg size (kbytes, -d)	unlimited	unlimited	프로세스 데이터 세그먼트 최대 크기
scheduling priority (-e)	0	31	각 스레드에는 스케줄링 우선 순위가 지정
file size (blocks, -f)	unlimited	unlimited	Shell에서 생성되는 파일 최대 크기
pending signals (-i)			대기중인 시그널
max locked memory (kbytes, -l)	unlimited	unlimited	Locked 메모리의 최대량
max memory size (kbytes, -m)	unlimited	unlimited	메모리 최대 크기
open files (-n)	1024	4096	오픈할 수 있는 최대 파일 수
pipe size (512 bytes, -p)	8	8	512byte 블럭의 파이프 크기
POSIX message queues (bytes,-q)	819200	819200	POSIX 메시지 큐 크기
real-time priority (-r)	0	99	실시간 프로세스의 우선순위
stack size (kbytes, -s)	8192	unlimited	프로세스의 스택 최대크기
cpu time (seconds, -t)	unlimited	unlimited	총 누적된 CPU시간(초)
max user processes (-u)	1024	14943	단일 유저가 사용 가능한 프로세스의 최대갯수
virtual memory (kbytes, -v)	unlimited	unlimited	쉘에서 사용 가능한 가상 메모리의 최대용량
file locks (-x)	unlimited	unlimited	락할 수 있는 최대 파일 수

 

  Tuxedo 운영시스템을 안정적으로 운영하기 위하여 반드시 고려해야 할 중요한 커널 파라미터는 다음과 같다.

 

1) 최대 파일 디스크립터 수 지정

Tuxedo 운영서버의 프로세스가 아주 많은 수의 파일과 네트워크 접속을 열게 되면, 할당된 파일 디스크립터(File Discriptor)의 수까지 증가하게 되는데, 사용할 수 있는 파일 디스크립터가 없다는 것은 이전의 네트워크 접속이 종료되어 사용하던 파일 디스크립터를 정리하기 전까지는 새로운 접속을 허용할 수 없는 상태도 있지만, 그 외에도 다음과 같은 에러가 발생하기도 한다.

 

• Too many open files

• Broken pipe

  물론, [Broken pipe] 에러는 다양한 경우에 발생하는 에러이지만 File Descriptor의 제한으로 인해 발생 할 수 있다.

• ClassNotFound

  소켓 이외에 디스크로부터 클래스를 얻어 로드하는 경우 File Descriptor가 사용이 되는데 부족하면 해당 시스템에 클래스가 존재하고도 ClassNotFound와 같은 에러가 표시되기도 한다.

   

  Linux에서는 limit나 ulimit의 Shell 명령을 이용해 하나의 프로세스가 동시에 Open할 수 있는 파일 디스크립터의 수를 증가 시킬 수 있다.

   

csh 경우)     limit descriptors 8192 sh, ksh 경우)     ulimit -n 8192     ulimit -s unlimited

 

Shell에서 한번 지정되면 이후에 실행되는 모든 명령어에 반영된다. 이 경우 장비를 reboot하는 경우 설정값이 초기값으로 되돌아 가므로 최대 파일의 개수에 대한 설정치를 추가하고, 시스템을 리부팅 한다.

 

현재 운영되고 있는 시스템의 커널 파라미터를 분석한 결과 현재 설정값을 기준으로 Linux에서 권장하는 값은 다음과 같다.

 

파라미터	설명	설정값	권장값	비고
open files	한 프로세스가 최소로 Open할 수 있는 File Descriptor 개수. 예) ulimit -n 8192	1024	8192
file-max	한 프로세스가 최대로 Open할 수 있는 File Descriptor 개수. 예) cat /ptoc/sys/fs/file-max	6815744	-
file-nr	현재 시스템에서 사용 중인 파일 핸들의 수. 예) cat /proc/sys/fs/file-nr	0

 

2) IPC(InterProcess Communication) 자원

 

  Tuxedo는 주로 프로세스 간의 통신에 관련되어 다음과 같이 IPC(InterProcess Communication)을 위한 시스템 자원을 할당하기 위한 Kernel Parameter 설정이 필요하다.

 

  현재 설정된 Tuxedo에 대한 최소로 요구되는 IPC 요구량은 다음과 같다.

 

[cv_tux] /home/cv_tux > tmboot -c Ipc sizing (minimum /T values only) ...                   Fixed Minimums Per Processor   SHMMIN: 1 SHMALL: 1 SEMMAP: SEMMNI                   Variable Minimums Per Processor                           SEMUME,           A                             SHMMAX                         SEMMNU,           *                               * Node                    SEMMNS  SEMMSL  SEMMSL  SEMMNI  MSGMNI  MSGMAP  SHMSEG ------                  ------  ------  ------  ------  ------  ------  ------ UATAPP01                   525      65     520   A + 1     600    1200  16717K   where 1 <= A <= 8.   The number of expected application clients per processor should be added to each MSGMNI value.

참고) A는 Machine당 BBL 수를 의미

 

이 값들은 해당 Tuxedo 도메인을 운용하기 위한 최소한의 값이기 때문에, 다른 어플리케이션에서 IPC 자원을 사용한다면 그에 대한 값도 여기에 더해져야 한다.

 

① Message Queue 관련 커널 파라메터

 

파라미터	현재 설정값	조치사항	비고
MSGMNI	7621		메시지 큐 구분자의 개수로 필요한 메시지 큐의 개수만큼 잡는다. 한 서버는 Request 큐와 Response 큐를 가지므로 2*(서버수)에 약간의 여유분을 두면 적당하다. 일반적으로 NPROC의 설정값을 지정한다.
MSGMAX	65536		업무에 사용하는 메시지를 담을 수 있는 메시지의 최대 크기로 하는 것이 좋다. 그러나 무한정 크게 할 수는 없으므로 64KB 정도로 한다. 사실 시스템에서 64KB로 제한되어 있는 경우가 많다.(LIBTUX_CAT:1285 오류 발생)
MSGMNB	65536	131070	하나의 큐에 대한 최대 길이로 어느 순간에 메시지 큐에 쌓인 메시지들의 총 Byte Size다. 메시지 큐에 쌓인 메시지들의 총 Byte 값이 MSGMNB 값의 80% 정도를 넘어서면 하드디스크에 임시 파일을 생성하여 이용하므로, 평균적인 전송데이터 길이의 2배 이상으로 설정하는 것이 바람직 하다.(MSGMAX 보다는 커야 함) 일반적으로 128K ~ 192K(MSGMAX * 2/3)로 지정한다.

 

현재 설정된 Message Queue)

[cv_tux] /home/cv_tux > ipcs -lq   ------ Messages: Limits -------- max queues system wide = 7621         ==> 시스템에서 사용할 수 있는 최대 큐의 수(MSGMNI) max size of message (bytes) = 65536     ==> 메시지의 최대 크기(MSGMAX) default max size of queue (bytes) = 65536 ==> 기본적인 큐의 최대 크기(MSGMNB)

 

② Semaphore 관련 커널 파라메터

 

파라미터	현재 설정값	조치사항	비고
SEMMSL	250	6640	하나의 Semaphore ID에 대하여 생성될 수 있는 Semaphore의 개수를 제한 것으로 논리적으로 SEMMSL는 SEMMNS의 값과 같거나 적어야 한다. 만일 이 값을 너무 크게 잡으면, 몇 개의 Semaphore ID가 시스템 전체에 있는 Semaphore를 독식할 수 있다.
SEMMNS	32000	6640	Undo 구조체구조체의 개수로 각 Semaphore에 대하여 16 바이트의 커널 메모리가 미리 할당한다. TUXEDO 내에서 BBL에 동시에 접속할 수 있는 Process 수를 의미한다.(MAXACCESSORS와 관련 있는 Parameter 임) Tuxedo에서 필요로 하는 값은 "tmboot -c" 명령으로 얻을 수 있으며, 데이터베이스에서 많이 사용하므로 사용되는 양을 "ipcs -b" 명령으로 확인한 후, 위의 두 값의 합에 여유분을 두어 결정한다. 일반적으로 (SEMMNI * 2)의 설정값을 지정한다.
SEMOPM	32	100	1 call(1개의 시스템 호출)이 초당 호출 가능한 최대 세마포어 갯수로 하나의 호출에서 여러 개의 세마포어를 지원할 수 있다. 보통 SEMOPM은 SEMMSL에 의해서 정의되어지고 값도 같은 것을 권장한다고 한다.
SEMMNI	128	3320	시스템에서 사용할 수 있는 최대 Semaphore sets (id)로 시스템에 있는 모든 Semaphore set은 유일한 ID와 제어구조를 갖는다. 각 Semaphore set에 대하여 84 바이트의 커널 메모리가 미리 할당하며, SEMMNI의 값을 65535 보다 크게 지정하지 못한다.

 

현재 설정된 Semaphore)

[cv_tux] /home/cv_tux > ipcs -ls   ------ Semaphore Limits -------- max number of arrays = 128          ==> 배열의 최대 수(SEMMNI) max semaphores per array = 250      ==> 배열 당 최대 세마포어 수(SEMMSL) max semaphores system wide = 32000 ==> 시스템에서 사용할 수 있는 최대 세마포어의 수(SEMMNS) max ops per semop call = 32         ==> semop 호출 당 최대 작업 수(SEMOPM) semaphore max value = 32767        ==> 세마포어의 최대 값

 

③ Shared memory 관련 커널 파라메터

 

 

파라미터	현재 설정값	조치사항	비고
SHMMNI	4096		시스템에 가용한 Shared memory id의 최대 개수로 모든 Shared memory segment는 이 id에 의해 관리한다. id 1개당 약 120 Byte 정도의 메모리가 미리 할당되며, 메모리의 1/4 이상이 이 id에 할당되지 못한다.
SHMMAX	67108864		Shared memory segment의 최대 크기로 커널이 필요할 때마다 할당 받아 사용한다. 값을 크게 지정하여도 시스템이 나쁜 영향을 주지는 않는다.
SHMALL	17179869184		특정 시점에 시스템에서 사용 가능한 공유 메모리의 최대 크기를 설ㅇ하는데 사용된다.

 

현재 설정된 Shared memory)

[cv_tux] /home/cv_tux > ipcs -lm   ------ Shared Memory Limits -------- max number of segments = 4096                ==> 생성할 수 있는 공유 메모리 최대 개수(SHMMNI) max seg size (kbytes) = 67108864                ==> 각 공유 메모리의 최대 크기(SHMMAX) max total shared memory (kbytes) = 17179869184 ==> 시스템에서 허용하는 공유 메모리의 총 크기                                                     (SHMALL) min seg size (bytes) = 1                         ==> 공유 메모리 최소 크기

 

2.Network 확인

 

Tuxedo 운영서버 또는 Database 등이 상호 접속함에 있어서, 적절한 Network bandwidth를 가져야 한다. 충분한 Bandwidth를 가졌음에도 불구하고 성능이 발휘가 되지 않는다면, 각각의 제조사에서 제공을 하는 Network monitoring tools를 이용하여 어떤 부분이 네트워크에서 부하를 주는지 알아내어 해결할 수도 있다. LAN infrastructure에서 100% 사용하여 한계를 넘는다면, 부하를 재배치 하거나, 네트워크를 재구성 하거나, 클라이언트의 수를 줄이거나, Systems handling the network load의 수를 늘려야 한다.

 

 

2.1 TCP/IP관련 파라미터 설정

인터넷에서 사용하는 HTTP는 TCP/IP 프로토콜 기반에서 동작 하므로 TCP 파라미터를 조정하여 네트워크 성능에 영향을 줄 수 있다. 기본으로 설정된 설정값들은 지연시간이 작은 LAN환경에서는 잘 동작하지만, 인터넷에서는 지연에 의해 불필요한 재전송이 발생되는 경우가 많다. Linux에서는 root계정으로 ndd 명령을 이용하여 실행중인 커널의 TCP/IP 파라미터를 바꿀 수 있다. 이 경우 장비를 reboot하는 경우 설정값이 초기값으로 되돌아 가므로 Kernel에 ndd 설정치를 추가하여 등록 해야 한다.

 

파라미터	설명	설정값	권장값	비고
tcp_syn_retries	일정한 시간과 IP별로 보내고 받는 SYN 재시도 횟수를 3회로 제한한다. 이 옵션은 스푸핑된(위조된) 주소로 오는 SYN 연결의 양을 줄여준다. 기본 값은 5이며 255를 넘지 않아야 한다.   예) echo 3 > /proc/sys/net/ipv4/tcp_syn_retries		3
tcp_synack_retries	Passive TCP 연결에서 재전송을 위해 지정한 시간만큼 지난 뒤에 초기화 SYNACK 패킷을 보낸다. 255보다 클 수 없다. 기본값은 5인데 180초에 해당한다.   예) echo 5 > /proc/sys/net/ipv4/tcp_synack_retries		5
tcp_keepalive_time	이미 프로세스가 종료되어 불필요하게 남아 있는 연결을 끊는 시간을 줄이도록 한다.   예) echo 10 > /proc/sys/net/ipv4/tcp_keepalive_time		10
tcp_keepalive_probes	연결이 끊어졌다고 여길 때까지 keepalive probe를 얼마나 내보낼지 정한다. 기본값은 9이다.   예) echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes		2
tcp_retries1	무언가 문제가 있을 때 연결을 위해 재시도 할 횟수, 최소 값과 기본 값은 3이다.   예) echo 3 > /proc/sys/net/ipv4/tcp_retries1		3
tpc_retries2	TCP 연결을 끊기 전에 재시도할 횟수이다.   예) echo 3 > /proc/sys/net/ipv4/tcp_retries2		3
tcp_orphan_retries	우리 쪽에서 닫은 TCP 연결을 끊기 전에 확인하는 횟수를 정한다. 기본값은 7로 RTO 50초에서 16분 사이에 해당한다. 머신에 웹 서버가 올라와 있다면 이 값을 줄여서 소켓 등이 귀한 리소스를 소비하지 않도록 할 수도 있다.   예) echo 0 > /proc/sys/net/ipv4/tcp_orphan_retries		0
tcp_fin_timeout	우리 쪽에서 닫을 때 FIN-WAIT-2 상태인 소켓을 잡아둘 시간을 정한다. 상대편은 깨어진 뒤에 스스로 닫지 못하거나 뜻하지 않게 죽어버릴 수도 있다. 기본 값은 60초이다. 2.2에서 일반적인 값은 180초였는데 2.4에서도 이 값을 그대로 사용할 수 있지만, 머신이 웹 서버로 부하가 많다면 죽은 소켓들이 그대로 엄청나게 쌓여 메모리가 넘쳐나는 문제가 생길 것이다. FIN-WAIT-2 소켓은 최대 1.5K 메모리만 잡아 먹으므로 FIN-WAIT-1 소켓보다는 덜 위험하다. 그러나 더 오래 버티는 경향이 있다.   연결을 종료시 소요되는 시간을 줄여준다(기본 설정값: 60).   예) echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout		5
tcp_max_tw_buckets	시스템에서 동시에 잡아두는 timewait 소켓의 수를 정한다. 이 값이 time-wait 소켓을 넘어서면 바로 파괴되고 경고가 출력된다. 이 제한은 단순한 DoS 공격을 방어하기 위해서만 필요하며, 기본값보다 작게해서는 절대 안된다. 네트워크 환경이 기본값보다 큰 값을 요구한다면 늘려도 된다.   예) echo 2000000 > /proc/sys/net/ipv4/tcp_max_tw_buckets		2000000
tcp_tw_recycle	빠른 재생 TIME-WAIT 소켓을 사용한다. 기본값은 1이다. 전문가의 조언/요청이 없다면 절대 바꾸지 마시가 바람.   예) echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle		1
tcp_max_orphans	시스템에 고정되었거나, 사용자 파일 핸들에 연결되지 않은 TCP 소켓의 최대 값을 지정한다. 고아 연결이 이 값을 초과하면 즉시 리셋되고 경고를 출력한다. 이 제한은 단순한 DoS 공격을 방어하기 위해서만 필요하며, 기본값보다 작게해서는 절대 안된다. 네트워크 환경이 기본값보다 큰 값을 요구하거나 오래 버티어서 그런 문제들은 더 공격적으로 죽이기 위해 네트워크를 조율한다면 늘려도 된다 (아마, 설치된 메모리를 증설한 다음) 한번 더 당부하자면: 고아 연결들은 스왑할 수 없는 메모리를 각자 64K 이상 잡아먹는다.   예) echo 65536 > /proc/sys/net/ipv4/tcp_max_orphans		65536
tcp_abort_on_overflow	리스닝 서비스가 새로운 연결을 수락하기에 너무 느리다면 그 서비스를 리셋한다. 기본값은 FALSE이다. 이 것은 갑자기 오버플로가 발생하더라도 연결이 복구된다는 뜻이다. 리스닝 디먼이 연결을 더 빨리 수락하도록 자리잡지 못하는게 정말 확실할 때에만 이 옵션을 활성화한다. 이 옵션을 활성화하면 서버에서 손상된 클라이언트라도 리슨한다.   예) echo 0 > /proc/sys/net/ipv4/tcp_abort_on_overflow		0
tcp_syncookies	커널을 컴파일할 때 CONFIG_SYNCOOKIES 를 활성화했을 때에만 사용가능하다. 일반적으로 'syn flood attack'로 알려진 공격을 방어한다. 기본값은 FALSE   syncookie는 예비 기능임을 기억해야 한다. 이 옵션은 합법적인 연결로 많은 부하가 걸리는 서버에서는 절대 사용하지 말아야 한다. 로그에서 synflod 경고가 뜨지만, 알고보니 정상적인 연결이 과중해서 생긴거라면 경고 메시지가 사라질 때까지 다른 패러미터를 조율해야 한다.   syncookies 는 TCP 프로토콜에 심각하게 어긋나며, TCP 확장을 사용할 수 없으며, 특정 서비스(f.e. SMTP relaying)에 심각한 손상을 가져올 수 있다.  보이지 않더라도, 클라이언트들은 연계되어 있다. 로그에 synflood 경고가 남지만 진짜로 넘쳐난 것이 아니라면, 서버 설정이 아주 잘못 되어 있을 것이다.   예) echo 1 > /proc/sys/net/ipv4/tcp_syncookies		1
tcp_stdurg	TCP urg 포인터 필드 해석기가 필요할 때에 사용한다. 대부분 오래된 BSD 해석기를 사용하는데, 리눅스가 그런 것들과 제대로 소통하지 못하는 듯 하다면 On해야 한다. 기본값은 FALSE   예) echo 0 > /proc/sys/net/ipv4/tcp_stdurg		0
tcp_max_syn_backlog	연결한 클라이언트로부터 응답 패킷을 받지 못하고 있는 접속 요청을 몇 개나 기억하고 있을지 정한다. 기본값은 1024로 128MB 이상 메모리를 가져야한다. 그보다 작을 때에는 128을 사용한다. 서버가 과부하에 허덕인다면 이 값을 늘려야 한다. 다만 1024 보다 크게 하려면 include/net/tcp.h 파일을 열어 TCP_SYNQ_HSIZE 값을 TCP_SYNQ_HSIZE*16 <= tcp_max_syn_backlog 공식에 맞추어 설정한 다음 커널을 다시 컴파일해야 한다.   예) echo 65536 > /proc/sys/net/ipv4/tcp_max_syn_backlog		65536
tcp_sack	SYN 패킷을 전송한 후에, 로스가 발생을 하여 ACK를 일부 받지 못했을 경우, 선택적으로(selected) 받지 못한 ACK만 받도록 요청하는 것을 허락한다. 로스가 많은 네트워크에서는 상당히 중요한 역할을 한다.   예) echo 0 > /proc/sys/net/ipv4/tcp_sack		0
tcp_timestamps	RFC1323에 정의된 timestamp들을 가능하게 한다.   예) echo 1 > /proc/sys/net/ipv4/tcp_timestamps		1
tcp_window_scaling	RFC1323에 정의된 Window scaling를 가능하게 한다.   예) echo 0 > /proc/sys/net/ipv4/tcp_window_scaling		0
tcp_fack	FACK 혼잡 회피와 빠른 재선송을 가능하게 한다. tcp_sack가 활성화되지 않았다면 값이 사용되지 않는다.   예) echo 1 > /proc/sys/net/ipv4/tcp_fack		1
tcp_dsack	Allows TCP to send "duplicate" SACKs.   예) echo 1 > /proc/sys/net/ipv4/tcp_dsack		1
tcp_ecn	명백한 혼잡 공지(Explicit Congestion Notification).   예) echo 0 > /proc/sys/net/ipv4/tcp_ecn		0
tcp_reordering	Maximal reordering of packets in a TCP stream. Default: 3   예) echo 3 > /proc/sys/net/ipv4/tcp_reordering		3
tcp_retrans_collapse	망가진 프린터에 Bug-to-bug 호환. 더 큰 패킷을 다시 전송해서 어떤 TCP 스택에 있는 버그를 피해간다.   예) echo 1 > /proc/sys/net/ipv4/tcp_retrans_collapse		1
tcp_wmem	min: TCP 소켓에서 send 버퍼를 위해 예약된 메모리 크기.Default: 4K   default: 이 값은 다른 프로토콜들에 의해 사용되는 net.core.wmem_default 값에 우선한다. Default: 16K   max: TCP 소켓에서 자동으로 선택된 send 버퍼를 위한 최대 메모리 크기. 이 값보다 net.core.wmem_max 값이 우선한다. Default: 128K   예) echo 150000000 > /proc/sys/net/ipv4/tcp_wmem		150000000
tcp_rmem	min: TCP 소켓에 의해 사용되는 receive 버퍼의 최소 크기. Default: 8K   default: 이 값은 net.core.rmem_default에 우선한다. Default: 87380 바이츠.   max: receiver 버퍼에서 사용할 수 있는 최대 크기. 이 값보다 net.core.rmem_max 가 우선한다. Default: 87380*2 bytes.   예) echo 30000000 > /proc/sys/net/ipv4/tcp_rmem		30000000
tcp_rfc1337	세팅되면 TCP 스택은 RFC1337을 따른다. 해제되면 RFC를 따르지 않지만 TCP TIME_WAIT asassination은 막아준다.   Default: 0   예) echo 1 > /proc/sys/net/ipv4/tcp_rfc1337		1

 

예)

# Kernel sysctl configuration file for Red Hat Linux # # For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and # sysctl.conf(5) for more details. # # Use '/sbin/sysctl -a' to list all possible parameters.   # Controls IP packet forwarding net.ipv4.ip_forward = 0   # Controls source route verification net.ipv4.conf.default.rp_filter = 1   # Do not accept source routing net.ipv4.conf.default.accept_source_route = 0   # Controls the System Request debugging functionality of the kernel kernel.sysrq = 0   # Controls whether core dumps will append the PID to the core filename. # Useful for debugging multi-threaded applications. kernel.core_uses_pid = 1   # Controls the use of TCP syncookies net.ipv4.tcp_syncookies = 1   # Controls the default maxmimum size of a mesage queue kernel.msgmnb = 65536   # Controls the maximum size of a message, in bytes kernel.msgmax = 65536   # Controls the maximum shared segment size, in bytes kernel.shmmax = 68719476736   # Controls the maximum number of shared memory segments, in pages kernel.shmall = 4294967296   # User define kernel.msgmni = 1024 kernel.sem = 1000 32000 32 512 #kernel.shmmax = 2147483648 #kernel.shmmax = 3221225472 #fs.file-max = 65535 net.core.netdev_max_backlog=2500 net.core.rmem_default = 65536 net.core.rmem_max = 8388608 net.core.wmem_default = 65536 net.core.wmem_max = 8388608 net.ipv4.tcp_rmem = 4096 87380 8388608 net.ipv4.tcp_wmem = 4096 65536 8388608 net.ipv4.tcp_mem = 4096 4096 4096 net.ipv4.tcp_syn_retries = 3 net.ipv4.tcp_synack_retries = 5 net.ipv4.tcp_keepalive_time = 30 net.ipv4.tcp_keepalive_probes = 2 net.ipv4.tcp_retries1 = 3 net.ipv4.tcp_retries2 = 3 net.ipv4.tcp_orphan_retries = 7 net.ipv4.tcp_fin_timeout = 5 net.ipv4.tcp_max_tw_buckets = 2000000 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_max_orphans = 65536 net.ipv4.tcp_abort_on_overflow = 0 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_stdurg = 0 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_sack = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_fack = 1 net.ipv4.tcp_dsack = 1 net.ipv4.tcp_reordering = 3 net.ipv4.tcp_retrans_collapse = 1 net.ipv4.tcp_rfc1337 = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.icmp_echo_ignore_broadcasts = 7 #net.ipv4.ip_local_port_range = 1024 65536 net.ipv4.tcp_challenge_ack_limit = 1073741823   net.ipv4.conf.all.accept_source_route = 0 #net.ipv4.conf.all.send_redirects=0 #net.ipv4.conf.all.accept_redirects=0 net.ipv4.conf.eth0.rp_filter = 1 net.ipv4.conf.lo.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.all.log_martians = 1 net.ipv4.route.flush = 1 #vm.bdflush = 100 1200 128 512 15 5000 500 1884 2 #vm.bdflush = 30 500 0 0 60 300 60 0 0   # For Oracle fs.aio-max-nr = 1048576 #fs.file-max = 6815744 #kernel.shmall = 2097152 kernel.shmmni = 4096 #kernel.sem = 250 32000 100 128 #net.ipv4.ip_local_port_range = 9000 65500 #net.core.rmem_default = 262144 #net.core.rmem_max = 4194304 #net.core.wmem_default = 262144 #net.core.wmem_max = 1048586 net.nf_conntrack_max = 131072

 

 

 

 

3. Tuxedo ubbconfig 설정

 

1) WSH의 개수 설정

 

  WSH의 역할은 WS 클라이언트와 통신하는 역할을 하며, 하나의 WSH은 멀티 플렉싱 기능을 이용하여 하나 이상의 WS 클라이언트와 통신이 가능하다.

 

  하나의 WSH가 몇 개의 WS 클라이언트와 통신을 할지는 ubbconfig의 WSL 정의 부분에 CLOPT 부분에 "-x" 옵션으로 지정하는데, 일반적으로 10`50개 사이의 값으로 설정하고, 하나의 WSH가 50개 이상의 클라이언트를 처리해야 하는 경우는 WSH의 수를 늘려야 한다.

 

2) 서버의 갯수의 설정

 

  Tuxedo 상의 어플리케이션 서버 프로세스의 수는 가능하면 적은 값이 좋습니다. 많은 수의 어플리케이션 프로세스가 기동되게 되면, OS의 자원이 많이 필요할 뿐만 아니라 Bulletin Board에 대한 Lock 경합이 발생하여 성능저하를 유발할 수 있기 때문이다.

 

  적정 서버수의 선정은 여러 서버를 운영하면서, tmadmin의 pq 옵션 등을 통해서 각 서버 프로세스 내의 Queue에 pending 되는 메시지가 많아지는 것이 원인이 되어 응답속도가 현저하게 떨어질 경우에 그 개수를 늘려주면 된다.

 

  Tuxedo 서버의 개수는 각 서버의 MIN과 MAX 값으로 설정할 수 있는데, 일반적으로 MIN과 MAX 값은 피크 타임을 기준으로 설정하는게 일반적이다.

 

3) SYSTEM_ACCESS

 

  RESOURCES 섹션에 정의되는 값으로 shared memory 영역에 대한 접근 방법을 정의한다. 크게 PROTECTED와 FASTPATH 두 가지로 구분된다.

 

① FASTPATH로 설정을 해 놓으면 shared memory 영역을 server가 항상 attach 하면서 사용한다. 시스템의 ACCESS 속도는 빠르지만 사용자 어플리케이션에서 잘못된 메모리 영역에 대한 ACCESS를 하거나 core dump나 kill -9와 같은 비 정상 종료시에는 shared memory 영역을 access 하던 중 종료되면 shared memory 영역이 깨져서 비정상적인 작동을 유발하기 때문에 사용자가 개발한 어플리케이션이 안정적일 경우에만 사용하는 것을 권장한다.

 

② PROTECTED로 설정을 해놓으면 shared memory 영역을 사용할 때만 attach하게 된다. 사용할 때마다 attach와 detach가 발생하기 때문에 속도는 떨어지지만 사용자 어플리케이션이 불안정하여 자주 shared memory 영역을 침범하였을 경우에는 이를 방지하여 안정적인 시스템 운영을 할 수 있도록 해준다.

 

4) BLOCK TIMEOUT과 TRANSACTION TIMEOUT

 

  BLOCKTIME은 Tuxedo 클라이언트가 request 보낸 후에 response를 받을 때 까지 시간의 허용값을 정의한다. 만약 이 BlockTIME 보다 시간이 더 소요되면 클라이언트에 이 내용을 알려서 무기한적으로 response를 기다리는 것을 방지한다.

 

  BLOCKTIME 값의 설정은 SCANUNIT 값에 영향을 받는데, 이 BLOCKTIME에 대한 검사는 SCANUNIT 주기로 발생하기 때문에, 만약 SANITYSCAN이 10초, BLOCKTIME을 60초로 해놓고 서비스를 호출하면 서비스를 호출하는 시점과 SCANUNIT 간격이 다르므로 60초가 아니라 60초 내지 70초 사이에 timeout이 발생한다. transaction timeout도 이와 마찬가지로 tpbegin에 지정한 시간에 정확히 timeout이 발생하는 것이 아니라 SCANUNIT 만큼의 오차가 있을 수 있다.

 

5) REPLYQ=Y

 

  각 Service간의 호출이 있고, 호출하는 쪽 (Caller)가 MSSQ를 사용할 때 REPLYQ를 설정해야 한다. 예를 들어 서비스 A에서 서비스 B를 호출할 때, 서비스 B가 호출이 작업이 끝나면 그 내용을 서비스 A의 서버의 request Q로 return한다. 이때 이 서버가 MSSQ를 사용하고 있다면 여러 서버가 이 MSSQ를 공유하고 있기 때문에, Caller 서버가 아닌 전혀 엉뚱한 서버로 갈 수 가 있다.

 

  이런 상황을 막기 위해서 caller 쪽에 REPLYQ를 따로 지정해서 이런 현상을 방지 하게 된다.

 

6) MSSQ 사용의 선택

 

  MSSQ는 Tuxedo에서 여러 개의 어플리케이션의 request Q를 하나로 통합하여 Q의 사용효율성을 높이고 효과적인 부하분산을 하고자 하는데 그 목적이 있으며, 아래와 같은 상황에 따라서 사용 여부를 선택해야 한다.

 

① MSSQ를 사용할 수 있는 경우

   -같은 MSSQ를 사용하는 모든 서버의 서비스가 동일해야 한다.

 

② MSSQ를 사용하면 좋은 경우

   -서버가 2개~12개 사이인 경우

   -메시지의 크기가 비슷한 경우

 

③ MSSQ를 사용하지 말아야 할경우

   -하나의 MSSQ를 사용하는 서버가 12개를 넘을 경우에는 MSSQ를 분리하는 것이 좋다.

   -메시지가 너무 큰경우

   -각각의 서버의 메시지의 크기가 상이하게 다른경우

 

8) Multithread Option OFF

 

  각 Tuxedo의 어플리케이션 서버가 Multi Threading을 사용하도록 구현이 되어 있는 경우에, Tuxedo에서는 이 각 Thread간의 동기화를 위해서 Mutex를 사용하는데, 만약 MultiThreading을 사용하지 않는다하더라도 이 Mutex가 Locking을 위해서 사용이되고, 이로 인한 부하를 유발할 수 있다.

 

  그래서 사용자 어플리케이션에서 Multi Threading을 사용하지 않는다면, 이 Mutex를 사용하지 않도록 설정하여 성능 향상을 기대할 수 있다.

 

Unix 환경 변수에서 “TMNOTHREADS=Y”로 설정해 주면 된다.

 

9) Turn off XA transaction

 

  Tuxedo에서 NON-XA 프로그래밍을 했을 때도 (TMS를 사용하지 않았음에도) Tuxedo에서는 내부적으로 transaction 처리를 위해서 몇가지 기능을 수행을 한다. 그러나 이 NON-XA에서는 사용자가 어플리케이션에서 직접 transaction 관리를 하기 때문에, 이러한 처리는 불필요하고 이로 인해서 불필요한 부하를 유발할 수 있다.

 

  그래서 NON-XA로 구성된 도메인의 경우 XA transaction 처리를 Turn OFF 할 경우 성능 향상을 기대할 수 있다.

 

  XA transaction을 Turn off 하기 위해서는 RESOURCES 부분의 OPTIONS에 NO_XA라는 옵션을 추가하면 된다. NO_XA는 XA transaction을 사용하지 않겠다는 의미이기 때문에 TMS를 사용하면 에러를 발생 시키게 된다.

 

10) Tuxedo Spincount 설정

 

  Tuxedo는 운영중의 RUNTIME 정보를 BB (Bulletin Board)에 저장해 놓는다. 이 BB는 각 Tuxedo 프로세스간의 공유 메모리 공간이기 때문에, 한 프로세스가 BB를 액세스 하고 있을 때, 다른 프로세스가 BB를 액세스 할 수 없도록 BB에 대한 LOCK을 걸어서 다른 프로세스의 접근을 제어한다.

 

  이때 BB Lock을 잡고 있는 이외의 프로세스 중에 BB Lock을 잡기 위해 대기 하는 프로세스는 BB Lock이 release 되었는지를 체크하게 되는데, 이 대기 프로세스는 BB Lock이 release 되었는지를 몇 번의 Loop를 돌아서 체크를 한 후에, 만약 Loop내에 Lock이 release가 되지 않으면, 자신의 프로세스 상태를 sleep 상태로 전환한다.

 

  BB Lock을 잡고 있는 프로세스가 해당 작업을 다 끝내고 Lock을 release할 때, BB Lock을 잡기 위해서 대기중인 프로세스 중에서 sleep 상태인 프로세스가 있으면 notify를 하여 BB Lock이 release가 되었음을 알리고, 다음 프로세스가 BB Lock을 잡고 BB에서 작업을 할 수 있도록 한다.

 

  위에서 설명한 바와 같이, BB Lock을 얻기 위해서 대기중인 프로세스는 일정주기 만큼 체크를 하다가 그 주기동안 BB Lock을 얻지 못하면 sleep 상태로 빠지는데, 이 sleep과 notify는 OS Level에서 많은 비용을 필요로 하는 작업이다.

 

  그래서 대기 프로세스가 sleep상태로 가기 전에 BB Lock이 release 되는 것을 체크하는 기간을 길게 줘서 sleep 비율을 줄이는 것이 성능에 유리한데, 이 설정이 MACHINES 섹션의 SPINCOUNT라는 값이다.

 

  CPU가 1개인 machine에서는 이 SPINCOUNT를 1로 설정하는 것이 성능에 유리하고, 2개 이상의 CPU를 가진 machine에서는 이 SPINCOUNT를 5000~100,000 사이의 값으로 설정하는데, 이 값의 지정은 SPINCOUNT값을 변경 시켜 가면서, Application 성능 테스트를 하고 그 중에서 최적값을 찾아서 선택한다.

 

예) SPINCOUNT=5000

 

11) OPENINFO절의 SesWt 설정

 

  Oracle에 XA를 사용하고 있는 환경에서 application server의 수행 시간 등이 길어져 Transaction time out이 발생한 경우 TMS에 큐잉이 되는 경우에 Oracle의 SesWt를 조정할 필요가 있다.

 

  SesWt는 다른 session에 의해 사용 중인 transaction branch를 얼마나 기다릴 것인가를 초단위로 지정하기 위한 parameter로 default 값은 60(초)이다.

 

  application server가 XA를 사용하는 경우 서비스가 시작되면 xa_start()가 수행되고 서비스가 끝나면 xa_end()가 수행된다. 수행 시간이 길어져 Transaction time out이 발생하게 되면 TMS에 의해 xa_rollback() 요청이 있게 되는데, 이때 Oracle은 xa_end()가 수행되지 않은 session에 대해 SesWt에 지정된 시간만큼 xa_rollback()을 wait한다.

 

  결과적으로 Oracle로부터 xa_rollback()의 return을 받지 못하므로 TMS에 큐잉이 발생한다.

 

  SesWt은 Oracle에서 xa_open string의 한 field로 제공하는 것으로, ubbconfig의 OPENINFO에서 설정할 수 있다.

 

12) CLOPT = "-r" 옵션을 이용한 운영 정보의 수집과 분석

 

이 옵션을 사용하면 각 서버의 서비스 사용 내역이 stderr에 logging된다. 이 내용을 txrpt를 이용해서 분석하면 튜닝에 필요한 정보를 리포트 형식으로 받을 수 있으며, 이 내용을 이용해서 서버의 개수 등과 같은 Tuxedo 운영상 필요한 튜닝을 할 수 있다.

 

13) 서비스간의 호출

 

① 같은 Machine내에서는(최소한 같은 GROUP내에서는) Service에서 Service를 호출하는 형태의 Transaction이 발생하지 않도록 Service를 구성하여야 한다. 이를 위해서는 단위 업무 기능을 함수로 구축하고 Service에서 이들 함수를 차례로 호출하도록 한다. 그래서 Service를 마치함수 호출하듯이 사용하는 형태의 프로그램이 나오지 않도록 한다.

 

② 만일 다른 Machine의 Service를 호출할 필요가 있을 때에는 tpcall()같은 Blocking Call 대신에 tpforward()같은 Non-Blocking Call을 사용하여 Server Process가 필요 없이 대기하고 있는 상황을 방지한다. 다른 Service를 호출하는 Service가 호출의 결과를 필요로 하는 곳에서는 Service를 분할하는 것이 좋다.

 

Non-Blocking Call을 사용하는 것은 CPU에서 Pipeline을 사용하는 것과 같은 형태의 기법이다. 그래서 Non-Blocking Call을 사용할 때에도 이러한 Pipeline의 효과를 극대화할 수 있는 방법을 사용하여야 할 것이다.

 

③ Blocking Call이 발생하는 것을 줄이기 위해 Global Transaction의 기동(tpbegin())과 완료(tpcommit())는 반드시 Client에서 호출하도록 한다. Service에서 Global Transaction을 기동하고 완료하는 경우에는완료의 성공메시지가 Service로 반환된후에 Service가 Client로 메시지를 반환하기 전에 장애가 발생하면 Global Transaction은 정상적으로 완료되었지만 Client에서는 이 사실을 알 수 없는 상황이 발생할 수 있다. 그러므로 원칙적으로 Global Transaction의 기동과 완료를 Client에서하여야 한다.

 

14) 동일 서버 내의 서비스 요청 시

 

  동일 Application 서버 내의 서비스에 대해 tpcall시에 TPENOENT 에러가 발생한다.

 

  tpcall시에 TPENOENT에러는 해당 서비스가 없을 때(해당 서버가 shutdown 되었거나, tpcall시 서비스명 기술을 잘못 하였을 때 등) 발생하게 된다.

 

  그런데 엄연히 해당 서비스가 구동되어 있는 상태인데도 불구하고, 동일 Application 서버 프로세스 내의 한 서비스에서 다른 서비스를 tpcall하는 경우 TPENOENT 에러를 발생시키게 되는데, 그 이유는 deadlock을 방지하기 위함이다.

 

  Tuxedo Application은 default로 multithread를 사용하지 않도록 생성이 된다(7.1 이후부터 multithread 사용 가능함).

 

  따라서 위와 같은 요청을 받아주게 되면, tpcall한 서비스는 tpcall 작업에 대한 응답을 받을 때까지 blocking이 될 것이고, 서비스 요청은 해당 서버 프로세스가 이미 tpcall 작업에 걸려있기 때문에 해당 요청을 받아줄 수 없는 상태가 되어 버린다(결국 deadlock을 유발한다.).

 

  동일 서버이더라도 해당 서버가 여러 개 기동이 되어 있는 경우에는 이와 같은 작업이 가능하다. 이때 tpcall을 하는 프로세스와 tpcall을 받아 서비스를 해주는 프로세스는 서로 다른 프로세스가 된다. 이런 경우 되도록이면 서비스를 다른 서버 프로세스로 분리해 주어야 한다.

 

 

4. Tuxedo 환경 변수

 

변수	현재  설정값	조치사항	비고
TMULOGUSINGSERVICENAME	Y		WSNAT_CAT:1043 에러가 발생했을 때 클라이언트가 요청한 서비스 이름을 표시하는 방법으로 해당 옵션을 아래와 같이 환경파일에 설정한다. export TMULOGUSINGSERVICENAME=Y
TMNOTHREADS		Y	Tuxedo 7.1부터 Multithreads 환경이 도입됨으로써, 컨텍스트를 보호하기 위해 ATMI 함수를 호출할 때는 내부적으로 항상 Mutexing 함수가 사용된다. 이로 인해 예전에 비해 부하가 증가한다. Multithreads를 사용하지 않는 Application에 대해서는 이를 방치함으로써, 성능을 크게 향상시킬 수 있다. 환경변수 TMNOTHREADS가 선언되어 있으면 Multithreads processing이 방지된다. export TMNOTHREADS=Y 이 기능은 Tuxedo 8.0에서부터 지원되며, 환경변수가 아니라 ENVFILE에 이 변수를 등록하면 프로세스별로 설정을 달리할 수 있다.
TM_KILL_WITH_BBLOCK	Y		Tuxedo 프로세스가 BB에서 작업하고 있을 때 SIGKILL이 내포된 명령어를 사용하여 프로세스를 강제 종료하는 경우에 BB의 데이터가 훼손을 방지할 수 있는 방법으로 해당 옵션을 아래와 같이 환경파일에 설정한다. export TM_KIL_WITH_BBLOCK=Y
SETTCPNODELAY		1	데이터가 소켓에 존재하면 TCP 패킷이 찰 때까지 기다리지 않고 바로 전송하는 방법으로 해당 옵션을 아래와 같이 환경파일에 설정한다. export SETTCPNODELAY=1
BBLRTESCANFIRST		Y	내부 behavior와 관련된 환경변수로  내부 Timeout check시 Transaction table보다 Registry table을 먼저 Check한다. TPETIME에 대한 timing issue를 최소화하기 위해 첫번째만 Registry table를 Check하기 위한 방법으로 해당 옵션을 아래와 같이 환경파일에 설정한다. export BBLRTESCANFIRST=Y
BBWAIT_TIME	1		Tuxedo BBL에 부하가 많이 주어지는 경우, 부하 조절을 위해 Tuxedo 내부적으로 일정시간(초)동안 sleep을 하게 된다. 해당 변수는 BBWAIT_TIME이며 10초로 설정이 되어 있다. 그런데 해당 설정값이 현재로서는 비효율적으로 너무 크게 설정되어 있는 관계로, 외부 환경 변수릍 통해 사용자가 임의로 값을 변경할 수 있게 Enhancement가 이루어 졌다. 해당 환경변수명은 BBWAIT_TIME이며, 사용자가 1~10초사이의 임의의 값을 설정할 수 있다. 현재 설정되어 있는 5초는 순간적인 큐잉이 발생할 경우 너무 큰 시간이므로 순간적인 큐잉이 발생할 경우를 예상하는 최소 설정값인 1초로 설정를 변경해야 한다. Tuxedo BBL에 부하가 많이 주어지는 경우 BBWAIT_TIME의 환경변수와 TM_TKTSPIN_YLDCNT, TM_TKTSPIN_YLDCNT_NAPTIME 환경변수를 같이 설정하는 것이 바람직하다.
TM_TKTSPIN_YLDCNT	1000		Tuxedo BBL의 Spin lock에 대한 반복횟수를 설정한다. (BBWAIT_TIME 설정시 같이 설정해야 함)
TM_TKTSPIN_YLDCNT_NAPTIME	10000		Tuxedo BBL의 Spin lock 에 대한 Sleep time(microsecond)을 설정한다.(BBWAIT_TIME 설정시 같이 설정해야 함)
TM_PREVENT_DEADLOCK		1	내부 Behavior와 관련된 환경변수로 Long time service call을 Issue하기 전에 BB에 대한 Lock을 Release하도록 해당 옵션을 아래와 같이 환경파일에 설정한다. export TM_PREVENT_DEADLOCK=1
TUXWA4ORACLE	1		오라클 데이터베이스와 XA Connection을 맺고 있는 서버의 경우에 해당 데이터베이스로의 접속이 끊어진 경우, 즉 ORA - 3113 에러가 발생하는 경우에 자동으로 재접속을 하기 위해서는 TUXWA4ORACLE 환경 변수가 있어야 한다. "WorkAround For Oracle"이란 의미로 해당 환경 변수에 설정되어 값은 의미가 없고 단지 설정이 되어 있으면 동작한다. 따라서 설정은 아래와 같이 예) export TUXWA4ORACLE = 1 설정을 하면 된다. 재접속은 해당 서버가 오라클에 접근하여 3113 에러가 발생하는 순간에 이루어진다.
ULOGMILLISEC		Y	Tuxedo 9.0부터 ULOG에 time stamp가 1/1000초까지 로깅할 수 있는데, 환경변수 ULOGMILLISEC를 Y로 설정하면 된다. export ULOGMILLISEC=Y