Kể từ khi nâng cấp lên Solaris 11, kích thước ARC của tôi đã liên tục nhắm mục tiêu 119 MB, mặc dù có RAM 30 GB. Gì? Tại sao?


9

Tôi đã chạy một hộp NAS / SAN trên Solaris 11 Express trước khi Solaris 11 được phát hành. Hộp là một HP X1600 có gắn D2700. Trong tất cả, các đĩa 12x 1TB 7200 SATA, 12x 300GB 10k SAS trong các zpool riêng biệt. Tổng RAM là 30 GB. Các dịch vụ được cung cấp là CIFS, NFS và iSCSI.

Tất cả đều ổn, và tôi đã có một biểu đồ sử dụng bộ nhớ ZFS trông như thế này:

Kích thước Arc khá khỏe mạnh khoảng 23GB - sử dụng bộ nhớ khả dụng để lưu vào bộ đệm.

Tuy nhiên, sau đó tôi đã nâng cấp lên Solaris 11 khi nó xuất hiện. Bây giờ, biểu đồ của tôi trông như thế này:

Sản lượng một phần của arc_summary.pllà:

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)

Đó là mục tiêu 119MB khi ngồi ở mức 915 MB. Nó có 30 GB để chơi. Tại sao? Họ đã thay đổi một cái gì đó?

Biên tập

Để làm rõ, arc_summary.pllà của Ben Rockwood và các dòng liên quan tạo ra các số liệu thống kê ở trên là:

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};

Các mục Kstat ở đó, tôi chỉ nhận được các giá trị kỳ lạ từ chúng.

Chỉnh sửa 2

Tôi vừa đo lại kích thước vòng cung bằng arc_summary.pl- Tôi đã xác minh những con số này bằng 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)

Điều gây ấn tượng với tôi là Kích thước mục tiêu là 119 MB. Nhìn vào biểu đồ, nó nhắm mục tiêu chính xác cùng một giá trị (124,91M theo cacti, 119M theo arc_summary.pl- nghĩ rằng sự khác biệt chỉ là 1024/1000 vấn đề làm tròn) kể từ khi Solaris 11 được cài đặt. Có vẻ như hạt nhân không nỗ lực để chuyển kích thước mục tiêu sang bất cứ thứ gì khác. Kích thước hiện tại đang dao động khi nhu cầu của hệ thống (lớn) chiến đấu với kích thước mục tiêu và nó xuất hiện trạng thái cân bằng là từ 700 đến 1000MB.

Vì vậy, câu hỏi bây giờ được đưa ra nhiều hơn một chút - tại sao Solaris 11 khó cài đặt kích thước mục tiêu ARC của tôi thành 119MB và làm cách nào để thay đổi nó? Tôi có nên tăng kích thước tối thiểu để xem điều gì xảy ra?

Tôi đã bị kẹt đầu ra kstat -n arcstatstại http://pastebin.com/WHPimhfg

Chỉnh sửa 3

Ok, kỳ lạ bây giờ. Tôi biết flibflob đã đề cập rằng có một bản vá để sửa lỗi này. Tôi chưa áp dụng bản vá này (vẫn phân loại các vấn đề hỗ trợ nội bộ) và tôi chưa áp dụng bất kỳ bản cập nhật phần mềm nào khác.

Thứ năm vừa qua, chiếc hộp bị rơi. Như trong, hoàn toàn ngừng đáp ứng với tất cả mọi thứ. Khi tôi khởi động lại nó, nó đã hoạt động tốt trở lại, nhưng đây là biểu đồ của tôi bây giờ trông như thế nào.

Có vẻ như đã khắc phục vấn đề.

Đây là công cụ la la đất thích hợp bây giờ. Tôi thực sự không biết chuyện gì đang xảy ra. :

Câu trả lời:


4

Thật không may, tôi không thể giải quyết vấn đề của bạn, nhưng đây là một số thông tin cơ bản:

  • Kích thước mục tiêu ARC dường như không phải là một giá trị sửa chữa. Tôi gặp vấn đề tương tự trên máy Solaris 11 và sau mỗi lần khởi động lại, tại một số điểm, kích thước mục tiêu dường như bị khóa ở giá trị trong khoảng từ 100 đến ~ 500MB.

  • Ít nhất 3 người khác đang phải đối mặt với cùng một vấn đề, như đã thảo luận trong http://mail.opensolaris.org/pipermail/zfs-discuss/2012-Janftime/050655.html

  • Ngoài ra còn có một báo cáo lỗi mở (7111576) về "Hỗ trợ Oracle của tôi" ( https://support.oracle.com ). Nếu máy chủ của bạn theo hợp đồng hỗ trợ hợp lệ, bạn nên gửi yêu cầu dịch vụ và tham khảo lỗi đó. Đến bây giờ, mọi lỗi vẫn có vẻ đang hoạt động ...

Ngoài ra, bạn không thể làm được gì nhiều. Nếu bạn chưa nâng cấp các phiên bản zpool / zfs của mình, bạn có thể thử khởi động vào môi trường khởi động Solaris 11 Express cũ của mình và chạy nó cho đến khi cuối cùng Oracle quyết định phát hành SRU khắc phục sự cố.

Chỉnh sửa: Vì câu hỏi về sự suy giảm hiệu suất đã được thảo luận ở trên: Tất cả phụ thuộc vào những gì bạn đang làm. Tôi đã thấy độ trễ khủng khiếp trên chia sẻ Solaris 11 NFS của tôi kể từ khi nâng cấp lên Solaris 11/11/11. Tuy nhiên, so với hệ thống của bạn, tôi có tương đối ít trục chính và phụ thuộc rất nhiều vào bộ nhớ đệm ARC và L2ARC hoạt động như mong đợi (xin lưu ý rằng sự cố cũng khiến L2ARC không phát triển đến bất kỳ kích thước hợp lý nào). Đây chắc chắn không phải là một vấn đề của thống kê giải thích sai.

Mặc dù bạn có thể không phụ thuộc quá nhiều vào ARC / L2ARC, nhưng bạn có thể sẽ có thể sao chép nó bằng cách đọc một tệp lớn (thường phù hợp với RAM của bạn) nhiều lần với dd . Bạn có thể sẽ nhận thấy rằng lần đầu tiên đọc tệp sẽ thực sự nhanh hơn bất kỳ lần đọc liên tiếp nào của cùng một tệp (do kích thước ARC lố bịch và vô số lỗi bộ nhớ cache).

Chỉnh sửa: Bây giờ tôi đã quản lý để nhận một bản vá IDR từ Oracle để giải quyết vấn đề này. Nếu hệ thống của bạn đang được hỗ trợ, bạn nên yêu cầu bản vá IDR cho CR 7111576. Bản vá áp dụng cho Solaris 11 11/11 với SRU3.


Tôi nghĩ rằng tôi đang được hỗ trợ, nhưng tôi làm việc trong một công ty lớn, vậy ai biết?
gầm gừ

1

Họ đã thay đổi kstats.

Oracle Solaris 11 đã xóa các thống kê sau khỏi zfs: 0: arcstats:

  • đuổi_l2_cached
  • evict_l2_ đủ điều kiện
  • evict_l2_inel đủ điều kiện
  • đuổi đi
  • kích thước hdr_size
  • l2_free_on_write
  • l2_size recycl_miss

và thêm các mục sau vào zfs: 0: arcstats:

  • buf_size
  • meta_limit
  • meta_max
  • meta_use

Vì vậy, điều này về cơ bản có thể chỉ là một vấn đề với kịch bản của bạn.


Đó là một điểm thú vị, nhưng tôi không nghĩ rằng tôi đang sử dụng bất kỳ số liệu nào để báo cáo những con số này. Xem chỉnh sửa.
triển

Những người thực sự vẫn còn ở đây. Xem xét rằng, điều này trông rất kỳ lạ. Bạn có thấy bất kỳ loại suy giảm hiệu suất?
juwi

Tôi không thể nói tôi có. Tôi có lẽ nên đo lường điều này.
triển

Trong trường hợp đây không phải là một lỗi trong những gì bạn đang nhìn và bạn thực sự có một sự kỳ lạ ở đó, xin lưu ý rằng bạn CÓ THỂ sửa đổi các giá trị này một cách nhanh chóng trên hệ thống trực tiếp hoặc sử dụng / etc / system vĩnh viễn.
Nex7
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.