Начиная с обновления до Solaris 11, мой размер ARC постоянно ориентирован на 119 МБ, несмотря на то, что у него 30 ГБ ОЗУ. Какая? Почему?


9

Я запускал NAS / SAN на Solaris 11 Express до выпуска Solaris 11. Коробка - HP X1600 с приложенным D2700. В целом, 12x 1 ТБ 7200 SATA дисков, 12x 300 ГБ 10k SAS дисков в отдельных zpools. Общий объем оперативной памяти составляет 30 ГБ. Предоставляемые услуги: CIFS, NFS и iSCSI.

Все было хорошо, и у меня был график использования памяти ZFS, похожий на этот:

Довольно здоровый размер Arc около 23 ГБ - использование доступной памяти для кэширования.

Тем не менее, когда я вышел, я обновился до 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)

Он нацелен на 119 МБ, сидя на 915 МБ. У него 30 ГБ для игры. Почему? Они что-то изменили?

редактировать

Чтобы уточнить, arc_summary.plэто Бен Роквуд, и соответствующие строки, генерирующие вышеуказанную статистику:

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)

Меня поражает то, что размер цели составляет 119 МБ. Глядя на график, он нацелен на точно такое же значение (124,91 млн согласно Cacti, 119 млн согласно arc_summary.pl- думаю, разница составляет всего 1024/1000 вопросов округления) с момента установки Solaris 11. Похоже, ядро ​​делает нулевое усилие, чтобы сместить целевой размер к чему-то другому. Текущий размер колеблется, поскольку потребности системы (большой) борются с целевым размером, и кажется, что равновесие находится между 700 и 1000 МБ.

Итак, теперь вопрос немного более острый: почему Solaris 11 жестко устанавливает целевой размер ARC на 119 МБ и как его изменить? Должен ли я поднять минимальный размер, чтобы увидеть, что происходит?

Я застрял вывод kstat -n arcstatsболее на http://pastebin.com/WHPimhfg

Редактировать 3

Хорошо, странность сейчас. Я знаю, что flibflob упомянул, что есть патч, чтобы это исправить. Я еще не применил этот патч (по-прежнему разбираюсь с проблемами внутренней поддержки), и я не применял никаких других обновлений программного обеспечения.

В прошлый четверг коробка разбилась. Как и в, полностью перестал отвечать на все вопросы. Когда я перезагрузил его, он снова заработал, но вот как выглядит мой график.

Кажется, это решило проблему.

Теперь это уместно. Я буквально не знаю, что происходит. :(

Ответы:


4

К сожалению, я не могу решить вашу проблему, но вот некоторая справочная информация:

  • Целевой размер ARC не является фиксированным значением. Я сталкиваюсь с той же проблемой на компьютере Solaris 11, и после каждой перезагрузки в какой-то момент целевой размер, кажется, фиксируется на уровне от ~ 100 до ~ 500 МБ.

  • По крайней мере, 3 других человека сталкиваются с той же проблемой, как описано в http://mail.opensolaris.org/pipermail/zfs-discuss/2012-January/050655.html.

  • Существует также открытый отчет об ошибке (7111576) в разделе «Моя поддержка Oracle» ( https://support.oracle.com ). Если ваш сервер имеет действующий контракт на поддержку, вы должны подать запрос на обслуживание и обратиться к этой ошибке. На данный момент, кажется, что все исправления находятся в стадии разработки ...

Кроме этого, вы мало что можете сделать. Если вы еще не обновили свои версии zpool / zfs, вы можете попробовать загрузиться в старую загрузочную среду Solaris 11 Express и запускать ее до тех пор, пока Oracle наконец не решит выпустить SRU, который устраняет проблему.

Изменить: Поскольку вопрос снижения производительности был обсужден выше: все зависит от того, что вы делаете. С момента обновления до Solaris 11 11/11 на моем общем ресурсе Solaris 11 NFS наблюдаются ужасные задержки. Однако по сравнению с вашей системой у меня относительно мало шпинделей, и я полагаюсь, что кеширование ARC и L2ARC работает должным образом (имейте в виду, что из-за этой проблемы L2ARC также не увеличивается до приемлемого размера). Это, конечно, не проблема неверно истолкованной статистики.

Даже если вы не слишком полагаетесь на ARC / L2ARC, вы, вероятно, сможете воспроизвести его, прочитав большой файл (который обычно умещается в вашей памяти) несколько раз с помощью dd . Вы, вероятно, заметите, что первое чтение файла будет на самом деле быстрее, чем любое последовательное чтение одного и того же файла (из-за нелепого размера ARC и бесчисленных вытеснений из кэша).

Изменить: Теперь мне удалось получить патч IDR от Oracle, который решает эту проблему. Если ваша система поддерживается, вам следует запросить патч IDR для CR 7111576. Патч применяется к Solaris 11 11/11 с SRU3.


Я думаю, что меня поддерживают, но я работаю в крупном корпоративном, так кто знает?
вырасти

1

Они изменили кстаты.

Oracle Solaris 11 удалил следующую статистику из zfs: 0: arcstats:

  • evict_l2_cached
  • evict_l2_eligible
  • 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

Так что это может быть просто проблемой с вашим скриптом.


Это интересный момент, но я не думаю, что я использую какие-либо из этих метрик, чтобы сообщить эти цифры. Смотрите редактировать.
вырасти

Те действительно все еще здесь. Учитывая это, это выглядит очень странно. Видите ли вы какое-либо снижение производительности?
Джуви

Я не могу сказать, что у меня есть. Я должен вероятно измерить это.
вырасти

В случае, если это не является ошибкой в ​​том, что вы смотрите, и у вас действительно есть странность, обратите внимание, что вы МОЖЕТЕ изменить эти значения на лету в реальной системе или постоянно использовать / etc / system.
Nex7
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.