Мы уже пару лет запускаем 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
Это может быть не 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.
Кратковременное решение - перезагрузка. Если перезагрузка помогает, вам необходимо установить параметр ядра. Это известная проблема 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 позже, если у нас все еще есть проблемы, на всякий случай, если это поможет.