EVE Online

EVE Online Dev Tracker




10 Mar

Comment

Yeah, what’s up with that @CCP_Swift?

Comment

Spot on analysis @MalcomReynolds_Serenity – BTW, we did indeed look at the Platinum processors but the price was not right.

Comment

More on this @Baldeda_Maxi; there was yet another deployment today to Search where the team is making changes and adding logging to try and track down these issues.


09 Mar

Comment

Some big improvements!

Comment

A SOL node is a process on a machine; we run 8 to 14 of them on each machine. But we often use no. 1 as well to refer to machines that only host SOL nodes.

Comment

This should have been corrected now in the latest build on Singularity. Thanks for your poke :slight_smile:

Comment

A node is a PROXY or SOL process in the game cluster that is assigned specific tasks. PROXY nodes are the nodes that the loadbalancer connect to on inbound connections from the Clients and they mostly handle session management and routing but SOL nodes handle solarsystem simulation and run other services (such as market, skill training, industry).

Comment

The session timer has probably always been there, in the background. I think it was only exposed in the UI in 2007.

Comment

Maybe, with future iterations on software.

Comment

Tranquility proper is in a datacenter just outside London.

Comment

I mix up terms sometimes, so it depends on who you are talking to and the context :slight_smile:

SOL Server would typically be either the physical or virtual server that our code runs on. A sol node would be one instance of the application code running on the actual SOL Server

Comment

Typically we use SOL as a interchangeable term for solar system node - a windows OS based server that can run one or more in-game solar systems/services.

For TQ, all sols are physical servers, most test servers run sols as virtual machines

Comment

We’re planning a SQL only blog for a later date where we can share more info on the various configs we have going on.

The param sniffing stuff, have not gotten deep into that yet, but that’s basically where the db team is at now - sql 2022 testing and excitement - it’s got a ton of great features that’ll be useful not only to us dba’s but our data engineering team as well.


08 Mar

Comment

Probably never. This is a safeguard that all the all nodes involved have finished their work in moving you; this is the timeout when the other nodes can move ahead if there is no confirmation.

Comment

No.

Inserting more characters here since evidently a reply must be 5 characters or more.

Comment

Every time we have upgraded hardware or optimized software, then players have brought more pilots for the next fleet fight.

Comment

I wrote this with input from @CCP_DeNormalized and others.

Comment

There is only one VM in Tranquility proper, and that is a proxy for internal use only. Everything player-facing is running directly in top of hardware. We have tested using VMs for some of the smaller player-facing services and it worked fine run-time but we had issues starting the cluster since the nodes running on the VMs would lag behind the nodes running on hardware.

There are many VMs and pods running in the Tranquility Ecosystem, inside AWS. None of them existed at the time of Tranquility Tech III but have added since then, outside the simulation/game cluster.

Comment

My current negotiations with Ops have us at a new DB VM with 512GB of ram to start with. We’ll see how it goes from there :slight_smile:

They don’t generally like it when I start a convo haha

We do have several virtual db’s in production though and always looking to migrate away from bare metal where it makes sense (one of the new vm’s is a remote AlwaysOn read-replica)

Comment

We have a few test servers running windows/sql 2022 - all running fine at the moment, but I do recall hearing some issues with a windows patch causing reboot loops