우수한 소프트웨어와 실용적인 튜토리얼
Ubuntu 시스템에서 하드 디스크 공간이 부족하여 쓰기가 불가능한 문제가 발생할 때
존재하다 리눅스 서버에서 하드 디스크 공간이 충분한 것처럼 보이더라도 여전히 다음과 같은 문제가 발생할 수 있습니다.쓸 수 없습니다이는 일반적으로 다음 때문에 발생합니다. 아이노드 탈진한.
하드디스크에 쓰기가 불가능한 경우디스크 공간아직 남아 있다면 inode가 고갈되었을 가능성이 높습니다. 작은 파일을 정리하고 조정할 수 있습니다.파일 시스템또는 보관 저장소 및 기타 방법을 사용하여 문제를 해결하고, 모니터링 및 최적화 설계와 협력하여 유사한 문제가 다시 발생하지 않도록 합니다.
inode란 무엇인가요?
Inode는 파일 시스템의 데이터 구조로, 파일에 대한 메타 정보(파일 권한, 소유자, 생성 시간 등)를 저장합니다.
각 파일은 파일 크기에 관계없이 하나의 inode를 차지합니다. inode가 모두 소진되면 하드 디스크에 여전히남은 공간, 새로운 파일을 생성할 수 없습니다.
하드 디스크와 inode 사용량을 확인하는 방법은?
디스크 공간 확인
df -h
이렇게 하면 사람이 읽을 수 있는 형식으로 디스크 사용량이 표시됩니다.
inode 사용량 확인
df -i
샘플 출력:
파일 시스템 Inode IUsed IFree IUse% 마운트됨
/dev/sda1 1000000 999999 1 100% /
IUse%는 inode 사용률을 나타냅니다. IUse%가 100%에 도달하면 inode가 모두 소진되었음을 의미합니다.
- 작은 파일이 너무 많습니다. 작은 파일이 많으면 많은 수의 inode를 소모하게 되는데, 특히 로그 파일과 임시 파일의 경우 더욱 그렇습니다.
- 파일 시스템 유형. 일부 파일 시스템(예: ext4)은 생성 시 고정된 개수의 inode를 할당하며 동적으로 조정할 수 없습니다.
- 애플리케이션 문제: 애플리케이션이 지속적으로 작은 파일을 생성하여 inode가 빠르게 고갈될 수 있습니다.
100%를 차지하는 inode에 대한 솔루션
먼저 시스템 로그 파일을 삭제하세요
sudo rm -rf /var/log/*.log
시스템 로그 파일을 삭제한 후에도 inode 사용률이 여전히 100%이거나 약간 감소한 것으로 나타났습니다. 이 경우, 시스템에서 어떤 디렉터리 파일이 너무 많은 공간을 차지하고 있는지 확인해야 합니다.
일반적으로 Linux에서는 /home에 웹사이트 프로그램 파일이 저장되고, 시스템 프로그램 파일은 대개 /var 디렉토리에 저장됩니다.
다음으로, 어느 디렉토리가 너무 많은 공간을 차지하는지 확인하고, 루트 디렉토리에 있는 폴더의 크기를 확인하고, 크기별로 정렬합니다.
du -h --max-깊이=1 / | 정렬 -시간
var 디렉터리의 어느 디렉터리가 디렉터리 크기에 비해 많은 파일을 차지하는지 추가로 확인하세요. 다른 디렉터리도 이 방법을 사용하여 확인하세요.
du -h --max-깊이=1 /var | 정렬 -시간
조사하는 동안 /usr/local/lsws/logs가 9.4G를 차지하는 것을 발견했습니다. 해당 디렉터리에 들어가 보니 거의 8G를 차지하는 auditmodsec.log 파일이 있었습니다.
auditmodsec.log는 ModSecurity의 감사 로그 파일로, 보안 규칙을 트리거하는 HTTP 요청과 응답 데이터를 기록합니다.
조사를 계속 진행한 결과, /var/lib/lsphp/session/lsphp83 디렉토리가 너무 많은 공간을 차지하고 파일이 너무 많다는 것을 발견했습니다.
/var/lib/lsphp/session/lsphp83 디렉터리는 LiteSpeed PHP(lsphp) 세션과 관련된 저장 디렉터리입니다. 이 디렉터리는 일반적으로 LiteSpeed 웹 서버에서 PHP 스크립트를 처리하는 데 사용되는 API인 LSAPI(LiteSpeed SAPI)와 관련이 있습니다.
/var/lib/lsphp/session은 LiteSpeed PHP 세션 파일이 저장되는 디렉터리입니다. PHP 세션 파일은 여기에 저장되며 세션 ID에 따라 이름이 지정됩니다.
세션 디렉터리에 파일이 너무 많거나 너무 크면 저장 공간이 부족해질 수 있습니다. 유효하지 않은 세션 파일을 정기적으로 정리하세요.
위에 언급된 inode들은 100%를 차지합니다. 대부분의 경우 이 디렉터리에 문제가 있습니다. /var/lib/lsphp/session 폴더에 파일이 너무 많아서 inode가 100%를 차지하고 하드 디스크가 파일을 쓸 수 없습니다. 하드 디스크가 가득 찬 것 외에도 inode가 100%를 차지하는 것이 또 다른 원인입니다.
이 두 가지 문제 모두 하드 디스크가 콘텐츠를 쓸 수 없게 만듭니다. 하드 디스크가 파일을 쓸 수 없으면 웹이나 데이터베이스가 작동 중에 임시 파일을 작성해야 합니다. 임시 파일을 작성하지 못하면 웹사이트 마비, 데이터베이스 마비 등 여러 문제가 발생할 수 있습니다.
세션 파일 정리 및 관리
cron을 사용하여 만료된 세션 파일을 정기적으로 정리하면 디렉터리가 너무 많은 공간을 차지하는 것을 방지할 수 있습니다. 일반적으로 만료된 세션 파일은 시스템 설정에 따라 자동으로 정리되지만, session.gc_maxlifetime을 설정하여 관리할 수도 있습니다.
먼저 PHP 설정 파일에서 재활용 관리를 활성화합니다.
PHP에서 세션 가비지 컬렉션(GC)은 만료된 세션 데이터를 정리하는 메커니즘입니다. 개발 환경, 트래픽이 많은 프로덕션 서버 등 환경 요구 사항에 따라 session.gc_probability, session.gc_divisor 및 session.gc_maxlifetime 설정을 최적화할 수 있습니다.
다음은 시나리오에 따라 재활용을 활성화하기 위한 최적의 설정에 대한 권장 사항입니다.
주요 매개변수 최적화 설명
세션.gc_확률
목적: 세션이 초기화될 때마다 가비지 수집이 발생할 확률을 제어합니다.
권장 설정:
개발 환경: 1. 디버깅 방해를 줄이기 위해 세션 데이터를 자주 정리하는 것이 편리합니다.
운영 환경: 1. 가비지 수집 메커니즘이 켜져 있는지 확인하세요.
세션.gc_divisor
함수: session.gc_probability와 함께 가비지 컬렉션이 발생할 확률을 결정합니다. 가비지 컬렉션의 확률 공식은 다음과 같습니다.
코드 복사
가비지 수집 확률 = gc_probability / gc_divisor
권장 설정:
개발 환경: 100(즉, 가비지 수집을 트리거할 확률은 1/100).
트래픽이 많은 프로덕션 환경: 1000(즉, 가비지 수집을 트리거할 확률이 1/1000이므로 성능 오버헤드가 줄어듭니다).
세션.gc_maxlifetime
목적: 세션 파일의 최대 유지 시간(초)을 설정합니다. 이 시간 이후에 사용되지 않는 세션은 "정크"로 간주됩니다.
권장 설정:
개발 환경: 필요에 따라 조정하고, 보통은 더 짧은 시간을 설정합니다(예: 1440초 = 24분).
생산 환경: 시간이 오래 걸리며, 애플리케이션 요구 사항과 사용자 습관에 따라 설정됩니다.
예를 들어:
일반 전자상거래 플랫폼 : 3600 (1시간)
엔터프라이즈 백엔드 시스템: 7200(2시간) 이상, 예: 14400(4시간).
; 가비지 수집 메커니즘을 활성화합니다. 운영 환경에서는 session.gc_probability = 1, session.gc_divisor = 1000, session.gc_maxlifetime = 14400으로 설정하는 것이 좋습니다. 4시간으로 설정하며, 비즈니스 요구에 따라 조정 가능합니다.
또는 PHP의 가비지 수집 메커니즘에 의존하는 대신, Cron 작업이나 다른 도구를 사용하여 주기적으로 세션 데이터를 정리할 수 있습니다.
/var/lib/lsphp/session/lsphp83 -type f -mmin +240 -delete 찾기
위 명령은 240분 전에 마지막으로 수정된 세션 파일을 정리합니다.
좋아요, 이제 우분투 시스템이 나옵니다하드 디스크 공간이 부족합니다글을 쓸 수 없는 문제가 해결되었습니다!
