Solaris 11로 업그레이드 한 이후 30GB RAM에도 불구하고 ARC 크기는 지속적으로 119MB를 목표로합니다. 뭐? 왜?

Solaris 11이 릴리스되기 전에 Solaris 11 Express에서 NAS / SAN 상자를 실행했습니다. 상자는 D2700이 장착 된 HP X1600입니다. 모두 12 개의 1TB 7200 SATA 디스크, 별도의 zpool에 12x 300GB 10k SAS 디스크가 있습니다. 총 RAM은 30GB입니다. 제공되는 서비스는 CIFS, NFS 및 iSCSI입니다.

모든 것이 좋았으며 ZFS 메모리 사용량 그래프는 다음과 같습니다.

약 23GB의 상당히 건강한 아크 크기-캐싱에 사용 가능한 메모리를 사용합니다.

그러나 그런 다음 Solaris 11로 업그레이드했습니다. 이제 내 그래프는 다음과 같습니다.

부분 출력 arc_summary.pl은 다음과 같습니다.

System Memory:
     Physical RAM:  30701 MB
     Free Memory :  26719 MB
     LotsFree:      479 MB

ZFS Tunables (/etc/system):

ARC Size:
     Current Size:             915 MB (arcsize)
     Target Size (Adaptive):   119 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    29677 MB (zfs_arc_max)

915MB에 앉아있는 동안 119MB를 목표로합니다. 플레이 할 30GB가 있습니다. 왜? 그들은 무언가를 바 꾸었습니까?

편집하다

명확히하면 arc_summary.plBen Rockwood이며 위의 통계를 생성하는 관련 줄은 다음과 같습니다.

my $mru_size = ${Kstat}->{zfs}->{0}->{arcstats}->{p};
my $target_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c};
my $arc_min_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c_min};
my $arc_max_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c_max};
my $arc_size = ${Kstat}->{zfs}->{0}->{arcstats}->{size};

Kstat 항목이 있습니다. 홀수 값을 가져옵니다.

편집 2

방금 아크 크기를 다시 측정했습니다. arc_summary.pl이 숫자를 kstat다음 과 같이 확인했습니다 .

System Memory:
     Physical RAM:  30701 MB
     Free Memory :  26697 MB
     LotsFree:      479 MB

ZFS Tunables (/etc/system):

ARC Size:
     Current Size:             744 MB (arcsize)
     Target Size (Adaptive):   119 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    29677 MB (zfs_arc_max)

나에게 맞는 것은 대상 크기가 119MB라는 것입니다. 그래프를 보면 arc_summary.plSolaris 11이 설치된 이후로 정확히 동일한 값 (선인장에 따르면 124.91M, 선인장에 따르면 119M-차이는 1024/1000 반올림 문제라고 생각합니다)을 대상으로합니다. 커널이 목표 크기를 다른 것으로 옮기기 위해 노력을 기울이지 않는 것처럼 보입니다. 시스템 (대형)의 요구가 대상 크기와 맞서 싸울 때 현재 크기가 변동하고 있으며 평형 상태는 700 ~ 1000MB입니다.

그래서 문제는 이제 좀 더 지적되었습니다. Solaris 11이 왜 ARC 대상 크기를 119MB로 설정하고 어떻게 변경합니까? 어떻게되는지보기 위해 최소 크기를 늘려야합니까?

나는 http://pastebin.com/WHPimhfgkstat -n arcstats 에서 출력을 막았습니다.

편집 3

좋아, 지금 이상해. flibflob가이 문제를 해결하기위한 패치가 있다고 언급했습니다. 아직이 패치를 적용하지 않았으며 (여전히 내부 지원 문제를 정렬) 다른 소프트웨어 업데이트를 적용하지 않았습니다.

지난 목요일, 상자가 추락했습니다. 마찬가지로 모든 것에 대한 반응을 완전히 중단했습니다. 재부팅하면 정상적으로 돌아 왔지만 그래프는 다음과 같습니다.

문제가 해결 된 것 같습니다.

이것은 이제 적절한 라라 랜드 물건입니다. 나는 무슨 일이 일어나고 있는지 전혀 모른다. 🙁



답변

불행히도 문제를 해결할 수는 없지만 몇 가지 배경 정보가 있습니다.

  • ARC 대상 크기는 수정 값이 아닌 것 같습니다. Solaris 11 시스템에서 동일한 문제가 발생하고 재부팅 할 때마다 대상 크기가 ~ 100MB ~ ~ 500MB 사이의 값으로 고정되는 것처럼 보입니다.

  • http://mail.opensolaris.org/pipermail/zfs-discuss/2012-January/050655.html 에서 논의 된 것처럼 적어도 3 명의 다른 사람들이 같은 문제에 직면하고 있습니다 .

  • “My Oracle Support”( https://support.oracle.com ) 에 공개 버그 보고서 (7111576 )도 있습니다. 서버가 유효한 지원 계약을 체결 한 경우 서비스 요청을 제출하고 해당 버그를 참조해야합니다. 현재로서는 버그 수정이 여전히 진행중인 것 같습니다 …

그 외에는 할 수있는 일이 많지 않습니다. zpool / zfs 버전을 아직 업그레이드하지 않은 경우 이전 Solaris 11 Express 부트 환경으로 부트하여 Oracle이 최종적으로 문제를 해결하는 SRU를 릴리스하기로 결정할 때까지이를 실행할 수 있습니다.

편집 : 성능 저하 문제는 위에서 논의되었으므로 모두 수행중인 작업에 따라 다릅니다. Solaris 11 11/11로 업그레이드 한 이후로 Solaris 11 NFS 공유에서 끔찍한 대기 시간을 보았습니다. 그러나 시스템에 비해 스핀들이 비교적 적으며 예상대로 ARC 및 L2ARC 캐싱 작업에 크게 의존합니다 (문제로 인해 L2ARC가 합리적인 크기로 커지지 않음). 이것은 잘못 해석 된 통계 문제가 아닙니다.

ARC / L2ARC에 너무 의존하지 않더라도 dd를 사용 하여 큰 파일 (일반적으로 RAM에 적합 할 것임)을 여러 번 읽음으로써 파일을 재생할 수있을 것입니다 . 파일을 처음 처음 읽을 때 실제로는 동일한 파일을 연속적으로 읽는 것보다 더 빠릅니다 (어리석은 ARC 크기 및 셀 수없는 캐시 제거로 인해).

편집 : 이제이 문제를 해결하는 Oracle의 IDR 패치를 받았습니다. 시스템이 지원되는 경우 CR 7111576의 IDR 패치를 요청해야합니다.이 패치는 SRU3가있는 Solaris 11 11/11에 적용됩니다.


답변

그들은 kstats를 변경했습니다.

Oracle Solaris 11은 zfs : 0 : arcstats에서 다음 통계를 제거했습니다.

  • evict_l2_cached
  • evict_l2_ 적격
  • evict_l2_ineligible
  • evict_skip
  • hdr_size
  • l2_free_on_write
  • l2_size recycle_miss

zfs : 0 : arcstats에 다음을 추가했습니다.

  • buf_size
  • meta_limit
  • meta_max
  • meta_used

따라서 이것은 기본적으로 스크립트에 문제가 될 수 있습니다.