와스킹의 사건현장

출처 : https://mkil.tistory.com/m/482

TCPDUMP 란
tcpdump는 주어진 조건식을 만족하는 네트워크 인터페이스를 거치는 패킷들의 헤더들을 출력

TCPDUMP 사용법
원하는 조건의 명령어를 입력으로 네트워크 패킷 로그를 출력하여 본다.

TCPDUMP 분석 프로그램
tcpdump로 패킷 캡춰한 내용을 파일로 저장한 다음 wireshark로 읽어서 분석

TCPDUMP 명령어 예시
# tcpdump -i eth0
> 인터페이스 eth0 을 보여줌
# tcpdump -w tcpdump.log
> 결과를 파일로 저장, binary 형식으로 저장됨
# tcpdump -r tcpdump.log
> 저장한 파일을 읽음
# tcpdump -i eth0 tcp port 80
> tcp 80 포트로 통신하는 패킷 보여줌
# tcpdump -i eth0 src 192.168.0.1
> source ip 가 192.168.0.1인 패킷 보여줌
# tcpdump -i eth0 dst 192.168.0.1
> destination ip 가 192.168.0.1인 패킷 보여줌

* and 옵션으로 여러가지 조건의 조합 가능
# tcpdump -w tcpdump.log -i eth0 dst 192.168.0.1 and udp and port 514
> 목적이 ip가 192.168.0.1인 곳으로 514포트를 사용하는 udp 패킷을 tcpdump.log 파일에 저장

# tcpdump host 192.168.0.1
> host 를 지정하면, 이 ip 로 들어오거가 나가는 양방향 패킷 모두 보여줌
# tcpdump src 192.168.0.1
> host 중에서 src 가 192.168.0.1인것 만 지정
# tcpdump dst 192.168.0.1
> host 중에서 dst 가 192.168.0.1인것 만 지정
# tcpdump net 192.168.0.1/24
> CIDR 포맷으로 지정할 수 있다.
# tcpdump tcp
> TCP 인것만
# tcpdump udp
> UDP 인것만
# tcpdump port 3389
> 포트 양뱡항으로 3389인 것.
# tcpdump src port 3389
> src 포트가 3389인 것.
# tcpdump dst port 3389
> dst 포트가 3389인 것.

* combine : and ( && ) , or ( || ) , not ( ! ) 으로 여러가지를 조합해서 사용 가능
# tcpdump src 192.168.10.1 and not dst port 22
> src ip 가 192.168.10.1 이고 dst 포트가 22 가 아닌 것

* grouping : ( )
# tcpdump ‘src19.18.0.1 and ( dst port 3389 or 22 )’
> src ip 가 19.18.0.1 이고 ( dst 포트가 3389 또는 22 ) 인 것
※ 여기서는 ‘ ‘ 가 반드시 있어야 한다.

원격 리눅스 서버에 암호 입력 없이 로그인 하는 방법

3단계 절차를 진행하면 됨

1. ssh-keygen 로 공용과 개인 키들을 생성
출발지접속계정으로 실행
    #> ssh-keygen -t rsa
      — 위 명령어 실행 후 갑 입력에 빈값 엔터
dd@local-host$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/dd/.ssh/id_rsa):[엔터키]
Enter passphrase (empty for no passphrase): [엔터키]
Enter same passphrase again: [엔터키]
Your identification has been saved in /home/dd/.ssh/id_rsa.
Your public key has been saved in /home/dd/.ssh/id_rsa.pub.
The key fingerprint is:
33:b3:fe:af:95:95:18:11:31:d5:de:96:2f:f2:35:f9 dd@localhost
    실행 완료 후 생성된 파일 확인
       생성 파일일 총 두개 ( ~/.ssh/id_rsa, id_rsa.pub )

2. 로컬호스트의 공용 키를 원격 호스트의 authorized_keys 파일에 복사
도착지접속계정의 홈
    ~/.ssh/authorized_keys
도착지접속계정 경로에 .ssh 디렉토리 없으면 생성
  키 파일 등록
#> cat id_rsa.pub >>  ~/.ssh/authorized_keys

3. 알맞은 권한을 원격 호스트의 홈, ~/.ssh, ~/.ssh/authorized_keys에 부여
도착지접속계정 경로에 퍼미션 부여
   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys

■ sftp 접속확인
#> sftp -P ssh포트번호 도착지접속계정@서버IP

■ 현상
was의 어플리케이션에서 아래와 같은 로그 발생
OutOfMemoryError : unable to create new native thread

■ 원인
/etc/security/limit.conf 에서 nproc의 값(4096)으로 인해 프로세스 생성 제한이 되어버림.
조치 후 was계정에서 생성한 프로세스의 개수(4961)

■ 조치사항
/etc/security/limit.conf 에서 was계정에 대해 아래와 같이 설정

testuser soft nofile 65535
testuser hard nofile 65535
testuser soft nproc 65535
testuser hard nproc 65535

□ ulimit과 /etc/security/limit.conf 에 대한 설명
리눅스는 /etc/security/limit.conf 파일을 통해 서버의 리소스를 관리함

ulimit는 프로세스의 자원 한도를 설정 및 확인하는 명령(limit.conf)에서 읽어온다. soft / hard 두가지 제한으로 나뉨

soft : 새로운 프로그램을 생성하면 기본으로 적용되는 한도
hard : 최대로 늘릴 수 있는 한도

# ulimit -a // Soft 설정 보기
# ulimit -aH // Hard 설정 보기

통상적으로 soft와 hard를 1:1로 맞추어 설정

limit.conf의 내용은 주로 아래와 같이 구성

testuser soft nofile 65535
testuser hard nofile 65535
testuser soft nproc 65535
testuser hard nproc 65535

nproc (number of processes) : 프로세스 최대 개수
nofile (number of open files) : 파일 열기 최대 개수

리눅스에서는 모든 개체를 파일로 보기에 nproc를 높이면 nofile도 같이 높여주는 것이 맞다.

● 계정당 생성한 프로세스 개수
# ps h -Led -o user | sort | uniq -c | sort -n
● 계정의 오픈한 파일 개수
# lsof -u [username] | wc -l
# sysctl -a |grep file-nr

■ 현상
파일 인코딩 값이 파일과 맞지 않을때

■ 원인
파일 업로드 시 계정에 따라 인코딩 값이 결정되어 파일의 인코딩값이 맞지 않아 변경이 필요

■ 조치사항
1) vi로 파일을 열고 나서
:set fileencoding=[인코딩값](utf8)
:w

2) 명령어로 바꾸기
iconv -f euc-kr -t utf-8 euc-kr.html --output utf8.html

1. nfs서버에서 /etc/exports 수정
파일시스템이름  마운트대상(권한)
/batch                     server1(rw,no_root_squash)

2. exports 동기화
$ exportfs -r
$ exportfs -v

3. 대상서버에서 마운트
$ mount -t nfs server1:/batch /batch_server1

출처 : https://brunch.co.kr/@dreaminz/2

출처 : https://waspro.tistory.com/106

1. HP-UX

$ glance

> glance Command 창에서 s를 누른 후 CPU를 점유중인 pid를 입력
> Process 정보창에서G(shift+g)를 누른 후 Thread 별로 CPU 사용량 확인가능(space로 다음페이지 확인 가능)
> Thread 정보의 TID와 Thread Dump의 lwpid와 맵핑해서 확인 할 수 있다.

2. Linux

$ top -h

> 여기서 pid는 Thread ID
> Thread Dump의 nid와 Pid 값을 16진수로 변환해 일치하는 값을 확인

출처 : b.luavis.kr/server/linux-performance-analysis

1. uptime

$ uptime
 23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02

uptime은 현재 대기중인 프로세스가 얼마나 있는지를 나타내는 load average값을 확인하는 가장 쉬운 방법이다. 리눅스 시스템에서 이 값은 대기 중인 프로세스뿐만 아니라 disk I/O와 같은 I/O작업으로 block된 프로세스까지 포함되어 있다. 이를 통해서 얼마나 많은 리소스가 사용되고 있는지 확인할수 있지만, 정확하게 이해할 수는 없다.
위에 있는 3개의 숫자는 각각 1분, 5분, 15분에 load average 값이다. 이를 통해서 시간의 변화를 알 수 있는데, 예를들어서 장애가 발생했다는 소식을 듣고 해당 instance에 로그인 했을때 1분 동안의 값이 15분 값에 비해서 작다면 이는 장애가 발생하고선 내가 너무 뒤늦게 로그인했음을 알 수 있다. 위 예제에서는 1분 값이 약 30이고 15분 값이 19정도 되는것으로 볼때 최근에 상승한것을 알 수 있다. 여기서 숫자가 이 만큼 높은 것은 많은 의미를 갖고 있다. 

2. dmesg | tail

$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0 [...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.

dmesg는 시스템 메세지를 확인할 수 있는 커맨드이다. 부팅시부터 시작해서 모든 커널메세지가 출력되기 때문에 tail을 이용해서 마지막 10줄만 출력한것이다. 이 메세지를 통해서 성능에 문제를 줄 수 있는 에러를 찾을 수 있는데 위의 예제에서는 oom-killer(out of memory)와 TCP request가 드랍된것을 알 수 있다.

3. vmstat 1

$ vmstat 1
procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0
32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0
32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0 

virtual memory stat의 약자인 vmstat은 왠만한 환경에서 사용 가능한 툴이다. 1을 인자로 준 vmstat은 1초마다 정보를 보여준다. 첫번째 라인은 부팅된 뒤에 평균적인 값을 나타낸다.
 
확인해봐야할 항목

• r: CPU에서 동작중인 프로세스의 숫자입니다. CPU 자원이 포화(saturation)가 발생하는지 확인. r 값이 CPU의 값보다 큰 경우에 포화되어 있다고 해석
• free: free memory를 kb단위로 나타냅니다. free memory가 너무 자리수가 많은 경우 free -m를 이용하면 조금더 편하게 확인할 수 있다.
• si, so: swap-in과 swap-out에 대한 값입니다. 0이 아니라면 현재 시스템에 메모리가 부족한것이다.
• us, sy, id, wa, st: 모든 CPU의 평균적인 CPU time을 측정할 수 있다. 각각 user time, 커널에서 사용되는 system time, idle, wait I/O 그리고 stolen time순이다(stolen time은 hypervisor가 가상 CPU를 서비스 하는 동안 실제 CPU를 차지한 시간을 이야기한다.).

4. mpstat -p ALL 1

$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99
07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03

이 커멘드는 CPU time을 CPU 별로 측정할 수 있다. 이 방법을 통하면 각 CPU별로 불균형한 상태를 확인할 수 있는데, 한 CPU만 일하고 있는것은 application이 single thread로 동작한다는 이야기다.

5. pidstat 1

$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java
07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat
07:41:03 PM UID PID %usr %system %guest %CPU CPU Command
07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave
07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java
07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java
07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass
07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat

pidstat은 process당 top명령을 수행하는것과 비슷하다. 다만 차이점은 스크린 전체에 표시하는것이 아니라 지속적으로 변화하는 상황을 띄워주기 떄문에 상황변화를 기록하기 좋다.
위 예제를 보면 두개의 java process의 CPU 사용량이 엄청나다. %CPU 항목은 모든 CPU의 전체 사용량을 이야기한다. 따라서 1591%를 사용중인 java process들은 16CPU 가까이 사용중임을 나타내는것이다.

6. iostat -xz 1

$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
             73.96 0.00 3.73 0.03 0.06 22.21
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda    0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09
xvdb    0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25
xvdc    0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26
dm-0   0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04
dm-1   0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00
dm-2   0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03

block device(HDD, SSD, …)가 어떻게 동작하는지 이해하기 좋은 툴이다.
 
확인해봐야할 항목

• r/s, w/s rkB/s, wkB/s: read 요청과 write 요청, read kB/s, write kB/s를 나타낸다. 어떤 요청이 가장 많이 들어오는지 확인해볼 수 있는 중요한 지표다. 성능 문제는 생각보다 과도한 요청때문에 발생하는 경우도 있기 때문이다.
• await: I/O처리 평균 시간을 밀리초로 표현한 값이다. application한테는 I/O요청을 queue하고 서비스를 받는데 걸리는 시간이기 때문에 application이 이 시간동안 대기하게 된다. 일반적인 장치의 요청 처리 시간보다 긴 경우에는 블럭장치 자체의 문제가 있거나 장치가 포화된 상태임을 알 수 있다.

7. free -m

$ free -m
            total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541 -/+ buffers/cache: 23944 222053
Swap: 0 0 0

확인해봐야할 항목

• buffers: Block 장치 I/O의 buffer 캐시, 사용량
• cached: 파일 시스템에서 사용되는 page cache의 양

버퍼와 캐시 값들이 0에 가까워 지면 안된다. 이는 곧 높은 Disk I/O가 발생하고 있음을 의미한다(iostat으로 확인 가능). 위 예제는 버퍼와 캐시가 각각 59MB, 541MB로 괜찮은 정도에 속한다.
““-/+ buffers/cache”는 사용중인 메모리와 여유 메모리의 양을 나타낸다. 리눅스는 빠르게 다시 애플리케이션에 메모리가 할당될 수 있도록 캐시메모리를 사용한다. 따라서 캐시 메모리도 여유 메모리에 포함되어 보여야한다. 

8. sar -n DEV 1

$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00
12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00
12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

이 툴을 사용하면 network throughput(Rx, Tx KB/s)을 측정할수 있다. 위 예제에서는 eth0의 수신량이 약 22Mbytes/s(21999.10rxkB/s)이다. 이는 176Mbits/s인데 한계인 1Gbit/s에 아직 많이 못 미치는 값이다.
위 값중 %ifutil은 nicstat로도 측정 가능한 네트워크 장치 사용률이다. 하지만 nicstat에서도 그렇듯 정확한 값을 가져오는게 어려워서 위 예제에서도 잘 작동하지 않는다.

9. sar -n TCP,ETCP 1

$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00
12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00
12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00
12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00

이 값은 TCP 통신량을 요약해서 보여준다.

• active/s: 로컬에서부터 요청한 초당 TCP 커넥션 수를 보여준다 (예를들어, connect()를 통한 연결).
• passive/s: 원격으로부터 요청된 초당 TCP 커넥션 수를 보여준다 (예를들어, accept()를 통한 연결).
• retrans/s: 초당 TCP 재연결 수를 보여준다.

active와 passive 수를 보는것은 서버의 부하를 대략적으로 측정하는데에 편리하다. 위 설명을 보면 active를 outbound passive를 inbound 연결로 판단할 수 있는데, 꼭 그렇지만은 않다. (예를들면 localhost에서 localhost로 연결같은 connection)
retransmits은 네트워크나 서버의 이슈가 있음을 이야기한다. 신뢰성이 떨어지는 네트워크 환경이나(공용인터넷), 서버가 처리할 수 있는 용량 이상의 커넥션이 붙어서 패킷이 드랍되는것을 이야기한다. 위 예제에서는 초당 하나의 TCP 서버가 들어오는것을 알 수 있다.

10. top

$ top
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem
  PID USER    PR NI   VIRT    RES   SHR S %CPU %MEM     TIME+ COMMAND
20248 root     20 0  0.227t 0.012t 18748 S 3090  5.2  29812:58 java
 4213 root     20 0 2722544  64640 44232 S 23.5  0.0 233:35.37 mesos-slave
66128 titancl+ 20 0   24344   2332  1172 R  1.0  0.0   0:00.07 top
 5235 root     20 0 38.227g 547004 49996 S  0.7  0.2   2:02.74 java
 4299 root     20 0 20.015g 2.682g 16836 S  0.3  1.1  33:14.42 java

top 명령어는 위에서 체크해본 다양한 측정치를 쉽게 체크할 수 있다. 시스템 전반적으로 값을 확인하기 쉽다는 장점이 있다. 화면이 지속적으로 바뀌는 점 떄문에 패턴을 찾는것이 어렵다. 일시적으로 멈추는 현상을 잡기 위해서도 화면을 주기적으로 빠르게 멈춰주지 않으면 찾기 힘들다(Ctrl+S는 업데이트를 중지시키고, Ctrl+Q는 다시 시작시킨다), 그리고 화면이 지워져버린다.

Unix / Linux 에서 표준 입력, 표준 출력, 표준 에러에 대한 파일 디스크립터는 다음과 같은 정수로 할당되어 있다.


표준 입력 = 0

표준 출력 = 1

표준 에러 = 2


따라서 표준 출력과 표준 에러를 한 파일로 리다이렉션 하려면 다음과 같이 하여야 한다.


# 명령어 > 표준 출력 리다이렉션  2>&1

 EX) cat test.txt > result.log 2>&1


최초 > 를 통해 리다이렉션 방향은 정해졌으며 표준 출력은 result.log에 저장된다.

그 뒤의 파일 디스크립터 2(표준 에러)는 1(표준 출력)으로 리다이렉션 되기 때문에,

쉽게 말하면 "2"를 "&1"로 보내라는 뜻 

result.log에 표준 에러와 표준 출력이 한 파일에 저장되게 된다.