Summary: | Утекает память в ядре | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Sisyphus | Reporter: | Vitaly Lipatov <lav> | ||||||||||||
Component: | kernel-image-std26-up | Assignee: | Sergey Vlasov <vsu> | ||||||||||||
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||||||||
Severity: | blocker | ||||||||||||||
Priority: | P3 | CC: | rider | ||||||||||||
Version: | unstable | ||||||||||||||
Hardware: | all | ||||||||||||||
OS: | Linux | ||||||||||||||
Attachments: |
|
Description
Vitaly Lipatov
2005-02-11 23:03:00 MSK
А что при этом наблюдается в /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 память перестала утекать. Так что закрываем за недоказанностью. |