Кажется, ничто не может объяснить 5 ГБ памяти, которой не хватает под Linux
У меня 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
бесплатно -h
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
1 ответ
ZFS использует ARC (Adaptive Replacement Cache).
Из вики Gentoo:
Способ, которым Linux учитывает память, используемую ARC, отличается от памяти, используемой кешем страниц. В частности, память, используемая ARC, включена в раздел "используется", а не "кэширована" в выводе, используемом свободной программой. Это никоим образом не препятствует освобождению памяти, когда системе не хватает памяти. Однако может сложиться впечатление, что ARC (и, соответственно, ZFS) будет использовать всю системную память, если будет предоставлена такая возможность.
Объем памяти, используемой для ARC, зависит от памяти, доступной в системе, и может управляться настройкой параметров zfs_arc_min и zfs_arc_max.
Вы можете установить значение zfs_arc_max во время выполнения с помощью:
echo 2147483648 >> /sys/module/zfs/parameters/zfs_arc_max
Или при загрузке с:
echo "options zfs zfs_arc_max=2147483648" >> /etc/modprobe.d/zfs.conf
Значения выражаются в байтах.