linux 성능 최적화

성능 최적화의 핵심은 시스템의 병목점을 찾아내는 것이다. 문제를 찾았고 최적화 작업도 절반을 완성했다.여기서 소개한 성능 최적화는 주로 두 가지 측면에서 소개한다. 그것이 바로 시스템 차원과 프로그램 차원이다.
시스템 병목 현상 분석
시스템 응답이 느려지면 먼저 대체적인 문제가 어디에서 발생하는지, IO 병목, CPU 병목, 메모리 병목인지 프로그램이 초래한 시스템 문제인지 포지셔닝해야 한다.
top 도구를 사용하면 우리가 주목하는 점을 비교적 전면적으로 볼 수 있다.

$top
    top - 09:14:56 up 264 days, 20:56,  1 user,  load average: 0.02, 0.04, 0.00
    Tasks:  87 total,   1 running,  86 sleeping,   0 stopped,   0 zombie
    Cpu(s):  0.0%us,  0.2%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.2%st
    Mem:    377672k total,   322332k used,    55340k free,    32592k buffers
    Swap:   397308k total,    67192k used,   330116k free,    71900k cached
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    1 root      20   0  2856  656  388 S  0.0  0.2   0:49.40 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      20   0     0    0    0 S  0.0  0.0   7:15.20 ksoftirqd/0
    4 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/

대화식 모드로 전환한 후:
4

M을 입력하고 프로세스 목록은 메모리의 사용 크기에 따라 순서를 낮추어 정렬하면 최대 메모리 사용자의 사용에 문제가 있음을 관찰할 수 있다(메모리 유출 문제를 검출한다)

4

P를 입력하고 프로세스 목록은 CPU 사용 크기에 따라 순서를 낮추어 정렬하면 우리가 CPU 자원을 가장 소모하는 사용자에게 문제가 있는지 관찰할 수 있다

top 세 번째 행에는 현재 시스템의 값이 두 가지 중요합니다.
4

%id: 유휴 CPU 시간 백분율, 이 값이 너무 낮으면 시스템 CPU에 병목이 있음을 나타낸다

4

%wa: 입출력을 기다리는 CPU 시간 백분율입니다. 이 값이 너무 높으면 입출력에 병목이 있음을 나타냅니다

메모리 병목 현상 분석
메모리에 병목이 있는지 확인하려면 top 명령을 사용하는 것이 번거롭고free 명령은 더욱 직관적이다.

[/home/weber#]free
             total       used       free     shared    buffers     cached
Mem:        501820     452028      49792      37064       5056     136732
-/+ buffers/cache:     310240     191580
Swap:            0          0          0
[/home/weber#]top
top - 17:52:17 up 42 days,  7:10,  1 user,  load average: 0.02, 0.02, 0.05
Tasks:  80 total,   1 running,  79 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    501820 total,   452548 used,    49272 free,     5144 buffers
KiB Swap:        0 total,        0 used,        0 free.   136988 cached Mem

top 도구는free 도구의 첫 줄에 있는 모든 정보를 표시하지만 실제 사용할 수 있는 메모리는 스스로 계산해야 알 수 있습니다.시스템에서 실제 사용할 수 있는 메모리는free 도구로 두 번째 줄의free+buffer+cached를 출력합니다.즉 세 번째 줄의free값 191580;free 명령의 각 값에 대한 상세한 해석은 이 글에서 사용할 수 있는 메모리를 참고하십시오.
메모리가 부족하면 시스템 응답이 느려지는 것이 뚜렷하다. 왜냐하면 이것은 시스템이 끊임없이 바꾸는 작업을 하기 때문이다.
더 나아가 메모리 사용 상황을 감시하고 vmstat 도구를 사용하여 운영체제의 메모리와 가상 메모리의 동적 변화를 실시간으로 동적 감시할 수 있다.참고: vmstat에서 메모리 사용 상황 감시하기;
입출력 병목 현상 분석
IO에 성능 병목이 존재하면 top 도구의%wa가 높습니다.
Iostat 도구를 사용한 추가 분석:

/root$iostat -d -x -k 1 1
Linux 2.6.32-279.el6.x86_64 (colin)   07/16/2014      _x86_64_        (4 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.02     7.25    0.04    1.90     0.74    35.47    37.15     0.04   19.13   5.58   1.09
dm-0              0.00     0.00    0.04    3.05     0.28    12.18     8.07     0.65  209.01   1.11   0.34
dm-1              0.00     0.00    0.02    5.82     0.46    23.26     8.13     0.43   74.33   1.30   0.76
dm-2              0.00     0.00    0.00    0.01     0.00     0.02     8.00     0.00    5.41   3.28   0.00

4

%iowait의 값이 너무 높으면 하드 드라이브에 I/O 병목 현상이 있음을 나타냅니다

4

%util이 100%에 육박하면 입출력 요청이 너무 많고 입출력 시스템이 부하가 차서 디스크에 병목이 있을 수 있습니다

4

svctm가await에 가깝다면 입출력이 대기시간이 거의 없음을 의미한다

4

await가svctm보다 크면 입출력 대기열이 너무 길고io 응답이 너무 느리면 최적화가 필요하다

4

만약에 avgqu-sz가 비교적 크다면 IO가 대량으로 기다리고 있음을 나타낸다

더 많은 파라미터 설명은 iostat을 참고하여 입출력 서브시스템을 감시하십시오.
분석 프로세스 호출
top 등 도구를 통해 시스템 성능 문제가 특정한 프로세스에서 발생한 것을 발견한 후에 우리는 이 프로세스를 분석해야 한다.질문이 어디에 있는지 계속 조회하기;
여기에 우리는 두 가지 유용한 도구가 있다: pstack과 pstrace
pstack은 프로세스 창고를 추적하는데 이 명령은 프로세스 문제를 조사할 때 매우 유용하다. 예를 들어 우리는 서비스가work상태(예를 들어 가사상태, 사순환상태)에 있는 것을 발견하고 이 명령을 사용하면 문제를 쉽게 포착할 수 있다.일정 시간 내에 pstack을 몇 번 더 실행할 수 있다. 만약에 코드 창고가 항상 같은 위치에 멈추는 것을 발견하면 그 위치는 중점적으로 주목해야 한다. 문제가 생긴 곳일 가능성이 높다.
예: bash 프로그램 프로세스 스택을 보려면 다음과 같이 하십시오.

/opt/app/tdev1$ps -fe| grep bash
tdev1   7013  7012  0 19:42 pts/1    00:00:00 -bash
tdev1  11402 11401  0 20:31 pts/2    00:00:00 -bash
tdev1  11474 11402  0 20:32 pts/2    00:00:00 grep bash
/opt/app/tdev1$pstack 7013
#0  0x00000039958c5620 in __read_nocancel () from /lib64/libc.so.6
#1  0x000000000047dafe in rl_getc ()
#2  0x000000000047def6 in rl_read_key ()
#3  0x000000000046d0f5 in readline_internal_char ()
#4  0x000000000046d4e5 in readline ()
#5  0x00000000004213cf in ?? ()
#6  0x000000000041d685 in ?? ()
#7  0x000000000041e89e in ?? ()
#8  0x00000000004218dc in yyparse ()
#9  0x000000000041b507 in parse_command ()
#10 0x000000000041b5c6 in read_command ()
#11 0x000000000041b74e in reader_loop ()
#12 0x000000000041b2aa in main ()

strace는 프로세스의 시스템 호출을 추적하는 데 사용된다.이 도구는 프로세스가 실행될 때의 시스템 호출과 수신 신호를 동적으로 추적할 수 있습니다.매우 효과적인 검사, 지도, 디버깅 도구이다.시스템 관리자는 이 명령을 통해 프로그램 문제를 쉽게 해결할 수 있다.
참고:strace 추적 프로세스의 시스템 호출;
최적화 프로그램 코드
자체 개발한 프로그램을 최적화하려면 다음 지침을 따르는 것이 좋습니다.
4

28법칙: 어떤 그룹의 물건 중에서 가장 중요한 것은 그 중의 작은 부분, 약 20%를 차지하고 나머지 80%는 다수이지만 부차적인 것이다.최적화 실천에서 우리는 그 20%의 가장 소모되는 코드를 최적화하는 데 정력을 집중하여 전체적인 성능이 현저하게 향상될 것이다.이것은 이해하기 쉽다.함수 A는 코드량이 많지만 정상적인 실행 절차에서 한 번만 호출된다.또 다른 함수인 B 코드는 A보다 양이 훨씬 적지만 1000번 호출되었다.분명히 우리는 B의 최적화에 더욱 관심을 가져야 한다

4

코드를 작성하고 최적화한다.인코딩을 할 때 항상 최상의 성능을 고려하는 것이 반드시 좋은 것은 아니다.최상의 성능을 강조하는 인코딩 방식과 동시에 코드의 가독성과 개발 효율을 잃을 수 있다

gprof 사용 절차
4

gcc, g++, xlC 컴파일러를 사용할 때 -pg 매개 변수를 사용합니다. 예를 들어 g++-pg-o test.exe test.cpp컴파일러는 자동으로 목표 코드에 성능 테스트에 사용되는 코드 단편을 삽입합니다. 이 코드는 프로그램이 실행될 때 함수의 호출 관계와 호출 횟수를 수집하고 기록하며 함수 자체의 실행 시간과 호출된 함수의 실행 시간을 기록합니다

4

컴파일된 실행 프로그램(예:./test.exe.이 절차의 실행 시간은 정상적으로 컴파일된 실행 가능한 프로그램의 실행 시간보다 조금 느릴 것이다.프로그램 실행이 끝난 후, 프로그램이 있는 경로 아래에 gmon이라는 부족한 파일을 생성합니다.out의 파일, 이 파일은 프로그램이 실행하는 성능, 호출 관계, 호출 횟수 등 정보를 기록하는 데이터 파일입니다

4

gprof 명령을 사용하여 프로그램의 운행 정보를 기록하는 gmon을 분석한다.out 파일, 예: gprof test.exe gmon.out은 디스플레이에서 함수 호출과 관련된 통계, 분석 정보를 볼 수 있다.상술한 정보도 gprof test를 채택할 수 있다.exe gmon.out> gprofresult.txt는 후속 분석을 위해 텍스트 파일로 방향을 바꿉니다

gprof의 사용 사례에 관하여 [f1]를 참고하십시오.
기타 도구
메모리 유출을 디버깅하는 도구valgrind, 관심 있는 분들은 구글에서 알 수 있습니다.
Oprofile: Linux 플랫폼의 강력한 성능 분석 도구로 참조[f2];
위에서 소개한 도구를 제외하고 비교적 전면적인 성능 분석 도구도 있다. 예를 들어sar(Linux시스템에서 기본적으로 설치하지 않기 때문에 수동으로 설치해야 한다).sar의 상주 모니터링 도구를 열면 비교적 전면적인 성능 분석 데이터를 수집할 수 있다.
sar의 사용에 관하여sar를 참고하여 시스템의 병목을 찾아내는 유리한 도구를 찾아낸다.
[f1]
C++의 성능 최적화 실천http://www.cnblogs.com/me115/archive/2013/06/05/3117967.html
[f2]
Oprofile로 성능 파악http://www.ibm.com/developerworks/cn/linux/l-oprof/
[f3]
Linux의 free 명령 설명http://www.cnblogs.com/coldplayerest/archive/2010/02/20/1669949.html