Hi. I am running GridLabD in server mode and using a Python process to send HTTP requests to read values and change device property values as the simulation progresses. The memory usage grows steadily and seems to be attributed to the HTTP requests as the memory usage increases faster the higher the rate of my HTTP requests. Eventually, when the usage grows to 2GB, a SuperLU_Malloc error will be thrown.
Is this is known issue? I have not been able to find anything on this except on the following github site:
Using older versions (modified builds of 2.2 and 2.3) on Windows I've hit the HTTP server with millions (maybe billions actually) of requests and never seen this.
So not a known issue that I'm aware of, but I'll let Jason and the team confirm.
Cheers,
Kelvin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The caveat (related to the github link) is that I made the HTTP server multithreaded. Jason knows where these changes are in SVN and as I'm on a mobile device at the moment I might leave it to him to comment about if these changes got merged through to more recent versions or not.
-Kelvin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Keep in mind that there are three possible ways a memory leak can occur in the situation. (1) it is directly related to the server processing of the message, (2) it is indirectly related in the sense that it is caused by the simulation changes the payload of the message causes, and (3) it has nothing to do with the server at all. To narrow the problem down you need to try the following:
a) don't send any messages and the let the simulation run and watch memory use. If memory use goes up it's condition (3) and it's caused by something the message payload does to one of the loaded modules.
b) send innocuous messages (they don't actually cause useful values to change) and watch memory use. This is done by created a useless variable in the same object you are changing now, e.g.,
classhouse {
doubleuseless;
}
and sending only messages to set that value. If memory use goes up it's we're looking at condition (1) otherwise it's condition (2).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried the three diagnostic tests and concluded on condition 1.
In my setup, memory usage seems to grow at the rate of 5MB per 1000 messages. These 1000 messages are control messages to about 1000 different PV inverters. Each PV inverter receives a message every 5min in simulation time. The simulation dies after around 23 hours, i.e. at a memory usage of 5MB x 270 ~= 1.4GB. Adding GLD's basic memory usage of 500MB in my setup, the total memory usage is 2GB.
David: For your test, I basically extended the runtime inverter class as you suggested and changed my control messages to set the value of the "useless" property. The memory usage still grows as before.
Kelvin: Not sure what is the issue since the total number of messages is less than 300,000.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm showing the last time server.c was touched as merging changes from 2.3 to 3.0 to "Fixed http_client so it allows larger data downloads.", so I'm assuming Kelvin that these were your changes being merged in.
The changes posted by sk4ld seem straight-forward...Dave, can you review them (only 2 lines changed):
Thanks again! Just wanted to add that.. I replaced server.c and recompiled, then I used the new gridlabd.exe file to replace the original version I had, the new system ran without memory issues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi. I am running GridLabD in server mode and using a Python process to send HTTP requests to read values and change device property values as the simulation progresses. The memory usage grows steadily and seems to be attributed to the HTTP requests as the memory usage increases faster the higher the rate of my HTTP requests. Eventually, when the usage grows to 2GB, a SuperLU_Malloc error will be thrown.
Is this is known issue? I have not been able to find anything on this except on the following github site:
https://github.com/sk4ld/gridpot/issues/1
Thanks.
Hi Desmond,
What version are you using and on what OS?
Using older versions (modified builds of 2.2 and 2.3) on Windows I've hit the HTTP server with millions (maybe billions actually) of requests and never seen this.
So not a known issue that I'm aware of, but I'll let Jason and the team confirm.
Cheers,
Kelvin
The caveat (related to the github link) is that I made the HTTP server multithreaded. Jason knows where these changes are in SVN and as I'm on a mobile device at the moment I might leave it to him to comment about if these changes got merged through to more recent versions or not.
-Kelvin
Keep in mind that there are three possible ways a memory leak can occur in the situation. (1) it is directly related to the server processing of the message, (2) it is indirectly related in the sense that it is caused by the simulation changes the payload of the message causes, and (3) it has nothing to do with the server at all. To narrow the problem down you need to try the following:
a) don't send any messages and the let the simulation run and watch memory use. If memory use goes up it's condition (3) and it's caused by something the message payload does to one of the loaded modules.
b) send innocuous messages (they don't actually cause useful values to change) and watch memory use. This is done by created a useless variable in the same object you are changing now, e.g.,
and sending only messages to set that value. If memory use goes up it's we're looking at condition (1) otherwise it's condition (2).
Thanks Kelvin, David.
I've tried the three diagnostic tests and concluded on condition 1.
In my setup, memory usage seems to grow at the rate of 5MB per 1000 messages. These 1000 messages are control messages to about 1000 different PV inverters. Each PV inverter receives a message every 5min in simulation time. The simulation dies after around 23 hours, i.e. at a memory usage of 5MB x 270 ~= 1.4GB. Adding GLD's basic memory usage of 500MB in my setup, the total memory usage is 2GB.
David: For your test, I basically extended the runtime inverter class as you suggested and changed my control messages to set the value of the "useless" property. The memory usage still grows as before.
Kelvin: Not sure what is the issue since the total number of messages is less than 300,000.
Ok. That narrows it down a lot. Can you tell exactly which version, build, and patch of gridlabd you're using.
I am using version 3.1 of GridLabD. The build was downloaded directly from source forge.
I'm showing the last time server.c was touched as merging changes from 2.3 to 3.0 to "Fixed http_client so it allows larger data downloads.", so I'm assuming Kelvin that these were your changes being merged in.
The changes posted by sk4ld seem straight-forward...Dave, can you review them (only 2 lines changed):
https://github.com/sk4ld/gridpot/commit/ce7eec40b9d1c4474e7659b32929526c0500e4f1
The fix is being tracked in https://sourceforge.net/p/gridlab-d/tickets/935/.
Thanks!
Note, that we temporarily cannot post the fix to the repository due to SF technical issues. The server.c fix can be found attached to the ticket.
Thanks Dave!
Thanks again! Just wanted to add that.. I replaced server.c and recompiled, then I used the new gridlabd.exe file to replace the original version I had, the new system ran without memory issues.