NSURLSession caused huge memory retain in libnetwork

I am using this code. I have huge number of urlSessions but this caused huge memory retain in libnetwork

NSURLSessionConfiguration* _configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
NSURLSession* urlSession = [NSURLSession sessionWithConfiguration:_configuration delegate:_delegate delegateQueue:NSOperationQueue.mainQueue];
NSURLSessionDataTask* dataTask = [urlSession dataTaskWithRequest:request];
 [dataTask resume];

how can i avoid this memory retain. I have tried all possible fixes by not using urlCache and all. below is xcode memory retain snippet -

please suggest how I can avoid this memory retain?

Post not yet marked as solved Up vote post of vinodkm2 Down vote post of vinodkm2
716 views

Replies

What is the size of the transfers you are making here? It looks like they are on the larger size for the slab allocator to be involved. This will allocate a larger chunk of memory to be used when you are making larger transfers usually of the same content type. For example, moving the same file over and over in a unit test. This takes place so there is not an overhead of allocating memory, storing the memory, freeing the memory over and over for the same content.

  • @meaton - yes transfer size is on larger side but I can't avoid it. Is there any way to avoid larger size allocation by slab allocator? one more question - will this retained VM used by network calls only or can any process use it?

Add a Comment

one more question - will this retained VM used by network calls only or can any process use it?

To my knowledge this is allocated for your process that has CFNetwork loaded into it's address space.

I have huge number of urlSessions

This is usually an anti-pattern. Your app should only have a small number of url sessions, e.g. grouped by subsystem or desired connection behavior (e.g. tasks on this session should only execute on WiFi). Do not create a new session for each task

Many apps can get away with 1-3 sessions for the whole app for the different use-cases. More complex ones might need more, but still a small number.