Ruby 가상 머신의 동작에 대한 통찰력은 애플리케이션 전체를 이해하고 성능을 개선하는 데 도움이 될 수 있습니다. New Relic은 Ruby VM이 수행하는 작업을 더 잘 이해하는 데 도움이 되는 몇 가지 주요 메트릭을 수집합니다. 이는 또한 성능 향상을 위한 VM 구성 조정의 영향을 평가하는 데 도움이 될 수 있습니다.
최소 요구 사항들
Ruby VM 메트릭 컬렉션은 Ruby 에이전트 버전 3.8.0 이상에서 사용할 수 있습니다(이전 버전에서는 일부 기본 가비지 컬렉션 측정의 컬렉션을 지원했지만).
또한 이 기능을 사용하려면 CRuby 1.9.2 or higher 와 호환되는 Ruby 버전을 사용해야 합니다. 각 개별 측정에 대한 아래 섹션에서는 각 측정 수집을 지원하는 루비 버전에 대해 설명합니다.
모든 Ruby 버전에서 모든 지표를 수집할 수 있는 것은 아닙니다. 일반적으로 최신 버전의 CRuby를 사용하는 경우 가장 완전한 데이터를 얻을 수 있습니다. 아래 목록은 사용 가능한 항목을 정확히 설명합니다.
Available on: CRuby 2.0+
프로세스에 할당된 Ruby 객체의 수입니다. UI에서 이 측정은 요청 수로 정규화되므로 요청당 할당된 개체 수를 파악할 수 있습니다.
객체 할당 빈도가 Ruby의 가비지 수집기가 실행되어야 하는 빈도에 대한 가장 큰 동인 중 하나이기 때문에 이것은 관찰해야 할 중요한 수치입니다.
CRuby에서 이 값은 GC.stat[:total_allocated_object] 에서 파생됩니다.
Available on: CRuby 1.9.2+, Rubinius 2.x(JRuby 지원에 대한 아래 참고 사항 참조)
Ruby 프로세스에서 가비지 수집(표시 및 스윕 단계 모두)에 소요된 시간입니다.
Ruby 에이전트는 실제로 이 값을 두 가지 방식으로 측정합니다. 요청 처리 중 발생하는 가비지 수집 시간과 총 가비지 수집 시간입니다. 요청 처리 중 발생하는 가비지 수거 시간은 메인 개요 그래프에 밴드로 표시되며, 개별 트랜잭션에 대한 분류 차트에는 표시됩니다. 벽시계 시간의 백분율로 표시되는 총 GC 시간은 Ruby VM 탭에 표시됩니다.
이 측정은 GC::Profiler.total_time 에서 파생됩니다.
Note: 이 측정값을 얻으려면 GC::Profiler (를) 활성화해야 합니다. 자세한 내용은 GC 계측을 참조하세요.
JRuby note: JRuby 또는 특정 JVM 버전의 버그 로 인해 JRuby에서는 GC 타이밍이 1000배나 다를 수 있습니다. 이러한 이유로 현재 JRuby에서는 GC::Profiler 활성화하지 않는 것이 좋습니다.
Available on: CRuby 1.9.2+, JRuby 1.7+, 루비니우스 2.x
가비지 컬렉터가 Ruby 프로세스를 실행하기 위해 얼마나 자주 중지해야 합니까? CRuby 2.1+에서는 메이저 및 마이너 GC 실행으로 분할됩니다. 이 숫자는 GC 실행당 처리된 요청 수로 UI에 표시됩니다.
사용 중인 Ruby 버전에 따라 이 값은 GC.count 또는 GC.stat[:minor_gc_count] 및 GC.stat[:major_gc_count] 에서 파생될 수 있습니다.
Available on: CRuby 1.9.2+
Ruby 인터프리터는 객체를 힙 에 저장하며 각 객체는 단일 힙 슬롯 을 차지합니다. 힙 내의 슬롯이 객체로 채워지면 힙은 필요에 따라 Ruby VM에 의해 확장됩니다.
Ruby 에이전트는 힙에 있는 활성 개체 수와 사용되지 않은 힙 슬롯 수를 주기적으로 측정합니다.
일반적으로 힙에 개체가 많을수록 각 GC 실행 시간이 더 오래 걸립니다(잠재적으로 힙의 모든 개체를 검사해야 하기 때문에). 힙에 개체가 많을수록 애플리케이션의 메모리 사용량도 높아집니다.
이 값은 GC.stat[:heap_live_slot] 또는 GC.stat[:heap_live_num] 및 GC.stat[:heap_free_slot] 또는 GC.stat[:heap_free_num] 에서 파생됩니다.
Available on: 모든 루비 버전
이 측정은 인스턴스(프로세스)당 평균 크기로 표시되는 Ruby 프로세스의 메모리 사용량(상주 세트 크기)을 보여줍니다. Ruby VM 설정을 조정할 때 메모리 사용량을 확인하는 것은 중요한 고려 사항입니다. 너무 커지면 호스트 시스템이 디스크로 페이징을 시작하거나 소프트웨어 적용 메모리 제한에 부딪힐 수 있습니다.
Linux 호스트에서 이는 /proc/PID/status 의 VmRSS 필드에서 파생됩니다.
Available on: CRuby 2.1+
객체에서 메서드가 호출될 때마다 Ruby는 객체의 상위 체인을 검색하여 해당 메서드의 구현을 찾아야 합니다. 이러한 검색은 비용이 많이 들기 때문에 Ruby VM은 이러한 검색 결과를 캐시합니다.
이전 버전의 CRuby(2.0 이전)에는 단일 전역 메서드 캐시가 있었고 전체 캐시를 무효화할 수 있는 다양한 작업 이 있었습니다.
CRuby 2.1 이상에서는 글로벌 캐시가 더 작은 클래스별 캐시 세트로 분할되어 한 클래스에 대한 캐시 무효화 변경 사항이 다른 관련 없는 클래스에 대한 캐시 항목을 버리지 않도록 합니다.
그러나 여전히 모든 메서드 캐시를 무효화하는 몇 가지 작업이 있습니다. Ruby 에이전트는 이러한 무효화가 발생하는 빈도를 측정하고 이 측정을 요청 수에 대해 정규화하여 보고하여 요청당 모든 메서드 캐시가 무효화된 횟수에 대한 아이디어를 제공합니다.
Ruby는 위에서 설명한 메서드 캐싱 동작과 유사한 방식으로 상수 위치를 캐싱합니다. 또한 Ruby 에이전트는 전역 상수 캐시가 무효화된 횟수를 측정하고 이를 요청당 평균 무효화 횟수로 보고할 수 있습니다.
이 값은 RubyVM.stat[:global_constant_state] 에서 파생됩니다.
Available on: CRuby 1.9.2+, JRuby 1.7+, 루비니우스 2.x
Ruby 에이전트는 Ruby 프로세스의 스레드 수를 추적할 수 있습니다. 다중 스레드 웹 서버를 사용하는 경우 스레드 풀이 실제로 구성한 크기인지 확인하는 데 사용할 수 있습니다. 스레드 누수가 있는 경우 강조 표시할 수도 있습니다(절대 끊어지지 않는 스레드를 생성하는 곳).
백그라운드 프로세스
기본적으로 뉴렐릭의 특정 이름으로 보고되는 모든 프로세스의 데이터는 사용자 인터페이스의 Ruby VM 페이지에 결합됩니다. 즉, 웹 프로세스와 백그라운드 프로세스(예: Resque, Sidekiq, DelayedJob 등)가 모두 동일한 뉴렐릭에 보고되는 경우 데이터가 혼란스러울 수 있다는 의미입니다.
이 문제를 해결하는 두 가지 방법이 있습니다.
app_name 구성 설정 또는 NEW_RELIC_APP_NAME 환경 변수를 설정하여 웹 및 백그라운드 프로세스를 New Relic의 별도 애플리케이션으로 가져옵니다.
구성 파일에서 disable_vm_sampler: true 을 설정하거나 애플리케이션 환경에서 NEW_RELIC_DISABLE_VM_SAMPLER=1 을 설정하여 백그라운드 프로세스에서 Ruby VM 측정항목 수집을 비활성화합니다.