High CPU usage durning login

[mehorz]

Figured I'd pop in and mention the cpu issue hasn't gone away. It's really odd though, sometimes it's so bad I can only run 8 bots, some times it's not as bad and I can run like 15. When it goes away which seems to be somewhat random, I can hit 25 or so. Only difference is how much cpu the java.exe's are using during login.

[SABadshah]

I wonder if this is Jagex's attempt to reduce the load on their login server by requiring more effort from the clients when they try to log in. For example, it might be a way to reduce the flood that is currently hitting their server, preventing a real ddos attack. I'm aware that their login server has occasionally been pretty unreliable, so I can only assume that they are overloaded with login requests or something.

[mehorz]

Wanted to provide an update on the situation, cpu issue just doesn't go away after updates any more, seems like jagex had code that was changed that kept making it in the updates then later wasn't included.

I've been wanting to get into modifying the client and such, so I've done some poking around, I've made an applet loader and have gotten the client to open in my own instance, basically the very basic first steps for building a bot client from scratch. If I find the issue in the bytecode and patch it, is there a way to make osbot load my offline copy of the gamepack.jar file, or will I have to write the bot from scratch effectively in a custom client?

I've done some really basic looking into the issue, the packet building process for the login happens quite quickly, the high cpu spike appears to be while the client is waiting for the reply from the server. My guess is some new programmer at jagex removed a small sleep in the while loop that would keep the cpu usage down. If/when I find the related class file and method, it should be a pretty easy patch. I'm quite new with working with the rs client, so steep learning curve, but so far it's not too bad working with bytecode.

I initially thought that this update was related to client detection or a way to offset the load from their servers by making the clients do some task. Now I'm thinking it's just an amateur programmer that made a mistake at jagex.

 

@SABadshah Their servers have been slower since this started by about 25% or so. It would be crazy if the same programmer made a mistake on the server side code, but I doubt that since the server doesn't crash with 50-100 logins at the same time granted the delay from server to database server should be very little.

osrs is due for an update before long, we have been on client version 209 for quite a while now. Hopefully version 210 fixes the problem, but I'm not expecting it lol. Of course once the new version comes out, I'll have to do my client research and mods all over again. I suspect it shouldn't be too hard to automate this task, I have some ideas on how to do it, and that's the route I started with, but it's a lot faster to test/dev directly editing the bytecode and adding the injection code later.

 

Also a small side note, I recently setup a Linux server and it seems to be able to handle a fair number of bots, around 25-30 with the limitation still cpu. That's with an 8 core amd 4000 series cpu. Been a while since I built it, but finally putting it to use. My old windows base server is running 6-8 to give context and a newer windows based server runs around 12-15 pretty well. Anyway, I doubt the OS is having much effect, but interesting that it seems the Linux machine is working out better for some reason. It's just running Linux Mint.

[Michelle Jame]

It's possible that the spike in CPU usage you're experiencing is related to changes in the game server or operating system that your server is running on. However, there are a few things you can try to help reduce the CPU usage:

• Clear the cache files: As you mentioned, clearing the cache files on your server may help to reduce the CPU usage. This can be done by deleting the cache folder in the OSBot directory.
• Check for memory leaks: It's possible that your script may be causing memory leaks, which can lead to high CPU usage. You can use a tool like VisualVM to monitor your script's memory usage and check for any leaks.
• Add a delay: Adding a delay in your script's loop can help to reduce CPU usage. You can use the sleep() function to add a delay between each iteration of the loop.
• Check for unnecessary code: Make sure that your script doesn't contain any unnecessary code or loops that could be causing high CPU usage.

If none of these solutions help, it may be worth contacting the OSBot developers to see if they can provide any additional insight or solutions.

[Delivery]

On 11/20/2022 at 12:03 AM, mehorz said:

Wanted to provide an update on the situation, cpu issue just doesn't go away after updates any more, seems like jagex had code that was changed that kept making it in the updates then later wasn't included.

I've been wanting to get into modifying the client and such, so I've done some poking around, I've made an applet loader and have gotten the client to open in my own instance, basically the very basic first steps for building a bot client from scratch. If I find the issue in the bytecode and patch it, is there a way to make osbot load my offline copy of the gamepack.jar file, or will I have to write the bot from scratch effectively in a custom client?

I've done some really basic looking into the issue, the packet building process for the login happens quite quickly, the high cpu spike appears to be while the client is waiting for the reply from the server. My guess is some new programmer at jagex removed a small sleep in the while loop that would keep the cpu usage down. If/when I find the related class file and method, it should be a pretty easy patch. I'm quite new with working with the rs client, so steep learning curve, but so far it's not too bad working with bytecode.

I initially thought that this update was related to client detection or a way to offset the load from their servers by making the clients do some task. Now I'm thinking it's just an amateur programmer that made a mistake at jagex.

 

@SABadshah Their servers have been slower since this started by about 25% or so. It would be crazy if the same programmer made a mistake on the server side code, but I doubt that since the server doesn't crash with 50-100 logins at the same time granted the delay from server to database server should be very little.

osrs is due for an update before long, we have been on client version 209 for quite a while now. Hopefully version 210 fixes the problem, but I'm not expecting it lol. Of course once the new version comes out, I'll have to do my client research and mods all over again. I suspect it shouldn't be too hard to automate this task, I have some ideas on how to do it, and that's the route I started with, but it's a lot faster to test/dev directly editing the bytecode and adding the injection code later.

 

Also a small side note, I recently setup a Linux server and it seems to be able to handle a fair number of bots, around 25-30 with the limitation still cpu. That's with an 8 core amd 4000 series cpu. Been a while since I built it, but finally putting it to use. My old windows base server is running 6-8 to give context and a newer windows based server runs around 12-15 pretty well. Anyway, I doubt the OS is having much effect, but interesting that it seems the Linux machine is working out better for some reason. It's just running Linux Mint.

You mentioned you had a custom login handler, have you done benchmarks to compare the default one with your one and see if this issue is still a thing?

 

If this persists could you just make a mutex and run one login maximum concurrently and just continue on the other logins after one has been complete.

[Michelle Jame]

I'm curious if Jagex is implementing this as a measure to alleviate strain on their login server, necessitating more effort from clients attempting to log in. This could potentially help mitigate the high volume of traffic currently hitting their server, providing a safeguard against actual DDoS attacks. Given the intermittent unreliability of their login server, it's plausible that it's facing an overload of login requests.