Memory Leak

[ConVicT]

The script.php for my server seems to have a bad memory leak somewhere.
Over the course of two days, it begins to use 25% of the memory.

Can someone who is good with script have a look for me, please?
P.S. The script isn't that long; if I knew what I was looking for, I imagine it's probably obvious

[Light]

Do you have anything killing the script? If it gets stuck in the while loop, they tend to just stack on top of each other.

Code: Select all

if (feof(STDIN))
    break;

That may solve your issue if you put it inside of your while loop.

[ConVicT]

Do you have anything killing the script? If it gets stuck in the while loop, they tend to just stack on top of each other.

Code: Select all

if (feof(STDIN))
    break;

That may solve your issue if you put it inside of your while loop.

I'm not quite sure where (I'm still no good with it).
I sent you the script if you could have a quick look for me?

Around 4 people have messed with this script. I forget which parts are even mine now lol.

[ConVicT]

So right now I have this:

Code: Select all

while (!feof(STDIN)) {
  $line = rtrim(fgets(STDIN, 1024));
  $split = explode(" ", $line);

So, I should make it look like this:

Code: Select all

while (!feof(STDIN)) 
        break;  {
  $line = rtrim(fgets(STDIN, 1024));
  $split = explode(" ", $line);

?

[Light]

Looks like you're already exiting the while loop on that. So, when the memory usage gets high, try checking what processes you have running.

Code: Select all

ps aux

If the script is running under script.php, it may show up with ..

Code: Select all

ps aux | grep 'script\.php'

That will show you how many of the scripts are running, assuming for some reason they're stacking. My only other thought at a quick glance is that maybe it's holding on to too much memory for the xml files. Maybe free the memory once you're done with the file. unset() or set to null should be enough to see if that's it.

I don't have time right now to actually run it and check it out, so a quick guess is all I can provide at the moment.

[aP|Nelg]

This has been resolved, right? Was removing the code Mirage added but was not useful anymore a fix?

[ConVicT]

Ye, I removed a lot of stuff. I wouldn't say it's resolved, more that it takes longer to happen now

[Lucifer]

How does it run? Is it running on a webserver? Or is it being executed from the arma dedicated server? Running as a separate process?

I don't think that in PHP you can get an EOF for STDIN, which is why I ask, of course. In fact, I'm not sure you ever get an EOF for STDIN (it works with cat because you press ctrl-d, which is an EOF).

[Light]

How does it run? Is it running on a webserver? Or is it being executed from the arma dedicated server? Running as a separate process?

I don't think that in PHP you can get an EOF for STDIN, which is why I ask, of course. In fact, I'm not sure you ever get an EOF for STDIN (it works with cat because you press ctrl-d, which is an EOF).

You can. I used to pipe to PHP scripts, and now I use the built-in script spawn / kill. Both exit the loop when the game server restarts. When I was doing it myself, I know without checking for EOF I would get scripts spawning on top of each other. I've never tried the built-in commands without checking EOF. The server may kill the script itself, but my scripts still have the EOF check in them, and don't spawn on top of each other.

[aP|Nelg]

How does it run? Is it running on a webserver? Or is it being executed from the arma dedicated server? Running as a separate process?

I believe they're starting it in the start script alongside the server - they aren't using SPAWN_SCRIPT for some reason.

[Lucifer]

How does it run? Is it running on a webserver? Or is it being executed from the arma dedicated server? Running as a separate process?

I believe they're starting it in the start script alongside the server - they aren't using SPAWN_SCRIPT for some reason.

If that's the case, then I'm going to suggest changing the setup so that the script gets restarted. Do something similar to the way you can have the dedicated server quit automatically when there are no players for a period of time (I forget the setting for this, but it's been there a long time), then the initscript restarts the server.

The problem with long-running scripts is that, if you're not extremely careful, the garbage collector in the interpretor doesn't collect everything. Say you have that while loop, and in the script you make numerous local scoped variables that get discarded with every iteration of the script, you're spawning these new variables, but the reference counter never truly releases them, you get a memory leak. PHP is notorious for this sort of situation, but since PHP usually runs in a webserver with relatively short scripts that get executed quickly and then completely garbage-collected, these sorts of problems never come up.

I've encountered similar problems with long running Python scripts, and Java is notorious for such problems (it's the reason there's a huge debate between garbage collection/reference counting and simple memory management strategies that manage to be garbage collection anyway. Weird debate).

In short, I'm saying you could be doing it perfectly right and the interpretor is what's screwing you over, so don't let the script run for too long. If it's fine for a day, restart it once a day, problem solved.

[Light]

If that's the case, then I'm going to suggest changing the setup so that the script gets restarted. Do something similar to the way you can have the dedicated server quit automatically when there are no players for a period of time (I forget the setting for this, but it's been there a long time), then the initscript restarts the server.

DEDICATED_IDLE is the setting you're talking about. The script running the server would just have to manage looping the execution of the server. You can forcefully kill the script each time as well if the problem is that, but there's something else wrong with the setup or script if that's happening.

In short, I'm saying you could be doing it perfectly right and the interpretor is what's screwing you over, so don't let the script run for too long. If it's fine for a day, restart it once a day, problem solved.

If that is the case, you could also free the memory by unsetting the vars or setting them to null (close enough). I do realize that's a little more work than just killing the script though.

With how long SPAWN/KILL_SCRIPT has been available, I don't see the reasoning for running the script separately. I can't imagine you gain anything useful from doing so.

[Lucifer]

In short, I'm saying you could be doing it perfectly right and the interpretor is what's screwing you over, so don't let the script run for too long. If it's fine for a day, restart it once a day, problem solved.

If that is the case, you could also free the memory by unsetting the vars or setting them to null (close enough). I do realize that's a little more work than just killing the script though.

Also, explicitly creating the variables before the loop even starts will stop the leak, if that's the case. The leak is caused by the part where the local variables inside the loop don't get garbage-collected until the loop is exited, but new variables get spawned. I've tested this thoroughly with Python, at least, and read about it in php, java, and perl (ruby doesn't have this problem, according to dlh). I've made it a habit of creating all loop variables before entering the loop, and that's fixed 90% of my memory leaks in scripts.

With how long SPAWN/KILL_SCRIPT has been available, I don't see the reasoning for running the script separately. I can't imagine you gain anything useful from doing so.

I generally agree, but the difference between you and I is that you've actually seen his script.

[Light]

I generally agree, but the difference between you and I is that you've actually seen his script.

Sort of. I haven't exactly sat down and looked at it. I glanced quick enough to see that EOF was checked.

[Lucifer]

I generally agree, but the difference between you and I is that you've actually seen his script.

Sort of. I haven't exactly sat down and looked at it. I glanced quick enough to see that EOF was checked.

Well, if he'd posted it here in a code block, I'd have read it in some detail and offered more useful feedback. But since he apparently wants near-NDA consent before sending it....