Hi, how do I print information on memory usage during execution? I have a program making heavy use of multithreading that surprisingly exhausts 750Gb of memory even if it does not use asserts and retracts friguzzi/lp4kg/blob/2344fd49a46458bd4ed2100fde8ea8ab11460db2/fbk237/inst2ranks_oi100.…

Note that this does not include memory for the stacks of the threads nor memory in tables (tries). One of these is most likely where the memory is.

So I printed the stack statistics with statistics(stack,S), format(user_error,"stack=~D\n",[S]), I get around 33Gb but the memory on the machine is exhausted (500 Gb). I also print the heap with statistics(heapused,H), writeln(user_error,heapused=H). and I always get 0. In the end the p…

[image] friguzzi: try to compile swipl with tcmalloc and see if it gets better I would expect similar results with tcmalloc if the code doesn’t use threads and somewhat more usage if it does use threads (because tcmalloc tries to avoid inter-thread locking issues by associating memory with th…

[image] peter.ludemann: tcmalloc was originally designed for multi-threaded webservers that heavily use callbacks and memory is often allocated in a thread, then freed in the callback, which can be in another thread Thanks. That is precisely what SWI-Prolog does when it comes to atoms and cl…

I ran heaptrack. These are the main results: MOST CALLS TO ALLOCATION FUNCTIONS 65267025 calls to allocation functions with 1.08M peak consumption from tmp_malloc at /hpc/home/rzf/swipl-devel/src/pl-alloc.c:1364 in /hpc/home/rzf/lib/swipl/lib/x86_64-linux/libswipl.so.9 .... PEAK MEMORY CONSUME…

[image] friguzzi: It seems there are massive memory leaks… No. In normal production version, SWI-Prolog does not try to cleanup memory on halt. Only when compiled in debug version this happens. As there can be some nasty dependencies on data behind blobs, this is a tedious and not 100% …

[image] jan: Do you have deeper stack traces? These are just the two main allocation functions Here they are lp4kg/out1.txt at 0b86684073b693b2afa578ee0a1a47b0d906a88c · friguzzi/lp4kg · GitHub

[image] jan: No. In normal production version, SWI-Prolog does not try to cleanup memory on halt. I have to add that this analysis was done while the process was still running, not at halt. And that the stack statistics was always 32G.

I can’t make much of the stack traces. The most expensive one seems to be about 0.5Gb contributed by the compiler for loading the code. I can’t find anything really big. Possibly you ran it too short? Anyway, you can also identify the suspect stack traces. If you cannot guess what is happeni…

To undestand better I used the trace for the whole execution and I used the GUI version of heaptrack I’m not an expert but I caught this [image] Does it make sense? I also added to the repo the raw trace that can be analyzed with heaptrack_gui: friguzzi/lp4kg/blob/eb325922778374bbdc63a3…

Memory usage

Help!

peter.ludemann August 9, 2024, 11:28am 30

This has been proposed and there’s some discussion: Suggestion: concurrent_findall - #11 by EricGT

1 Like

Topic		Replies	Views
Disabling tcmalloc: warning for data science and big data apps General	27	3295	July 11, 2021
Poor memory reuse (tcmalloc?) Split Topic malloc	16	2875	March 27, 2020
Prolog uses only 13% of CPU and takes an hour to complete General	23	1496	September 8, 2020
SWI does some good garbage-collection/optimisation these days General	23	1109	October 28, 2021
Performance implications of `--threads=false` in embedded swipl General	14	518	October 16, 2023

Memory usage

Related topics