리눅스 정기점검 스크립트.. 

다른 사람들은 어떻게 구성했는지 많은 소스 참고하면 좀 더 좋아지겠지..

chksystem.sh

리눅스 시스템을 운영하다 보면  시스템 Hang-up에 대한  문제점을 많이 들어나게 됩니다. 물론  리눅스 시스템
자체의 문제점이라고 보다는 특정 운영 프로세스에 대해서 인터럽트 또는 스케쥴이 정상적으로 진행되지 못했을때 나타는 문제점에 대해서 간략해 소개해 보고자 합니다.

갑자기 시스템  로그에서 출력하게된 /var/log/message 의 시스템 로그.

[예상 문제점 1]
시스템 로그에서 나타난  kernel:INFO: task 의 메세지를 나타내는 의미는 현재 운영하고자 하는 startup.sh
스크립트에 대해서  120초 (2분 default) 동안 khungtaskd  쓰레드에서 D-state 상태를 감지하여  call trace
를 호출하게 되는  상황으로 예측할 수 있습니다. 

[예상 문제점2]
시스템의 성능저하 특히 레드햇의 보고서에 의하면 디스크의 heavy I/O 로 나타나는 문제점으로
예측될수 있습니다.

[예상 문제점 2]
운영되고 있는 Application에 대해서 "D-state" (Uninterruptible sleep) 모드가 120초 동안 지속되었을때
예측될수 있는 문제로  해당 프로세스가 정상적으로 스케쥴링이 일어나지 않았을 때도 나타나게 됩니다

[ D-state 원인분석을 위해서는 ? ]
위와같은 문제점에 대해서 접근할수 있는 기본적인 방법에 대해서는  정확한 문제점을  파악하기 위해서는  커널의 덤프를 이용하여 core를 분석하는 것이 가장 정확할수 있습니다. core를 분석하기 위한 방법론에 대해서는 다음
블로깅을 통하여 소개하도록 하겠습니다.

위와 같이  kernel core를  생성하기 위해 설정을 진행한 후 동일한 현생이 발생되어 core가 생성이 되면 문제가
되는 운영 프로세스의 D-state 문점에 대해서 분석이 가능합니다.

[ hung_task_timeout을 Disable 시켜라]
기본적인 Work-Arround에 대해서는  아래와 같이 hung_task_timeout 부분에 대해서 Disable 시켜주는 것을 권장하고 있습니다.

위와 같이  커널에서 Hang Time OUt 을 체크하는 부분에 대해서 Disable 시켜준 후에는  call trace 여부가 지속적으로 발생되는지  모니터링이 필요합니다. 만약  해당 프로세스에 대해서  Uninterrupt sleep이 지속적으로 발생한다면 커널 업데이트 또한 고려해야 합니다.

일반적으로 레드햇 계열 (RedHat, CentOS, SUSE Linux)에서 패키지 관리에 사용되는 강력한 기능중에 YUM
기능은 패키지 의존성 (Dependency)를  고려해서 안전하게  패키지를 설치 구성이 가능한데 , 데비안 계열의
리눅스의 경우는 apt-get (Advanced Packaging Tool)이라고 하는 아주 쓸만한 놈이 있네요  다음과 같이 레드햇 계열의 리눅스에서 사용하고 있는 YUM과 비교해서 정리해 봅니다.

1. deb 패키지 정보에 대한 인덱스 저장소

apt-get은 패키지들에 대한 인덱스  정보를 기반으로  패키지 리스트를 가져오는데  yum의 repository와 유사한것으로 판단해도 무리는 없을듯 합니다.

경로는 : /etc/apt/sources.list

2. apt-get 을 이용한 패키지 설치 하기

이제 본격적으로  우분투에서 제공하는 apt-get을 이용한  패키지 설치는 진행해 봅니다. 아래와 같은 단계로 필요한 부분에 대해서 설치를 적절하게 진행 해보는 것도 도움이 됩니다.

2.1 패키지 설치와 업데이트

sudo apt-get install [패키지 명] : 설치하고자 하는 패키지를 검색하여 설치를 진행
sudo apt-get upgrade : 패지키들에 대한 업그레이드 진행
sudo apt-get update : 전체 패키지를 검색하여  업데이트 대상의 패키지들을 자동 업데이트
sudo apt-get dist-upgrade : 패키지 업그레이드시 우선 의존성을 검증한후 설치를 진행
sudo apt-get --reinstall [패키지명] :  재설치 하고자 하는 패키지를 설치

2.2 패키지 검색 및 삭제

sudo apt-cache search [Package Name] : 원하는 패키지를 검색하고자 할때 사용
sudo apt-get remove [Package Name] : 원하는 패키지를 삭제하고자 할때 사용
sudo apt-get source [Package Name] : 원하는 패키지의 소스 코드를 받고자 할때 사용
sudo apt-get build-dep [Package Name] : OnLIne에서 받은 패키지를 ㅏ현시스템의 의존성에 맞게 빌드
sudo apt-cache show [Package Name] : 원하는 패키지들에 대한 상세정보 볼수 있다.

apt-get 으로 설치된 모든 패키지 들은  아래의 경로에 따라 자동 저장이 됩니다. 나중에 설치된 우분투 패키지를
찾고자 할때  유용하게 확인할수 있습니다.

deb package path : /var/cache/apt/archive

음..오랬동안 레드햇 계열 리눅스만 써왔던터러 여러가지 스크립트며 설정파일에 대한 부분이 아직은 익숙하지는 않은데 뭐..별다를게 있겠습니까. 시간이 지나면 익숙해 지겠지요.정말 놀라운 것은 문서화가 잘되어 있다는 점도 일단은 마음에 들고 하나둘씩 중요한 것들 정리해 나가면 레드햇 계열처럼 익숙해 지겠죠 .. 

1. eth0에 대한 장치정의 

일단 우분투의 네트워크 인터페이스 스크립트 파일은 /etc/network/interfaces 파일을 

편집해야 하죠

위와 같이 설정한 후에 네트워크를 내렸다가 다시 올리는 방식으로 재기동 해주면 되는군요 

2. How to Set up Interfaces 

우분투 리눅스의 네트워크 인터페이스에 대한 정의에 대한 파일을 확인해볼 필요도 있을듯 합니다. 
스크립트 파일은 /usr/share/doc/ifupdown/examples 파일이 있으며 network-interfaces.gz 파일을 압축을 해제하면 아래와 같은 network interfaces에 대한 구성 예배파일이 나옵니다. 참고해 보시죠 

######################################################################

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

#

# A "#" character in the very first column makes the rest of the line

# be ignored. Blank lines are ignored. Lines may be indented freely.

# A "\" character at the very end of the line indicates the next line

# should be treated as a continuation of the current one.

#

# The "pre-up", "up", "down" and "post-down" options are valid for all

# interfaces, and may be specified multiple times. All other options

# may only be specified once.

#

# See the interfaces(5) manpage for information on what options are

# available.

######################################################################

# We always want the loopback interface.

#

# auto lo

# iface lo inet loopback

# An example ethernet card setup: (broadcast and gateway are optional)

#

# auto eth0

# iface eth0 inet static

#     address 192.168.0.42

#     network 192.168.0.0

#     netmask 255.255.255.0

#     broadcast 192.168.0.255

#     gateway 192.168.0.1

# A more complicated ethernet setup, with a less common netmask, and a downright

# weird broadcast address: (the "up" lines are executed verbatim when the

# interface is brought up, the "down" lines when it's brought down)

#

# auto eth0

# iface eth0 inet static

#     address 192.168.1.42

#     network 192.168.1.0

#     netmask 255.255.255.128

#     broadcast 192.168.1.0

#     up route add -net 192.168.1.128 netmask 255.255.255.128 gw 192.168.1.2

#     up route add default gw 192.168.1.200

#     down route del default gw 192.168.1.200

#     down route del -net 192.168.1.128 netmask 255.255.255.128 gw 192.168.1.2

# A more complicated ethernet setup with a single ethernet card with

# two interfaces.

# Note: This happens to work since ifconfig handles it that way, not because

# ifup/down handles the ':' any differently.

# Warning: There is a known bug if you do this, since the state will not

# be properly defined if you try to 'ifdown eth0' when both interfaces

# are up. The ifconfig program will not remove eth0 but it will be

# removed from the interfaces state so you will see it up until you execute:

# 'ifdown eth0:1 ; ifup eth0; ifdown eth0'

# BTW, this is "bug" #193679 (it's not really a bug, it's more of a

# limitation)

#

# auto eth0 eth0:1

# iface eth0 inet static

#     address 192.168.0.100

#     network 192.168.0.0

#     netmask 255.255.255.0

#     broadcast 192.168.0.255

#     gateway 192.168.0.1

# iface eth0:1 inet static

#     address 192.168.0.200

#     network 192.168.0.0

#     netmask 255.255.255.0

# "pre-up" and "post-down" commands are also available. In addition, the

# exit status of these commands are checked, and if any fail, configuration

# (or deconfiguration) is aborted. So:

#

# auto eth0

# iface eth0 inet dhcp

#     pre-up [ -f /etc/network/local-network-ok ]

#

# will allow you to only have eth0 brought up when the file

# /etc/network/local-network-ok exists.

# Two ethernet interfaces, one connected to a trusted LAN, the other to

# the untrusted Internet. If their MAC addresses get swapped (because an

# updated kernel uses a different order when probing for network cards,

# say), then they don't get brought up at all.

#

# auto eth0 eth1

# iface eth0 inet static

#     address 192.168.42.1

#     netmask 255.255.255.0

#     pre-up /path/to/check-mac-address.sh eth0 11:22:33:44:55:66

#     pre-up /usr/local/sbin/enable-masq

# iface eth1 inet dhcp

#     pre-up /path/to/check-mac-address.sh eth1 AA:BB:CC:DD:EE:FF

#     pre-up /usr/local/sbin/firewall

# Two ethernet interfaces, one connected to a trusted LAN, the other to

# the untrusted Internet, identified by MAC address rather than interface

# name:

#

# auto eth0 eth1

# mapping eth0 eth1

#     script /path/to/get-mac-address.sh

#     map 11:22:33:44:55:66 lan

#     map AA:BB:CC:DD:EE:FF internet

# iface lan inet static

#     address 192.168.42.1

#     netmask 255.255.255.0

#     pre-up /usr/local/sbin/enable-masq $IFACE

# iface internet inet dhcp

#     pre-up /usr/local/sbin/firewall $IFACE

# A PCMCIA interface for a laptop that is used in different locations:

# (note the lack of an "auto" line for any of these)

#

# mapping eth0

#    script /path/to/pcmcia-compat.sh

#    map home,*,*,*                  home

#    map work,*,*,00:11:22:33:44:55  work-wireless

#    map work,*,*,01:12:23:34:45:50  work-static

#

# iface home inet dhcp

# iface work-wireless bootp

# iface work-static static

#     address 10.15.43.23

#     netmask 255.255.255.0

#     gateway 10.15.43.1

#

# Note, this won't work unless you specifically change the file

# /etc/pcmcia/network to look more like:

#

#     if [ -r ./shared ] ; then . ./shared ; else . /etc/pcmcia/shared ; fi

#     get_info $DEVICE

#     case "$ACTION" in

#         'start')

#             /sbin/ifup $DEVICE

#             ;;

#         'stop')

#             /sbin/ifdown $DEVICE

#             ;;

#     esac

#     exit 0

# An alternate way of doing the same thing: (in this case identifying

# where the laptop is is done by configuring the interface as various

# options, and seeing if a computer that is known to be on each particular

# network will respond to pings. The various numbers here need to be chosen

# with a great deal of care.)

#

# mapping eth0

#    script /path/to/ping-places.sh

#    map 192.168.42.254/24 192.168.42.1 home

#    map 10.15.43.254/24 10.15.43.1 work-wireless

#    map 10.15.43.23/24 10.15.43.1 work-static

#

# iface home inet dhcp

# iface work-wireless bootp

# iface work-static static

#     address 10.15.43.23

#     netmask 255.255.255.0

#     gateway 10.15.43.1

#

# Note that the ping-places script requires the iproute package installed,

# and the same changes to /etc/pcmcia/network are required for this as for

# the previous example.

# Set up an interface to read all the traffic on the network. This

# configuration can be useful to setup Network Intrusion Detection

# sensors in 'stealth'-type configuration. This prevents the NIDS

# system to be a direct target in a hostile network since they have

# no IP address on the network. Notice, however, that there have been

# known bugs over time in sensors part of NIDS (for example see

# DSA-297 related to Snort) and remote buffer overflows might even be

# triggered by network packet processing.

#

# auto eth0

# iface eth0 inet manual

# up ifconfig $IFACE 0.0.0.0 up

#       up ip link set $IFACE promisc on

#       down ip link set $IFACE promisc off

#       down ifconfig $IFACE down

# Set up an interface which will not be allocated an IP address by

# ifupdown but will be configured through external programs. This

# can be useful to setup interfaces configured through other programs,

# like, for example, PPPOE scripts.

#

# auto eth0

# iface eth0 inet manual

#       up ifconfig $IFACE 0.0.0.0 up

#       up /usr/local/bin/myconfigscript

#       down ifconfig $IFACE down

3. 온라인 패키지 검색

일반적으로 레드햇 계열의 리눅스 운영체제에서는 yum search 기능을 많이 쓰고는 했는데 데비안
계열인 우분투에서는 다음과 같은 명령어를 날리면 아름답게 deb 패키지를 검색해 오네요.우분투 
업무 시스템을 운영하는 운영자 입장에서는 아~~~~주 유용할듯..

요즘들어  금융권에 대한  성능 튜닝 이슈가 많이 요구되는 듯 하여 정리해서 올려봅니다. 

물론 운영되는 어플리케이션에 대한 특성과 환경에 고려되어야 하겠지만 일반적으로 금융

Low-latency 환경을 요구하는 시스템의 경우에는  Shared memory 또는  세마포어 

값을 민감하게 건들어야 하는 시스템의 경우는 아래와 같이 사용하기 합니다.

[수정후]
title Red Hat Enterprise Linux Server LL (2.6.32-220.4.2.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-220.4.2.el6.x86_64 ro root=UUID=dd05c407-d62c-40b1-800e-ddff20d33062 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM nohpet intel_idle.max_cstate=0 processor.max_cstate=1 cgroup_disable=memory mce=ignore_ce transparent_hugepage=never nmi_watchdog=1 elevator=deadline idle=mwait nohz=off
        initrd /initramfs-2.6.32-220.4.2.el6.x86_64.img

[수정내용]
기존 kernel 구문에
intel_idle.max_cstate=0 processor.max_cstate=1 cgroup_disable=memory mce=ignore_ce transparent_hugepage=never nmi_watchdog=1 elevator=deadline idle=mwait nohz=off
추가

[각 항목에 대한 설명]
* intel_idle.max_cstate=0 : Processor C-Status 기능 사용한함.
* processor.max_cstate=1 : 프로세서 절전 상태로 진입하지 않게 함.
* cgroup_disable=memory : 자원의 QoS를 제공하는 cgroup기능 사용안함.
* mce=ignore_ce : HW의 corrected error scan으로 인한 latency spike 무시.
* transparent_hugepage=never : hugepage 사용하지 않음
* nmi_watchdog=1 : kdump를 사용설정
* elevator=deadline : cfq가 기본값인 I/O 스케쥴러를 deadline으로 변경
* idle=mwait : CPU idle시 대기처리를 조금만 수행하도록 함
* nohz=off : CPU의 c-status 진입방지

2. 기존 sysctl.conf의 추가 및 변경 사항

#### Kdump 사용 설정
net.ipv4.conf.lo.force_igmp_version = 2
net.ipv4.conf.eth0.force_igmp_version = 2
net.ipv4.conf.eth1.force_igmp_version = 2
net.ipv4.conf.eth4.force_igmp_version = 2
kernel.unknown_nmi_panic = 1
kernel.panic_on_unrecovered_nmi = 1
kernel.panic_on_io_nmi = 1

#### 각 네트워크의 multicast 트래픽에 대한 filtering을 off
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth4.rp_filter = 0

#### 10G NIC tuning (SolarFlare에 문의해서 low latency에 적합한 튜닝값을 적용)
net.ipv4.neigh.default.unres_qlen = 100
net.ipv4.neigh.lo.unres_qlen = 100
net.ipv4.neigh.eth0.unres_qlen = 100
net.ipv4.neigh.eth1.unres_qlen = 100
net.ipv4.neigh.eth4.unres_qlen = 100
net.ipv4.tcp_low_latency = 1
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_mem = 16777216 16777216 16777216 
net.ipv4.tcp_rmem = 4096 8388608 16777216 
net.ipv4.tcp_wmem = 4096 8388608 16777216 
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_default = 8388608
net.core.wmem_max = 16777216

### LAN에서의 arp 요청에 대한 응답을 하지 않게 설정하여 network latency를 줄여줌
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth1.arp_ignore = 1
net.ipv4.conf.eth4.arp_ignore = 1

### 세마포어 최적값 수정
kernel.shmmni = 4096
kernel.sem = 2000 32000 512 5029

### swap 사용비율 설정
vm.swappiness = 10

### 스케쥴러 nr 수정
kernel.sched_nr_migrate = 12

net.core.netdev_max_backlog = 20000
net.core.optmem_max = 25165824
#net.core.optmem_max = 20480

3. tuned를 사용한 Low Latency 프로파일 적용
OS를 사용되는 용도에 맞게 사전 tuning된 프로파일을 제공하는 tuned를 이용해서 
레드햇에서 권고하는 시스템 전반적인 tuning을 할 수 있으며 아래와 같이 tuned를 이용해서 적용.

# tuned-adm profile latency-performance

4. 파일시스템 Tuning
[수정내역]
/etc/fstab의 각 마운트 구문중 defaults 뒤에 noatime,nodiratime,nobarrier 옵션 추가

[각 옵션 설명]
* noatime : filesystem meta정보에 file의 access time 기록하지 않음
* nodiratime : filesystem meta정보에 Directory의 access time 기록하지 않음
* nobarrier : fsync기능을 사용하지 않도록 설정.
 
5. 서비스 실행 사용자 계정 File open 수 제한 설정
[수정내역]
/etc/limit.conf 파일에
사용자명              -       nofile          4096
# 서비스 실행 사용자의 File Open 수를 4096으로 증

리눅스 3.7 커널 릴리즈: TCP Fast Open, vxLan 지원

리눅스 운영체제에서 재부팅 없이 SCSI 디스크를 인식 시키기 위해서는 아래와 같은 절차를 통해서

진행한다. 운영하고 있는 시스템을 재부팅 하면서 까지 그럴필요는 없쥐.. 암암.. 

It is possible to add or remove a SCSI device explicitly, or to re-scan an entire SCSI bus without rebooting a running system. Please see the Online Storage Reconfiguration Guide for a complete overview of this topic on Red Hat Enterprise Linux 5.

For Red Hat Enterprise Linux 5

With fibre attached storage, it is possible to issue a LIP (loop initialization primitive) on the fabric:

echo "1" > /sys/class/fc_host/host#/issue_lip

Issuing a LIP (above) on Red Hat Enterprise Linux 5 is all that is needed to rescan fibre

attached storage. Once the LIP is issued, the bus scan may take a few seconds to complete.

Although present on previous releases, this feature is only fully supported in Red Hat Enterprise Linux 5.

For Red Hat Enterprise Linux 4 and 5

With other SCSI attached storage, a rescan can be issued:

echo "- - -" > /sys/class/scsi_host/host#/scan

Replace the # with the number of the SCSI bus to be rescanned.

In addition to re-scanning the entire bus, a specific device can be added or deleted for some

versions or Red Hat Enterprise Linux as specified below.

For Red Hat Enterprise Linux 4 or 5

To remove a single existing device explicitly

# echo 1 > /sys/block//device/delete

For Red Hat Enterprise Linux 3, 4, or 5

To add a single device explicitly:

# echo "scsi add-single-device " > /proc/scsi/scsi

To remove a device explicitly:

# echo "scsi remove-single-device " > /proc/scsi/scsi

Where are the host, bus, target, and LUN numbers for the device,as reported in /sys (2.6 kernels only) or /proc/scsi/scsi or dmesg.

These numbers are sometimes refered to as "Host", "Channel", "Id", and "Lun" in Linux tool output and documentation.

리눅스 시스템에서 FC를 이용한 스토리지 볼륨을 사용할 경우 전반적인 SCSI 정보를 Gathering

할필요가 있다. WWPN 이라든지, HBA 카드 정보라든지, SCSI 연결 정보에 대한 전체적인 

정보를  어떻게 가져오는지 다음과 같이 진행해 보자.. 

1. SYSFS를 통한 WWPN 검색 

/sys/class/scsi_host/host1/state 를  아래와 같이 검색했을 경우  각 Host 별로 FC Link  

현황에 대한 상태 정보를 확인할수 있다. 

2. SYSTOOL 를 통한 WWPN 검색 

SYSTOOL은 RedHat Enterprise Linux 계열의 운영체제에서만 사용할수 있는 Tool 이다. 

SYSTOOL을 사용하기 위해서는 아래와 같이 설치 절차를 진행한다. 

[root@/]yum -y install sysutils --> SysTool Packag에 systool 명령어가

포함되어 있다. 

Original Source : https://access.redhat.com/knowledge/solutions/9936

일반적인 Enterprise System에서는 System Hang-up을 방지하기 위한 NMI 스위치를 제공하기는하나
x86_64 시스템의 경우 NMI 신호처리를 운영체제에서 해주는 것이 일반적인다. 특히 리눅스의 경우
커널 파라메터에서 NMI 옵션을 적용함으로 인해서 System Hangup을 미연해 방지해주는 경우도 있다.

- Check Point 1 - 

레드햇이나, 수세 리눅스 처럼 엔터프라이즈 환경에 운영되어야 하는 리눅스의 경우 NMI의 옵션이
기본적으로 Enable 되어 있다. 이 사실을 모르는 상태에서 H/W에서 NMI 신호를 받았을때 시스템이
재부팅 되었을 경우 당황해 하는 경우가 있다. 아래의 Virtual File system에서 NMI 신호에 대한 옵션을 확인해 보자. 

cat /proc/sys/kernel/nmi_watchdog 

1

위의 경우 처럼 /proc/sys/kernel/nmi_watchdog을 쿼리했을때 옵션 값이 1 로 나올경우 커널옵션과 
상관없이 NMI 리눅스 상에서 동작하게 된다.  

- Check Point 2 - 

# grep NMI /proc/interrupts 
NMI:    0    0    0    0

title Red Hat Enterprise Linux Server (2.6.18-128.el5) 
        root (hd0,0) 
        kernel /vmlinuz-2.6.18-128.el5 ro root=/dev/sda nmi_watchdog=1 
        initrd /initrd-2.6.18-128.el5.img 

# grep NMI /proc/interrupts 
NMI:    2123797    2123681    2123608    2123535 
# grep NMI /proc/interrupts 
NMI:    2124855    2124739    2124666    2124593 
# grep NMI /proc/interrupts 
NMI:    2125981    2125865    2125792    2125719 
# grep NMI /proc/interrupts 
NMI:    2126692    2126576    2126503    2126430 
# grep NMI /proc/interrupts 
NMI:    2127406    2127290    2127217    2127144 

grep NMI /proc/interrupts

NMI:       187       107        293       199
grep NMI /proc/interrupts
NMI:       187       107        293       199
grep NMI /proc/interrupts
NMI:       187       107        293       200

x86 시스템을 운영하면서 과도한 네트워크 부하가 발생하게 되면 해당 서비스를 진행하는 이더넷
인터페이스 에서는  Packet Overrun이 발생될수 있다. 패킷 Overrun 이 발생되면, incomming/Outgoing 되는 패킷들의 Frame Loss 가 발생되기 때문에 여러모로 모니터링이 필요한 
항목이기도 하다.

1. 패킷 Overrrun의 원인 

지금까지 프레임 손실 (Frame Loss) 에 대한 가장 일반적인 이유는 큐 오버런입니다.커널은 큐의 길이에 제한을 설정하고 있기 때문에 때로는 대기열의  배수보다 더 빨리 채워집니다. 이 현상이 오래 지속이 되면 Frame Loss 가 발생되는 것입니다. 

[root@/ ~]# ip -s -s link ls p4p2

11: p4p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP qlen 1000

    link/ether 00:10:18:ce:0c:0e brd ff:ff:ff:ff:ff:ff

    RX: bytes  packets  errors  dropped overrun mcast

    3405890854 1534610082 146442  0       146442  13189

    RX errors: length  crc     frame   fifo    missed

               0        0       0       0       0

    TX: bytes  packets  errors  dropped carrier collsns

    3957714091 1198049468 0       0       0       0

    TX errors: aborted fifo    window  heartbeat

               0        0       0       0

2. Network Recive Path Diagram 

네트워크의 패킷을 받아들이는데 경로 다이아그램 (Path Diagram)을 이해한다면 장애처리시 물리적인 장치에 대한 Trouble Shooting 이나 운영체제 대한 트러블 슈팅에 대한 판단을 쉽게 진행할수 있다. 

리눅스 커널은  패킷을 받아들이는데 위의 그림과 같이 기본적으로 4가지 경로를 거치게 된다. 

1. Hardware Reception: the network interface card (NIC) receives the frame on the wire. Depending on its driver configuration, the NIC transfers the frame either to an internal hardware buffer memory or to a specified ring buffer.
   
   

2. Hard IRQ: the NIC asserts the presence of a net frame by interrupting the CPU. This causes the NIC driver to acknowledge the interrupt and schedule the soft IRQ operation.
   
   

3. Soft IRQ: this stage implements the actual frame-receiving process, and is run insoftirq context. This means that the stage pre-empts all applications running on the specified CPU, but still allows hard IRQs to be asserted.

   In this context (running on the same CPU as hard IRQ, thereby minimizing locking overhead), the kernel actually removes the frame from the NIC hardware buffers and processes it through the network stack. From there, the frame is either forwarded, discarded, or passed to a target listening socket.

   When passed to a socket, the frame is appended to the application that owns the socket. This process is done iteratively until the NIC hardware buffer runs out of frames, or until the device weight ( dev_weight). For more information about device weight, refer to Section 8.4.1, “NIC Hardware Buffer”
   
   

4. Application receive: the application receives the frame and dequeues it from any owned sockets via the standard POSIX calls ( read, recv, recvfrom). At this point, data received over the network no longer exists on the network stack

    5. CPU Affinity 

    To maintain high throughput on the receive path, it is recommended that you keep

the L2 cache hot. As described earlier, network buffers are received on the same CPU as the IRQ that signaled their presence. This means that buffer data will be on the L2 cache of that receiving CPU.

출처) https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-network-packet-reception.html#packet-reception-png

3 운영체제 입장에서의 Work Arround 

Queu Overrun이 발생되면  H/W의 Buffer 상태를 check하여 Frame Loss 패킷의 증가가 있는지 확인. 

[root@linux] ethtool -S etho | grep frame 

rx_frame_error = 0 

만약 위의 항목중  rx_frame_error  발생하게 된다면 아래와 같이 진행한다. 

    eth0     Link encap:Ethernet  HWaddr D4:AE:52:34:E6:2E  
             UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1

         >>  RX packets:1419121922 [errors:71111] dropped:0 [overruns:71111] frame:0  <<

             TX packets:1515463943 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:1000 
             RX bytes:864269160026 (804.9 GiB)  TX bytes:1319266440662 (1.1 TiB)
             Interrupt:234 Memory:f4800000-f4ffffff

# ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096
Current hardware settings:
RX:     256
RX Mini:    0
RX Jumbo:   0
TX:     256

# ethtool -G eth0 rx 4096 tx 4096

# ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096
Current hardware settings:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096

# Improving the max buffer size TCP for 16MB
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# Improving the limit of autotuning TCP buffer for 16MB
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# Max Number of packages that are queued when the
# interface receive the packages faster than the kernel
# can support
net.core.netdev_max_backlog = 250000

# sysctl -a | grep -i congestion_control
net.ipv4.tcp_congestion_control = bic

net.ipv4.tcp_congestion_control=htcp

    overrun:  Shows the number of times that the receiver hardware was incapable of
handing received data to a hardware buffer because the input rate exceeded
the receiver's capability to handle the data.