리눅스 성능튜닝~-리눅스-php.cn

리눅스 성능튜닝~

리눅스 운영체제는 오픈소스 제품이자 오픈소스 소프트웨어의 실천이자 응용 플랫폼이기도 하다. 이 플랫폼에는 Apache, Tomcat, mysql, php 등과 같은 수많은 오픈 소스 소프트웨어 지원이 있습니다. 오픈소스 소프트웨어의 가장 큰 개념은 자유로움과 개방성이다. 따라서 오픈 소스 플랫폼인 Linux의 목표는 이러한 오픈 소스 소프트웨어의 지원을 통해 최저 비용으로 최적의 애플리케이션 성능을 달성하는 것입니다. 성능 문제와 관련하여 주로 달성되는 것은 Linux 운영 체제와 애플리케이션의 최상의 조합입니다.

1. 성능 문제 개요

시스템 성능은 작업을 완료하는 데 있어 운영 체제의 효율성, 안정성 및 응답 속도를 나타냅니다. Linux 시스템 관리자는 시스템 불안정 및 느린 응답 속도와 같은 문제에 자주 직면할 수 있습니다. 예를 들어 Linux에서 웹 서비스를 구축할 때 웹 페이지가 자주 열리지 않고 열림 속도가 느리다고 불평하는 사람들이 있습니다. 리눅스 시스템은 실제로 피상적이지 않습니다. 운영 체제가 작업을 완료하면 시스템 자체 설정, 네트워크 토폴로지, 라우팅 장비, 라우팅 정책, 액세스 장비, 물리적 회선 및 기타 측면과 밀접한 관련이 있습니다. 모든 링크의 문제는 전체 시스템의 성능에 영향을 미칩니다. 따라서 리눅스 응용프로그램에서 문제가 발생하면 응용프로그램, 운영체제, 서버하드웨어, 네트워크 환경 등을 종합적으로 조사하여 문제가 발생한 부분을 찾아 중앙에서 해결해야 한다.

애플리케이션, 운영 체제, 서버 하드웨어, 네트워크 환경 등의 측면에서 성능에 가장 큰 영향을 미치는 두 가지 측면은 애플리케이션과 운영 체제입니다. 이 두 측면의 문제는 감지하기 어렵고 고도로 은폐되기 때문입니다. 하드웨어나 네트워크에 문제가 있는 한 일반적으로 즉시 찾을 수 있습니다. 다음은 주로 운영 체제에 대한 성능 조정 아이디어를 자세히 설명합니다.

다음은 Linux 성능에 영향을 미치는 요소, 성능 분석에 참여하는 사람, 시스템 성능 최적화 도구, 시스템 성능 평가 기준이라는 네 가지 측면에서 Linux를 최적화하는 일반적인 아이디어와 방법을 소개합니다.

2. Linux 성능에 영향을 미치는 요인

2.1 시스템 하드웨어 리소스

1． CPU

CPU는 운영 체제의 안정적인 작동을 위한 기반입니다. CPU의 속도와 성능은 시스템 전체 성능에 큰 영향을 미칩니다. 따라서 CPU가 많을수록, 주 주파수가 높을수록 서버 성능이 좋아집니다. 될거야. 그러나 그것은 전적으로 사실이 아닙니다.

현재 대부분의 CPU는 동시에 하나의 스레드만 실행할 수 있습니다. 하이퍼 스레드 프로세서는 동시에 여러 스레드를 실행할 수 있으므로 프로세서의 하이퍼 스레드 기능을 사용하여 시스템 성능을 향상시킬 수 있습니다. Linux 시스템에서 하이퍼스레딩은 SMP 커널을 실행할 때만 지원되지만 더 많은 CPU를 설치할수록 하이퍼스레딩으로 얻을 수 있는 성능 이점은 줄어듭니다. 또한 Linux 커널은 멀티 코어 프로세서를 여러 개의 개별 CPU로 인식합니다. 예를 들어 Lnux 시스템에서는 2개의 4코어 CPU가 8개의 단일 코어 CPU로 간주됩니다. 그러나 성능 측면에서 2개의 4코어 CPU와 8개의 싱글 코어 CPU는 완전히 동일하지 않습니다. 권위 있는 부서에서 도출한 테스트 결론에 따르면 전자의 전체 성능은 후자보다 25%~30% 낮습니다.

CPU 병목 현상이 발생할 수 있는 애플리케이션에는 DB 서버, 동적 웹 서버 등이 포함됩니다. 이러한 애플리케이션의 경우 CPU 구성 및 성능이 우선적으로 고려되어야 합니다.

2. 추억

메모리 크기도 Linux 성능에 영향을 미치는 중요한 요소입니다. 메모리가 너무 작으면 시스템 프로세스가 차단되고, 메모리가 너무 크면 애플리케이션이 느려지거나 응답하지 않게 되므로 리소스가 낭비됩니다. Linux 시스템에서는 물리적 메모리와 가상 메모리라는 두 가지 방법을 사용합니다. 가상 메모리는 물리적 메모리 부족을 완화할 수 있지만 너무 많은 가상 메모리를 차지하면 고성능 작업을 보장하기 위해 애플리케이션 성능이 크게 저하됩니다. 애플리케이션의 물리적 메모리는 충분히 커야 하지만 물리적 메모리가 너무 크면 메모리 리소스가 낭비됩니다. 예를 들어 32비트 프로세서를 사용하는 Linux 운영 체제에서는 8GB를 초과하는 물리적 메모리가 낭비됩니다. 따라서 더 큰 메모리를 사용하려면 64비트 운영 체제를 설치하고 Linux의 대용량 메모리 커널 지원을 활성화하는 것이 좋습니다.

프로세서의 주소 지정 범위 제한으로 인해 32비트 Linux 운영 체제에서는 단일 응용 프로그램 프로세스가 최대 4GB의 메모리만 사용할 수 있습니다. 이러한 방식으로 시스템에 더 큰 메모리가 있어도 응용 프로그램은 " 즐겨보세요. 해결 방법은 64비트 프로세서를 사용하고 64비트 운영 체제를 설치하는 것입니다. 64비트 운영 체제에서는 모든 애플리케이션의 메모리 사용 요구 사항을 거의 제한 없이 충족할 수 있습니다.

메모리 성능 병목 현상이 발생할 수 있는 애플리케이션에는 NOSQL 서버, 데이터베이스 서버, 캐시 서버 등이 있습니다. 이러한 애플리케이션의 경우 메모리 크기에 우선순위를 두어야 합니다.

3． 디스크 I/O 성능

디스크 I/O 성능은 애플리케이션 성능에 직접적인 영향을 미칩니다. 자주 읽고 쓰는 애플리케이션에서는 디스크 I/O 성능이 충족되지 않으면 애플리케이션이 정체됩니다. 다행스럽게도 오늘날의 디스크는 I/O 성능을 향상시키기 위해 일반적인 디스크 RAID 기술과 같은 다양한 방법을 사용합니다.
RAID 기술로 구성된 디스크 그룹은 대용량 하드 디스크와 동일하며, 사용자는 해당 디스크에서 파티션 포맷, 파일 시스템 생성 등의 작업을 수행할 수 있으며, 유일한 차이점은 I/O입니다. 단일 하드 드라이브의 성능 비율이 훨씬 높으며 데이터 보안도 크게 향상됩니다.

다양한 디스크 조합 방법에 따라 RAID는 RAID0, RAID1, RAID2, RAID3, RAID4, RAID5, RAID6, RAID7, RAID0+1, RAID10 및 기타 레벨로 나눌 수 있으며 일반적으로 사용되는 RAID 레벨은 RAID0, RAID1, RAID5, RAID0입니다. +1. 간단한 소개입니다.

“

RAID 0: 여러 하드 드라이브를 더 큰 용량의 하드 드라이브 그룹에 결합하여 디스크 성능과 처리량을 향상시킵니다. 이 방법은 비용이 저렴하고 디스크가 2개 이상 필요하지만 내결함성 및 데이터 복구 기능이 없으므로 높은 데이터 보안이 요구되지 않는 환경에서만 사용할 수 있습니다.
RAID 1: 즉, 디스크 미러링입니다. 한 디스크의 데이터를 다른 디스크로 미러링하여 디스크 데이터의 신뢰성과 복구 가능성을 극대화하지만 디스크 활용도는 50%에 불과합니다. 따라서 비용이 가장 높으며 중요한 데이터를 저장하는 상황에서 주로 사용됩니다.
RAID5: 디스크 분할 및 패리티 검사 기술을 사용하여 시스템 안정성을 향상합니다. RAID5는 읽기 효율성과 평균 쓰기 효율성이 높으며 최소 3개의 디스크가 필요합니다. 데이터 가용성에 영향을 주지 않고 디스크 장애를 허용합니다.
RAID0+1: RAID0과 RAID1 기술을 결합하면 RAID0+1이 되며 최소 4개의 하드 드라이브가 필요합니다. 이 방법의 데이터가 여러 디스크에 분산되는 것 외에도 각 디스크에는 자체 미러 디스크가 있어 전체 중복성을 제공하여 데이터 가용성에 영향을 주지 않고 하나의 디스크 오류를 허용하고 빠른 읽기/쓰기 기능을 제공합니다.

”

각 RAID 수준의 성능을 이해하면 애플리케이션의 다양한 특성에 따라 적합한 RAID 수준을 선택할 수 있으므로 애플리케이션이 최적의 디스크 성능을 달성할 수 있습니다.

4. 인터넷 광대역

Linux의 다양한 애플리케이션은 일반적으로 네트워크를 기반으로 하기 때문에 네트워크 대역폭도 성능에 영향을 미치는 중요한 요소입니다. 네트워크가 느리고 불안정하면 네트워크 애플리케이션 액세스가 차단되고, 안정적이고 빠른 네트워크 대역폭을 사용하면 네트워크 애플리케이션 액세스가 차단됩니다. 애플리케이션이 네트워크에서 원활하게 실행되도록 보장합니다. 다행스럽게도 오늘날의 네트워크는 일반적으로 기가비트 대역폭 또는 광섬유 네트워크이며 대역폭 문제가 애플리케이션 성능에 미치는 영향은 점차 줄어들고 있습니다.

2.2 운영 체제 관련 리소스

운영 체제를 기반으로 한 성능 최적화도 다면적이며 시스템 설치, 시스템 커널 매개변수, 네트워크 매개변수, 파일 시스템 등과 같은 여러 측면에서 측정할 수 있습니다. 아래에 간략하게 소개되어 있습니다.

1． 시스템 설치 최적화

시스템 최적화는 운영 체제 설치부터 시작할 수 있습니다. Linux 시스템을 설치할 때 디스크 파티셔닝 및 SWAP 메모리 할당은 시스템의 향후 운영 성능에 직접적인 영향을 미칩니다. 예를 들어 디스크 할당은 애플리케이션의 요구 사항을 따를 수 있습니다.

빈번한 쓰기 작업이 필요하지만 데이터 보안 요구 사항이 낮은 애플리케이션의 경우 디스크를 RAID 0으로 만들 수 있습니다. 데이터 보안이 높고 읽기 및 쓰기에 대한 특별한 요구 사항이 없는 애플리케이션의 경우 디스크를 RAID 1로 만들 수 있습니다.
읽기 작업에 대한 요구 사항은 높지만 쓰기 작업에 대한 특별한 요구 사항은 없으며 데이터 보안을 보장하려는 애플리케이션의 경우 RAID 5를 선택할 수 있습니다.
이러한 방식으로 다양한 애플리케이션 요구 사항에 따라 다양한 RAID 레벨이 설정되고 시스템이 디스크 하단에서 최적화됩니다.

메모리가 작은 경우(물리적 메모리가 4GB 미만) 일반적으로 SWAP 스왑 파티션 크기를 메모리의 2배로 설정합니다. 실제 메모리가 8GB보다 크고 16GB보다 작은 경우 SWAP 크기를 실제 메모리와 같거나 약간 작게 설정할 수 있습니다.
2. 커널 매개변수 최적화

예를 들어 시스템이 Oracle 데이터베이스 애플리케이션을 배포하는 경우 시스템 공유 메모리 세그먼트(kernel.shmmax, kernel.shmmni, kernel.shmall), 시스템 세마포(kernel.sem) 및 파일 핸들(fs)을 구성해야 합니다. .file-max) 및 기타 매개변수, 웹 애플리케이션을 배포하는 경우 net.ipv4.ip_local_port_range, net.ipv4.tcp_tw_reuse와 같은 네트워크 커널 수정과 같이 웹 애플리케이션의 특성에 따라 네트워크 매개변수를 최적화해야 합니다. , net.core.somaxconn 등의 매개변수입니다.

3. 파일 시스템 최적화

파일 시스템 최적화는 시스템 리소스 최적화의 초점이기도 합니다. Linux의 선택적 파일 시스템에는 ext2, ext3, ReiserFS, ext4 및 xfs가 포함됩니다.

Linux 표준 파일 시스템은 VFS에서 시작하고 ext2를 거쳐 ext2가 Linux의 표준 파일 시스템이라고 해야 할까요. ext3은 VFS에서 ext4까지 로그를 추가하여 구성됩니다. 많은 변경 사항은 없으며 모두 슈퍼 블록과 inode를 기반으로 하는 초기 UNIX 제품군의 설계 개념을 기반으로 합니다.

XFS 파일 시스템은 디스크 요청을 분산하고, 데이터를 찾고, 캐시 일관성을 유지함으로써 파일 시스템 데이터에 대한 낮은 대기 시간, 고대역폭 액세스를 제공하는 고급 로그 파일 시스템입니다. 뛰어난 로깅 기능, 강력한 확장성 및 빠른 쓰기 성능을 제공합니다.

현재 서버측 ext4와 xfs가 주류 파일 시스템입니다. 적합한 파일 시스템을 선택하는 방법은 파일 시스템의 특성과 비즈니스 요구에 따라 결정되어야 합니다.

애플리케이션 최적화는 실제로 전체 최적화 프로젝트의 핵심입니다. 애플리케이션에 BUG가 있으면 다른 모든 측면이 최적 상태에 도달하더라도 전체 애플리케이션 시스템의 성능은 여전히 낮습니다. 애플리케이션 최적화는 프로그램 설계자와 프로그램 개발자에게 더 높은 요구 사항을 제시하는 성능 최적화 프로세스입니다.

3. 시스템 성능 분석에 참여하는 인력

3.1, 리눅스 운영 및 유지보수 인력

성능 최적화 과정에서 Linux 운영 및 유지 관리 담당자는 매우 중요한 작업을 수행합니다.

성능 최적화 자체는 복잡하고 지루한 과정입니다. Linux 운영 및 유지 관리 담당자가 시스템 하드웨어 정보, 네트워크 정보, 운영 체제 구성 정보 및 응용 프로그램 정보를 이해해야만 Linux 운영 및 유지 관리가 필요한 서버 성능의 목표 최적화를 수행할 수 있습니다. 유지보수 인력은 충분한 이론적 지식, 풍부한 실무 경험, 문제를 신중하게 분석할 수 있는 정신을 갖추고 있습니다.

시스템 성능 최적화에 관여하는 두 번째 유형의 인력은 애플리케이션 설계자입니다. Linux 운영 및 유지 관리 담당자가 종합적인 판단을 거쳐 애플리케이션의 실행 효율성이 성능에 영향을 미친다는 사실을 알게 되면 프로그램 아키텍처 설계자는 적시에 개입하여 프로그램의 실행 상태를 심층적으로 이해해야 합니다.

우선, 시스템 아키텍처 설계자는 프로그램의 실행 효율성을 추적하고 이해해야 합니다. 실행 효율성에 문제가 있는 경우 문제가 어디에 있는지 찾아내야 합니다. 둘째, 아키텍처 설계에 실제로 문제가 있는 경우 시스템 아키텍처를 즉시 최적화하거나 개선하고 더 나은 애플리케이션 시스템 아키텍처를 설계해야 합니다.

3.3, 소프트웨어 개발자
시스템 성능 최적화의 마지막 단계에는 프로그램 개발자가 참여합니다. Linux 운영 및 유지 관리 담당자 또는 아키텍처 설계자가 프로그램이나 구조적 병목 현상을 발견하면 프로그램 개발자는 즉시 개입하여 해당 프로그램을 수정해야 합니다. 프로그램을 수정할 때에는 프로그램의 실행 효율성을 기준으로 프로그램의 로직을 개선하고 코드를 목표에 맞게 최적화해야 합니다. 예를 들어, Linux 운영 및 유지 관리 담당자는 시스템 리소스를 많이 소비하는 SQL 문을 발견했으며, 실행된 SQL 문을 캡처하여 이 SQL 문의 실행 효율성이 너무 낮다는 사실을 발견했습니다. 이는 실행 속도가 낮기 때문입니다. 개발자가 작성한 코드의 효율성을 높이려면 개발자에게 이 정보를 피드백해야 합니다. 이 질문을 받은 후 개발자는 대상 SQL 최적화를 수행하여 프로그램 코드를 최적화할 수 있습니다.
위 프로세스에서 볼 수 있듯이 시스템 성능 최적화를 위해 일반적으로 따르는 프로세스는 다음과 같습니다.
먼저, Linux 운영 및 유지보수 담당자는 시스템의 전반적인 상태를 점검하며, 주로 시스템 하드웨어, 네트워크 장비, 운영 체제 구성, 애플리케이션 아키텍처, 프로그램 코드 등 5가지 측면에서 종합적인 판단을 내립니다. 하드웨어, 네트워크 장비 또는 운영 체제 구성, Linux 운영 및 유지 관리 담당자가 상황에 따라 독립적으로 문제를 해결할 수 있습니다.

프로그램 구조에 문제가 있는 것으로 확인되면 프로그램 설계자에게 제출해야 합니다.

프로그램 코드 실행에 문제가 있는 것으로 확인되면 코드 최적화를 위해 개발자에게 전달됩니다.

이것으로 시스템 성능 최적화 프로세스가 완료됩니다.

4. 튜닝 요약시스템 성능 최적화는 광범위하고 지루하며 장기적인 작업입니다. 성능 문제의 근본 원인을 찾는 것이 가장 어려운 부분인 경우가 많습니다. 문제의 원인을 찾으면 성능 문제는 쉽게 해결됩니다. 따라서 문제 해결 아이디어가 매우 중요해집니다.
예를 들어 Linux 시스템의 웹사이트 시스템의 경우 웹사이트 접속 속도가 매우 느리고 가끔 접속이 불가능하다는 사용자들의 신고가 있었습니다.
이 질문에 대한 답변:
첫 번째 단계는 네트워크를 감지하는 것입니다. ping 명령을 사용하여 웹사이트의 도메인 이름 확인이 정상적인지 확인하는 동시에 서버 주소에 대한 핑 지연이 너무 큰지 등을 확인할 수 있습니다. 네트워크에 문제가 없다면 먼저 네트워크에서 발생할 수 있는 문제를 제거할 수 있습니다

그런 다음 두 번째 단계로 들어가 Linux 시스템의 메모리 사용량을 확인합니다. 웹 사이트 응답 속도가 느리기 때문에 일반적으로 메모리와 관련이 있습니다. 메모리 리소스가 부족한지 확인하려면 free, vmstat 및 기타 명령을 사용하십시오. 메모리 리소스에는 문제가 없습니다

세 번째 단계로 들어가면 시스템 CPU의 로드 상태를 확인할 수 있습니다. CPU에 문제가 없는지 sar, vmstat, top 등의 출력을 통해 CPU에 과부하 문제가 있는지 종합적으로 판단할 수 있습니다.
4단계로 진행하여 시스템의 디스크 I/O에 병목 현상이 발생하는지 확인합니다. 디스크 읽기 및 쓰기에 문제가 없으면 iostat, vmstat 등의 명령을 통해 디스크의 읽기 및 쓰기 성능을 확인할 수 있습니다. 리눅스 시스템 자체의 성능 문제는 기본적으로 해소되어야 합니다. 마지막으로 하는 일은 프로그램 자체에 문제가 있는지 확인하는 것입니다. 이러한 사고 방식을 통해 계층별 감지 및 단계별 문제 해결을 통해 성능 문제는 "숨길 곳이 없게" 되며 성능 문제가 발생한 링크를 찾는 것이 매우 간단해집니다.