Solaris 10 ZFS ARC исчерпан и процессор перегружен
Мы уже пару лет используем ZFS на Solaris 10 на сервере Oracle M5000 Enterprise с 32 ядрами ЦП и 256 ГБ памяти. Мы запустили базу данных / приложение на этом сервере, который, кажется, тяжело читается.
У нас были проблемы с вводом / выводом в UFS, и это было решено переключением на ZFS. У нас есть накопитель NetApp, который представляет диски по оптоволоконному каналу, а затем форматируется с использованием ZFS на уровне ОС на одном LUN. Сначала у нас были проблемы с памятью приложения, и мы должны были ограничить размер ARC до 128 ГБ памяти.
Теперь проблема, с которой мы начали сталкиваться, заключается в том, что ARC достигает максимума. В течение этого времени процессоры перегружаются 0% времени простоя. Процессы приложений останавливаются, и автоматизированные процессы начинают сталкиваться друг с другом.
Я изучал эту проблему в течение некоторого времени и консультировался с различными источниками, которые, кажется, все считают, что нам просто нужна большая машина или чтобы поставщик оптимизировал свой код. Мы смотрим на покупку M10-4 и работаем с поставщиком приложений, но мне интересно, возможно, что-то еще происходит.
Буду признателен за любую помощь и дайте мне знать, если потребуется дополнительная информация.
Ниже вывод из arc_summary.pl
System Memory:
Physical RAM: 257614 MB
Free Memory : 79033 MB
LotsFree: 4022 MB
ZFS Tunables (/etc/system):
set zfs:zfs_arc_max = 137438953472
ARC Size:
Current Size: 131043 MB (arcsize)
Target Size (Adaptive): 131072 MB (c)
Min Size (Hard Limit): 64 MB (zfs_arc_min)
Max Size (Hard Limit): 131072 MB (zfs_arc_max)
ARC Size Breakdown:
Most Recently Used Cache Size: 6% 8190 MB (p)
Most Frequently Used Cache Size: 93% 122881 MB (c-p)
ARC Efficency:
Cache Access Total: 217693264863
Cache Hit Ratio: 99% 217640359356 [Defined State for buffer]
Cache Miss Ratio: 0% 52905507 [Undefined State for Buffer]
REAL Hit Ratio: 67% 146336547931 [MRU/MFU Hits Only]
Data Demand Efficiency: 99%
Data Prefetch Efficiency: 96%
CACHE HITS BY CACHE LIST:
Anon: 32% 71281340234 [ New Customer, First Cache Hit ]
Most Recently Used: 0% 172508676 (mru) [ Return Customer ]
Most Frequently Used: 67% 146164039255 (mfu) [ Frequent Customer ]
Most Recently Used Ghost: 0% 3430197 (mru_ghost) [ Return Customer Evicted, Now Back ]
Most Frequently Used Ghost: 0% 19040994 (mfu_ghost) [ Frequent Customer Evicted, Now Back ]
CACHE HITS BY DATA TYPE:
Demand Data: 62% 136382108166
Prefetch Data: 0% 1145425065
Demand Metadata: 4% 9980846285
Prefetch Metadata: 32% 70131979840
CACHE MISSES BY DATA TYPE:
Demand Data: 19% 10410690
Prefetch Data: 72% 38324623
Demand Metadata: 1% 874219
Prefetch Metadata: 6% 3295975
Ниже вывод от vmstat:
# vmstat 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr m1 m1 m1 m1 in sy cs us sy id
0 0 0 40892888 93939912 256 1411 165 26 26 0 0 8 1 2 0 5651 274471 42913 2 5 93
0 0 0 22113320 81957648 118 1324 3 0 0 0 0 0 0 0 0 5631 313043 58903 2 35 63
0 0 0 22145624 81977312 353 459 0 746 746 0 0 145 0 0 0 5177 379709 58255 2 33 65
0 0 0 22150976 81982088 120 1329 0 0 0 0 0 1 0 0 0 5200 314711 59490 2 33 65
0 0 0 22147600 81981680 504 1834 0 8 5 0 0 5 0 0 0 5197 334201 58339 2 32 66
0 0 0 22146160 81982544 715 610 0 5 3 0 0 2 0 0 0 6296 364301 58900 2 35 63
0 0 0 22116584 81960496 678 1928 0 3 3 0 0 1 0 0 0 5178 351160 58947 2 34 64
1 0 0 22107080 81949528 95 1095 0 0 0 0 0 0 0 0 0 4531 309206 58450 2 35 63
Ниже приведен вывод из zpool iostat:
# zpool iostat ntapdatatel 5
capacity operations bandwidth
pool alloc free read write read write
----------- ----- ----- ----- ----- ----- -----
ntapdatatel 1.07T 437G 10 13 1.07M 1.01M
ntapdatatel 1.07T 437G 0 0 51.2K 4.00K
ntapdatatel 1.07T 437G 0 0 0 0
ntapdatatel 1.07T 437G 0 95 0 6.47M
ntapdatatel 1.07T 437G 0 0 0 0
ntapdatatel 1.07T 437G 0 0 0 0
ntapdatatel 1.07T 437G 0 0 0 0
ntapdatatel 1.07T 437G 0 0 0 0
ntapdatatel 1.07T 437G 0 0 25.6K 0
ntapdatatel 1.07T 437G 0 87 0 5.16M
и свойства файловой системы:
NAME PROPERTY VALUE SOURCE
ntapdatatel type filesystem -
ntapdatatel creation Sun Oct 28 17:09 2012 -
ntapdatatel used 1.07T -
ntapdatatel available 413G -
ntapdatatel referenced 432G -
ntapdatatel compressratio 1.00x -
ntapdatatel mounted yes -
ntapdatatel quota none default
ntapdatatel reservation none default
ntapdatatel recordsize 128K default
ntapdatatel mountpoint /ntapdatatel local
ntapdatatel sharenfs off default
ntapdatatel checksum on default
ntapdatatel compression off default
ntapdatatel atime on default
ntapdatatel devices on default
ntapdatatel exec on default
ntapdatatel setuid on default
ntapdatatel readonly off default
ntapdatatel zoned off default
ntapdatatel snapdir hidden default
ntapdatatel aclmode discard default
ntapdatatel aclinherit restricted default
ntapdatatel canmount on default
ntapdatatel shareiscsi off default
ntapdatatel xattr on default
ntapdatatel copies 1 default
ntapdatatel version 5 -
ntapdatatel utf8only off -
ntapdatatel normalization none -
ntapdatatel casesensitivity sensitive -
ntapdatatel vscan off default
ntapdatatel nbmand off default
ntapdatatel sharesmb off default
ntapdatatel refquota none default
ntapdatatel refreservation none default
ntapdatatel primarycache all default
ntapdatatel secondarycache all default
ntapdatatel usedbysnapshots 0 -
ntapdatatel usedbydataset 432G -
ntapdatatel usedbychildren 666G -
ntapdatatel usedbyrefreservation 0 -
ntapdatatel logbias latency default
ntapdatatel sync standard default
ntapdatatel rekeydate - default
ntapdatatel rstchown on default
2 ответа
Это может быть не zfs - у вас много свободной памяти, поэтому рассмотрите эту возможность -
echo 'pg_contig_disable/D' | mdb -k
Если вывод:
echo pg_contig_disable/D | mdb -k
pg_contig_disable:
pg_contig_disable: 0
Возможно, вы столкнулись с проблемой NUMA. Solaris 10 пытается ускорить доступ к памяти, настроив блоки памяти для повышения эффективности кэширования. Это, когда у вас много памяти и оракула, приводит к странной ситуации - как вы и описали. Примерно через месяц безотказной работы, небольшого количества пользователей процессора, большого количества системного времени процессора и система останавливается. В долгосрочной перспективе установите для параметра ядра pg_contig_disable значение 1.
Краткосрочное исправление - перезагрузка. Если перезагрузка помогает, вам нужно установить ядро parm. Это известная проблема Solaris 10 в системах с большим количеством свободной памяти.
Спасибо Джиму Макнамаре за то, что он указал мне правильное направление. Я не видел симптомов, согласующихся с проблемой pg_contig_disable, но это привело меня к проблеме с zfetch.
Я обнаружил ту же проблему, что и у нас, на следующем сайте: http://solaristalk.blogspot.com/2014_05_01_archive.html
Это привело к появлению статьи о настройке на сайте Oracle, объясняющей, почему предварительная выборка ZFS была для нас проблемой: http://docs.oracle.com/cd/E26502_01/html/E29022/chapterzfs-4.html
Мы видели dmu_zfetch_find в верхней части списка мьютексов, используя lockstat во время большой нагрузки. С тех пор я отключил предварительную выборку в нашей реализации ZFS. Я буду перезагружаться этим вечером, чтобы все очистилось и мы начали все заново.
Надеюсь, это билет. Мы можем провести некоторое тестирование с pg_contig_disable позже, если у нас все еще будут проблемы на случай, если это поможет.