[0.16.3] Memory not returning to OS after a planning request is finished/planned #318
Replies: 1 comment
-
There are several malloc libraries available and the primary two at least on Linux are pcmalloc and tcmalloc. The pcmalloc is the default unless you explicitly tell your process to use something else. The library tcmalloc was developed by Google and optimized for performance which is what I usually use for the arm planner process. At a high level these libraries decide when and how fast the process gives memory back to the system. They want to avoid constantly going back to the system for more memory so each library does it a little different on how it decides to release memory back to the system. In the case of motion planning it can allocates a lot of memory and when finished it is cleared but not given back to the system. The reason is, the malloc library assumes that the process may continue to need that level of memory so it holds on to it for performance reasons. Now after sometime if the process does not consume more than what it has already acquired it starts to give the excess memory back at some rate. Each of the malloc libraries have tunables which allow the user to tune it for your applications. In additions, if your application has multiple threads then this is also done at an individual thread level. Which is one of the reasons the planning server can show to be consuming more memory than what you might expect. I recommend taking a look at these tools and try different configurations. One way to help with in multi threaded application is to tell to use a single arena where all child thread use the same as the parent. In addition, these tools provide c++ libraries where you can force it to release all memory with a single function call. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I am using 0.16.3 tagged tesseract + tesseract planning repo and using TaskComposerPluginFactory to create planning task and taskflow executor. The way I am doing it is similar to the following:
` fs::path config_path(taskComposerPluginsFilePath);
m_factory = std::make_unique(config_path);
m_planningServer = m_factory->createTaskComposerExecutor("TaskflowExecutor");
m_profiles = std::make_shared();
m_profiles->addProfile(
"CheckInputTask", std::to_string(m_plannerType), std::make_shared());
// Profile defines some functions that handle each of the waypoint cases
m_profiles->addProfile("SimpleMotionPlannerTask",
"path_" + std::to_string(m_plannerType),
std::make_shared());
// Profile for process generator that processes the seed so it meets a minimum length
m_profiles->addProfile(
"MinLengthTask", std::to_string(m_plannerType), std::make_shared());
// Profile for trajectory Contact check
m_profiles->addProfile(
"DiscreteContactCheckTask", std::to_string(m_plannerType), std::make_shared());
// Profile for ompl
m_profiles->addProfile("OMPLMotionPlannerTask", std::to_string(m_plannerType), omplProfile);
TaskComposerDataStorage task_data;
task_data.setData(m_inputKey, *m_robotProgram);
m_robotProgram->print("Program: ");
// Create problem
TaskComposerProblem task_problem(m_environment, task_data);
// Create task input
m_taskInput = std::make_shared(task_problem, m_profiles);
m_response = m_planningServer->run(*m_task, *m_taskInput);
m_response->wait();
`
After this process, the smart pointers are reset and local variables are destroyed. However, the memory doesn't seem to be returned to the OS and memory usage of our planning server is increased everytime a planning request is solved. Any ideas why and what should I do to let memory be returned to OS? Thanks!
Beta Was this translation helpful? Give feedback.
All reactions