На одном из моих серверов у меня есть служба KV с памятью/диском, Память KV ведет себя как memcached, запрашивает большой объем памяти (10 ГБ) при инициализации, Диск Kv ведет себя как leveldbd, его случайное чтение и последовательная запись, и он часто читает много файлов. Память распределяется с использованием libc malloc.Использование кеша high slab
серверный процесс Моего КВ не потребляет много памяти, как показано ниже (так как отсутствие памяти, я убил память К., оставив только KV диск, но свободная память все еще идет вниз):
:~$top
PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20 0 5030m 3.9g 2772 S 8 6.1 10430:52 tair_server
20 0 4833m 3.9g 4560 S 8 6.1 10171:07 tair_server
20 0 4844m 3.9g 3844 S 38 6.1 10073:32 tair_server
20 0 4765m 3.8g 4144 S 8 6.0 10552:39 tair_server
20 0 2941m 2.4g 9.8m S 0 3.8 256:45.70 tair_server
20 0 2953m 2.4g 12m S 1 3.7 276:54.64 tair_server
Но , моя память исчезла.
$free -m
total used free shared buffers cached
Mem: 64552 57778 6774 0 16 326
-/+ buffers/cache: 57435 7117
Swap: 0 0 0
Я вижу, что плита потребляет много моей памяти, и это неудачно.
$cat /proc/meminfo
MemTotal: 66101892 kB
MemFree: 6816228 kB
Buffers: 17024 kB
Cached: 456640 kB
SwapCached: 0 kB
Active: 19697712 kB
Inactive: 3197312 kB
Active(anon): 19546504 kB
Inactive(anon): 2875632 kB
Active(file): 151208 kB
Inactive(file): 321680 kB
Unevictable: 48 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 6612 kB
Writeback: 72 kB
AnonPages: 22421152 kB
Mapped: 54408 kB
Shmem: 332 kB
Slab: 28870400 kB
SReclaimable: 213344 kB
SUnreclaim: 28657056 kB
KernelStack: 30000 kB
PageTables: 62776 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 33050944 kB
Committed_AS: 37517224 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 388624 kB
VmallocChunk: 34324313700 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 5696 kB
DirectMap2M: 2082816 kB
DirectMap1G: 65011712 kB
Это информация о плите.
$slabtop -s c
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
69842766 69838389 38% 0.19K 1663025 42 13304200K kmalloc-192
69314912 69314796 38% 0.12K 2166091 32 8664364K kmalloc-128
70866624 70866323 39% 0.06K 1107291 64 4429164K kmalloc-64
69299968 69299592 38% 0.03K 541406 128 2165624K kmalloc-32
128388 72434 56% 0.99K 4230 32 135360K ext4_inode_cache
208782 94112 45% 0.19K 4971 42 39768K dentry
Я не понимаю, что потребляет много памяти, почему это так и как решить эту проблему.
Может ли это быть ошибкой ядра интервала?
ИЛИ это проблема glibc, она не возвращает память обратно в систему, из-за частого чтения диска?
Обычно, когда кто-то спрашивает " где все мое Linux-память ушла «ответ» - это «дисковый кэш», и это не проблема », но я не знаю, так ли это здесь. Ошибка сервера может быть лучше. Возможно, посмотрите на этот вопрос: http://serverfault.com/questions/240277/slab-uses-88gb-of-128gb-available-what-could-cause- this –
В вопросе, который ссылается на serverfault, есть высокий уровень отзыва, который довольно хорош другой зверь от SUnreclaimable - что представляется проблемой здесь. Теперь я рассматриваю аналогичную проблему, когда выделение SOA на 64, 128 и 192 байта кажется «утечкой». Это старый вопрос, но я отчитаю, если что-нибудь придумаю. Тем временем, если кто-нибудь знает, как распределяются SOA-ресурсы в Linux, мне понравятся ваши мысли. –
@ J.Paulding Я также изучаю аналогичную проблему. Все, что вы нашли. – Joe