developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

모든 정보가 안전하게 전송되었습니다.

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

모든 정보가 안전하게 전송되었습니다.

My developerWorks：

나의 통지：

로그아웃

언어 선택：

리눅스 퍼포먼스 향상

시스템 향상에 대한 실용 예제

Cameron Laird, 부회장, Phaseit, Inc.

Cameron Laird는 Phaseit, Inc.의 전임 개발자이다.

요약： 애플리케이션을 개발할 때 발생할 수 있는 퍼포먼스 문제들을 모델링한 유용한 예제들을 소개한다.

여기에 태그 달기!

원문 게재일: 2003 년 4 월 10 일
난이도: 초급
페이지뷰： 883 회
의견：

퍼포먼스 향상은 두 가지로 나뉘는 것 같다. 쉽거나 어렵거나! 장난처럼 들리는가? 이 둘 사이의 경계는 놀라울 정도로 명확하다.

좋은 프로그래머는 어려운 모드에서나 쉬운 모드에서나 작동시킬 수 있다. 퍼포먼스는 리눅스 프로그래머에게 중요한 주제이다.

언제나 요구사항(requirements)으로 시작한다.

죽음과 세금은 불가피성이라는 공통점이 있다. 개발자들에게 이와 거의 비슷한 정도의 중요성의 의미를 띄는 것이 요구사항에 대한 신중한 고려이다. 이것은 모든 프로그래밍의 주제이다.

퍼포먼스는 확실히 중요하지만 이 요구사항을 다루는 최상의 방법은 항상 명확한 것은 아니다. 나는 다음과 같은 유형을 따르는 소프트웨어 도전을 반복해서 경험했다: 프로그램이 실행되고 있다. 이것의 기능은 정확하다. 그럼에도 불구하고 사용자는 이를 멈추고 "너무 느리다"는 리포트를 보내고 업그레이드를 요청한다. 팀의 누군가는 퍼포먼스를 약간 느리게 하는 것을 모니터에서 해킹(hack)하지만 사용자는 오랜 실행시간 중 남은 시간이 얼마인지를 계속해서 보게된다.

나는 이런 현상을 1960년대 후반에 처음 발견했고 그 이후에 십년 마다 경험했다. 내 생각으로는 이것은 컴퓨팅의 시작 단계에서 부터 있었던 것 같다. 중요한 것은 사용자가 속고 있거나 빛나는 장식에 마음을 빼앗겨서가 아니다. 그들은 퍼포먼스에 대한 우리들의 편협한 전문가적 생각보다 더 큰 목표를 갖고 있다. 많은 경우 그들은 전산이 빨라져야 한다라고 말할 때 그것이 진실로 의미하는 것은 전산이 얼마나 오래 걸릴 것인가에 대해 빠르고 신뢰성있는 답을 듣고 싶다는 것이다. 그 스코어에 대한 정확한 정보를 가지고 사용자는 컴퓨터 지연 시간동안 다른 태스크 스케줄을 짜면서 행복해 할 수 있다.

위로

두 개의 countdown 예제

긴 계산을 수행하는 동시에 진행 모델에 대한 정보를 사용자가 볼 수 있도록 하는 것은 애플리케이션 디자인에 있어서 재미있는 문제이다. 이것은 병행성(concurrency) 또는 "멀티태스킹"의 한 예이다. 많은 개발자들은 병행성이 정교한 메커니즘을 필요로 하고 적절한 솔루션을 위해 어려운 쓰레딩 코드가 특히 필요하다고 믿고 있다.

이것은 사실이 아니다. 단순한 병행 프로그래밍은 1988년 이후 모든 유닉스 호스트에서 사용할 수 있었다. 이 때는 ksh가 "공동 프로세스(co-processes)"를 표준화했을 때이다. 아래 Listing 1의 ksh 소스를 ex1.ksh로 저장하고 이를 실행하면 "카운트다운(10, 9, 8..)" 디스플레이를 보게된다. 그리고 나서 "All done" 이라는 ksh 하위 프로세스 결과가 나온다. 실제로는 오랫동안 실행되는 화학 계산이나 데이터베이스 검색에 사용한다. 하위 프로세스로서 실행을 시작하지만 사용자들은 무엇이 진행되는지 또는 완료까지 얼마나 남았는지에 대한 정보를 받게된다. 두 줄의 소스 코드로 디스플레이를 업데이트 할 수 있다.

Listing 1. ksh 소스 코드: 카운트다운 디스플레이

        (echo "This models a long-lasting process"; sleep 10;
                                        echo "All done") |&
        for ((i = 10; i > 0; i--))
        do
            printf "%2d seconds before completion ...\r" $i
            sleep 1
        done

        read -p line;      # Discard the title line.
        read -p line
        echo ""
        echo "Output from the sub-process is '$line'."

사용자에 대한 "실시간(Real-time)" 정보는 약간의 코딩 정도만 필요하다. 심지어 캐릭터 기반의 애플리케이션도 이를 수행할 수 있다. GUI가 당신의 상황에 더 맞다면 그것 역시 쉽다. 많은 툴킷들이 "busy", "waiting", "progress" 디스플레이를 구현한다. 이를 구할 수 없다면 몇 줄의 Tk 또는 다른 GUI 툴킷으로 충분하다:

Listing 2. Tk 소스 코드: 카운트다운 디스플레이

      proc countdown {seconds} {
          init
          countdown_kernel $seconds
      }
      
      
      proc countdown_kernel seconds {
          hands $seconds
          if !$seconds return
          after 1000 [list countdown_kernel [incr seconds -1]]
      }
      
      
      proc draw_hand {angle decorations} {
          eval .c create line $::size $::size [get_xy $angle] $decorations
      }
      
      
      proc end_coordinate difference {
          set hand_length [expr $::size * .9]
          return [expr $::size + $hand_length * $difference]
      }
      
      
      proc get_xy angle {
          return [list [end_coordinate [expr sin($angle)]] \
                       [end_coordinate [expr -cos($angle)]]]
      }
      
      
      proc hands seconds {
          catch {.c delete withtag hands}
      
          set twopi 6.283185
          set seconds_angle [expr $seconds * $twopi / 60.]
          draw_hand $seconds_angle "-width 1 -tags hands"
          set minutes_angle [expr $seconds_angle / 60.]
          draw_hand $minutes_angle \
                       "-width 3 -capstyle projecting -tags hands"
      }
      
      proc init {} {
          catch {destroy .c}
          set ::size 30
          set full_diameter [expr 2 * $::size]
          pack [canvas .c -width $full_diameter -height $full_diameter]
          set border 2
          set diameter [expr 2 * $::size - $border]
          .c create oval $border $border \
                         $diameter $diameter \
                         -fill white -outline black
      }
      
      
      countdown 10

그림 1. Tk로 코딩된 카운트다운 시계
analogue countdown display

정보는 기능에 버금가는 중요한 것이다. 사용자가 애플리케이션의 내부 상태에 대해 많이 알수록 그들이 당신에게 요구하는 것은 적어진다. 명백한 퍼포먼스 문제들은 프로그램이 무엇을 하고있는지를 보이게끔 함으로서 해결할 수 있다.

위로

소팅은 어렵다!

지금까지는 "쉬운것"에 대한 레슨이였다. 프로그래밍에 대한 배경이 없는 사람들은 쉬운 것은 이해할 수 있다. 하지만 소팅은 "어려운" 범주에 속해있다.

소팅은 많은 퍼포먼스 도전과제의 중심에 있었다. 퍼포먼스는 대규모 컴퓨팅 관련 문제이다. 사람들은 한번에 적은 것만 이해할 수 있기 때문에 오랜 시간이 걸리는 큰 문제를 파악하는 방식은 특정 방식으로 조직화 또는 구조화하는 것이다. 소팅은 가장 일반적인 방법이다. 소팅이 된 리스트는 줄(linearly searched) 보다는 바이너리(binary-searched)이다.

상위 알고리즘은 종종 하위 알고리즘보다 근소한 차이로 성능이 우수하다. 이것은 소팅 작업의 전형이다. 소팅을 지능적으로 하는데 주의를 기울인다.

하지만 가장 지능적인 것은 소팅 모두를 피하는 것이거나 적어도 공지되지 않을 때로 제한하는 것이다. 이것은 데이터베이스 관리 시스템에는 일반적이다. 다른 혜택 중에서도 "insert-time" 인덱스 구조를 허용한다. 소팅된 결과가 필요하면 인덱스에서 직접 읽힐 수 있다. 엘리먼트를 만들거나 삽입하는 것보다 약간 오래 걸린다. 하지만 사용자들은 애플리케이션의 워크플로우가 일반적이라면 이를 공지하지 않는다.

Knuth의 레퍼런스는 특정 상황에서 소팅 작동을 향상시키는데 사용되는 "Boyer-Moore" 또는 "Rabin-Karp" 같은 방법을 설명하고 있다. 이러한 것을 통합하는 하나의 일반적인 원리는 특정 문제 보다는 일반적인 문제를 해결하는데 쉽다는 것이다. 수학자들은 이것에 익숙하다.

이것은 나의 "decorate-sort-undecorate" (DSU)에 대한 생각이다. 다음과 같은 데이터세트가 있다고 생각해보자:

총 수입별로 소팅된 이름이 필요하다고 가정해보자. 순진한 접근방식은 비교 함수에서 제공되는 소팅용 라이브러리 엔트리 포인트를 사용하는 것이다. "Kim Black"은 "Dan Smith"를 앞선다. 왜냐하면 40,000은 6,000 보다 많기 때문이다. 등등..이것은 단순하며 작은 문제에 효과적이다.

좀더 효율적인 것으로는-비록 이것은 한번에 수백만 아이템을 소팅할 때에 알맞는 경우이고 생명공학, 금융 등에 일반적인 것이지만-특별한 목적의 "역 테이블(reverse table)을 만드는 것이다. 이 작동은 시간이 걸리지만 소팅이 매우 빠르다. 이 원리는 어떤 언어에서나 손쉽게 사용할 수 있다:

Listing 3. decorate-sort-undecorate (파이썬)

    decorated = [ (revenues[name], name) for name in name_list ]
    decorated.sort()
    for (revenue, name) in decorated:
        print "%14s: %8d" % (name, revenue)

위로

500배 빠르게!

컨설턴트인 Alex Martelli는 바로 작년에 드라마틱한 해결책을 찾았다. 그는 Python Business Forum 메일링 리스트에 가입되어 있었기 때문에 태스크 완료까지 8 시간이나 걸리는 XML 프로세서를 구현했다. 이것은 비합리적이였다. 사용자들은 그렇게 오랜시간을 기다리지 못한다. 그는 여러 픽스들을 결합하여 1분 으로 시간을 단축했다!

먼저, 빌트인 파이썬 XML 라이브러리를 pyRXP 파서로 전환했다. 프로세싱 사이클을 적게 사용하게 되면서 pyRXP는 메모리 풋프린트를 현격하게 줄였다.

대안 제품이나 알고리즘을 평가할 때 쓰루풋 뿐만아니라 메모리 영향까지 벤치마크했다. 후자는 애플리케이션의 효과적인 확장을 주도했다.

위로

디스크 드라이브는 의심을 받아야한다.

퍼포먼스 향상에 굶주린 사람들에게 주는 마지막 팁은 디스크 드라이브를 의심하라는 것이다. 대용량 스토리지는 양적으로 크게 발전했고 지난 몇 십년 동안 신뢰도 얻었다. 하지만 최근에 보게 된 현상은 적어도 몇몇의 제조자들은 품질 향상에 대한 노력을 너무 적게 하는 것 같다.

세밀하게 검사하지 않는한 실제의 액세스 시간이나 디스크 서브시스템의 쓰루풋을 알 수 없다. 이는 대용량 스토리지가 RAID나 SAN 등으로 설정될 때 발생한다. 특정 유닛은 종종 고장이 난다. 하지만 애플리케이션 레벨에서 드러나는 결과는 전체 퍼포먼스에 퍼지는 유령같은 변종이다.

이에 대해 무엇을 할 수 있는가. 많은 방법들이 가능하겠지만 문서화가 엉망이다. 다음과 같이 정리해보았다:

신뢰할 만한 장비를 구입하라. 대용량 스토리지는 믿을 수 있는 제품이어야 한다.
인벨롭을 밀지 말아라. 다른 것들이 SAN, 최근에 생성된 SCSI, gigaether 스토리지, 기타 오퍼링을 밀도록하라.
구입한 제품에서 검사할 것들을 찾아라. 자신의 퍼포먼스와 환경(온도 포함)을 모니터링하는 디스크를 찾는다. 레코드를 기록하면 장비에서 기대되는 것이 무엇인지 알게된다. 프로젝트가 크면 디스크 미스테리에 빠질 수 있다. 이러한 일이 발생한 후에 오류를 트래킹하는 것 보다는 문서를 찾는 것이 낫다.

어떤 퍼포먼스 픽스는 인식 또는 구현에 불과 몇 분 정도 걸린다. 반면 어떤 것은 많은 시간이 투자된다. 애플리케이션 속도의 실제 한계를 알고싶다면 퍼포먼스의 다양한 문제를 검토해봐야 한다.

참고자료