nick
Veteran Member
Posts: 766
|
Post by nick on Jul 12, 2020 18:18:06 GMT
Can we discuss why core-protect is taking longer then usual to rollback or restore? I had a grief earlier which was only 10 blocks, rolling that back took about 40.8s and when lyicx rollback a tnt explosion, that took almost 1.40m.
It's alot slower in 1.16.1 then it use to be in 1.15.2
|
|
fionn
Club 4000 Member
Admin Officer
elmon sucks
Posts: 6,157
| Likes: 4,775
|
Post by fionn on Jul 12, 2020 18:46:25 GMT
probably because of how large the sql file is now.... it’s been on the server for almost a year and every single block a player places gets logged in a db file
|
|
Waspter
Veteran Member
Advertising...
Posts: 3,237
| Likes: 315
|
Post by Waspter on Jul 12, 2020 18:49:46 GMT
probably because of how large the sql file is now.... it’s been on the server for almost a year and every single block a player places gets logged in a db file Perhaps it's time for a wipe? |
|
AshazTGA
Veteran Member
Posts: 317
| Likes: 102
|
Post by AshazTGA on Jul 12, 2020 19:08:10 GMT
probably because of how large the sql file is now.... it’s been on the server for almost a year and every single block a player places gets logged in a db file Perhaps it's time for a wipe? I recommend we do it alongside a flatland wipe. People's buildings could be griefed when we delete the file and they might not know who did it. If we tell them like over the course of the day before we do it, then we can ensure it's a fresh wipe |
|
Feueristic
Full Member
C'est la vie
Posts: 133
| Likes: 207
|
Post by Feueristic on Jul 12, 2020 20:30:17 GMT
I recommend we do it alongside a flatland wipe. I believe that it should be closer to "wiping the data 2 wipes before this one" if it's possible to implement this. Even when people are encouraged to always save their builds in flatlands, I'd say it'd be fairer if we only wiped the long-gone data for people who weren't online for the wipe. The "wipe" should also retain any other world's CO data for obvious reasons. |
|
Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on Jul 12, 2020 20:31:05 GMT
Can we not shrink the DB Down, just drop changes that are logged from 6+ Months ago or something?
MySQL was never designed to scale like this, and it's why CoreProtect was always a pain to design in properly because TF historically relied on regular wiping of the maps.
|
|
StevenNL2000
Forum Admin 
Posts: 6,415
| Likes: 6,936
IGN: StevenNL2000
Timezone: UTC+01:00
Member is Staff. Need immediate assistance? Send a PM
|
Post by StevenNL2000 on Jul 12, 2020 20:36:55 GMT
It would be beneficial to keep the old data if possible. We might try running VACUUM (PostgreSQL, SQLite) or OPTIMIZE (MySQL) and see if that helps, but Seth needs to do that with an external program while the server is not running.
|
|
grntbg
Full Member
Omnis anima potestatibus sublimioribus subdita sit.
Posts: 295
|
Post by grntbg on Jul 12, 2020 22:37:56 GMT
The plugin shouldn’t be using SQLite with the size of this server. A suggestion was made years ago to get rid of this, and if we’re moving backwards in terms of progress then it’s no wonder everything is taking longer than it used to.
|
|
|
|
Post by Telesphoreo on Jul 13, 2020 1:02:04 GMT
The plugin shouldn’t be using SQLite with the size of this server. A suggestion was made years ago to get rid of this, and if we’re moving backwards in terms of progress then it’s no wonder everything is taking longer than it used to. We're not using SQLite. The server uses MySQL |
|
|
|
Post by DragonSlayer2189 on Jul 13, 2020 6:45:17 GMT
I don't think it has anything to do with the size of the database, but any admin has the ability to just /co purge
|
|
elmon
Veteran Member
Asst. Server Liaison
fionn sucks
Posts: 1,476
| Likes: 1,842
|
Post by elmon on Jul 13, 2020 6:49:30 GMT
I don't think it has anything to do with the size of the database, but any admin has the ability to just /co purge Also last I checked Telnets can do /wipecoreprotectdata |
|
grntbg
Full Member
Omnis anima potestatibus sublimioribus subdita sit.
Posts: 295
|
Post by grntbg on Jul 13, 2020 6:51:32 GMT
The plugin shouldn’t be using SQLite with the size of this server. A suggestion was made years ago to get rid of this, and if we’re moving backwards in terms of progress then it’s no wonder everything is taking longer than it used to. We're not using SQLite. The server uses MySQL This is in response to Fionn's comment about there being a ".db file" in which all block placements are logged, but there is no such file if this server avoids SQLite for large databases as it should. CoreProtect has native in-game log purging which means that purging logs from [x] server wipes ago would be possible if server wipes were conducted automatically and not at the whim of admins. |
|
|
|
Post by DragonSlayer2189 on Jul 13, 2020 6:59:47 GMT
We're not using SQLite. The server uses MySQL This is in response to Fionn's comment about there being a ".db file" in which all block placements are logged, but there is no such file if this server avoids SQLite for large databases as it should. CoreProtect has native in-game log purging which means that purging logs from [x] server wipes ago would be possible if server wipes were conducted automatically and not at the whim of admins. I’m still not 100% sure that this has anything to due with the database as OP said it was fine in 1.15 but is slower in 1.16, we also do wipes every so often, I think this may be a case of the plugin just being slower in which case we may have to wait for an optimization update to release for it |
|
grntbg
Full Member
Omnis anima potestatibus sublimioribus subdita sit.
Posts: 295
|
Post by grntbg on Jul 13, 2020 7:01:51 GMT
This is in response to Fionn's comment about there being a ".db file" in which all block placements are logged, but there is no such file if this server avoids SQLite for large databases as it should. CoreProtect has native in-game log purging which means that purging logs from [x] server wipes ago would be possible if server wipes were conducted automatically and not at the whim of admins. I’m still not 100% sure that this has anything to due with the database as OP said it was fine in 1.15 but is slower in 1.16, we also do wipes every so often, I think this may be a case of the plugin just being slower in which case we may have to wait for an optimization update to release for it I am affiliated with several servers using the latest release and it's running fine. Even if it's not the database's unmaintained size, for you to ensure that the plugin is working as expected you'll need to get rid of the database. |
|
|
|
Post by Telesphoreo on Jul 13, 2020 7:10:47 GMT
We're not using SQLite. The server uses MySQL This is in response to Fionn's comment about there being a ".db file" in which all block placements are logged, but there is no such file if this server avoids SQLite for large databases as it should. CoreProtect has native in-game log purging which means that purging logs from [x] server wipes ago would be possible if server wipes were conducted automatically and not at the whim of admins. Had no idea at all about this. Thanks for telling me!!1!1 |
|
[/spolier]
