Open vsbaldeev opened 2 months ago
If you are running on CPU with languages other than python you can disable MemoryArena:
@yuslepukhin Thank you for your attention on this problem. I have several questions about enable_cpu_mem_arena
property.
Memory arena was created to pool GPU allocations as they are much more expensive. However, historically, it was left on by default for CPU scenarios.
This is a slub allocator. Memory arena serves only Tensor allocations and nothing else. With the arena off, all allocations for CPU EP go to the OS heap.
Typically, OS heap is much more intelligent than arena locking (CUDA workloads usually do not run from multiple threads) and thus may benefit users. The exact perf impact may depend on the model you are running and the environment.
In the past we have fixed a few kernels that exhibited heap contention due to inefficiencies, but not many. It does reduce memory footprint.
Python environment due to its GC makes matters more complicated. Said that, I will look into your scenario.
As far as I understand, there are no memory leaks in the main branch version because of #22323 and one can disable memory arena in python. Will this fix be added to the next release ? Which version should I use in my scenario ?
We are not aware of any memory leaks on Onnxruntime side. However, one issue here, if memory arena is enabled and at least one OrtValue leaks and/or not garbage collected, then that arena is held allocated.
I cannot recommend you a specific version, we usually recommend the latest. I think this PR would be in the upcoming release.
Depending on the scenario, some customers reported a slight perf improvement and some slight degradation when memory arena is disabled, but nothing major. However, everyone likes the reduced memory consumption.
I ran the same model via C++ API and there are no leaks. I will check Python side when I get a chance.
I ran it with tracemalloc
and while I cannot explain everything, this is what it shows.
It seems that the top offender is uuid module. Its memory is not growing when its results are not used for inferencing. Somehow, a large amount of memory is retained otherwise, and there might be some connection between uuid strings generated and uuid internals, though it beats me to explain what it might be. I tried to run a GC, but it has no effect on it.
Memory gains from onnxruntime appear to be minimal and are likely to be GCed.
I will check if we are leaking those strings in Pybind.
The PID of this script is: 28556 run_model_many_times, dummy = False
[ Top 10 differences ] c:\Python\lib\tracemalloc.py:558: size=57.8 KiB (+57.8 KiB), count=1115 (+1114), average=53 B d:\dev\data\gh_issue_22271.venv\lib\site-packages\skl2onnx\operator_converters\text_vectoriser.py:426: size=1232 B (-24.7 KiB), count=22 (-452), average=56 B d:\dev\data\gh_issue_22271.venv\lib\site-packages\skl2onnx\operator_converters\text_vectoriser.py:105: size=0 B (-19.5 KiB), count=0 (-415) d:\dev\data\gh_issue_22271.venv\lib\site-packages\skl2onnx\common_container.py:797: size=0 B (-11.4 KiB), count=0 (-209) d:\dev\data\gh_issue_22271.venv\lib\site-packages\onnxruntime\capi\onnxruntime_inference_collection.py:266: size=2118 B (+2118 B), count=55 (+55), average=39 B c:\Python\lib\uuid.py:281: size=1780 B (+1780 B), count=21 (+21), average=85 B D:\dev\data\gh_issue_22271\repro.py:65: size=680 B (+680 B), count=3 (+3), average=227 B c:\Python\lib\tracemalloc.py:423: size=568 B (+568 B), count=4 (+4), average=142 B d:\dev\data\gh_issue_22271.venv\lib\site-packages\psutil__init__.py:1127: size=560 B (+496 B), count=2 (+1), average=280 B D:\dev\data\gh_issue_22271\repro.py:73: size=496 B (+496 B), count=1 (+1), average=496 B Memory in the middle = 147.01171875
[ Top 10 differences ] c:\Python\lib\uuid.py:281: size=16.2 MiB (+16.2 MiB), count=200021 (+200001), average=85 B c:\Python\lib\tracemalloc.py:193: size=29.5 KiB (-27.8 KiB), count=629 (-592), average=48 B c:\Python\lib\tracemalloc.py:558: size=87.6 KiB (+27.3 KiB), count=1746 (+587), average=51 B d:\dev\data\gh_issue_22271.venv\lib\site-packages\onnxruntime\capi\onnxruntime_inference_collection.py:266: size=7890 B (+5900 B), count=121 (+68), average=65 B c:\Python\lib\uuid.py:138: size=1425 B (+1425 B), count=2 (+2), average=712 B d:\dev\data\gh_issue_22271.venv\lib\site-packages\psutil__init__.py:1127: size=560 B (+560 B), count=2 (+2), average=280 B D:\dev\data\gh_issue_22271\repro.py:73: size=496 B (+496 B), count=1 (+1), average=496 B D:\dev\data\gh_issue_22271\repro.py:80: size=0 B (-496 B), count=0 (-1) d:\dev\data\gh_issue_22271.venv\lib\site-packages\onnxruntime\capi\onnxruntime_inference_collection.py:248: size=474 B (+474 B), count=2 (+2), average=237 B D:\dev\data\gh_issue_22271\repro.py:45: size=784 B (+392 B), count=8 (+7), average=98 B Memory in the middle = 219.84375
[ Top 10 differences ] c:\Python\lib\uuid.py:281: size=32.4 MiB (+16.2 MiB), count=400021 (+200001), average=85 B D:\dev\data\gh_issue_22271\repro.py:73: size=496 B (+496 B), count=1 (+1), average=496 B D:\dev\data\gh_issue_22271\repro.py:80: size=0 B (-496 B), count=0 (-1) c:\Python\lib\tracemalloc.py:484: size=0 B (-128 B), count=0 (-2) d:\dev\data\gh_issue_22271.venv\lib\site-packages\psutil_pswindows.py:727: size=1528 B (+112 B), count=6 (+2), average=255
There is a memory leak in PyBind layer. This is only manifested when data is not fed via numpy array. Until it is fixed, the simple workaround is to feed data with numpy array.
I wrapped the data with numpy array.
import uuid
import onnxruntime
import psutil
import numpy
from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import StringTensorType
from sklearn.ensemble import RandomForestClassifier
from sklearn.feature_extraction.text import CountVectorizer
from sklearn.pipeline import Pipeline
def create_trained_model():
x = [str(uuid.uuid4()) for _ in range(100)]
y = ["a" for _ in range(50)] + ["b" for _ in range(50)]
pipeline = Pipeline(
steps=[
("vectorizer", CountVectorizer()),
("classifier", RandomForestClassifier())
]
)
pipeline.fit(x, y)
return pipeline
def convert_sklearn_model_to_onnx_session(sklearn_model):
onnx_model_proto_string = convert_sklearn(
sklearn_model,
initial_types=[('features', StringTensorType((None,)))],
verbose=False
).SerializeToString()
options = onnxruntime.SessionOptions()
options.enable_cpu_mem_arena = False
return onnxruntime.InferenceSession(
onnx_model_proto_string,
providers=["CPUExecutionProvider"],
sess_options=options
)
def get_one_prediction(onnx_model, input_data):
return onnx_model.run(
[onnx_model.get_outputs()[1].name],
{onnx_model.get_inputs()[0].name: input_data}
)
def get_used_megabytes():
# https://psutil.readthedocs.io/en/latest/#psutil.Process.memory_full_info
# uss (Linux, macOS, Windows): aka “Unique Set Size”,
# this is the memory which is unique to a process and which would be freed
# if the process was terminated right now.
return psutil.Process().memory_full_info().uss / (1024 * 1024)
def run_model_many_times(onnx_model, count, *, dummy):
print("run_model_many_times, dummy = ", dummy)
print("Memory in the beginning = ", get_used_megabytes())
for i in range(count):
input_data = numpy.array([str(uuid.uuid4()) for _ in range(20)])
if not dummy:
get_one_prediction(onnx_model, input_data)
if i % 10000 == 0:
print("Memory in the middle = ", get_used_megabytes())
print("Memory in the end = ", get_used_megabytes())
def main():
sklearn_model = create_trained_model()
onnx_model = convert_sklearn_model_to_onnx_session(sklearn_model)
count = 100000
run_model_many_times(onnx_model, count, dummy=False)
run_model_many_times(onnx_model, count, dummy=True)
if __name__ == '__main__':
main()
Code above is producing the following output
run_model_many_times, dummy = False
Memory in the beginning = 129.03125
Memory in the middle = 129.03125
Memory in the middle = 129.0625
Memory in the middle = 129.1875
Memory in the middle = 129.328125
Memory in the middle = 129.328125
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the end = 129.375
run_model_many_times, dummy = True
Memory in the beginning = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the middle = 129.375
Memory in the end = 129.375
Describe the issue
In then following scenario I see that memory consumption of python process is continuously growing:
To reproduce
The following code run run_model_many_times function two twice. Once with running onnxruntime.InferenceSession method and once without. While code is running it is printing memory consumption in megabytes, which is close to macOs activity monitor numbers.
In the first case memory consumption is continuously growing and in the second case is not.
Example of printing:
Urgency
On production server python process consumed 100 GB of RAM memory after two months. The only solution is restart the process. So yes, it's urgent.
Platform
Linux
OS Version
both of MacOs 15.0 and Ubuntu 20
ONNX Runtime Installation
Released Package
ONNX Runtime Version or Commit ID
1.19.2
ONNX Runtime API
Python
Architecture
X64
Execution Provider
Default CPU
Execution Provider Library Version
No response