Bug 6103 - Утекает память в ядре
Summary: Утекает память в ядре
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-image-std26-up (show other bugs)
Version: unstable
Hardware: all Linux
: P3 blocker
Assignee: Sergey Vlasov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-11 23:03 MSK by Vitaly Lipatov
Modified: 2005-08-30 03:46 MSD (History)
1 user (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Vitaly Lipatov 2005-02-11 23:03:00 MSK
Утекает память в ядре.  
Воспроизводится при проверке подписи к пакету (отдельно 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 Sergey Vlasov 2005-02-11 23:16:51 MSK
А что при этом наблюдается в /proc/slabinfo ?
Comment 2 Vitaly Lipatov 2005-02-12 00:42:44 MSK
Да вроде ничего необратимого не происходит - xfs_ что-то там меняется, 
но в определённых рамках. 
Поскольку я это наблюдаю на разных файловых системах, не могу сказать что 
это может быть связано с какой-то из них.  
Comment 3 Vitaly Lipatov 2005-02-14 00:15:17 MSK
См. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286803 
где ситуация рассматривалась подробно. 
Comment 4 Sergey Vlasov 2005-02-15 21:26:37 MSK
И всё-таки, пожалуйста, приведите полностью содержимое /proc/meminfo и
/proc/slabinfo, причём и до, и после выполнения операций, вызывающих проблему.
Ссылка "Create a New Attachment" тут как раз предназначена для прицепления
файлов, не влезающих в комментарий.
Comment 5 Vitaly Lipatov 2005-02-16 16:15:06 MSK
Created attachment 744 [details]
/proc/meminfo before testing
Comment 6 Vitaly Lipatov 2005-02-16 16:15:25 MSK
Created attachment 745 [details]
/proc/slabinfo before testing
Comment 7 Vitaly Lipatov 2005-02-16 16:15:41 MSK
Created attachment 746 [details]
/proc/slabinfo AFTER testing
Comment 8 Vitaly Lipatov 2005-02-16 16:16:03 MSK
Created attachment 747 [details]
/proc/slabinfo AFTER testing
Comment 9 Vitaly Lipatov 2005-02-16 16:16:40 MSK
Created attachment 748 [details]
ps axu AFTER testing

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

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 Sergey Vlasov 2005-02-16 16:48:18 MSK
Кстати, проявляется ли проблема при загрузке с mem=800M (т.е., без HIGHMEM)? 
Если нет, тогда понятно, почему я её у себя не вижу...
Comment 12 Vitaly Lipatov 2005-02-16 17:00:25 MSK
(In reply to comment #11) 
> Кстати, проявляется ли проблема при загрузке с mem=800M (т.е., без HIGHMEM)?  
> Если нет, тогда понятно, почему я её у себя не вижу... 
 
Если я скажу, что у меня дома, где ситуация такая же, памяти всего 512Мб, 
это снимет вопрос? 
Comment 13 Vitaly Lipatov 2005-02-16 17:09:29 MSK
(In reply to comment #11) 
> Кстати, проявляется ли проблема при загрузке с mem=800M (т.е., без HIGHMEM)?  
> Если нет, тогда понятно, почему я её у себя не вижу... 
Проявляется - то же самое. 
У меня есть подозрение, что это из-за raid - в обоих случаях используется 
программный raid, а мне совсем не нравится его код, равно как и актуальность 
утилит к нему в пакете raidtools. 
 
Comment 14 Sergey Vlasov 2005-02-16 23:02:30 MSK
(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 Vitaly Lipatov 2005-02-17 00:29:27 MSK
> Попробовал reiserfs на raid1 - всё равно не воспроизводится (правда, 
половина 
> лежит на /dev/hda4, а другую пришлось сунуть в loop на XFS). 
Хотите шелл предоставлю? 
 
 
> Хм... а при проверке на CD использовался subfs или нет? 
Я проверял и локально на XFS - та же картина. А subfs использовался. 
Хотите на fat проверю или ext2? 
 
Comment 16 Anton Farygin 2005-02-17 14:00:11 MSK
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 Vitaly Lipatov 2005-02-18 00:25:19 MSK
(In reply to comment #16) 
> subfs влиять не должен, он только монтирует. 
> Кстати, а такой вот вопрос: лезет ли при этом система в swap ??? 
Лезет, причём полностью. Когда оперативка кончается, начинается убийство всех 
процессов, а потом полный затык. 
  
> Просто тут очень похоже на агрессивное кэширование, которое должно 
освобождаться при необходимости. 
Ну может быть и похоже, но не освобождается. В любом случае какое тут 
кэширование, если объём buffers, cache и free сходит в ноль постепенно. 
 
 
Comment 18 Vitaly Lipatov 2005-02-25 23:26:01 MSK
Возможно проблема связана с поддержкой чипсета nForce2? 
Я готов провести любые тесты, предоставить shell, только давайте как-то решим 
проблему. 
Comment 19 ahtoh 2005-02-28 11:53:48 MSK
Наблюдается на nforce2
На остальных чипах не замечено.
Comment 20 ahtoh 2005-02-28 11:54:51 MSK
Пока bug наблюдается на платах с nforce2.
На остльных чипах пока не замечено.
Comment 21 Vitaly Lipatov 2005-04-17 14:35:02 MSD
программный raid всё-таки ни при чём, потому что в тестируемых системах он 
хоть и присутствует, но именно для тестируемых разделов (где лежат пакеты) не 
применяется. 
Comment 22 Vitaly Lipatov 2005-07-16 20:01:41 MSD
Ну на 2.6.12-alt1 память перестала утекать. Так что закрываем 
за недоказанностью.