Bug 6103 - Утекает память в ядре
: Утекает память в ядре
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/kernel-image-std26-up)
: unstable
: all Linux
: P3 blocker
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2005-02-11 23:03 by
Modified: 2005-08-30 03:46 (History)


Attachments
/proc/meminfo before testing (670 bytes, text/plain)
2005-02-16 16:15, Vitaly Lipatov
no flags Details
/proc/slabinfo before testing (13.06 KB, text/plain)
2005-02-16 16:15, Vitaly Lipatov
no flags Details
/proc/slabinfo AFTER testing (670 bytes, text/plain)
2005-02-16 16:15, Vitaly Lipatov
no flags Details
/proc/slabinfo AFTER testing (13.06 KB, text/plain)
2005-02-16 16:16, Vitaly Lipatov
no flags Details
ps axu AFTER testing (2.14 KB, text/plain)
2005-02-16 16:16, Vitaly Lipatov
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-02-11 23:03:00
Утекает память в ядре.  
Воспроизводится при проверке подписи к пакету (отдельно md5sum не даёт такого  
эффекта).  
Запускаем команду  
$ find путь_к_rpm-файлам | xargs rpm --checksig  
Зависимости от диска (DVD/CD или файловая система XFS/reiserfs не наблюдается)  
  
Вот выдержка из /proc/meminfo:  
MemTotal:       516088 kB  
MemFree:         43076 kB  
Buffers:         60564 kB  
Cached:          12444 kB  
SwapCached:        132 kB  
Active:         236288 kB  
Inactive:       207064 kB  
  
Как видно, занято около 400Мб памяти, причём это runlevel 1,  
и запущен только bash, в котором я файл с отчётом по состоянию памяти и  
сохранял.  
  
Вот обсуждения на эту тему:  
http://lists.altlinux.ru/pipermail/sisyphus/2005-January/051619.html   
http://lists.altlinux.ru/pipermail/sisyphus/2005-February/052638.html  
http://lists.altlinux.ru/pipermail/devel-kernel/2005-February/005073.html   
   

Actual Results:  
Объём доступной памяти для программ уменьшается и уменьшается.
------- Comment #1 From 2005-02-11 23:16:51 -------
А что при этом наблюдается в /proc/slabinfo ?
------- Comment #2 From 2005-02-12 00:42:44 -------
Да вроде ничего необратимого не происходит - xfs_ что-то там меняется, 
но в определённых рамках. 
Поскольку я это наблюдаю на разных файловых системах, не могу сказать что 
это может быть связано с какой-то из них.  
------- Comment #3 From 2005-02-14 00:15:17 -------
См. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286803 
где ситуация рассматривалась подробно. 
------- Comment #4 From 2005-02-15 21:26:37 -------
И всё-таки, пожалуйста, приведите полностью содержимое /proc/meminfo и
/proc/slabinfo, причём и до, и после выполнения операций, вызывающих проблему.
Ссылка "Create a New Attachment" тут как раз предназначена для прицепления
файлов, не влезающих в комментарий.
------- Comment #5 From 2005-02-16 16:15:06 -------
Created an attachment (id=744) [details]
/proc/meminfo before testing
------- Comment #6 From 2005-02-16 16:15:25 -------
Created an attachment (id=745) [details]
/proc/slabinfo before testing
------- Comment #7 From 2005-02-16 16:15:41 -------
Created an attachment (id=746) [details]
/proc/slabinfo AFTER testing
------- Comment #8 From 2005-02-16 16:16:03 -------
Created an attachment (id=747) [details]
/proc/slabinfo AFTER testing
------- Comment #9 From 2005-02-16 16:16:40 -------
Created an attachment (id=748) [details]
ps axu AFTER testing

Мы видим, что после тестирование всего несколько процессов незначительно
занимают память.
------- Comment #10 From 2005-02-16 16:39:39 -------
Ага, вот теперь проблема видна:

buffer_head       244682 244950     52   75    1 : tunables  120   60    0 :
slabdata   3266   3266      0

Что-то похожее: http://marc.theaimsgroup.com/?t=110840949300005&r=1&w=2 .
------- Comment #11 From 2005-02-16 16:48:18 -------
Кстати, проявляется ли проблема при загрузке с mem=800M (т.е., без HIGHMEM)? 
Если нет, тогда понятно, почему я её у себя не вижу...
------- Comment #12 From 2005-02-16 17:00:25 -------
(In reply to comment #11) 
> Кстати, проявляется ли проблема при загрузке с mem=800M (т.е., без HIGHMEM)?  
> Если нет, тогда понятно, почему я её у себя не вижу... 
 
Если я скажу, что у меня дома, где ситуация такая же, памяти всего 512Мб, 
это снимет вопрос? 
------- Comment #13 From 2005-02-16 17:09:29 -------
(In reply to comment #11) 
> Кстати, проявляется ли проблема при загрузке с mem=800M (т.е., без HIGHMEM)?  
> Если нет, тогда понятно, почему я её у себя не вижу... 
Проявляется - то же самое. 
У меня есть подозрение, что это из-за raid - в обоих случаях используется 
программный raid, а мне совсем не нравится его код, равно как и актуальность 
утилит к нему в пакете raidtools. 
 
------- Comment #14 From 2005-02-16 23:02:30 -------
(In reply to comment #13)
> У меня есть подозрение, что это из-за raid - в обоих случаях используется 
> программный raid, а мне совсем не нравится его код, равно как и актуальность 
> утилит к нему в пакете raidtools. 

Попробовал reiserfs на raid1 - всё равно не воспроизводится (правда, половина
лежит на /dev/hda4, а другую пришлось сунуть в loop на XFS).

В некоторых случаях число buffer_head зашкаливает за 100000 (в частности, при
md5sum на vfat), но при смене нагрузки эта память освобождается. Исчезновения
памяти "непонятно куда" (ни в Buffers, ни в Cached, ни в Slab) добиться так и не
удалось.

Хм... а при проверке на CD использовался subfs или нет?
------- Comment #15 From 2005-02-17 00:29:27 -------
> Попробовал reiserfs на raid1 - всё равно не воспроизводится (правда, 
половина 
> лежит на /dev/hda4, а другую пришлось сунуть в loop на XFS). 
Хотите шелл предоставлю? 


> Хм... а при проверке на CD использовался subfs или нет? 
Я проверял и локально на XFS - та же картина. А subfs использовался. 
Хотите на fat проверю или ext2? 
------- Comment #16 From 2005-02-17 14:00:11 -------
subfs влиять не должен, он только монтирует.
Кстати, а такой вот вопрос: лезет ли при этом система в swap ???

Просто тут очень похоже на агрессивное кэширование, которое должно освобождаться
при необходимости.

например - у меня на сервере ситуация такая:
$ cat /proc/meminfo 
MemTotal:      1035704 kB
MemFree:        145520 kB
Buffers:          1376 kB
Cached:         835636 kB
SwapCached:          0 kB
Active:         341992 kB
Inactive:       511204 kB
HighTotal:      130496 kB
HighFree:          140 kB
LowTotal:       905208 kB
LowFree:        145380 kB
SwapTotal:      401584 kB
SwapFree:       401584 kB
Dirty:             220 kB
Writeback:           0 kB
Mapped:          23012 kB
Slab:            26364 kB
CommitLimit:    919436 kB
Committed_AS:    39716 kB
PageTables:        760 kB
VmallocTotal:   114680 kB
VmallocUsed:     23280 kB
VmallocChunk:    91124 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     4096 kB
------- Comment #17 From 2005-02-18 00:25:19 -------
(In reply to comment #16) 
> subfs влиять не должен, он только монтирует. 
> Кстати, а такой вот вопрос: лезет ли при этом система в swap ??? 
Лезет, причём полностью. Когда оперативка кончается, начинается убийство всех 
процессов, а потом полный затык. 
  
> Просто тут очень похоже на агрессивное кэширование, которое должно 
освобождаться при необходимости. 
Ну может быть и похоже, но не освобождается. В любом случае какое тут 
кэширование, если объём buffers, cache и free сходит в ноль постепенно. 
 
 
------- Comment #18 From 2005-02-25 23:26:01 -------
Возможно проблема связана с поддержкой чипсета nForce2? 
Я готов провести любые тесты, предоставить shell, только давайте как-то решим 
проблему. 
------- Comment #19 From 2005-02-28 11:53:48 -------
Наблюдается на nforce2
На остальных чипах не замечено.
------- Comment #20 From 2005-02-28 11:54:51 -------
Пока bug наблюдается на платах с nforce2.
На остльных чипах пока не замечено.
------- Comment #21 From 2005-04-17 14:35:02 -------
программный raid всё-таки ни при чём, потому что в тестируемых системах он 
хоть и присутствует, но именно для тестируемых разделов (где лежат пакеты) не 
применяется. 
------- Comment #22 From 2005-07-16 20:01:41 -------
Ну на 2.6.12-alt1 память перестала утекать. Так что закрываем 
за недоказанностью.