Not sure if this is a memleak at work, nor how to identify it so I am just reporting what I see using TOP on the EQ2Dev server.
See the current_world process is devouring 70%+ of the 4gb assigned. If this is because of debug mode, then nm.

But notice when current_world first starts, it's at a nice, low 12%
Just a heads up in case something weirder than usual is going on.

i had a similar issue in windows when i first created my server, not sure if its releated

but it had to do with the character history not getting written to the db correclty and on ever history save it was literally doubling the number of records in the history db and hence getting loaded into memory since the world loads character history
might be worth a shot to look into

I think there's a memleak in the spell casting process (at least on my server anyway).

Spawning like 50 mobs and having them all fight each other (50 mobs that cast spells, I mean), and it seemed like there was a leak just sitting there watching them cast forever.

tyrbo wrote: Sat Jan 20, 2018 3:54 pm Spawning like 50 mobs and having them all fight each other (50 mobs that cast spells, I mean), and it seemed like there was a leak just sitting there watching them cast forever.

I just did this last night, so fun and funny to watch Had about 40 NPCs doing battle in the commonlands - I didn't pay attention to leaky memory, but instead I noticed my EQ2Client's GPU level was slammed to 100%, while CPU was around 25%.

There was a massive backlog in the "queue", for lack of a better term, between the server and the client. Meaning, watching the server console debug logging, it's usually spamtastic when NPCs are fighting/casting, but it would literally halt - zero logs for >minutes< while the GPU was pegged. Further, no commands took affect until after the "jam" was cleared in the queue. With only 40 NPCs, it took over 15 minutes for /depop to fire under these conditions.

Not sure if that's a server fault though. Sounds like the client just isn't made for epic battles.

I'm not sure if your code is fixed, but a lot of that massive client backlog spam (where it's trying to catch up with packet processing) can be mitigated with a change to the server.

https://github.com/stitchpvp/world/comm ... 883c06cf23 was my particular fix around FaceTarget spam, which is being called constantly when you're in combat, which without any checks causes unnecessary updates to be sent to the client.

A good test to see if it is a client vs server lag issue, is to put another client in the zone out of range of the fighting mobs. The client that can't see the mobs should be lag free.

tyrbo wrote: Thu Feb 01, 2018 11:28 am A good test to see if it is a client vs server lag issue, is to put another client in the zone out of range of the fighting mobs. The client that can't see the mobs should be lag free.

Oh yes, I forgot about that. I'll try that this weekend.


Btw, are any of these core fixes making their way back to EQ2Emulator code? If not, they should be. Anything that's open source, non-custom, anyway. Thanks for fixing stuff