• 0
mubby

Database Load Times / Long Restarts (10-15min)

Question

Posted (edited)

My server has really long restart times. From all of the other threads I've looked at, everyone suggests that it is related to the mods/addons/scripts being used, but I am convinced that it is related to the database, specifically the Constructions and Containers tables.

I have a test server that is identical to my main server in terms of addons, extra scripts, etc. and that server can fully boot within 1-3min, but the main server still takes 10-15min. The only difference between the two is that the test server has a blank database. After reviewing the RPTs over several restarts, I've noticed that the main culprits seem to be the Construction and Container tables within the database. Families, Territories, Vehicles, and World Spawn Vehicles all take about 20-30sec each, but Constructions takes about 7min and Containers takes about 4-6min every restart.

My territory size has a maximum construction limit of 300 pieces (which is less than other servers I've played on that boot quickly). The only thing that I can think of is maybe it's got something to do with loading non-Exile buildings from Extended Base Mod? Same for containers maybe? There are some giant cargo containers that hold about 5x more than Safes...but I wonder if having 5 Safes that are full would make any difference compared to 1 Cargo Container that is full...I don't really know too much about databases, so I was hoping someone can help me out.

Any ideas on how to improve this? I'm also running the server on 32bit, do you think upgrading it to 64bit would improve this a lot? I feel like it might, but like I said there are plenty of other servers that seem more heavily modded and/or have bigger construction limits than mine and they've all been able to restart quickly on 32bit all this time...I just don't get it. :(

I'll list the mods/addons below, but I'm still 90% sure it's related to the database, but maybe I'm wrong? Hopefully someone here knows a solution...
 

Spoiler


MODS:
 - Exile
 - CBA
 - Extended Base Mod
 - Ryan Zombies
 - CUP Core
 - CUP Maps
 - CUP Weapons
 - CUP Vehicles
 - CUP Units

ADDONS:
 - A3XAI
 - ExileZ
 - DMS Missions
 - Bigfoot's Shipwrecks
 - ZCP Capture Points
 - ExAd (Core, Grinding, Hacking, Virtual Garage, StatsBar, Deploy Vehicle)
 - R3F Loading/Towing/Lifting
 - AVS
 - infiSTAR

ADDONS THAT HAVE DATABASE CHANGES:
 - ExAd (Virtual Garage)
 - infiSTAR
 - AVS (separate .ini file though)

 

Edited by mubby

Share this post


Link to post
Share on other sites

11 answers to this question

  • 0

I think it might be your main server. You did not include any details of your "main" server, but it could be that your MySQL server and the ArmA server are not on the same machine, which could cause huge load times. Where are you hosting your ArmA server? Also, HDD can cause also long boot times if you compare it to a SSD

Share this post


Link to post
Share on other sites
  • 0

Thanks for the response! :)

Both servers are purchased through NFO Servers and in the same data center (as far as I know - I chose New York for both). The test server is a private server, while the main is public, but I don't see how a password would really affect things.

I have no idea whether its using HDD vs SSD, but I would assume that I'd be getting the same treatment between the two (if not a better experience on the main server since I'm paying more for it). I also don't know if the MySQL server and Arma are on the same machine, but I can check and get back to you.

Sorry, I wasn't sure what other details would be good to include in the initial post, when it comes to databases I am generally clueless...ask away and I can try to answer.

Share this post


Link to post
Share on other sites
Advertisement
  • 0

@GolovaRaoul Sorry for the delayed response, but I just spoke with my server provider today and they confirmed a couple of things:

1) Both Arma servers are identical in terms of specs.
2) The Arma servers and MySQL servers are on separate machines (Arma = NYC, NY; MySQL = Seattle, WA).
3) Arma servers = HDD, MySQL servers = SSD.
4) My databases appear to be operating on different MySQL servers. That's the only real difference they saw between my two set ups.

They are suggesting that I enable database compression in my extDB config or try moving my production server's database over to the same MySQL server that the test server runs. I'm going to try those when I can, but do you think that would do the trick or is there a good chance I might just be SOL since they are on separate machines from the game servers?
 

Share this post


Link to post
Share on other sites
  • 0
8 hours ago, mubby said:

@GolovaRaoul Sorry for the delayed response, but I just spoke with my server provider today and they confirmed a couple of things:

1) Both Arma servers are identical in terms of specs.
2) The Arma servers and MySQL servers are on separate machines (Arma = NYC, NY; MySQL = Seattle, WA).
3) Arma servers = HDD, MySQL servers = SSD.
4) My databases appear to be operating on different MySQL servers. That's the only real difference they saw between my two set ups.

They are suggesting that I enable database compression in my extDB config or try moving my production server's database over to the same MySQL server that the test server runs. I'm going to try those when I can, but do you think that would do the trick or is there a good chance I might just be SOL since they are on separate machines from the game servers?
 

Probably yes. I never had the MySQL server on another machine running, but I heard mostly that you should try to avoid this because of Network latency and performance reasons. I don't think you can fix this by removing Extended Base Building or making your Exile Server run on the *.64 bit ArmA executable.

You might want to consider switching host. I don't know what your paying now, but I'm gona send you a PM with a good and pretty cheap dedicated server (I'm not gona post it here, that might be against the rules not sure)

Share this post


Link to post
Share on other sites
  • 0

I have been through this before, and yes, if the databases are separated, like most hosting companies do, then load times can be astronomical on database loading. Don't ask why, thats a mystery of the cloud, but having the database on seperate machines, in two different locations in the real world will cause massive load times when loading containers and constructions. You should use compressed files as stated in the extdb but this will not help much. Hosting companies don't like wasting the precious resources they can sell on a machine with simple mysl, so they outsource those servers to some cheap back woods locations with probably minimal specs, and a backbone thats like dial up for a few bucks a month, and all mysql serives are located on it, like maybe thousands. Trying to request them tomove the DB to your machine will get you no where, na dmest suggestion is to rent a dedicated box and have it all on one machine. But thats gonna cost ya...

1 person likes this

Share this post


Link to post
Share on other sites
  • 0

@williamv1999 Sorry for my late response, I've been out of the country for a little while. I am using compression now, but like you mentioned, it does not seem to make too much of a difference. I also tried their suggestion of trying to use the same MySQL server that my test server uses since it seems to have better performance, but that did not work either (obviously).

It does seem like the only real solution is to get a dedicated box. I just find it hard to believe that all of these arma servers run on dedicated machines...I know many do, but it feels like my server is the only one with these 10-15min restarts, so I was just hoping there was some other alternative because I am extremely reluctant to set up a dedicated box because I do not want to deal with troubleshooting and self-supporting it. Plus, it's very expensive...

However, NFO offered a slightly different idea which could be a nice compromise/band-aid solution. They suggested that I order a Virtual Dedicated Server and just set it to the same location that my server is in (NYC) and setup a MySQL server/database on that instead, so all of the information stays within NYC instead of having to travel from NYC to Seattle and back, which should cut down on a lot of the latency issues I would imagine, right?

Later down the road, when I'm ready, I'd love to run a full dedicated machine, but this seems like a decent suggestion that could potentially solve or at least greatly reduce the problem. The game and database would still be on separate machines, but they won't have to communicate across the country anymore at least...

Do you think this could even work or not really? I suppose I can always ask for a trial run and see.

Share this post


Link to post
Share on other sites
  • 0

@mubbyhere's a quick explanation over why you should have the SQL box as close to the ARMA machine as possible (and also for the benefit of anyone reading this in the future);

(Disclosure - I know enough about this stuff to explain it in simple terms but not the detail. If there's an expert in the room please correct if needed)

Every time a server (doesn't matter if it's ARMA or something else) makes a call to the SQL database, it runs a query command, the SQL server acknowledges the command, runs the query and returns the data. Unfortunately, this may require MANY, MANY calls to the database.... Think about one database call for ONE read request (please bear in mind that this is simplified for the purposes of basic understanding).

  1. Login to database
  2. Acknowledgement - Login success
  3. Send SQL Command
  4. Acknowledgement - command received
  5. Return Data
  6. Acknowledgement - data received

There's 6 commands there just to say get the placement of an object on the map. If you have the SQL box on the same machine then these commands can happen in under a millisecond. But, if you move them away from each other like the OP did at his hosting provider to have (for example) a 5ms latency between them, the command above went from taking under a millisecond to taking tens of milliseconds. A HUGE difference.

Now, multiply that out by the THOUSANDS of objects in a busy server database and you can quickly see why things get slow.

This is why it is always highly recommended to have the SQL box as close to (if not on) the same machine as the ARMA server. I hope that helps someone else in the future understand why databases can get slow inexplicably.

Share this post


Link to post
Share on other sites
  • 0

@Riker2335 Thanks for the reply, it makes perfect sense. I don't think I'll be able to get the MySQL server to be on the same server as Arma 3 until I get a full dedicated machine in the future, but it does sound like that moving the MySQL server from Seattle to NYC should still make a significant impact.

1 person likes this

Share this post


Link to post
Share on other sites
  • 0

guys.. i've hived on separate machines on high pop servers and never experienced any issue.. (though same ovh datacenter). mysql is very little data transfer.. i'd say its ipc performance of the rented cpus..

But.. what map?  took me forever to get Taunus to startup, for example.. :)

Share this post


Link to post
Share on other sites
  • 0

@odizzzzle I'm using Chernarus.

@Riker2335 @GolovaRaoul @williamv1999 Thanks again for your help guys. I just tested setting up a MySQL server on a droplet that we use for TS that is located in NYC and the boot time dropped from 15min to 4min...unbelieveable! After a successful test like that, the solution is obvious: move the MySQL server closer.

For anyone else who has an issue here: check to make sure that database is located in the same state/city as your game server (and if possible, on the same machine)!

2 people like this

Share this post


Link to post
Share on other sites
Advertisement

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.