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 ( readrecvrecvfrom). 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.

To take advantage of this, place process affinity on applications expected to receive the most data on the NIC that shares the same core as the L2 cache. This will maximize the chances of a cache hit, and thereby improve performance.


출처) 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  발생하게 된다면 아래와 같이 진행한다. 



Replace ethX with the NIC's corresponding device name. This will display how many frames have been dropped within ethX. Often, a drop occurs because the queue runs out of buffer space in which to store frames.

There are different ways to address this problem, namely:
Input traffic

You can help prevent queue overruns by slowing down input traffic. This can be achieved by filtering, reducing the number of joined multicast groups, lowering broadcast traffic, and the like.
Queue length

Alternatively, you can also increase the queue length. This involves increasing the number of buffers in a specified queue to whatever maximum the driver will allow. To do so, edit the rxtx ring parameters of ethX using:
ethtool --set-ring ethX

Append the appropriate rx or tx values to the aforementioned command. For more information, refer to man ethtool.
Device weight

You can also increase the rate at which a queue is drained. To do this, adjust the NIC's device weight accordingly. This attribute refers to the maximum number of frames that the NIC can receive before the softirq context has to yield the CPU and reschedule itself. It is controlled by the 
/proc/sys/net/core/dev_weight variable.
Most administrators have a tendency to choose the third option. However, keep in mind that there are consequences for doing so. Increasing the number of frames that can be received from a NIC in one iteration implies extra CPU cycles, during which no applications can be scheduled on that CPU.

참고문서 
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-network-common-queue-issues.html

Issue

  • A NIC shows a number of overruns in ifconfig output as example below:
    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

Environment

  • Red Hat Enterprise Linux

Resolution

It is not a problem related with OS. So, this kind of problem is related with infra-structure of a environment, in other words, the network used here seems not support the traffic demand that is necessary.

Workaround

We can use the following steps to try fix this kind of issue.

1 - First of all, we are going to set the network device to work with Jumbo Frame, in other words, improve the MTU size (size of fragmentation packages) that are running in this device.

1.1 - Edit the /etc/sysconfig/network-scripts/ifcfg-ethX file and insert the following parameter: MTU=9000

With the parameter above, the interface and alias will set the value for MTU.

Now, for that settings are applied.

2 - Let's change the Ring Buffer for the highest supported value:

2.1 - Check the values that are set (Current hardware settings:) and What the max value acceptable (Pre-set maximums:) as the example below:

# 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

Above, through the command # ethtool -G eth0 rx 4096 tx 4096 we set the Ring Buffer for the max size supported on my device.

This command line have to be inserted in /etc/rc.local for that can be persistent in case of reboots, because, there are no ways to set this parameter in own device.

3 - By default, some parameters of "auto-tuning" are not set in Linux and, the default size of TCP buffer is very small initially. For 10Gb devices, generaly set the Buffer value to 16Mb is a recommended value. Values above this are only for devices with the capacity greater than 10Gb.

3.1 - Edit the /etc/sysctl.conf file and add the following lines at the end of file:

# 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

Save file and exit.

3.2 - Check what is the collision control algorithm used in yout environment: # sysctl -a | grep -i congestion_control

By default, RHEL uses 'bic' algorithm

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

For this kind of cases of NICs with high speed, is recommended use algorithms as the 'cubic' ou 'htcp'. For some versions of RHEL 5.3 - 5.5 (Kernel 2.6.18) there is a bug that is being fixed with the 'cubic'. So, is recommended use initially the 'htcp' algorithm and check the performance.

At /etc/sysctl.conf file, add the following parameter:

net.ipv4.tcp_congestion_control=htcp

Save file and exit

After we did this, apply the changes made in the sysctl.conf file with the following command: # sysctl -p

Root Cause

Overrun is a number of times that a NIC is unable to transmit the received data in buffer, because the transfer rate of Input exceeded the environment capacity to receive the data. It usually is a signal of excessive traffic.

Each interface has two buffers (queues) with a determinated size, one for transmit data and other to receive data (packages). When one of these queues 'fill', the surplus packages are discarded as 'overruns'. In this case, the NIC is trying receive or transmit more packages than the environment can support.

Diagnostic Steps

    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. 

리눅스의 이더넷 (Ethernet) 이중화에 대한 구성은 일반적으로 물리적인 연결에 대한 감지 모니터링을 

통해서 2중화 구성을 진행하게 된다. 

하지만  본딩구성과 관련하여서 물리적인 연결에 대한 감지가 늦어지게 되는경우 리눅스는 물리적으로

는 Fail되었으나 운영체제 상에서는 Live 상태로 오동작 하는 경우가 생길수 있다. 본딩 Failover 절차

를 가장 빠르게 할수 있는 방안은 ARP Table을 Ping 테스트를 진행하여 연결 상태를 확인하는 것이 

가장 빠르다. 

DEVICE=bond1 


IPADDR=110.22.34.52 


NETMASK=255.255.255.0 


USERCTL=no 


BOOTPROTO=static 


ONBOOT=yes 


#BONDING_OPTS="mode=active-backup miimon=100" 


BONDING_OPTS="mode=active-backup arp_interval=200 

arp_ip_target=110.22.34.1" 


[* Bonding OPTS= arp_target 에 대한 적용은 miimon 옵션의 경우 Ethernet Card 자체에 대한 이상여부를 판단함으로 네트워크 젃체시 Ethernet을 Live 상태로 판단하여 클러스터에서 정상이라고 판단 서비스를 이관하지 않는 문제로 인하여 ARP Table을 check 하도록 구성, 일반적으로 금융권에 구성하는 시스템의 경우는 arp_table 옵션을 적용하는 경우가 많음] 




Sometime System Administrator would like to get more information about system H/W Configuration without system downtime, but linux operating system provide very useful command for linux system administrator.

 

1. dmidecode  type information 

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


1. Follow the step if you want to check out of System BIOS Status 

[root@localhost] dmidecode --type 0 

dmidecode 2.8
SMBIOS 2.5 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
        Vendor: American Megatrends Inc.
        Version: V1.5B2
        Release Date: 10/31/2007
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 1024 kB
        Characteristics:


2. if you want know about system memory status without system downtime it' very 
usefull command below so far

[root@localhost]dmidecode --type memory 

# dmidecode 2.8
SMBIOS 2.5 present.

Handle 0x0008, DMI type 5, 20 bytes
Memory Controller Information
        Error Detecting Method: 64-bit ECC
        Error Correcting Capabilities:
                None
        Supported Interleave: One-way Interleave
        Current Interleave: One-way Interleave
        Maximum Memory Module Size: 512 MB
        Maximum Total Memory Size: 1024 MB

        Supported Speeds:
                70 ns
                60 ns
        Supported Memory Types:
                SIMM
                DIMM
                SDRAM
        Memory Module Voltage: 3.3 V
        Associated Memory Slots: 2
                0x0009
                0x000A
        Enabled Error Correcting Capabilities:
                None


레드햇 엔터브라이즈 리눅스 (RHEL6) 환경에서 KVM을 이용하여 가상화를 구성할경우 NAT 보다는 Bridge를 이용하여

TCP/IP를 통신할수 있도로 구성한다. virt-manager는 VM에 대한 환경구성에 대한 부분만 지원하기 때문에 하이퍼바이저 환경

구성은 지원하지 않는다. 아래의 절차대로 구성을 진행한다.


1. KVM의 기본구성은 NAT로 구성된다.

초기 가상화 구성시 아래와 같이 virtbr0로 나타나게 되면 NAT로 구성되어 있다고 판단해도 무방하다. 

 # ifconfig virbr0
virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:7921 (7.7 KiB)

위와 같이 NAT가 확인되었으면 아래의 절차대로 Bridge로 변경하는 작업을 진행해 준다.

1. virtbr0를 지운다. (물론 Ethernet Interface가 많으면 상관없다.)

2. /etc/sysconfig/network-script/ifcfg-eth0의 스크립트 파일에 dhcp 기능을 지우고 br0로 변경 

3. br0를 만드는데 BOOTPROTO는 네트워크 환경에 따라 설정해 준다. (DHCP 환경이라면 DHCP로 지정)

    DEVICE=br0
    TYPE=Bridge
    BOOTPROTO=static
    BROADCAST=192.168.1.255
    IPADDR=192.168.1.10
    NETMASK=255.255.255.0
    NETWORK=192.168.1.0
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=no
    ONBOOT=yes

2. NAT 네트워크 제거

위와 같이 인터페이스 파일에 브릿지 설정이 정상적으로 설정이 되었으면 기존의 NAT로 설정된 인터페이스를 제거해 준다.

2.1 virsh list를 이용하여 NAT 인터페이스 확인한다. 

# virsh net-list
Name                 State      Autostart
-----------------------------------------
default              active     yes


2.2 버추얼 네트워크 이름이 'default'로 되어있는 것을 Destory 한다.

# virsh net-destroy default
# virsh net-undefine default
# service libvirtd restart


eth0 의 dhcp 를 지우고 br0 로 Bridged 한다.

다음과 같이 합니다.

cat > ifcfg-eth0 <
DEVICE=eth0
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
BRIDGE=br0
NM_CONTROLLED=no
EOF


br0를 만든다. 

다음과 같이 합니다.

# cat > ifcfg-br0 <
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0
NM_CONTROLLED=no
EOF

위과정을 거치면 설정은 끝납니다. 한가지 더 있는데, 리눅스의 NetworkManager 데몬을 꺼주고 network 서비스를 다시 올려줍니다. 

# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network restart


이제 virt-manager 로 KVM 게스트를 설치할 다음과 같이 이더넷을 설정해 주면 됩니다.





http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=%2Fliaai%2Fcrashdump%2Fliaaicrashdumpnmiwatch.htm



http://www.ibm.com/developerworks/kr/library/l-cfs/index.html

공유 메모리(shared memory)는 프로세스가 공유 메모리 세그먼트를 통해 공통 데이타 구조 및 데이타에 접근할 수 있게 합니다. 공유 메모리는 커널 작업을 수반하지 않으며 프로세스 간의 데이타 복제 작업이 불필요하기 때문에, IPC(inter-process communication)를 위한 가장 빠른 방법으로 선호되고 있습니다.

오라클은 오라클의 백업 및 포어그라운드 프로세스를 위한 공유 메모리 영역으로 Shared Global Area (SGA)를 제공합니다. SGA는 데이타베이스 버퍼 캐시, 공유 SQL, 접근 경로 등의 저장에 활용되므로, SGA 크기의 설정에 따라 오라클의 성능이 크게 달라질 수 있습니다.

공유 메모리 설정을 확인하려면 아래와 같이 명령을 수행합니다:

# ipcs -lm

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

SHMMAX의 설정

SHMMAX매개변수는 공유 메모리 세그먼트의 최대 크기(바이트 단위)를 정의하는데 사용됩니다. 오라클 SGA는 공유 메모리로 구성되며, SHMMAX가 올바르게 설정되지 않은 경우 SGA의 크기가 제약될 수도 있습니다. 따라서 SGA의 크기보다 작지 않도록 SHMMAX를 설정해야 합니다. SHMMAX 매개변수가 잘못 설정된 경우에는 다음과 같은 에러가 발생합니다:

ORA-27123: unable to attach to shared memory segment
SHMMAX 매개변수의 설정값을 확인하려면 아래와 같이 명령을 수행합니다:
# cat /proc/sys/kernel/shmmax
33554432
SHMMAX의 디폴트 값은 32MB입니다. 이 사이즈는 Oracle SGA로 활용하기에는 너무 부족합니다. 필자는 보통 SHMMAX 매개변수를 2GB로 설정합니다. 그 방법이 아래와 같습니다:

  • · /proc 파일시스템에 변경사항을 직접 적용하면 서버를 리부팅하지 않고도 SHMMAX 설정을 변경할 수 있습니다. SHMMAX의 값을 다이내믹하게 변경하고 커맨드를 /etc/rc.local 스타트업 파일에 영구적으로 적용하는 방법이 아래와 같습니다:
    # echo "2147483648" > /proc/sys/kernel/shmmax


  • · 또는 sysctl 커맨드를 사용하여 SHMMAX의 값을 변경할 수도 있습니다:
    # sysctl -w kernel.shmmax=2147483648


  • · 마지막으로, /etc/sysctl.conf 스타트업 파일에 커널 매개변수를 추가함으로써 변경 사항을 영구적으로 적용할 수 있습니다:
    # echo "kernel.shmmax=2147483648" >> /etc/sysctl.conf
SHMMNI의 설정

SHMMAX 매개변수는 공유 메모리 세그먼트의 최대 숫자를 설정하는데 사용되며, 디폴트 값은 4096입니다. 이 값은 일반적으로 충분하며 변경될 필요가 없습니다.

SHMMNI의 설정값을 확인하는 방법이 아래와 같습니다:

# cat /proc/sys/kernel/shmmni
4096
SHMALL의 설정

마지막으로, SHMALL 커널 매개변수는 특정 시점에 시스템에서 사용 가능한 공유 메모리의 최대 크기(페이지 단위)를 설정하는데 사용됩니다. 따라서 이 매개변수는 최소한 아래 값보다 커야 합니다:

ceil(SHMMAX/PAGE_SIZE)
SHMALL의 디폴트 사이즈는 2097152이며 아래 명령을 통해 조회할 수 있습니다:
# cat /proc/sys/kernel/shmall
2097152
SHMALL의 디폴트 설정값은 이 가이드에서 사용하는 테스트용 Oracle RAC 10g 설치 환경에 충분합니다.
(참고: i386 플랫폼 기반 Red Hat Linux의 페이지 사이즈는 4,096 바이트입니다. bigpages를 이용하면 메모리 페이지의 사이즈를 더 크게 변경할 수도 있습니다.)

Semaphore의 설정

세마포어(semaphore)란 (공유 메모리와 같은) 공유 리소스의 사용 과정에서 프로세스(또는 프로세스 내 쓰레드) 간의 동기화를 위해 사용되는 일종의 카운터(counter)입니다. 세마포어 셋(semaphore set)은 Unix System V에서 지원됩니다. 애플리케이션이 세마포어를 이용하면, 운영체체는 "셋(set)"을 통해 세마포어를 지원합니다.

세마포어 설정값을 확인하려면 아래와 같이 명령을 수행합니다:

# ipcs -ls

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767
또는 다음 명령을 사용합니다:
# cat /proc/sys/kernel/sem
250     32000   32      128

SEMMSL의 설정

세마포어 셋 당 세마포어의 최대 갯수는 SEMMSL 커널 매개변수를 통해 정의됩니다.

오라클은 init.ora 파일의 PROCESS 인스턴스 매개변수의 (전체 데이타베이스 중) 최대값에 10을 더한 값을 사용할 것을 권장하고 있습니다. 또 SEMMSL의 값을 100 이상으로 설정하는 것이 권장됩니다.

SEMMNI의 설정

SEMMNI 커널 매개변수는 전체 Linux 시스템의 세마포어 셋의 최대 개수를 정의하는데 사용됩니다. 오라클은 SEMMNI를 100 이상의 값으로 설정할 것을 권장하고 있습니다.

SEMMNS의 설정

SEMMNI 커널 매개변수는 전체 Linux 시스템의 ("세마포어 셋"이 아닌) 세마포어의 최대 개수를 정의하는데 사용됩니다.

오라클은 각 데이타베이스의 PROCESSES 인스턴스 매개변수의 값을 모두 더한 뒤, 가장 큰 PROCESSES값을 두 차례 더하고, 마지막으로 각 데이타베이스 별로 10을 더한 값으로 SEMMNS를 설정하도록 권고하고 있습니다.

Linux 시스템에 할당될 수 있는 세마포어의 최대 개수를 결정하기 위해 다음과 같은 공식을 사용합니다. 아래의 두 항목 중 더 낮은 값을 적용합니다:

SEMMNS  또는  (SEMMSL * SEMMNI)
SEMOPM의 설정

SEMOPM 커널 매개변수는 semop 시스템 호출 (system call) 별로 수행될 수 있는 세마포어 작업의 수를 설정하는데 사용됩니다.

semop 시스템 호출(함수)은 하나의 semop 시스템 호출을 통해 여러 개의 세마포어를 지원합니다. 세마포어 셋에서 가질 수 있는 세마포어의 최대값은 SEMMSL 매개변수를 통해 정의됩니다. 따라서 SEMOPMSEMMSL과 동일하게 설정하는 것이 권장됩니다.

오라클은 SEMOPM을 100 이상의 값으로 설정할 것을 권장하고 있습니다.

세마포어 커널 매개변수의 설정

마지막으로 세마포어 매개변수를 설정하는 방법에 대해 알아보겠습니다. 여기에서는 SEMOPM 만을 변경하고, 다른 설정은 디폴트 값을 그대로 사용하는 것으로 합니다.


  • · /proc 파일시스템에 변경 내용을 직접 적용하면, 시스템을 리부팅하지 않고도 세마포어 매개변수를 변경할 수 있습니다. /etc/rc.local 스타트업 파일에 아래 라인을 추가하면 됩니다:
    # echo "250 32000 100 128" > /proc/sys/kernel/sem


  • · sysctl 커맨드를 사용하면 전체 세마포어 설정을 한꺼번에 변경할 수 있습니다:
    # sysctl -w kernel.sem="250 32000 100 128"


  • · 마지막으로 /etc/sysctl.conf 스타트업 파일에 커널 매개변수를 추가함으로써 변경 내용을 영구적으로 적용할 수 있습니다:
    # echo "kernel.sem=250 32000 100 128" >> /etc/sysctl.conf

File Handle의 처리


Red Hat Linux 서버를 구성하는 과정에서, 사용 가능한 파일 핸들(file handle)의 수가 충분한지 확인하는 것은 매우 중요합니다. 파일 핸들의 최대 개수 설정에 따라 Linux 시스템에서 동시에 오픈할 수 있는 파일의 수가 달라지게 됩니다.

전체 시스템에서 사용 가능한 파일 핸들의 최대값을 확인하기 위해 아래 명령을 실행합니다:

# cat /proc/sys/fs/file-max
32768
오라클은 전체 시스템의 파일 핸들 수를 최소 65536개 이상으로 설정할 것을 권고하고 있습니다..

  • · /proc 파일시스템에 변경 내용을 직접 적용하면, 시스템을 리부팅하지 않고도 매개변수를 변경할 수 있습니다. /etc/rc.local 스타트업 파일에 아래 라인을 추가하면 됩니다:
    # echo "65536" > /proc/sys/fs/file-max


  • · 또는 sysctl 커맨드를 이용하여 SHMMAX의 값을 변경할 수도 있습니다:
    # sysctl -w fs.file-max=65536


  • · 마지막으로 /etc/sysctl.conf 스타트업 파일에 커널 매개변수를 추가함으로써 변경 내용을 영구적으로 적용할 수 있습니다:
    # echo "fs.file-max=65536" >> /etc/sysctl.conf
현재 사용되고 있는 파일 핸들의 수는 아래와 같이 조회할 수 있습니다:
# cat /proc/sys/fs/file-nr
613     95      32768
file-nr 파일에서 제공되는 3 개의 매개변수가 다음과 같습니다: 할당된 파일 핸들의 수, 현재 사용 중인 파일 핸들의 수, 할당 가능한 최대 파일 핸들의 수.
(참고: /proc/sys/fs/file-max의 값을 증가시키고자 하는 경우, 먼저 ulimit이 올바르게 설정되었는지 확인할 필요가 있습니다. 2.4.20 버전에서는 ulimit이 "unlimited"로 설정되는 것이 일반적입니다. umilit 커맨드를 사용하면 ulimit 설정을 확인할 수 있습니다:
# ulimit
unlimited


http://techiess.wordpress.com/tag/memory/

리눅스의 메모리 사용량의 경우 항상 물리적인 메모리 대비 Cache 와 Buffer의 사용량에 대해서 논쟁이도고는 한다.
물론 운영중에 갑자기 물리적인 메모리의 사용량이 늘어서 SWAP을 사용하는 경우라면 달라지겠지만 실질적으로  어플리케이션이 동작하지 않는 가운데 메모리의 사용량이 터무니 없이 나타나는건 , Buffer나 Cache에 대한 용량적인 계산에 대해서 잘못 인식하고 있는 경우가 많기 때문이다..
아래는 /proc/meminfo에 대한 항목에 대한 내용인데.. 메모리 관련 부분에 있어서 설명할때 필요한 부분인듯 하다..
/proc/meminfo 내용

This is one of the more commonly used files in the /proc/ directory, as it reports a large amount of valuable information about the systems RAM usage.

The following sample /proc/meminfo virtual file is from a system with 256 MB of RAM and 512 MB of swap space:

         MemTotal: 255908 kB MemFree: 69936 kB Buffers: 15812 kB Cached: 115124 kB SwapCached: 0 kB Active: 92700 kB Inactive: 63792 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 255908 kB LowFree: 69936 kB SwapTotal: 524280 kB SwapFree: 524280 kB Dirty: 4 kB Writeback: 0 kB Mapped: 42236 kB Slab: 25912 kB Committed_AS: 118680 kB PageTables: 1236 kB VmallocTotal: 3874808 kB VmallocUsed: 1416 kB VmallocChunk: 3872908 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 4096 kB       

Much of the information here is used by the free, top, and ps commands. In fact, the output of the free command is similar in appearance to the contents and structure of /proc/meminfo. But by looking directly at /proc/meminfo, more details are revealed:

  • MemTotal — Total amount of physical RAM, in kilobytes.

  • MemFree — The amount of physical RAM, in kilobytes, left unused by the system.

  • Buffers — The amount of physical RAM, in kilobytes, used for file buffers.

  • Cached — The amount of physical RAM, in kilobytes, used as cache memory.

  • SwapCached — The amount of swap, in kilobytes, used as cache memory.

  • Active
    — The total amount of buffer or page cache memory, in kilobytes, that
    is in active use. This is memory that has been recently used and is
    usually not reclaimed for other purposes.

  • Inactive
    — The total amount of buffer or page cache memory, in kilobytes, that
    are free and available. This is memory that has not been recently used
    and can be reclaimed for other purposes.

  • HighTotal and HighFree — The total and free amount of memory, in kilobytes, that is not directly mapped into kernel space. The HighTotal value can vary based on the type of kernel used.

  • LowTotal and LowFree — The total and free amount of memory, in kilobytes, that is directly mapped into kernel space. The LowTotal value can vary based on the type of kernel used.

  • SwapTotal — The total amount of swap available, in kilobytes.

  • SwapFree — The total amount of swap free, in kilobytes.

  • Dirty — The total amount of memory, in kilobytes, waiting to be written back to the disk.

  • Writeback — The total amount of memory, in kilobytes, actively being written back to the disk.

  • Mapped — The total amount of memory, in kilobytes, which have been used to map devices, files, or libraries using the mmap command.

  • Slab — The total amount of memory, in kilobytes, used by the kernel to cache data structures for its own use.

  • Committed_AS
    — The total amount of memory, in kilobytes, estimated to complete the
    workload. This value represents the worst case scenario value, and also
    includes swap memory.

  • PageTables — The total amount of memory, in kilobytes, dedicated to the lowest page table level.

  • VMallocTotal — The total amount of memory, in kilobytes, of total allocated virtual address space.

  • VMallocUsed — The total amount of memory, in kilobytes, of used virtual address space.

  • VMallocChunk — The largest contiguous block of memory, in kilobytes, of available virtual address space.

  • HugePages_Total — The total number of hugepages for the system. The number is derived by dividing Hugepagesize by the megabytes set aside for hugepages specified in /proc/sys/vm/hugetlb_pool. This statistic only appears on the x86, Itanium, and AMD64 architectures.

  • HugePages_Free — The total number of hugepages available for the system. This statistic only appears on the x86, Itanium, and AMD64 architectures.

  • Hugepagesize
    — The size for each hugepages unit in kilobytes. By default, the value
    is 4096 KB on uniprocessor kernels for 32 bit architectures. For SMP,
    hugemem kernels, and AMD64, the default is 2048 KB. For Itanium
    architectures, the default is 262144 KB. This statistic only appears on the x86, Itanium, and AMD64 architectures.


정보는 최고사용량과 최저사용량으로 표현되며, 먼저 최고사용량에 대해 살펴보면 다음과 같다.

- MemoryTotal :
사용 가능한 최대 메모리(RAM)량
( Physical RAM - a few reserved bits - kernel binary code )

- MemFree :
LowFree + HighFree

- MemShared :
호환성을 위한 값이며 항상 0임

- Buffers :
버퍼 캐시 메모리로 최근에는 거의 쓸모없는 값

- Cached :
pagecache(diskcache) - SwapCache

- SwapCache :
스와핑 아웃되었던 메모리로, 스와핑 인되었지만 여전히 스왑 파일에 존재하는
메모리(메모리가 다시 필요하다면 이미 스왑파일에 존재하므로 또 다시 스와핑
아웃될 필요가 없음. 이는 I/O를 절약할 수 있음)
가상 메모리 통계는 다음과 같다.
가상 메모리는 캐시 페이지를 active와 inactive 메모리로 나누고,
The idea is that if you need memory and some cache needs to be sacrificed for that, you take it from inactive since that's expected to be not used. The vm checks what is used on a regular basis and moves stuff around.
When you use memory, the CPU sets a bit in the pagetable and the VM checks that bit occasionally, and based on that, it can move pages back to active. And within active there's an order of "longest ago not used" (roughly, it's a little more complex in reality). The longest-ago used ones can get moved to inactive. Inactive is split into two in the above kernel (2.4.18-24.8.0). Some have it three.

- Active : 가장 최근에 사용되었던 메모리로 완전히 불필요하지 않은 경우를 제외하고서는
반환되지 않음

- Inact_dirty :
여기서 dirty의 의미는 "디스크나 스왑 공간으로 기록될 필요가 있음"을 의미하며,
빈 공간으로 반환되기 위해서는 몇가지 작업이 필요하다. 아직 기록되지 않은
파일이 예가 될 것이다. 너무 일찍 메모리에 기록하여 I/O의 성능을 떨어뜨릴
필요가 없기 때문이다. 예를 들어 log를 기록한다고 할 때 완벽한 로그가 구성될
때까지 디스크에 기록하지 않는 것이 성능에 도움이 된다.

- Inact_clean :
쉽게 빈 공간으로 반환될 수 있음을 의미한다. 커널은 항상 일정한 양의 빈 공간을
확보하고 있는데, 이는 움직일 수 있는 여유를 가지기 위함이다.

- Inact_target :
Just a goal metric the kernel uses for making sure there are enough inactive pages around. When exceeded, the kernel will not do work to move pages from active to inactive. A page can also get inactive in a few other ways, e.g. if you do a long sequential I/O, the kernel assumes you're not going to use that memory and makes it inactive preventively. So you can get more inactive pages than the target because the kernel marks some cache as "more likely to be never used" and lets it cheat in the "last used" order.
메모리 통계

- HighTotal :
상위 영역(high region)에 존재하는 메모리의 전체 양으로, Highmem은
physical RAM에서 대략 860MB 위의 메모리를 의미한다. 커널은 상위 영역의
메모리 메모리에 접근하기 위해 간접적인 트릭(indirect tricks)을 사용한다.
데이터 캐시가 이 메모리 영역에 포함될 수 있다.

- LowTotal :
비상위메모리(non-highmem) 영역에 대한 총량

- LowFree :
하위메모리 영역(low memory region)의 빈 공간. 커널이 직접적으로 접근할 수
있는 메모리 영역으로, 모든 커널 데이터구조(datastructures)가 이 메모리 영역에
저장된다.

- SwapTotal :
물리적인 스왑 메모리(physical swap memory)의 총량

- SwapFree :
스왑 공간의 빈 영역의 총량

- Committed_AS :
99.99%의 보장(이러한 부하에서는 OOM[Out of Memory]를 결코 발생시키지
않음)을 위해 필요로 하는 RAM의 추측값으로, 일반적인 상황에서는 커널이 메모리를
지나치게 낭비하는 경우이다. 즉, 1GB malloc를 사용한다고 할 때 실제적으로는
아무런 일도 발생하지 않는다. 단지 메모리를 실제로 사용하기 시작할 때 malloc에
의해 필요로 하는 메모리가 요구된다. 즉 저당을 잡히고 은행이 망하지 않기만을
바라는 상황이 된다. 또 다른 경우에는 mmap 파일을 이용해서 두 프로세스 간에
공유할 경우가 포함된다. Committed_AS는 최악의 상황에서 필요로 하는

RAM/swap의 추측값이다.

참고url
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-proc-meminfo.html
http://blog.daum.net/_blog/BlogTypeView.do?blogid=05S77&articleno=86&_bloghome_menu=recenttext#ajax_history_home


==================


'Linux 이야기. > LInux Article.' 카테고리의 다른 글

Linux Shared Memory에 대한 Handling  (0) 2012.05.25
Linux Memory 매니지먼트  (0) 2012.05.14
OpenStack RedHat Contribution  (0) 2012.04.19
RHEL6에서 Bonding 하기  (0) 2012.02.29
RHEL6 UDP Communicate 에러관련  (0) 2012.02.13

레드햇이  오픈스택에 대한  Contribution Rate를 높이기 시작했습니다.  클라우드 컴퓨팅 멀티 플랫폼 지원과 관련되어서 본격

적으로  관심을 갖기 시작했다는 이야기죠.. 기존의 클라우드 가상화 환경에서 제공되어지는 관리운영 환경은 단독적인 

매니지먼트에 운영 시스템에 대한 의존도를 높일수 밖에 없었으나, 이제는 클라우드 플랫폼 운영환경에 대한 Flexibility를 

높이고자 하는 단계로 접어들기 위한 전략의 시작이라 생각해도 무리는 없을듯 합니다. RedHat Cloud Forms의 그림이 

명확해 지내요.. 반면에 아파치 재단으로 등을 돌린 Citrix의 Cloud Stack과의 경쟁도 볼만할듯 합니다....


http://www.readwriteweb.com/cloud/2012/04/who-wrote-openstack-essex-a-de.php





+ Recent posts