SHAME THEIR IP!!!!
SHAME THEIR IP!!!!
SHAME THEIR IP!!!!
SHAME THEIR IP!!!!
SHAME THEIR IP!!!!

:)

You may want to. If it's every 90 seconds, sounds like a misfiring bot or feed service.

That has to be a bot, yeah. Maybe if the post here didn't do the trick, a temporary ban will at least get their attention?

Depends. We have some scrape bots usually out of China who appear to have the whole class c. When we ban their IP address, they just move one up.

Or try to at least. Once we see it, we just ban the range.

GogDb isn't even finished and they already abuse it with bots -_-

It's not a bot, just a regular Chrome browser. I can clearly see when that person went to bed and turned off their PC :D. It's not impacting server stability in any way, so I posted a warning here instead of blocking right away. Thanks for your concerns, but it looks like I'm just dealing with a very impatient American, not a malicious Chinese hacker.

Just trying to be helpful. Some of us deal with an average of 6.2 million of these a day.

Thank goodness for firewalls. :)

The server probably ran out of RAM again. This happens like once every month and I still haven't figured out why. The Linux out of memory killer is being a completely useless piece of garbage and just ignores the situation until the system locks up and I am forced to reset the VM. If someone has any suggestions on how to fix this problem I'd really appreciate if you post them, because this is getting very annoying. Sorry for the downtime and thanks for reporting!

Sorry. I fiddle a little with KVM on some offsite server monitoring units but we're strictly Direct Admin on FreeBSD shop here...

I guess a swap file could decrease the down time a bit, before you find the real problem and fix it.

It depends on what is eating away at your RAM:
-> If it's a process, you can disable/kill/regularly restart/reconfigure it.
-> If it's your code, you can go back to the drawing board.
-> If it's the system's memory cache that is somehow locking up the VM (though it should not happen), you can do this.
Also see this, just for some laughs.

Since it all anchors on identifying where the memory consumption comes from, I'd recommend running a top command every now and then to find out who the culprit is.

Sometimes funny things happen between hypervizors, guest VM memory allocators and the OOM Killer which confuses some or all of them and make your VMs lock up before any of them can do something about it. Of course there's no clear answer and you have to investigate your way out of it.

My guess is that from the OOM Killer's point of view your VM is not out of memory yet, but the hypervizor thinks otherwise and may inadvertently lock up the guest OS.

I've just had about 16 hours updater downtime because GOG decreased the maximum page items again to the size they have on their store pages. I can't really blame them and this was somewhat expected, but I still took the risk and this is the result. Sorry for the delayed updates :(

The program causing the RAM problems seems to be my script. I've set a memory limit and enabled more verbose logging so I can hopefully find the bug at some point. Thanks for your suggestions.

Would it possible for GogDB to compare the game version on GOG against what is on the Steam versions? It is bit of a problem with GOG games, in that they are rarely updated with their Steam cousins, sometimes not at all.

Being able to easily know before parting with my dollars would be very reassuring.

Assume you already know of it, but just in case, there is some tracking of that matter.