Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak #7

Open
SteveMullen opened this issue Oct 7, 2019 · 5 comments
Open

Memory leak #7

SteveMullen opened this issue Oct 7, 2019 · 5 comments

Comments

@SteveMullen
Copy link

SteveMullen commented Oct 7, 2019

I am seeing a significant memory leak, and it's not clear to me what I can do about it.

Steps to Reproduce

When I request Properties (either through /Properties or /replication), each fetch results in a proportional memory usage. For replication where the limit is grabbing 2,000 listings, I see a usage of about 35 Mb.

Looping using the next url uses an equivalent amount of memory for each loop. For instance, when replicating, each batch of 2,000 listings adds to overall memory consumption by about 35 Mb. My script has a memory_limit of 512 Mb, and

Expected behavior:

I do not see any API method to free up the previous data. I am unsetting the returned json manually, but that is not helping.

Actual behavior:
Debug:
`
[replicate] [1] Replication found 2,000 listings [using 205,445,336 bytes]

[replicate] [2] Replication found 2,000 listings [using 240,005,560 bytes]

[replicate] [3] Replication found 2,000 listings [using 275,442,864 bytes]

[replicate] [4] Replication found 2,000 listings [using 310,723,216 bytes]
`

Reproduces how often:
This is consistent behavior.

Versions

Using the latest Aug 13, 2018 version of RESO-WebAPI-Client-PHP
php 7.2

Additional Information

`do {
RESO\RESO::setAccessToken("my auth token");
RESO\RESO::setAPIRequestUrl("https://api.bridgedataoutput.com/api/v2/OData/miamire/");
$this->replicate_url = "/replication";

RESO\Request::setAcceptType("json");

$json_obj							= RESO\Request::request($this->replicate_url, 'json', $decode_json = true);

$this->replicate_url				= null;
if (is_array($json_obj))
	{
	if (isset($json_obj['@odata.nextLink']) && !empty($json_obj['@odata.nextLink']))	{
		$this->replicate_url		= $roverWEBAPIAUTH->reso_property_replication_url(
																				$one_class, 
																				$json_obj['@odata.nextLink']
																				);
		}
	}

unset($json_obj);
} while (!is_null($this->replicate_url));`
@JacobEdmondKerr
Copy link

I am having issues with a memory leak via CURL. I'm not sure if it's my PHP version? I'm using PHP Version 5.5.38. SteveMullen did you find a solution to this problem?

The line that is using the memory is line 185 in CurlClient.php: $rbody = curl_exec($this->curl); I have read that CURL has issues with CURLOPT_RETURNTRANSFER in some versions of PHP.

@SteveMullen
Copy link
Author

Hi Jacob - I don't use the RESO\RESO api anymore, because there were a few problems I couldn't solve. I ended up writing my own code.

@abiggrboat
Copy link

I just started using the reso api client and have noticed the same issue. It's not possible to retrieve larger numbers of records in a loop without exhausting all available memory. It turns out the culprit is the request member function is initializing the curl client on every call. I revised the request class (i.e. in my copy) to persist the curl object and only initialize it once and the memory leak is gone.

@redtailmatt
Copy link

I've noticed that the RESO\HttpClient\CurlClient is never closed in RESO\Request::request() or ::requestPost().
Have you tried adding $curl->close(); before the return line of the request functions? This significantly reduced the memory usage for me.

@ConnectGrid
Copy link

I am having issues with a memory leak via CURL. I'm not sure if it's my PHP version? I'm using PHP Version 5.5.38. SteveMullen did you find a solution to this problem?

Just a note, as of 2024, it's highly advisable to be using PHP 7 or greater, preferably PHP 8. Is there a reason that your server is stuck on such an outdated version of PHP? Can you get that addressed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants