Question: DB Size - URGENT
Moderator: SEOW Developers
Question: DB Size - URGENT
Hi there...
We're 7 missions into a campaign and MP is really starting to bog-down and I am trying to figure-out why.
A DB backup after campaign initialization was 1.6MB but after 7 missions, we're up to 6MB.
Is this normal?
MP is close to being unusable...did I miss a mySQL or DCS or MP setting?
Thanks!
We're 7 missions into a campaign and MP is really starting to bog-down and I am trying to figure-out why.
A DB backup after campaign initialization was 1.6MB but after 7 missions, we're up to 6MB.
Is this normal?
MP is close to being unusable...did I miss a mySQL or DCS or MP setting?
Thanks!
-
- Posts: 302
- Joined: Fri 13 Apr 2007 1:13 pm
- Location: Italy
-
- Posts: 2211
- Joined: Mon 08 Jan 2007 11:10 pm
- Location: Perth, Western Australia
Hi Opus,
Perhaps you need to tweak your MySQL server to improve your performance. Here are some settings I have in "my.ini":
max_connections=100
query_cache_size=200M
tmp_table_size=103M
innodb_buffer_pool_size=643M
You may wish to learn about these options and consider how they could be set for your system to improve performance. In my experience the query_cache_size setting can be very important for Mission Planner performance.
Cheers,
4Shades
Perhaps you need to tweak your MySQL server to improve your performance. Here are some settings I have in "my.ini":
max_connections=100
query_cache_size=200M
tmp_table_size=103M
innodb_buffer_pool_size=643M
You may wish to learn about these options and consider how they could be set for your system to improve performance. In my experience the query_cache_size setting can be very important for Mission Planner performance.
Cheers,
4Shades
IV/JG7_4Shades
SEOW Developer
SEOW Developer
-
- Posts: 2211
- Joined: Mon 08 Jan 2007 11:10 pm
- Location: Perth, Western Australia
Hi Zoi,
The tables that usually grow the fastest are Unit_Name_Mapping, ObjMissionData, New Waypoints and Waypoints. The first two contain data for each unit in each mission. Unit_Name_Mapping also contains data for each target object in each mission.
You will know the number of units in your campaign. Reducing the number of units will reduce the rate at which these tables grow.
Cheers,
4S
The tables that usually grow the fastest are Unit_Name_Mapping, ObjMissionData, New Waypoints and Waypoints. The first two contain data for each unit in each mission. Unit_Name_Mapping also contains data for each target object in each mission.
You will know the number of units in your campaign. Reducing the number of units will reduce the rate at which these tables grow.
Cheers,
4S
IV/JG7_4Shades
SEOW Developer
SEOW Developer
-
- Posts: 2211
- Joined: Mon 08 Jan 2007 11:10 pm
- Location: Perth, Western Australia
OK so I checked with Tushka and he informs me that anything under 100 megs is not considered large. Up to this point I had only ran small campaigns and didn't realize how much things have changed over the last two years.
That post was made in 2011 and databases are 10 times that size now I guess.A DB backup after campaign initialization was 1.6MB but after 7 missions, we're up to 6MB.
-
- Posts: 162
- Joined: Wed 10 Jan 2007 1:13 am
- Location: Sydney, Australia
The JG26 Battle of France campaign went for 18 months or so and finished at 345.375 Mb.
In Navicat I used this query to get a size in Mb's of all my databases:
SELECT table_schema "Data Base Name", sum( data_length + index_length ) / 1024 / 1024 "Data Base Size in MB"
FROM information_schema.TABLES GROUP BY table_schema ;
In Navicat I used this query to get a size in Mb's of all my databases:
SELECT table_schema "Data Base Name", sum( data_length + index_length ) / 1024 / 1024 "Data Base Size in MB"
FROM information_schema.TABLES GROUP BY table_schema ;
Not sure but the Cartagena database may have some issue. I restarted the campaign using some existing data and missions and my last export of the new campaign is under 3 megs. I had forgotten that I had editted the Airforce_Units and AirRegimentStructure tables as the axis and allied assignments were wrong. There in may lie the answer to the errors and size.
At least I'm fairly sure the special character used in the SEDB33C didn't look right to me. I will let you know if that solves the problem.
At least I'm fairly sure the special character used in the SEDB33C didn't look right to me. I will let you know if that solves the problem.