Linux 파일 시스템 작동 방식: 인덱스 노드와 디렉터리 항목의 모든 항목은 파일입니다.

Linux 파일 시스템 작동 방식인덱스 노드 및 디렉터리 항목

리눅스의 모든 것은 파일이다. 일반 파일, 디렉터리, 블록 장치, 소켓, 파이프도 통합 파일 시스템을 통해 관리되어야 한다.

Linux는 각 파일에 인덱스 노드와 디렉토리 항목이라는 두 가지 데이터 구조를 할당합니다. 이는 주로 파일의 메타 정보와 디렉토리 구조를 기록하는 데 사용됩니다.

인덱스 노드는 각 파일의 유일한 식별자입니다. 디렉토리 항목은 파일 시스템의 트리 구조를 유지합니다. 이는 간단히 말해서 파일로 이해될 수 있습니다. 여러 이름을 가질 수 있습니다.

하드 링크를 통해 파일에 대해 생성된 별칭은 다른 디렉터리 항목에 해당합니다. 이러한 디렉터리 항목은 기본적으로 여전히 동일한 파일에 연결되어 있으므로 해당 인덱스 노드는 동일합니다.

C 디스크의 가장 작은 단위는 트랙(512B)입니다. 하지만 각각의 읽기 및 쓰기 용량이 너무 작아 효율성이 매우 낮습니다. 따라서 파일 시스템은 연속적인 트랙을 논리 블록으로 구성합니다. 매번 논리 블록은 데이터를 관리하는 최소 단위로 사용됩니다. 4KB는 연속 8트랙으로 구성된다.

두 가지 주의 사항:

가상 파일 시스템

디렉터리 항목, 인덱스 노드, 논리 블록 및 슈퍼 블록은 Linux 파일 시스템의 네 가지 주요 요소를 구성합니다. 다양한 파일 시스템을 지원하기 위해 Linux는 사용자 프로세스와 파일 시스템 사이에 가상 파일 시스템 VFS라는 구체적인 계층을 도입합니다.

VFS는 모든 파일 시스템에서 지원되는 데이터 구조 및 표준 소켓 세트를 정의합니다.

파일 시스템 I/O

I/O 분류: 버퍼링된 I/O와 버퍼링되지 않은 I/O, 직접 및 간접 I/O, 차단 및 비차단 I/O, 동기 및 비동기 I/O.

공간이 부족합니다. df가 C 드라이브를 확인해보니 남은 공간이 많이 남아있습니다

파일 데이터뿐만 아니라 인덱스 노드도 C 드라이브의 공간을 차지하지만 다음 명령을 사용하세요.

df-i

C 드라이브에 inode가 부족하고 공간이 충분한 경우 작은 파일이 너무 많아서 발생할 수 있습니다. 이 문제는 작은 파일을 삭제하거나 충분한 인덱스 노드가 있는 다른 C 드라이브에 연결하여 해결할 수 있습니다.

커널은 Slab 메커니즘을 사용하여 디렉토리 항목 및 인덱스 노드의 캐시를 관리합니다. /proc/meminfo는 Slab의 전체 크기만 제공합니다. 각 Slab 캐시에 대해 /proc/slabinfo도 확인해야 합니다.

스토리지 시스템 I/O 작동 원리:

스토리지 시스템의 I/O는 일반적으로 전체 시스템에서 가장 느린 링크입니다. 따라서 Linux는 다양한 캐싱 메커니즘을 사용하여 I/O 효율성을 최적화합니다. 예를 들어, 파일 액세스 성능을 최적화하기 위해 페이지 캐시, 인덱스 노드 캐시, 디렉토리 엔트리 캐시 등 다양한 캐싱 메커니즘을 사용하여 상위 계층 블록 장치에 대한 직접 호출을 줄입니다. 마찬가지로 블록 장치의 액세스 효율성을 최적화하기 위해 버퍼를 사용하여 블록 장치 데이터를 캐시합니다.

c 드라이브 성능 지표

사용량은 I/O 크기가 아닌 I/O 유무만 고려합니다. 즉, 사용량이 100%일 때 C 드라이브는 여전히 새로운 I/O 요청을 받아들일 수 있습니다

특정 지표를 단독으로 비교할 수는 없지만 데이터베이스의 무작위 읽기-쓰기에서 읽기-쓰기 비율, I/O 유형(임의 또는 연속) 및 I/O 크기를 결합하여 종합적으로 분석해야 합니다. 작은 파일 등 임베디드 Linux를 사용하는 더 많은 시나리오에서 IOPS는 시스템의 전체 성능을 더 잘 반영할 수 있습니다. 멀티미디어와 같이 순차적인 읽기 및 쓰기가 더 많은 시나리오에서는 처리량이 시스템의 전체 성능을 더 잘 반영할 수 있습니다.

이러한 "미친 로깅" 시나리오가 발생하면 iostat, strace, lsof 및 기타 도구를 사용하여 로깅 프로세스를 찾고 해당 로그 파일을 찾은 다음 애플리케이션 소켓을 통해 로그 수준을 조정하여 문제를 해결할 수 있습니다. 애플리케이션이 로그 수준을 동적으로 조정할 수 없는 경우 구성을 적용하려면 애플리케이션의 구성을 변경하고 애플리케이션을 다시 시작해야 할 수도 있습니다.

strace가 이 프로세스를 추적하지만 쓰기 시스템 호출을 감지하지 못하는 이유는 무엇입니까?

파일 쓰기는 하위 스레드에 의해 수행되므로 모든 strace 추적 프로세스에는 쓰기 시스템 호출이 표시되지 않습니다. pstree를 통해 프로세스의 스레드 정보를 본 다음 strace를 사용하여 strace-fppid를 통해 모든 스레드를 추적할 수 있습니다.

느린 쿼리 분석

top과 iostat는 시스템의 CPU와 C 드라이브 사용량을 분석하여 C 드라이브의 I/O 딜레마를 발견했습니다. 그런 다음 pidstat를 사용하여 문제가 mysqld에 의해 발생했음을 확인했습니다. 그런 다음 strace와 lsof

linux 파일 시스템 최적화

를 사용하여 mysqld가 읽고 있는 파일을 찾았습니다. 동시에 파일명과 경로를 통해 mysqld가 운영하고 있는 데이터베이스와 데이터 테이블을 알아냈다. 이 정보를 토대로 우리는 이것이 인덱스를 사용하지 않아 발생하는 쿼리 속도 저하 문제라는 것을 확인했습니다.

데이터 서비스를 중지하면 IO 문제가 사라집니다. 이유는 무엇입니까?

케이스 애플리케이션에서 접근하는 데이터 테이블은 MyISAM 엔진을 기반으로 하며, MyISAM의 특징은 비디오 메모리에 인덱스만 캐시하고 데이터를 캐시하지 않는다는 점입니다. 따라서 쿼리 문장에서 인덱스를 사용할 수 없는 경우 데이터베이스 파일에서 데이터 테이블을 비디오 메모리로 읽어와 처리해야 합니다.

dataservice는 지속적으로 파일 캐시를 해제하므로 mysql이 C 드라이브 캐시에 의존하지 않게 됩니다.

Redis는 먼저 top과 iostat를 사용해 시스템의 CPU, 메모리, C드라이브 사용량을 분석했는데, 시스템 리소스에 딜레마가 없다는 사실을 발견했습니다. 더 자세히 분석하려면 시스템과 애플리케이션의 작동 방식을 어느 정도 이해해야 합니다. 예를 들어 내일의 경우에는 C 디스크 I/O에 딜레마가 없더라도 Redis의 원칙에 따르면 캐시를 쿼리할 때 C 디스크 I/O 쓰기 작업이 많아지면 안 됩니다. 이러한 사고방식에 따라 우리는 pidstat, strace, lsof 및 nsenter와 같은 일련의 도구를 계속 사용하여 두 가지 잠재적인 문제를 발견했습니다. 하나는 Redis의 불합리한 구성이고 다른 하나는 Python 애플리케이션의 Redis 남용이었습니다. I/O 벤치마크 테스트 도구

fio(flexibleI/OTester)

I/O 성능 최적화

앱 최적화

임의 쓰기를 추가 쓰기로 대체하고, 폴링 비용을 줄이고, I/O 쓰기 속도를 높입니다. 캐시된 I/O를 활용Linux 파일 시스템 최적화, 시스템 캐시를 최대한 활용하여 실제 I/O 수를 늘립니다. . 자체 캐싱을 생성하거나 Redis와 같은 외부 캐싱 시스템을 사용합니다. 이러한 방식으로 캐시된 데이터와 수명 주기는 애플리케이션 내에서 제어될 수 있으며, 다른 한편으로는 캐시를 사용하는 다른 애플리케이션이 자체적으로 미치는 영향도 줄일 수 있습니다. C 표준 라이브러리에서 제공하는 fopen, fread 등의 라이브러리 기능은 표준 라이브러리의 캐시를 활용하여 C 드라이브의 동작을 줄입니다. open, read 등의 시스템 콜을 직접 사용할 경우 운영체제에서 제공하는 페이지 캐시와 버퍼만 사용할 수 있고, 동일한 C 디스크 공간을 자주 읽고 써야 하는 경우에는 사용할 수 있는 라이브러리 기능의 캐시가 없습니다. , 읽기/쓰기 대신 mmap을 사용하여 비디오 메모리의 복사본 수를 줄일 수 있습니다. 동기 쓰기가 필요한 시나리오에서는 각 요청을 C 드라이브에 동기적으로 쓰는 대신 쓰기 요청을 병합해 보세요. O_SYNC 대신 fsync()를 사용하여 여러 응용 프로그램에서 동일한 파일을 공유할 수 있습니다. c 드라이브에서 Linux 메모리 관리를 사용할 때 응용 프로그램이 I/O를 완전히 차지하지 않도록 하려면 다음을 사용하는 것이 좋습니다. cgroup의 I/O 하위 시스템을 사용하여 프로세스/프로세스 그룹의 IOPS 및 처리량을 제한할 수 있습니다. CFQ 스케줄러를 사용할 때 ionice를 사용하여 프로세스의 I/O 예약 우선 순위를 조정하고 특히 I/O 우선 순위를 향상시킬 수 있습니다. 핵심 애플리케이션의 ionice는 Idle, Best-effort 및 Realtime의 세 가지 우선 순위 클래스를 지원합니다. 그 중 Best-effort와 Realtime도 각각 0부터 7까지의 레벨을 지원하며, 값이 작을수록 우선순위가 높습니다.

위 내용은 Linux 파일 시스템 작동 방식: 인덱스 노드와 디렉터리 항목의 모든 항목은 파일입니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!