• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

TFS 1.2 Memory leek? Linux

SixNine

Active Member
Joined
Dec 12, 2018
Messages
452
Reaction score
41
Hello,
so i was playing with friends and i noticed that server is going worst and worst so it happened with small ping then it went up and up and up until it reached like 1-2k and it shutdown the server so i refreshed the server everything went perfect again. I guess there is memory leak or something? It happens randomly it can happen only once in a week basically or can happen next day after server refresh so its random or there is something that triggers it and i dont know what.
Hosting is 4gb
3cpu
ssd
linux - debian
map size - 16mb
creatures like 16k
player base 3-5 only me with friends ( as far as i know this type of trash hosting with this settings can hold up to 100 players, so i dont think hosting is to weak)

I have tested it long time ago with localhost everything was fine but my pc is
16gb
i7
ssd
and really trash internet, but it never had a moment when it had like insane ping drop like that. I contacted hosting they said everything is perfect from their side ofc they cant track if i had memory leek or something like that. So is there any ideas? Using this server [8.60] The Forgotten Server 1.2 (https://otland.net/threads/8-60-the-forgotten-server-1-2.236489/) i guess this is what people meant by 'not stable' so since people using this downgraded version really often maybe someone have fixed it already and can share a solution if its source bug.
 
i dunno what's happening in this case, but afaik Ninja's 8.6 downgrade it's too bugged, i would recommend you to use nekiro downgrade nekiro/forgottenserver-1.3-8.6 (https://github.com/nekiro/forgottenserver-1.3-8.6)
To much work and time and money was invested in ninja's version i cant just go to another tfs like its nothing, it would be better try to investigate it and fix it in my opinion since like 50% ot owners are using this same tfs so im pretty sure people have found whats the problem if they had it. Its not a good idea to run from you problems, i want to face them and beat them with support if you know what i mean.
 
or starts to use something really made for 8.6
 
or starts to use something really made for 8.6
Again people stop posting this type of useless comments.
 
The ping doesn't have much to do with a memory leak. You can do some monitoring of your server's resources to find out what the server is doing exactly while this is happening. Errors never happen randomly, they are always triggered by something, you just gotta figure out what it is triggered by.

At this point, you cannot know if it is the TFS version or a problem with the server or processes in general.
The information you provided is not enough to tell you exactly what the problem is. So start monitoring, debugging and logging errors.
 
The ping doesn't have much to do with a memory leak. You can do some monitoring of your server's resources to find out what the server is doing exactly while this is happening. Errors never happen randomly, they are always triggered by something, you just gotta figure out what it is triggered by.

At this point, you cannot know if it is the TFS version or a problem with the server or processes in general.
The information you provided is not enough to tell you exactly what the problem is. So start monitoring, debugging and logging errors.
What do you mean by monitoring when that ping appears im not sure
 
What do you mean by monitoring when that ping appears im not sure
Watch your resources, your RAM, your CPU, your current traffic, etc.

One of the reasons why you should also monitor the traffic is the following:
A problem might also be that, for some stupid reason, Tibia OTs use the TCP protocol instead of UDP. Generally in games UDP is used because it doesn't matter that much if one packet gets lost. With TCP the client/server always expects an answer that the packet arrived, if it doesn't get that answer in time, it will send the packet again. This can cause a huge mess in games and allow for way too much traffic. If a packet in UDP gets lost, it's simply lost, the client doesn't know the packet ever existed and the server doesn't know it didn't arrive.
 
Watch your resources, your RAM, your CPU, your current traffic, etc.

One of the reasons why you should also monitor the traffic is the following:
A problem might also be that, for some stupid reason, Tibia OTs use the TCP protocol instead of UDP. Generally in games UDP is used because it doesn't matter that much if one packet gets lost. With TCP the client/server always expects an answer that the packet arrived, if it doesn't get that answer in time, it will send the packet again. This can cause a huge mess in games and allow for way too much traffic. If a packet in UDP gets lost, it's simply lost, the client doesn't know the packet ever existed and the server doesn't know it didn't arrive.
So to be honest its not even possible to do something about it? Even if i track my ram cpu knowing that it use X value at X time it wont point where is the problem or it wont help to track what cause it, like you said tibia use TCP not UDP so i dont think its possible to do something
 
This is CPU usage when lag appears i think.
View attachment 37309
My friend, don't you think it's easy to test another server, and if that server is perfectly running, then you know the problem is at your server sources?

Because I think you're loosing time here, if your sources are wrong then just start checking for mallocs, packets, everything that can trigger your problem.

Some people just shared other sources in this thread, I would try just to save time...
 
My friend, don't you think it's easy to test another server, and if that server is perfectly running, then you know the problem is at your server sources?

Because I think you're loosing time here, if your sources are wrong then just start checking for mallocs, packets, everything that can trigger your problem.

Some people just shared other sources in this thread, I would try just to save time...
My friends its way harder to test another server, i would need to run another server on linux so main server would be effected and there would be no players to test it, and no one knows how much time it would take to find out. I think no one gets hurt if i ask and maybe high iq coder had same problem and knows where is the roots of this problem. But at least you mentioned mallocs, packets that i will check
 
My friends its way harder to test another server, i would need to run another server on linux so main server would be effected and there would be no players to test it, and no one knows how much time it would take to find out. I think no one gets hurt if i ask and maybe high iq coder had same problem and knows where is the roots of this problem. But at least you mentioned mallocs, packets that i will check

You can create simple system to create logs every cpu consumings things and enable it when your cpu usage is 50%+. Just a few functions in source and use linux tool like Monit, so it will trigger debug functions at defined cpu usage.

But for now just try run server for 24hours on other vps on the same and check if without players you have the same problem.
(just on same system)
 
You can create simple system to create logs every cpu consumings things and enable it when your cpu usage is 50%+. Just a few functions in source and use linux tool like Monit, so it will trigger debug functions at defined cpu usage.

But for now just try run server for 24hours on other vps on the same and check if without players you have the same problem.
(just on same system)
my friend he doesn't wanna spend time, he's not going to build anything for testing:
  • "its way harder to test another server, i would need to run another server"
  • "no one knows how much time it would take to find out"

it smells like a buffer overflow, typical error hard to detect, I don't know why but I feel like that (I know probbably I'm wrong), 95% of problems I've found at C (not C++) was at buffer.. based on your words, if you don't want to spend time/effort just hire someone:
  • otland.net
  • upwork.com
  • freelancer.com
As I said, I'd keep an eye at mallocs, arrays, anything that can reallocate memory, but keep in mind the problem doesn't have to be in memory, as Perun said, it can just be your machine that totally possible... I don't know how you can debug something without effort that's harder as debugging is a pain in the ass (I work debugging databases C/AL procedures 8 hours a day)

Maybe you have the option to build a docker or vm? That should be easy but try to don't copy an image, install it as default so you don't move your problem to the new machine
 
Last edited:
Back
Top