Excessive log files / errors crash the server #1028
Comments
KateHutch
added
the
Requires Testing
5 tasks
Merged
|
Fixed in 5777376 |
NotMyFault
added
Approved
dordsor21
added a commit
that referenced
this issue
Jun 8, 2021
**Add a null-check to CharBlocks FULL section layer-retrieval.** - It is possible to trim CharBlocks whilst it is attempting to read data due to the batching of chunks to help reduce memory - This is done when the number of chunks sitting loaded in memory with having been "submitted" to the queue for writing to disk becomes high - Seconday operations such as heightmap processing and lighting will quickly load chunks, meaning many chunks are submitted early - This leads to much higher chances of the chunk being submitted and subsequently trimmed given heightmap and light processing is done layer-by-layer over many chunks, rather than chunk-by-chunk - thus leading to NPEs. - By adding synchronisation to and around only the specific sections when loading/updating, and not blocking the whole chunk, many access can still be thread-safe without causing deadlocks - This allows removal of lots of the needless and very-slowing synchronisation on get**Block** methods **Remove much of the synchronisation from ChunkHolder** - We shouldn't be synchronising with call() and safety should be added elsewhere. (plus it's making edits very very slow when queue target size is hit) - Also remove much of synchronisation because we've added the null-check and section-specific synchronisation to CharBlocks **Some QOL/thread-safe data access changes** - Replaces the Array#clone seen in the get blocks classes with System#arraycopy as deep cloning is not required, and is also slower than arraycopy - Add System#arraycopy when accessing chunk section data via history to ensure it is not altered whilst being written - Renaming EMPTY to empty means it is not implied to be a static variable Fixes #1028 Fixes #1025 Fixes #1089 Fixes #1091 Fixes #1097
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Server Implementation
Paper
Server Version
1.16.5
Describe the bug
Over the past couple of months, we have had an intermittent issue where an occasional error in FAWE causes the hard drive to fill up completely (in excess of 300GB). I'm not aware of what specifically triggers this issue.
This error has been happening on the following versions:
Due to the size of the log file I have not been able to access it, however I here is a link to a snippet of the error log: https://haste.athion.net/uhamaxotod.sql
To Reproduce
I'm not actually sure what triggers this issue, nor the steps to reproduce it but I believe it's something like this:
Expected behaviour
If FAWE encounters a "fatal error" it would be great if it could either forcefully stop whatever task it's doing.
Screenshots / Videos
No response
Error log (if applicable)
https://haste.athion.net/uhamaxotod.sql
Fawe Debugpaste
N/A
Fawe Version
FastAsyncWorldEdit-Bukkit-1.16-648.jar
Checklist
I have included a Fawe debugpaste.
I am using the newest build from https://ci.athion.net/job/FastAsyncWorldEdit-1.16/ and the issue still persists.
The text was updated successfully, but these errors were encountered: