Доброго всем времени суток и сильного иммунитета! :)Недавно вот стал замечать вот такую странную вещь... В ТОПе очень отображается очень большое кол-во Активной ОЗУ.
Вот сейчас, к примеру:Mem: 1348M Active, 212M Inact, 197M Wired, 45M Cache, 112M Buf, 195M Free
Всего имеем 2048 МБ ОЗУ.
Все бы ничего - но нету ни одного процесса, который использовал бы такое кол-во ОЗУ.
Т.е., если подсчитать ВСЕ (тож те вывод ps -aux) процессы - получается от силы 500 Мб :(
- и такое даже если остановить все (ну, насколько это возможно) сервисы. Перезагрузку делать не хочется.. :)
Подскажите, может кто-нибудь знает - как можно определить, куда память утекает..?
>[оверквотинг удален]
>Free
>
>Всего имеем 2048 МБ ОЗУ.
>Все бы ничего - но нету ни одного процесса, который использовал бы
>такое кол-во ОЗУ.
>Т.е., если подсчитать ВСЕ (тож те вывод ps -aux) процессы - получается
>от силы 500 Мб :(
>- и такое даже если остановить все (ну, насколько это возможно) сервисы.
>Перезагрузку делать не хочется.. :)
>Подскажите, может кто-нибудь знает - как можно определить, куда память утекает..?rtorrent
>>[оверквотинг удален]
>rtorrentКак в той пьесе: "А вы откуда знаете, дядя?" (ответом было - "Я знаю, потому что я жизнь прожил") :)
Действительно, с недавнего времени иногда использую... %)После убиения оного (ну, вышел по-нормальному) - памяти не освободилось, к сожалению...
>>>[оверквотинг удален]
>>rtorrent
>
>Как в той пьесе: "А вы откуда знаете, дядя?" (ответом было -
>"Я знаю, потому что я жизнь прожил") :)
>Действительно, с недавнего времени иногда использую... %)
>
>После убиения оного (ну, вышел по-нормальному) - памяти не освободилось, к сожалению...
>И у меня не освобождается....
Но если перезагрузить комп и не пользоваться rtorrent, ну, скажем несколько дней - то с Active ОЗУ все в порядке. Стоит загрузить - понемногу начинает расти, пока не выходит на 60-70% от общего объема....
>[оверквотинг удален]
>>
>>После убиения оного (ну, вышел по-нормальному) - памяти не освободилось, к сожалению...
>>
>
>И у меня не освобождается....
>
>Но если перезагрузить комп и не пользоваться rtorrent, ну, скажем несколько дней
>- то с Active ОЗУ все в порядке. Стоит загрузить -
>понемногу начинает расти, пока не выходит на 60-70% от общего объема....
>Если интересно...:
http://forum.lissyara.su/viewtopic.php?f=8&t=16000
>>>[оверквотинг удален]
>>rtorrent
>
>Как в той пьесе: "А вы откуда знаете, дядя?" (ответом было -
>"Я знаю, потому что я жизнь прожил") :)
>Действительно, с недавнего времени иногда использую... %)
>обалдеть, вот это сеанс телепатии :-)
+1
Если ну очень хочется уменьшить Active ОЗУ - почитайте man rtorrent - конец - все в секции: ADVANCED SETTINGSВот интересное:
hash_read_ahead = MB
Configure how far ahead we ask the kernel to read when doing
hash checking. The hash checker uses madvise(..., MADV_WILLNEED)
for the requests.max_memory_usage = bytes
Set the max amount of memory space used to mapping file chunks.
This may also be set using ulimit -m where 3/4 will be allocated
to file chunks.И т.д. :)
Успехов.
О - а я этот вопрос когда-то давно пытался для себя решать. Если я ничего не путаю использование max_memory_usage немного улучшало картину, но полностью проблему не решало.Для себя я использовал вот такое "решение" - я вызывал msync с ключиком MS_INVALIDATE перед вызовом munmap в libtorrent (библиотека, которую использует rtorrent и вобщем-то откуда и идёт активное использование mmap/munmap). За счёт этого после вызова munmap регион памяти попадает в inactive / free пулы.
Если пошагово, то это примерно так:
1. Бэкапим libtorrent (на всякий случай):
pkg_create -b libtorrent-0.12.5
2. Распаковываем исходные коды libtorrent:
cd /usr/ports/net-p2p/libtorrent
make clean extract
3. Открываем в любимом редакторе файл /usr/ports/net-p2p/libtorrent/work/libtorrent-0.12.5/src/data/memory_chunk.cc и находим определение функции MemoryChunk::unmap()
4. Вносим следующие изменения:
void
MemoryChunk::unmap() {
if (!is_valid())
throw internal_error("MemoryChunk::unmap() called on an invalid object");+ if (msync(m_ptr, m_end - m_ptr,MS_INVALIDATE) != 0)
+ throw internal_error("MemoryChunk::unmap() - msync() system call failed");
+
if (munmap(m_ptr, m_end - m_ptr) != 0)
throw internal_error("MemoryChunk::unmap() system call failed: " + std::string(rak::error_number::current().c_str()));
}5. Собираем и устанавливаем изменённый libtorrent:
cd /usr/ports/net-p2p/libtorrent
make && make deinstall reinstall
>[оверквотинг удален]
>+
> if (munmap(m_ptr, m_end - m_ptr) != 0)
> throw internal_error("MemoryChunk::unmap() system call failed: "
>+ std::string(rak::error_number::current().c_str()));
> }
>
Если кто попробует - отпишитесь пожалуйста помогло или нет. Самому rtorrent пока не нужен, но чувствую скоро понадобится.
>Если кто попробует - отпишитесь пожалуйста помогло или нет. Самому rtorrent пока
>не нужен, но чувствую скоро понадобится.Помогло. И не только мне :) 12 часов уже прошло - Active ОЗУ все еще 52 Мб (как было при старте ОС):
last pid: 20505; load averages: 0.04, 0.06, 0.02 up 0+11:22:01 20:10:40
52 processes: 2 running, 50 sleeping
CPU: 0.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.2% idle
Mem: 52M Active, 154M Inact, 82M Wired, 488K Cache, 60M Buf, 200M Free
Swap: 2048M Total, 2048M Free
>[оверквотинг удален]
>ОЗУ все еще 52 Мб (как было при старте ОС):
>
>last pid: 20505; load averages: 0.04, 0.06, 0.02
> up 0+11:22:01 20:10:40
>52 processes: 2 running, 50 sleeping
>CPU: 0.8% user, 0.0% nice, 0.0% system, 0.0%
>interrupt, 99.2% idle
>Mem: 52M Active, 154M Inact, 82M Wired, 488K Cache, 60M Buf, 200M
>Free
>Swap: 2048M Total, 2048M FreeПодредактировал код, пересобрал libtorrent.
Mem: 1529M Active, 247M Inact, 133M Wired, 53M Cache, 112M Buf, 36M Free
Swap: 1024M Total, 1476K Used, 1022M Free- Одна закачка, 48Гб, скорость ~4.6 мегабайт в секунду.
memory_limit установил в 256МбИ вот самое странное...
Минут тридцать - все ОК, активной не увеличивается, а потом в течение минуты может - резкое падение кол-ва свободной и рост активной :(
После убиения rtorrent памяти освободилось еще 40 мегабайт, т.е., сейчас имею где-то 75мб свободной.Через пол-часа после убиения rtorrent:
Mem: 1481M Active, 299M Inact, 127M Wired, 52M Cache, 112M Buf, 38M Free
Swap: 1024M Total, 1076K Used, 1023M Free
Я не уверен, что полностью и правильно понял смысл предыдущего сообщения, поэтому лучше расскажу поподробнее моё видение этого вопроса/проблемы - тогда, возможно, и мне и всем станет яснее из-за чего возникает проблема и каких изменений можно ждать от патча который я предложил выше.Начнём с того, что при работе с файлами rtorrent (libtorrent) активно использует системные вызовы mmap/munmap т.е. программа "отражает" файл в память.
Использование этих системных вызовов имеет несколько особенностей. Одна из них - при множественных запросах на отражение одного участка файла (как в рамках одного процесса, так и в случае с различными процессами) возможно (при определенных условиях) ограничиться всего одной "копией" файла в памяти. В определенных случаях это приводит к многократной экономии памяти.
Следует заметить, что память, "в которую" производится чтение mmap-ed файла явно не соотнесена с процессом, который выполнил системный вызов mmap (т.е. она не считается "памятью только этого процесса"). Именно по этой причие после вызова mmap можно заметить, как объём active памяти увеличивается, но rss процесса (rtorrent) не изменяется.
Почему так происходит? - Отчасти потому что данное "отражение файла в памяти" может использоваться другими процессами.Что происходит когда выполняется munmap? - Грубо говоря "количество ссылок" на участок памяти, хранящий "отражение файла в памяти" уменьшается. Но этот участок памяти всё ещё относится к Active пулу. И он будет очищен только когда в следствии "vm pressure" операционная система начнёт искать участки памяти которые безболезненно можно освободить (за счёт наличия их в backing store). В данном случае "отражение файла в памяти" плюс сам файл (на физическом носителе) и будут представлять "участок памяти, который может быть освобождёт" плюс его backing store.
**
Небольшое отступление для тех, "кому очень интересно" - попробуйте скачать хотябы двухсотмегабайтный файл при помощи rtorrent, далее обратие внимание на состояние памяти, потом удалите файл (или отмонтируйте раздел, куда файл был скачан) и посмотрите на то, что произойдёт с Active в следующие 30 секунд.
**Таким образом получается, что при использовании mmap/munmap для отражения файлов в память, размер active пула будет рости до тех пор, пока не возникнет своего рода "событие нехватки памяти" и vm не начнёт выполнять ревизию страниц памяти active пула.
Что происходит при использовании данного патча - при помощи вызова msync
мы указываем, что участок памяти (который мы собираемся "освободить") необходимо считать "недействительным" отражением файла. За счёт этого после вызова munmap участок памяти попадает во free пул.Всё это значит, что с этим патчем:
- при использовании rtorrent не должен происходить постоянный/неконтролируемый/необъяснимый рост active памяти. Но объём active память может увеличиваться в момент когда происходит проверка хэша, или когда вы раздаёте/качаете файлы для/у значительного количества пиров. Т.е. если, например, 100 пиров качают у меня 100 различных фрагментов файлов, в раздачах, где chunk size равен 1Мб, то размер Active памяти увеличится на 100Мб.
- как только rtorrent закончил отдавать или качать определённый фрагмент файла он вызывает unmap, а значит сразу же освобождается и Active память
- после выхода из программы все участки памяти, которые rtorrent запрашивал у ОС для "отражения файлов в памяти", попадут во free poolПримечание №1: для того, чтоб детально не описывать возможные режимы работы mmap/munmap я ограничивался фразами типа "существуют режимы работы" или "в определённых случаях".
Примечание №2: всё вышесказанное демонстрирует уровень моей некомпетенции в понимании вопросов работы виртуальной памяти :) Т.е. на самом деле всё может быть совсе не так, как это понимаю я :)
торренты рулят :)
раньше игрушки были двигателями прогресса, а теперь вот торренты напрягают мозг:))>Подредактировал код, пересобрал libtorrent.
>
>Mem: 1529M Active, 247M Inact, 133M Wired, 53M Cache, 112M Buf, 36M
>Free
>Swap: 1024M Total, 1476K Used, 1022M Free
>одно радует, что своп всё-таки не задействуется, то есть выше приведенная фраза есть true!
а именно:"FreeBSD will not <...> try to deactivate pages (active queue -> inactive queue) when the system is not being stressed, even if they are not being used."
>одно радует, что своп всё-таки не задействуется, то есть выше приведенная фраза
>есть true!
>а именно:Возможно товарищ что-то неправильно сделал.
Я проверил на своем сервере и на сервере знакомого - нам обоим патч помог!
У товарища Active ОЗУ было всегда 1500 Мб (из 2-х Гб) - у меня: 333 (из 512).
После патча у него Active 200 Мб (раздача много гигов) - у меня 52-60 Мб...
Да нет, все правильно... :)С маленькой скоростью - действительно кол-во ОЗУ не увеличивается... А когда вот под десять мегабайт в сек - лажа.
>Для себя я использовал вот такое "решение" - я вызывал msync с
>ключиком MS_INVALIDATE перед вызовом munmap в libtorrent (библиотека, которую использует rtorrent
>и вобщем-то откуда и идёт активное использование mmap/munmap). За счёт этого
>после вызова munmap регион памяти попадает в inactive / free пулы.Огромное спасибо, у меня была точно такая же проблема, решение помогло. На freebsd.org уже есть ссылка на ваш патч: http://forums.freebsd.org/showthread.php?t=9935&page=2
Рад это слышать, и вам спасибо :) Приятно "оказаться полезным" :)
> Подскажите, может кто-нибудь знает - как можно определить, куда память утекает..?Ничего не куда не утекает. Бросьте эти виндовые замашки, что бы не показывал топ - так оно и должно быть.
>> Подскажите, может кто-нибудь знает - как можно определить, куда память утекает..?
>
>Ничего не куда не утекает. Бросьте эти виндовые замашки, что бы не
>показывал топ - так оно и должно быть.
>> Подскажите, может кто-нибудь знает - как можно определить, куда память утекает..?
>
>Ничего не куда не утекает. Бросьте эти виндовые замашки, что бы не
>показывал топ - так оно и должно быть."виндовые замашки" бросил уже давно.
Просто если страницы памяти помечены как активные, то "просто так" так не будет.
Правильно? :)
Если сумма всех процессов в два раза меньше этой активной памяти (даже если вычесть кол-во неактивной памяти) - то так быть, судя по всему, быть не должно :)
Ничто не возникает из ниоткуда ведь..? И не исчезает в никуда..?
Ну и после убиения ресурсоемких процессов та память все равно остается помеченной как активная и использовать ее очень проблематично - у меня, например, начинает своп дергаться (а это при 2ГБ ОЗУ именно в данной ситуации - как-то ненормально :) ).
Сервер ночью перезагружу, попробую rtorrent донастроить, потестирую :)
Да, последний рторрент не радует. Раньше было всё пучком, а теперь херь эта.
>[оверквотинг удален]
>Вот сейчас, к примеру:
>
>Mem: 1348M Active, 212M Inact, 197M Wired, 45M Cache, 112M Buf, 195M
>Free
>
>Всего имеем 2048 МБ ОЗУ.
>Все бы ничего - но нету ни одного процесса, который использовал бы
>такое кол-во ОЗУ.
>Т.е., если подсчитать ВСЕ (тож те вывод ps -aux) процессы - получается
>от силы 500 Мб :(а вот и ответ -- http://www.freebsd.org/doc/en/articles/vm-design/allen-brigg...
"What this means is that FreeBSD will not try very hard to separate out dirty pages (inactive queue) from clean pages (cache queue) when the system is not being stressed, nor will it try to deactivate pages (active queue -> inactive queue) when the system is not being stressed, even if they are not being used."
т.е. процесс завершился, но память, которую он использовал (втч. через mmap) еще не "очищена" и не освобождена, ибо нет нужды.
>[оверквотинг удален]
>>такое кол-во ОЗУ.
>>Т.е., если подсчитать ВСЕ (тож те вывод ps -aux) процессы - получается
>>от силы 500 Мб :(
>
>а вот и ответ -- http://www.freebsd.org/doc/en/articles/vm-design/allen-brigg...
>
>"What this means is that FreeBSD will not try very hard to separate out dirty pages (inactive queue) from clean pages (cache queue) when the system is not being stressed, nor will it try to deactivate pages (active queue -> inactive queue) when the system is not being stressed, even if they are not being used."
>
>т.е. процесс завершился, но память, которую он использовал (втч. через mmap) еще
>не "очищена" и не освобождена, ибо нет нужды."нет нужды" ее очищать, но есть нужда использовать своп..?
Память, которую "нет нужды очищать" должна перейти в Inact.
Но никак не оставаться Active, заставляя работать своп (причем, даже после завершения самого процесса).
То, что память после использования НЕ переходит во Free а становится Inactive - это нормально, и с этим все понятно.
НО! Мы говорим о ситуации (Вот в нашем случае), когда память из Active НЕ переходит ни в Inactive ни во Free, ни через час, ни через два, три, десять - а остается Active, то есть, из машины с 2ГБ ОЗУ получаем машинку с 64МБ ОЗУ :) Пока не будет произведен ребут.И это НЕ есть нормально.
Такое поведение (по крайней мере у меня) замечено действительно только с rtorrent (хотя, другие пробовать не успел - нет нужды).
>"нет нужды" ее очищать, но есть нужда использовать своп..?а что, используется своп?
>Память, которую "нет нужды очищать" должна перейти в Inact.
>Но никак не оставаться Active, заставляя работать своп (причем, даже после завершения
>самого процесса).
>То, что память после использования НЕ переходит во Free а становится Inactive
>- это нормально, и с этим все понятно.
>НО! Мы говорим о ситуации (Вот в нашем случае), когда память из
>Active НЕ переходит ни в Inactive ни во Free, ни через
>час, ни через два, три, десять - а остается Active, то
>есть, из машины с 2ГБ ОЗУ получаем машинку с 64МБ ОЗУпочитайте целиком документ, из которого я взял цитату. там объясняется, что при первой же необходимости cache и inactive превращаются во free, но без нужды ни того, ни того не происходит -- на случай, если быстро потребуется "активировать" inactive/cached память (быстро -- не подкачивая с диска).
>[оверквотинг удален]
>>НО! Мы говорим о ситуации (Вот в нашем случае), когда память из
>>Active НЕ переходит ни в Inactive ни во Free, ни через
>>час, ни через два, три, десять - а остается Active, то
>>есть, из машины с 2ГБ ОЗУ получаем машинку с 64МБ ОЗУ
>
>почитайте целиком документ, из которого я взял цитату. там объясняется, что
>при первой же необходимости cache и inactive превращаются во free, но
>без нужды ни того, ни того не происходит -- на случай,
>если быстро потребуется "активировать" inactive/cached память (быстро -- не подкачивая с
>диска).Вы или издеваетесь, или действительно невнимательно читаете мои посты...
По той ссылке говорится именно о неактивной памяти. А я вам пишу что большое количество активной (98% от общего) - а вот для того чтоб она могла быть использована, она должна, хотя бы, перейти в неактивную - для начала. Этого не происходит - говорю уже который раз. Она не может быть использована другим приложением! (потому что, как бы "уже используется"). Ну и на все остальные процессы остается совсем немножко свободной и неактивной. И начинает использоваться своп (да, он начинает использоваться !!! Я об этом упоминал раза три).
>Вы или издеваетесь, или действительно невнимательно читаете мои посты...
>По той ссылке говорится именно о неактивной памяти. А я вам пишу
>что большое количество активной (98% от общего) - а вот для
>того чтоб она могла быть использована, она должна, хотя бы, перейти
>в неактивную - для начала. Этого не происходит - говорю уже
>который раз. Она не может быть использована другим приложением! (потому
>что, как бы "уже используется"). Ну и на все остальные процессы
>остается совсем немножко свободной и неактивной. И начинает использоваться своп (да,
>он начинает использоваться !!! Я об этом упоминал раза три)."FreeBSD will not <...> try to deactivate pages (active queue -> inactive queue) when the system is not being stressed, even if they are not being used"
у меня нет объяснения тому поведению, что вы описали. разве что "system is not being stressed".
>"FreeBSD will not <...> try to deactivate pages (active queue -> inactive queue) when the system is not being stressed, even if they are not being used"
>
>у меня нет объяснения тому поведению, что вы описали. разве что
>"system is not being stressed".ХЗ. С другим софтом это происходит. Убьешь - активной уменьшится :)
Свободной больше станет) А с рторрент - не так :(
И, как я понял, действительно имеет место такая проблема - как понимаю, не только во FreeBSD.
>остается совсем немножко свободной и неактивной. И начинает использоваться своп (да,
>он начинает использоваться !!! Я об этом упоминал раза три).
>Вы бы привели всё-таки следующую строчку Swap: из вывода top и все бы успокоились :)
Mem: 180M Active, 155M Inact, 114M Wired, 19M Cache, 77M Buf, 32M Free
Swap: 1007M Total, 6808K Used, 1000M Free
>[оверквотинг удален]
>+
> if (munmap(m_ptr, m_end - m_ptr) != 0)
> throw internal_error("MemoryChunk::unmap() system call failed: "
>+ std::string(rak::error_number::current().c_str()));
> }
>
>
>5. Собираем и устанавливаем изменённый libtorrent:
>cd /usr/ports/net-p2p/libtorrent
>make && make deinstall reinstallЕсли кто попробует - отпишитесь пожалуйста помогло или нет. Самому rtorrent пока не нужен, но чувствую скоро понадобится.
Поставил попробовать transmission.
Что сказать - небо и земля =)
Поставил на закачку архив 8мб, со скоростью 8.6 мегабайт в секунду закачался, при этом загрузка процессора 23%. Активной памяти во время закачки не увеличивалось, увеличилось кол-во неактивной, но в разумных пределах :)
Но функционал вэб-интерфейса далеко не так богат как у рторрент.
>[оверквотинг удален]
>>+ std::string(rak::error_number::current().c_str()));
>> }
>>
>>
>>5. Собираем и устанавливаем изменённый libtorrent:
>>cd /usr/ports/net-p2p/libtorrent
>>make && make deinstall reinstall
>
>Если кто попробует - отпишитесь пожалуйста помогло или нет. Самому rtorrent пока
>не нужен, но чувствую скоро понадобится.Действительно, результат положительный есть :)
Хотя, сам перешел уже на другой клиент.
>Действительно, результат положительный есть :)
>Хотя, сам перешел уже на другой клиент.Ну да, сразу бы винду поставили, что там. Из-за циферок, которые вы даже не в состоянии интерпретировать, грешить на систему и клиент, клиника.
>>Действительно, результат положительный есть :)
>>Хотя, сам перешел уже на другой клиент.
>
>Ну да, сразу бы винду поставили, что там.Может тогда сразу какой-нибудь Xbox ? ))
Кардинальные меры какие-то предлагаете...Из-за циферок, которые вы
>даже не в состоянии интерпретироватьЯ или Вы?
> грешить на систему и клиент, клиника.
О, да... ) Active - весь объем ОЗУ Почти, Inactive нету, своп - используется.
Ага, точно) Ну если Вы предлагаете все свободные ресурсы выделять под один процесс...)
Да, грешу на клиент ) С transmission таких проблем не возникало. На что мне грешить в данной ситуации? ) Циферки неправильные, или может еще что..?