Утекает память в ядре. Воспроизводится при проверке подписи к пакету (отдельно 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: Объём доступной памяти для программ уменьшается и уменьшается.
А что при этом наблюдается в /proc/slabinfo ?
Да вроде ничего необратимого не происходит - xfs_ что-то там меняется, но в определённых рамках. Поскольку я это наблюдаю на разных файловых системах, не могу сказать что это может быть связано с какой-то из них.
См. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286803 где ситуация рассматривалась подробно.
И всё-таки, пожалуйста, приведите полностью содержимое /proc/meminfo и /proc/slabinfo, причём и до, и после выполнения операций, вызывающих проблему. Ссылка "Create a New Attachment" тут как раз предназначена для прицепления файлов, не влезающих в комментарий.
Created attachment 744 [details] /proc/meminfo before testing
Created attachment 745 [details] /proc/slabinfo before testing
Created attachment 746 [details] /proc/slabinfo AFTER testing
Created attachment 747 [details] /proc/slabinfo AFTER testing
Created attachment 748 [details] ps axu AFTER testing Мы видим, что после тестирование всего несколько процессов незначительно занимают память.
Ага, вот теперь проблема видна: 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 .
Кстати, проявляется ли проблема при загрузке с mem=800M (т.е., без HIGHMEM)? Если нет, тогда понятно, почему я её у себя не вижу...
(In reply to comment #11) > Кстати, проявляется ли проблема при загрузке с mem=800M (т.е., без HIGHMEM)? > Если нет, тогда понятно, почему я её у себя не вижу... Если я скажу, что у меня дома, где ситуация такая же, памяти всего 512Мб, это снимет вопрос?
(In reply to comment #11) > Кстати, проявляется ли проблема при загрузке с mem=800M (т.е., без HIGHMEM)? > Если нет, тогда понятно, почему я её у себя не вижу... Проявляется - то же самое. У меня есть подозрение, что это из-за raid - в обоих случаях используется программный raid, а мне совсем не нравится его код, равно как и актуальность утилит к нему в пакете raidtools.
(In reply to comment #13) > У меня есть подозрение, что это из-за raid - в обоих случаях используется > программный raid, а мне совсем не нравится его код, равно как и актуальность > утилит к нему в пакете raidtools. Попробовал reiserfs на raid1 - всё равно не воспроизводится (правда, половина лежит на /dev/hda4, а другую пришлось сунуть в loop на XFS). В некоторых случаях число buffer_head зашкаливает за 100000 (в частности, при md5sum на vfat), но при смене нагрузки эта память освобождается. Исчезновения памяти "непонятно куда" (ни в Buffers, ни в Cached, ни в Slab) добиться так и не удалось. Хм... а при проверке на CD использовался subfs или нет?
> Попробовал reiserfs на raid1 - всё равно не воспроизводится (правда, половина > лежит на /dev/hda4, а другую пришлось сунуть в loop на XFS). Хотите шелл предоставлю? > Хм... а при проверке на CD использовался subfs или нет? Я проверял и локально на XFS - та же картина. А subfs использовался. Хотите на fat проверю или ext2?
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
(In reply to comment #16) > subfs влиять не должен, он только монтирует. > Кстати, а такой вот вопрос: лезет ли при этом система в swap ??? Лезет, причём полностью. Когда оперативка кончается, начинается убийство всех процессов, а потом полный затык. > Просто тут очень похоже на агрессивное кэширование, которое должно освобождаться при необходимости. Ну может быть и похоже, но не освобождается. В любом случае какое тут кэширование, если объём buffers, cache и free сходит в ноль постепенно.
Возможно проблема связана с поддержкой чипсета nForce2? Я готов провести любые тесты, предоставить shell, только давайте как-то решим проблему.
Наблюдается на nforce2 На остальных чипах не замечено.
Пока bug наблюдается на платах с nforce2. На остльных чипах пока не замечено.
программный raid всё-таки ни при чём, потому что в тестируемых системах он хоть и присутствует, но именно для тестируемых разделов (где лежат пакеты) не применяется.
Ну на 2.6.12-alt1 память перестала утекать. Так что закрываем за недоказанностью.
