Еще одна проблема с утечкой памяти (память все еще отсутствует, когда программа завершается) - программа C на SLES

Может ли быть несовпадение malloc () / free (), которое приведет к потере памяти навсегда, т. е. даже после завершения процесса?

Нет, malloc и free, и даже mmap безвредны в этом отношении, и когда процесс завершает работу ОС (SUSE Linux в этом случае) запрашивает обратно всю свою память (если она не используется совместно с каким-либо другим процессом, который все еще работает).

Что еще в программе C (не C ++) может вызвать необратимую потерю памяти, то есть после завершения программы и даже закрытия окна терминала? Только перезагрузка возвращает память. Я читал другие сообщения о том, что файлы, которые не закрываются, вызывают проблемы, но не думаю, что у меня эта проблема.

Подобно malloc / free и mmap, файлы, открытые процессом, автоматически закрываются ОС.

Есть несколько вещей, которые вызывают постоянные утечки памяти, например большие страницы, но вы наверняка знали бы об этом, если бы использовали их. Кроме того, нет.

Однако, если вы определяете потерю памяти как память, которая не помечается сразу как «свободна», может произойти несколько вещей.

1. Записи на диск или mmap могут быть на некоторое время кэшированы в RAM. ОС должна сохранять страницы, пока не синхронизирует их с диском.
2. Файлы, ПРОЧИТАННЫЕ процессом, могут оставаться в памяти, если ОС не имеет ничего другого, чтобы использовать эту оперативную память прямо сейчас - при разумном предположении, что они могут потребоваться в ближайшее время и быстрее прочитать копию, которая уже находится в ОЗУ. Опять же, если ОС или другому процессу требуется некоторая часть этой оперативной памяти, ее можно немедленно удалить.

Обратите внимание: как человек, заплативший за всю мою оперативную память, я бы предпочел, чтобы ОС использовала ВСЕ ее ВСЕГДА, если это помогает хотя бы малейшим образом. Свободная RAM - это потраченная впустую RAM.

Основная проблема с небольшим объемом свободной оперативной памяти - это перегрузка, что означает, что сейчас больше процессов (и ОС) запрашивают или используют оперативную память, чем доступно в системе. Похоже, вы используете около 4 Гб ОЗУ в своих процессах, что может быть проблемой - (и помните, что ОС тоже нужен хороший кусок. Но похоже, что у вас много ОЗУ! Попробуйте запустить половину количества процессов и посмотрите если станет лучше.

Иногда утечка памяти может вызвать временную перегрузку - это хорошая идея. Попробуйте построить график использования памяти вашей программой с течением времени - если он постоянно растет, то это вполне может быть утечка.

Обратите внимание, что forking процесса создает копию, которая разделяет память, выделенную исходным, - до тех пор, пока оба не будут закрыты или один из них не будет исполняться. Но вы этого не делаете.

Допустимо ли смотреть на верхнюю и свободную статистику памяти, т.е. точно ли они описывают ситуацию с памятью? Похоже, они соответствуют медленной работе программы.

Да, top и ps - вполне разумные способы посмотреть на память, в частности, на поле RES. Пока не обращайте внимания на поле VIRT. Кроме того:

Чтобы увидеть, что вся система делает с памятью, запустите:

vmstat 10

Пока ваша программа работает и некоторое время после нее. Посмотрите, что происходит с ---memory--- столбцами.

Кроме того, после завершения вашего процесса запустите

cat /proc/meminfo

И разместите результаты в своем вопросе.

Если программа показывает использование памяти только на 4%, найдет ли эту проблему что-нибудь вроде valgrind?

Возможно, но это может быть очень медленным, что в данном случае может оказаться непрактичным. Есть множество других инструментов, которые могут помочь, например, electricfence и другие, которые не усложняют работу вашей программы. заметно. Раньше я даже катался самостоятельно.

malloc () / free () работают в куче. Эта память гарантированно будет освобождена ОС после завершения процесса. Возможна утечка памяти даже после завершения процесса выделения с использованием определенных примитивов общей памяти (например, System V IPC). Однако я не думаю, что все это имеет прямое отношение.

Немного отступив, вот вывод слегка загруженного сервера Linux:

$ uptime
 03:30:56 up 72 days,  8:42,  2 users,  load average: 0.06, 0.17, 0.27
$ free -m
             total       used       free     shared    buffers     cached
Mem:         24104      23452        652          0      15821        978
-/+ buffers/cache:       6651      17453
Swap:         3811          5       3806

О нет, всего 652 Мб бесплатно! Правильно? Неправильный.

Всякий раз, когда Linux обращается к блочному устройству (например, к жесткому диску), он ищет любую неиспользуемую память и сохраняет там копию данных. В конце концов, а почему бы и нет? Данные уже находятся в ОЗУ, какой-то программе явно нужны эти данные, а неиспользуемая ОЗУ никому не принесет никакой пользы. Если появляется программа и запрашивает больше памяти, кэшированные данные отбрасываются, чтобы освободить место - до тех пор они могут с таким же успехом повиснуть на них.

Ключом к этому free выводу является не первая строка, а вторая. Да, используется 23,4 ГБ ОЗУ, но для программ, которым это необходимо, доступно 17,4 ГБ. См. Помощь! Linux съел мою оперативную память!, чтобы узнать больше.

Я не могу сказать, почему программа становится медленнее, но постоянное снижение показателя «свободная память» до нуля - это совершенно нормально, а не причина.

Операционная система освобождает ровно столько памяти, сколько ей необходимо. Освобождение памяти - это напрасная трата усилий, если впоследствии память будет использоваться в обычном режиме - более эффективно просто напрямую перевести память от одного использования к другому, чем освобождать память только для того, чтобы сделать ее несвободной позже.

Единственное, для чего системе нужна свободная память, - это для операций, требующих памяти, которые не могут переключать используемую память с одной цели на другую. Это очень небольшой набор необычных операций, таких как обслуживание сетевых прерываний.

Если вы наберете эту команду sysctl vm.min_free_kbytes, система сообщит вам, сколько КБ необходимо освободить. Вероятно, меньше 100 МБ. Так что иметь любую сумму, превышающую эту, совершенно нормально.

Если вы хотите освободить больше памяти, удалите ее с компьютера. В противном случае операционная система предполагает, что ее использование не требует дополнительных затрат, а значит, и дает нулевую выгоду от ее бесплатного использования.

Например, рассмотрим данные, которые вы записали на диск. Операционная система могла освободить память, в которой хранились эти данные. Но это двойная потеря. Если данные, которые вы записали на диск, позже будут прочитаны, ему придется читать их с диска, а не просто извлекать их из памяти. И если эта память позже понадобится для какой-то другой цели, ей просто нужно будет отменить всю работу, которую она проделала, чтобы освободить ее. Фу. Так что, если системе совершенно не нужна свободная память, она не освободит ее.

Думаю, проблема не в вашей программе, а в операционной системе. ОС хранит кеш недавно использованных файлов в памяти, предполагая, что вы собираетесь получить к ним доступ снова. Он не знает с уверенностью, какие файлы потребуются, поэтому может в конечном итоге решить сохранить неправильные за счет тех, которые вы хотели бы сохранить.

Он может сохранять выходные файлы первого запуска в кэше, когда вы выполняете второй запуск, что не позволяет эффективно использовать кеш при втором запуске. Вы можете проверить эту теорию, удалив все файлы из первого запуска (что должно освободить их из кеша) и посмотреть, ускоряет ли это второй запуск.

Если это не сработает, попробуйте также удалить все входные файлы для первого запуска.

Ответы

1. Да, в C или C ++ нет требования освобождать память, которая не освобождена обратно в ОС
2. Есть ли у вас файлы с отображением памяти, дескрипторы открытых файлов для удаленных файлов и т. Д. Linux не удалит файл, пока все ссылки на него не будут удалены. Также linux будет кэшировать файл в памяти на случай, если его нужно будет прочитать снова - использование памяти файлового кеша можно игнорировать, так как ОС будет с этим справляться.
3. No
4. Может быть, valgrind выделит случаи, когда памяти нет