У меня Kubuntu 16.04 и я использую ZFS для раздела с большими данными (RAIDZ1)
Мне не хватает 5 ГБ оперативной памяти, и я не могу выяснить, куда он пошел. И НЕТ ЭТОГО НЕ КЕШИТЬ
В соответствии со всеми инструментами, которые я мог придумать, у меня в настоящее время есть следующая статистика:
Actively used: 9458.3 MB
Inacively used: 2544.5 MB
Mapped for IO: 2433.0 MB
Buffers: 242.6 MB
Slab: 6669.2 MB
Page Tables: 91.0 MB
Cached: 3758.1 MB
Dirty: 0.1 MB
Writeback: 0.0 MB
Free: 1856.5 MB
------------------------------
Total: 27053.3 MB
Total Memory: 32133.5 MB
------------------------------
Missing ???: 5080.2 MB
Итак, 5 ГБ! ОЗУ не учитываются. Куда они делись?
Инструментальные выходы
Nmon:
RAM High Low Swap Page Size=4 KB │
│ Total MB 32133.5 -0.0 -0.0 8195.5 │
│ Free MB 1856.5 -0.0 -0.0 8195.5 │
│ Free Percent 5.8% 100.0% 100.0% 100.0% │
│ MB MB MB │
│ Cached= 3758.1 Active= 9458.3 │
│ Buffers= 242.6 Swapcached= 0.0 Inactive = 2544.5 │
│ Dirty = 0.1 Writeback = 0.0 Mapped = 2433.0 │
│ Slab = 6669.2 Commit_AS = 16647.1 PageTables= 91.3 │
│ Large (Huge) Page Stats ───────────────────────────────────────────────────────────────────────────────────────────────│
│ There are no Huge Pages │
│ - see /proc/meminfo │
│ │
│ Virtual-Memory ────────────────────────────────────────────────────────────────────────────────────────────────────────│
│nr_dirty = 37 pgpgin = 0 High Normal DMA │
│nr_writeback= 0 pgpgout = 0 alloc 0 343 0 │
│nr_unstable = 0 pgpswpin = 0 refill 0 0 0 │
│nr_table_pgs= 23384 pgpswpout = 0 steal 0 0 0 │
│nr_mapped = 622856 pgfree = 305 scan_kswapd 0 0 0 │
│nr_slab = -1 pgactivate = 0 scan_direct 0 0 0 │
│ pgdeactivate= 0 │
│allocstall = 0 pgfault = 74 kswapd_steal = 0 │
│pageoutrun = 0 pgmajfault = 0 kswapd_inodesteal= 0 │
│slabs_scanned= 0 pgrotated = 0 pginodesteal = 0
cat /proc /memstat
MemTotal: 32904740 kB
MemFree: 1759548 kB
MemAvailable: 5372548 kB
Buffers: 249072 kB
Cached: 3852616 kB
SwapCached: 0 kB
Active: 9819328 kB
Inactive: 2609860 kB
Active(anon): 8334856 kB
Inactive(anon): 412176 kB
Active(file): 1484472 kB
Inactive(file): 2197684 kB
Unevictable: 7932 kB
Mlocked: 7932 kB
SwapTotal: 8392188 kB
SwapFree: 8392188 kB
Dirty: 224 kB
Writeback: 0 kB
AnonPages: 8335424 kB
Mapped: 2497092 kB
Shmem: 416004 kB
Slab: 6829716 kB
SReclaimable: 333652 kB
SUnreclaim: 6496064 kB
KernelStack: 26496 kB
PageTables: 95636 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 24844556 kB
Committed_AS: 17097748 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 4306944 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 9029708 kB
DirectMap2M: 22384640 kB
DirectMap1G: 2097152 kB
бесплатно
total used free shared buff/cache available
Mem: 31G 19G 1.8G 406M 10G 5.2G
Swap: 8.0G 0B 8.0G
сверху
MEM | tot 31.4G | free 1.8G | | cache 3.7G | dirty 0.1M | buff 243.5M | | slab 6.5G | | | | | |
SWP | tot 8.0G | free 8.0G | | | | | | | | | | vmcom 16.3G | vmlim 23.7G |
Дополнительная информация / история
У меня было только 16 ГБ памяти, и я увидел, что система начала переставлять. Хотя не постоянно. Похоже, что использование памяти росло, пока она не начала использовать несколько мегабайт подкачки, а затем перестала расти. Это был первый раз, когда я узнал о "плите" и обнаружил, что большая часть моей памяти ушла туда из-за ZFS.
Отлично, нет проблем, поэтому я установил еще 16 ГБ памяти, это должно сделать работу, верно? Но вместо этого я снова увидел то же поведение. Память росла до тех пор, пока она не начала слегка использовать своп. Однако на этот раз я не смог узнать, куда собираются 5ГБ. В Windows я привык находить назначение каждой страницы памяти с помощью нужных инструментов (https://www.youtube.com/watch?v=AjTl53I_qzY), но здесь я немного растерялся. 5Gb только что ушли. Это утечка памяти ядра?
Пока я установил swappiness на 15, это, кажется, мешает использовать swap "на данный момент", но 5 ГБ по-прежнему нет.
Обновление 1: после запуска в течение 2 недель, этот эффект почти исчез.
│ Memory Stats ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── │
│ RAM High Low Swap Page Size=4 KB │
│ Total MB 32133.5 -0.0 -0.0 8195.5 │
│ Free MB 1871.9 -0.0 -0.0 8186.4 │
│ Free Percent 5.8% 100.0% 100.0% 99.9% │
│ MB MB MB │
│ Cached= 6275.9 Active= 10217.1 │
│ Buffers= 363.4 Swapcached= 1.3 Inactive = 3134.5 │
│ Dirty = 0.2 Writeback = 0.0 Mapped = 3911.0 │
│ Slab = 6159.5 Commit_AS = 13696.9 PageTables= 95.0
Actively used: 10217.1 MB
Inacively used: 3134.5 MB
Mapped for IO: 3911.0 MB
Buffers: 363.4 MB
Slab: 6159.5 MB
Page Tables: 95.0 MB
Cached: 6275.9 MB
Dirty: 0.2 MB
Writeback: 0.0 MB
Free: 1871.9 MB
------------------------------
Total: 32028,3 MB
Total Memory: 32133.5 MB
------------------------------
Missing ???: 105.2 MB
Действительно неиспользованная (свободная) память оставалась довольно постоянной. Но кеш и маппинг пошли вверх. Это действительно похоже на то, что есть некоторый скрытый кеш, который медленно истощается, но не отображается в статистике.
Сильвио Массина упомянул, что это может быть АРК. Вот вывод
cat /proc /spl /kstat /zfs /arcstats
6 1 0x01 91 4368 56409879056 315868863969705
name type data
hits 4 15276585
misses 4 1100779
demand_data_hits 4 10451405
demand_data_misses 4 57248
demand_metadata_hits 4 3886139
demand_metadata_misses 4 876962
prefetch_data_hits 4 133147
prefetch_data_misses 4 71927
prefetch_metadata_hits 4 805894
prefetch_metadata_misses 4 94642
mru_hits 4 2334376
mru_ghost_hits 4 9870
mfu_hits 4 12003233
mfu_ghost_hits 4 34745
deleted 4 89041
mutex_miss 4 10
evict_skip 4 239
evict_not_enough 4 2
evict_l2_cached 4 0
evict_l2_eligible 4 14139960320
evict_l2_ineligible 4 3255242752
evict_l2_skip 4 0
hash_elements 4 554684
hash_elements_max 4 568778
hash_collisions 4 424785
hash_chains 4 33824
hash_chain_max 4 5
p 4 3482926902
c 4 11779217520
c_min 4 33554432
c_max 4 16847226880
size 4 11717468560
hdr_size 4 226991968
data_size 4 8517812736
metadata_size 4 1503463424
other_size 4 1469200432
anon_size 4 11872256
anon_evictable_data 4 0
anon_evictable_metadata 4 0
mru_size 4 2606045184
mru_evictable_data 4 1947246592
mru_evictable_metadata 4 39131136
mru_ghost_size 4 7123638784
mru_ghost_evictable_data 4 6026175488
mru_ghost_evictable_metadata 4 1097463296
mfu_size 4 7403358720
mfu_evictable_data 4 6570566144
mfu_evictable_metadata 4 378443776
mfu_ghost_size 4 598224896
mfu_ghost_evictable_data 4 589954048
mfu_ghost_evictable_metadata 4 8270848
l2_hits 4 0
l2_misses 4 0
l2_feeds 4 0
l2_rw_clash 4 0
l2_read_bytes 4 0
l2_write_bytes 4 0
l2_writes_sent 4 0
l2_writes_done 4 0
l2_writes_error 4 0
l2_writes_lock_retry 4 0
l2_evict_lock_retry 4 0
l2_evict_reading 4 0
l2_evict_l1cached 4 0
l2_free_on_write 4 0
l2_cdata_free_on_write 4 0
l2_abort_lowmem 4 0
l2_cksum_bad 4 0
l2_io_error 4 0
l2_size 4 0
l2_asize 4 0
l2_hdr_size 4 0
l2_compress_successes 4 0
l2_compress_zeros 4 0
l2_compress_failures 4 0
memory_throttle_count 4 0
duplicate_buffers 4 0
duplicate_buffers_size 4 0
duplicate_reads 4 0
memory_direct_count 4 445
memory_indirect_count 4 3009
arc_no_grow 4 0
arc_tempreserve 4 0
arc_loaned_bytes 4 0
arc_prune 4 0
arc_meta_used 4 3199655824
arc_meta_limit 4 12635420160
arc_meta_max 4 4183324304
arc_meta_min 4 16777216
arc_need_free 4 0
arc_sys_free 4 526475264
Я не могу сделать много из этого. Если я правильно понимаю, size должен быть размером с ARC. Но это было бы 11 ГБ. который не вписывается нигде в моей статистике памяти.
Обновление 2:
Я только что закончил Baloo (Search indexer под Kubuntu), и теперь все снова экстремально.
Memory Stats ──────────────────────────────────────────────────────────────────────────────────────────────────────────│
│ RAM High Low Swap Page Size=4 KB │
│ Total MB 32133.5 -0.0 -0.0 8195.5 │
│ Free MB 1004.4 -0.0 -0.0 8132.1 │
│ Free Percent 3.1% 100.0% 100.0% 99.2% │
│ MB MB MB │
│ Cached= 3458.4 Active= 7348.9 │
│ Buffers= 177.5 Swapcached= 3.7 Inactive = 2662.9 │
│ Dirty = 2.9 Writeback = 0.0 Mapped = 937.9 │
│ Slab = 5526.4 Commit_AS = 13320.6 PageTables= 89.2 │
│───────────────────────────────────────────────────────────
Теперь мне не хватает 6,5 ГБ !! барана.
Процесс Baloo использовал 3.5Gb, прежде чем я закончил его.
Использует ли здесь KDE какие-то неприятные уловки?
ОБНОВЛЕНИЕ 3
Становится хуже. Я тестировал на другом компьютере с Linux, и там было ясно, что Inactive used микширование в кеш. Так что мне не хватает еще памяти.
Решение и последствия
Как отметил принятый ответ Сильвио Массина, это действительно была АРК ZFS.
Теперь он утверждал, что выделил 14 ГБ памяти.
cat /proc/spl/kstat/zfs/arcstats | grep -E "^size"
size 4 14953847480
Поэтому я использовал stress чтобы получить 10 ГБ памяти:
stress --vm-bytes 10000000000 --vm-keep -m 1
И вуаля, значение кэша ARC действительно уменьшилось соответственно
cat /proc/spl/kstat/zfs/arcstats | grep -E "^size"
size 4 4147553616
И теперь после stress меня есть 11 ГБ свободной памяти, которую ARC постепенно снова съедает. (Что совершенно нормально)
Таким образом, ARC похож на кэш, но вместо этого отображается в used памяти и не отображается вместе с процессами, только в своем собственном информационном файле. Это странно для меня, так как я думаю, что ОС всегда должна быть хозяином памяти и сообщать, кто ее использует. Я сделал более точный вопрос об этом в AskUbuntu, если кому-то из вас это интересно.
PS: Пожалуйста, не забывайте высказываться против меня, если это также помогло вам. Щедрость не была дешевой G