<이전 | 목차 | 다음>

부하 평균이 같더라도 시스템마다 동작 방식이 다르다는 점을 명심하세요. 예를 들어, 하드웨어 가속을 지원하는 그래픽 카드가 장착된 시스템은 3D 이미지 렌더링에 아무런 문제가 없지만, 저렴한 VGA 카드를 장착한 시스템은 렌더링 속도가 크게 느려집니다. 제 오래된 P133은 X 서버를 시작하면 상당히 불편해졌지만, 최신 시스템에서는 시스템 부하 차이를 거의 느낄 수 없습니다.

4.3.5. 사용자로서 무엇이든 할 수 있나요?

규모가 큰 환경은 속도를 저하시킬 수 있습니다. 셸 변수 대신 환경 변수가 많이 설정되어 있고, 최적화되지 않은 긴 검색 경로(경로 환경 변수 설정 오류)가 있으며, 일반적으로 "즉시" 설정되는 설정이 많으면 시스템이 데이터를 검색하고 읽는 데 더 많은 시간이 필요합니다.

X에서 윈도우 관리자와 데스크톱 환경은 CPU를 상당히 많이 소모할 수 있습니다. 정말 멋진 데스크톱은 무료로 다운로드할 수 있더라도, 대부분의 데스크톱이 무한정 추가 기능을 제공하기 때문에 비용이 발생합니다. 겸손

매년 새 컴퓨터를 사지 않는다면 미덕입니다.

4.3.5.1. 우선

작업의 우선순위 또는 중요성은 다음에 의해 정의됩니다. 좋은 nice 값이 높은 프로그램은 다른 프로그램, 다른 사용자, 그리고 시스템에 친화적이며, 중요한 작업이 아닙니다. nice 값이 낮을수록 작업의 중요성이 높아지고, 공유하지 않으면 더 많은 리소스를 소모하게 됩니다.

nice 번호를 높여 작업을 더 nice하게 만드는 것은 CPU 시간을 많이 사용하는 프로세스(컴파일러, 수학 응용 프로그램 등)에만 유용합니다. 항상 많은 I/O 시간을 사용하는 프로세스는 시스템에서 자동으로 보상을 받고 더 높은 우선순위(낮은 nice 번호)를 부여받습니다. 예를 들어, 키보드 입력은 시스템에서 항상 가장 높은 우선순위를 갖습니다.

프로그램의 우선순위 정의는 다음과 같이 수행됩니다. 좋은 명령.

대부분의 시스템은 BSD도 제공합니다. 르니스 명령을 사용하면 다음을 변경할 수 있습니다. 친절 실행 중인 명령의 경우, 시스템별 정보는 매뉴얼 페이지를 참조하세요.

대화형 프로그램

이것은 좋은 생각이 아닙니다 좋은 or 르니스 대화형 프로그램이나 포그라운드에서 실행되는 작업.

이러한 명령어를 사용하는 것은 일반적으로 시스템 관리자의 몫입니다. 시스템 관리자가 사용할 수 있는 추가 기능에 대한 자세한 내용은 매뉴얼 페이지를 참조하세요.

4.3.5.2. CPU 리소스

모든 Linux 시스템에서는 사용자가 시스템에 유일한 사용자일지라도 많은 프로그램이 동시에 CPU를 사용하려고 합니다. 모든 프로그램은 실행을 위해 일정량의 CPU 사이클을 필요로 합니다. CPU가 너무 바빠서 사이클이 충분하지 않은 경우도 있습니다. 가동 시간 이 명령은 매우 부정확합니다(평균값만 표시하기 때문에 정상 범위를 알아야 합니다). 하지만 전혀 쓸모없는 것은 아닙니다. 시스템 응답 속도 저하의 원인이 CPU라고 생각된다면 다음과 같은 조치를 취할 수 있습니다.

• 부하가 낮을 때 무거운 프로그램을 실행하세요. 밤에는 시스템에 문제가 있을 수 있습니다. 스케줄링은 다음 섹션을 참조하세요.

• 시스템이 불필요한 작업을 수행하지 않도록 방지합니다. 사용하지 않는 데몬과 프로그램을 중지하고

무거운 발견 대신에 위치를 찾으세요, ...

• 낮은 우선 순위로 큰 작업 실행

이러한 해결책 중 어느 것도 귀하의 특정 상황에서 사용할 수 없다면 CPU를 업그레이드하는 것이 좋습니다. UNIX 시스템에서는 시스템 관리자가 이 작업을 수행해야 합니다.

4.3.5.3. 메모리 리소스

현재 실행 중인 프로세스가 시스템에서 물리적으로 사용 가능한 것보다 더 많은 메모리를 예상하는 경우 Linux 시스템은 충돌하지 않고 페이징을 시작합니다. 스와핑즉, 프로세스가 디스크 또는 스왑 공간의 메모리를 사용하여 물리적 메모리의 내용(실행 중인 프로그램의 일부 또는 스왑의 경우 전체 프로그램)을 디스크로 옮기고, 이를 통해 물리적 메모리를 회수하여 더 많은 프로세스를 처리합니다. 이렇게 하면 디스크 액세스 속도가 메모리 액세스 속도보다 훨씬 느려져 시스템 속도가 크게 저하됩니다. 상단 명령을 사용하여 메모리 및 스왑 사용량을 표시할 수 있습니다. glibc를 사용하는 시스템은 다음을 제공합니다. 추억 그리고 memusagestat 메모리 사용량을 시각화하는 명령.

메모리와 스왑 공간이 많이 사용되고 있다고 생각되면 다음을 시도해 보세요.

• 메모리의 큰 덩어리를 사용하는 프로그램을 종료, 중지 또는 제거합니다.

• 시스템에 더 많은 메모리(그리고 어떤 경우에는 더 많은 스왑 공간)를 추가합니다.

• 시스템 성능 튜닝은 본 문서의 범위를 벗어납니다. 자세한 내용은 부록 A의 참고 자료를 참조하십시오.

4.3.5.4. I/O 리소스

I/O 제한은 시스템 관리자에게 큰 스트레스 요인이지만, Linux 시스템은 I/O 성능을 측정하는 유틸리티가 다소 부족합니다. ps, vmstat 그리고 상단 도구는 I/O를 기다리고 있는 프로그램의 수에 대한 정보를 제공합니다. NETSTAT 네트워크 인터페이스 통계를 표시하지만 시스템 부하에 대한 I/O 응답을 측정할 수 있는 도구는 사실상 없습니다. iostat 이 명령은 일반적인 I/O 사용법에 대한 간략한 개요를 제공합니다. 이러한 명령의 출력을 사람이 이해하기 쉬운 형태로 제공하기 위해 다양한 그래픽 프런트엔드가 존재합니다.

각 장치에는 고유한 문제가 있지만, 네트워크 인터페이스에 사용 가능한 대역폭과 디스크에 사용 가능한 대역폭은 I/O 성능 병목 현상의 두 가지 주요 원인입니다.

네트워크 I/O 문제:

• 네트워크 과부하:

네트워크를 통해 전송되는 데이터 양이 네트워크 용량보다 많아 모든 사용자의 네트워크 관련 작업 실행 속도가 느려집니다. 이러한 문제는 네트워크 정리(주로 불필요한 프로토콜 및 서비스 비활성화) 또는 네트워크 재구성(예: 서브넷 사용, 허브를 스위치로 교체, 인터페이스 및 장비 업그레이드)을 통해 해결할 수 있습니다.

• 네트워크 무결성 문제:

데이터가 잘못 전송될 때 발생합니다. 이러한 문제는 오류가 발생한 부품을 분리하여 교체하는 방법으로만 해결할 수 있습니다.

디스크 I/O 문제:

• 프로세스당 전송 속도가 너무 낮음:

단일 프로세스의 읽기 또는 쓰기 속도가 충분하지 않습니다.

• 집계 전송 속도가 너무 낮음:

시스템이 실행되는 모든 프로그램에 제공할 수 있는 최대 총 대역폭이 충분하지 않습니다.

이러한 문제는 감지하기가 더 어렵고, 과부하된 하드웨어가 문제의 원인인 경우 버스, 컨트롤러 및 디스크에 걸쳐 데이터 스트림을 재분배하기 위해 일반적으로 추가 하드웨어가 필요합니다. 이 문제를 해결하는 한 가지 방법은 입출력 작업에 최적화된 RAID 어레이 구성을 사용하는 것입니다. 이렇게 하면 동일한 하드웨어를 유지할 수 있습니다. 일반적으로 더 빠른 버스, 컨트롤러 및 디스크로 업그레이드하는 것이 다른 방법입니다.

과부하가 원인이 아니라면 하드웨어가 서서히 고장 나거나 시스템 연결 상태가 좋지 않을 수 있습니다. 먼저 접점, 커넥터, 플러그를 점검해 보세요.

4.3.5.5. 사용자

사용자는 리소스 사용에 대한 동작에 따라 여러 클래스로 구분할 수 있습니다.

• 다수의 소규모 작업을 실행하는 사용자: 예를 들어 Linux 초보자인 여러분.

• 비교적 적지만 대규모 작업을 실행하는 사용자: 시뮬레이션, 계산, 에뮬레이터 또는 많은 메모리를 사용하는 다른 프로그램을 실행하는 사용자이며, 일반적으로 이러한 사용자는 대용량 데이터 파일을 가지고 있습니다.

• 적은 수의 작업을 실행하지만 많은 CPU 시간을 사용하는 사용자(개발자 등).

시스템 요구 사항은 사용자 계층마다 다르며, 모든 사용자를 만족시키기는 어려울 수 있다는 점을 알 수 있습니다. 다중 사용자 시스템을 사용하는 경우, 특정 목적에 맞게 시스템을 최대한 활용하기 위해 다른 사용자와 시스템의 사용 습관을 파악하는 것이 유용하고 재미있습니다.

4.3.5.6. 그래픽 도구

그래픽 환경에서는 다양한 모니터링 도구가 제공됩니다. 아래는 프로세스 정보를 표시하고 검색하며 시스템 리소스를 모니터링하는 기능을 갖춘 Gnome 시스템 모니터의 스크린샷입니다.

그림 4-3. Gnome 시스템 모니터

작업 표시줄에 설치할 수 있는 디스크, 메모리, 부하 모니터 등 편리한 아이콘도 몇 가지 있습니다. 엑스로드 시스템 부하를 모니터링하는 또 다른 작은 X 애플리케이션입니다. 마음에 드는 것을 찾아보세요!

4.3.5.7. 프로세스 중단

권한이 없는 사용자는 자신의 프로세스에만 영향을 미칠 수 있습니다. 특정 사용자에게 속한 프로세스를 표시하고 필터링하는 방법, 그리고 발생할 수 있는 제한 사항에 대해서는 이미 살펴보았습니다. 프로세스 중 하나가 시스템 리소스를 너무 많이 소모하는 경우, 다음 두 가지 조치를 취할 수 있습니다.

1. 프로세스를 방해하지 않고 리소스 사용을 줄입니다.

2. 그 과정을 전부 중단하세요.

프로세스가 계속 실행되기를 원하지만 시스템의 다른 프로세스에도 기회를 주고 싶은 경우 다음을 수행할 수 있습니다. 르니스 프로세스. 사용 외에도 좋은 or 르니스 명령, 상단 문제가 있는 프로세스를 발견하고 우선순위를 낮추는 쉬운 방법입니다.

"NI" 열에 있는 프로세스를 식별하세요. 이 프로세스는 대부분 음수 우선순위를 가질 것입니다. 유형 r 그리고 renice할 프로세스의 프로세스 ID를 입력하세요. 그런 다음 nice 값(예: "20")을 입력하세요. 그러면 이제부터 이 프로세스가 최대 CPU 사이클의 1/5만 사용하게 됩니다.

계속 실행하려는 프로세스의 예로는 에뮬레이터, 가상 머신, 컴파일러 등이 있습니다.

프로세스가 중단되거나 I/O 소모, 파일 생성 또는 기타 시스템 리소스 사용으로 인해 완전히 난동을 부리고 있기 때문에 프로세스를 중지하려면 다음을 사용하십시오. 죽이기 명령입니다. 기회가 있으면 먼저 프로세스를 부드럽게 종료하고 다음 명령을 보내보세요. 시그텀 신호. 이는 프로그램 코드에 설명된 절차에 따라 현재 수행 중인 작업을 종료하라는 명령입니다.

조:~> 추신 -ef | GREP 모질라

joe 25822 1 0 11월XNUMX일 ?

00:34:04 /usr/lib/mozilla-1.4.1/mozilla-

조:~> 추신 -ef | GREP 모질라

joe 25822 1 0 11월XNUMX일 ?

조:~> 죽이기 -15 25822

조:~> 죽이기 -15 25822

위의 예에서 사용자 조 Mozilla 브라우저가 멈췄어요.

일부 프로세스는 제거하기가 조금 더 어렵습니다. 시간이 있다면 SIGINT 신호를 보내 중단시키는 것이 좋습니다. 그래도 문제가 해결되지 않으면 가장 강력한 신호인 SIGKILL을 사용하세요. 아래 예시에서는 조 동결된 Mozilla를 중지합니다.

조:~> 추신 -ef | GREP 모질라

joe 25915 1 0 11월XNUMX일 ?

00:15:06 /usr/lib/mozilla-1.4.1/mozilla-

조:~> 추신 -ef | GREP 모질라

joe 25915 1 0 11월XNUMX일 ?

조:~> 죽이기 -9 25915

조:~> 추신 -ef | GREP 25915

joe 2634 32273 0 18:09 pts/4 00:00:00 grep 25915

조:~> 죽이기 -9 25915

조:~> 추신 -ef | GREP 25915

joe 2634 32273 0 18:09 pts/4 00:00:00 grep 25915

이러한 경우 프로세스가 실제로 종료되었는지 확인하려면 다음을 사용하는 것이 좋습니다. GREP PID에서 다시 필터링합니다. 이것이 다음만 반환하는 경우 GREP 프로세스가 중단되면 프로세스를 중단하는 데 성공했다는 것을 확신할 수 있습니다.

프로세스 중 가장 제거하기 어려운 것 중 하나가 바로 셸입니다. 셸은 좋은 점입니다. 셸을 쉽게 제거할 수 있다면, 입력할 때마다 셸을 잃게 될 테니까요. Ctrl 키-C 이는 SIGINT를 보내는 것과 동일하므로 명령줄에서 실수로 보내는 것입니다.

파이프 없는 UNIX는 거의 상상할 수 없습니다.

파이프(|)를 사용하여 한 명령의 출력을 다른 명령의 입력으로 사용하는 방법은 다음 장인 5장에서 설명합니다.

<이전 | 목차 | 다음>