Cooper의 상상은 이루어진다.

CentOS 7.6에서 too many files open 에러 발생 현상시 조치방안

[환경]

CentOS 7.6, mariadb 10.2.23

[증상]

[ERROR] Error in accept: Too many open files 에러 문구가 출력되면서 PC Agent 접속이 안되거나 DBSAFER DB 접속이 안되는 증상

[원인]

DB에서 Open File limit 수를 초과하여 파일을 열었을 경우 발생

[조치방안]

1. OS 계정별로 열수 있는 파일 개수 확인 및 수정 > DBSAFER 5.0 설치시 하기 사진과 같이 기본적으로 설정되어 있음

vi /etc/security/limits.conf 

2. 설정값 확인

ulimit -a

ulimit -n

> DBSAFER RPM 설치시 65534값으로 설정된 것 확인됨

3. maria DB 접속후 open file limits 개수 확인

show variables like 'open_files_limit';

ps -ef |grep mysql (PID 체크 후) -> losf -p [PID] |frep wc -l로 현재 mysql이 열고 있는 파일 개수 확인

4. open_files_limit 설정 방법

vi /etc/,y.cnf

> max_connections 하기에 open_files_limit=64000 추가 ** 권장값은 30000입니다. **

5. DB 재시작

systemctl restart mysql

6. 프로세스 시간 체크

ps -ef  |grep mysql

7. DB 접속 후 값 변경된거 확인

show variables like 'file_open_limit';

내용참고

https://kugancity.tistory.com/entry/mysql-maxopenfile-%EC%82%AC%EC%9D%B4%EC%A6%88-%EC%A6%9D%EA%B0%80%ED%95%98%EA%B8%B0

백업서버에 있는 로그 파일을 SFTP로 가져오는 스크립트

[스크립트]

1. 감사로그 백업파일 가져오는 스크립트

#!/bin/bash

HOST="서버 IP"

PASSWORD="1q2w3e"

USER="root"

expect<<EOF
spawn sftp $USER@$HOST
expect "password:"
send "$PASSWORD\r"
set timeout 36000
expect "sftp>"
send "cd /home/backup/\r" # 경로 디렉토리
expect "sftp>"
send "get /home/backup/dbsafer_log_$(date +%Y_%m -d'+1 months ago').tar.gz\r"   ->> 한달전 백업 파일 가져옴
expect "sftp>"
send "quit\r"
EOF

2. 금월 정책 DB 백업 가져오는 스크립트

#!/bin/bash

HOST="TEST 서버 IP"

PASSWORD="TEST123"

USER="root"

expect<<EOF
spawn sftp $USER@$HOST
expect "password:"
send "$PASSWORD\r"
set timeout 36000
expect "sftp>"
send "cd /home/backup/\r"  # 경로 디렉토리
expect "sftp>"
send "get /home/backup/dbsafer_policy_$(date +%Y_%m).tar.gz\r"
expect "sftp>"
send "quit\r"
EOF

[crontab 설정]

# vi /var/log/sftpshell.log 로그파일 생성 (touch로 생성해도 무관)

# crontab -e 스케쥴 등록

분 시 일 월 요 /실행파일경로/실행파일명 >> /var/log/sftpshell.log 2>&1

# crontab -l 등록된 스케쥴 확인 명령어

물리적 메모리free영역이, 남아있음에도 불구하고, Swap영역을 Attach하는 이유는 무엇인가?

Free 메모리가 있는 상황에서 시스템이 어느정도의 스왑메모리를 사용하는 것은 정상적인 상황이다.

커널은 미래에 사용될 가능성이 높은 메모리 페이지(사용자 프로세스, 커널 캐쉬등)를 스왑 아웃하지 않고 메모리상에 계속 보관해두어

퍼포먼스를 높이려고 한다. 또한, 아주 적은 빈도로 사용될 가능성이 높은 페이지는 가용메모리 공간 낭비를 피하기 위해 스왑아웃 시킨다.

이와 관련해서 커널의 스와핑 활용 경향을 변경/셋팅할 수 있다./proc/sys/vm/swappiness 값을 셋팅하면 되는데 기본값은 60이다.

-> 0으로 셋팅할 경우, Free메모리가 남아있을 때까지는 스왑공간을 사용하지 않음.

-> 100으로 셋팅할 경우, Free메모리가 남아있더라도 최대한 적극적으로 스왑공간을 활용.

시스템이 운영되고 있는 상황에서 임시적으로 변경하고자 할 경우는 sysctl 명령으로 vm.swappiness 커널 파라미터에 값을 주면 된다.

영구적으로 값을 셋팅할 경우 /etc/sysctl.conf 파일에 vm.swapiness= 형식으로 값을 셋팅하면 된다.

- vm.swappiness = 60 (기본값) 스왑메모리에 대한 활용 빈도를 결정한다.

예) echo "100" > /proc/sys/vm/swappiness 스왑을 적극적으로 활용한다.

메모리 스와핑은 두가지 면에서 중요하다.

첫째, 시스템에서 특정 어플리케이션이나 프로세스가 현재 가용한 피지컬 메모리보다 많은 양의 메모리를 요청할 경우, 커널은 적은 빈도율로 사용되는 메모리 페이지를 스왑아웃해서 가용 메모리 공간을 확보한 뒤 이를 해당 프로세스에 할당해 줌으로써 프로세스 실행이 가능하게된다.

둘째, 특정 어플리케이션이 실행되기 시작할 때 초기화를 위해서만 필요하고 이후에는 사용되지 않는 메모리 페이지들은 시스템에 의해 스왑아웃되며, 이로인해 가용해진 메모리 공간은 다른 어플리케이션이나 디스크캐쉬 용도로 활용된다.

스와핑의 단점은 아래와 같다.

메모리는 나노초 단위로 수행되는 반면, 디스크는 밀리초단위로 수행되기 때문에 상대적으로 속도가 느리다.스왑아웃된 데이터를 메모리대신 디스크에서 액세스할 경우, 메모리에서 해당 데이터를 액세스하는 것에 비해 상대적으로 느리게되므로 퍼포먼스 저하가 발생하게 된다.

[스왑 메모리 초기화]

: #swapoff -a && swapon -a