mirror of
https://github.com/CivMC/Civ.git
synced 2026-07-18 00:20:44 +00:00
558f661833
The problem with snitches crashing the server is that the MariaDB query planner decides that it is going to be smart, and actually do a query from the (very small) ja_snitch_actions table, and then join the (humongous) ja_snitch_entries table. To do this, it has the genius idea of filtering the ja_snitch_entries table by the type_id column. This column represents the type of snitch entry, be it entering the snitch, breaking a block, placing a block, etc. Naturally, MariaDB thinks that it can reduce the 10M+ row database to just 1000 rows with this filter. But it turns out that there are LOTS of entries for each type_id, so it actually get about 600K columns, and has to linearly search through them. Only a handful of snitches have been found to crash the server this way. I don't know how the MariaDB query planner works, nor do I want to, but I can speculate that only very heavily trafficked snitches would crash the server in this way, or perhaps those that show an unusual distribution of entry types. Here is the MariaDB ANALYZE output for when the query planner thinks it's really smart: ``` +------+-------------+-------+-------+-----------------------------+---------+---------+------------------+------+-----------+----------+------------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | r_rows | filtered | r_filtered | Extra | +------+-------------+-------+-------+-----------------------------+---------+---------+------------------+------+-----------+----------+------------+-------------+ | 1 | SIMPLE | jsa | range | PRIMARY | PRIMARY | 4 | NULL | 17 | 1.00 | 100.00 | 100.00 | Using where | | 1 | SIMPLE | jse | ref | type_id,snitch_action_index | type_id | 5 | jukealert.jsa.id | 1241 | 671443.00 | 0.51 | 0.00 | Using where | +------+-------------+-------+-------+-----------------------------+---------+---------+------------------+------+-----------+----------+------------+-------------+ ``` As you can see, the query planner thinks it will get 1241 rows, but it actually gets 600K. Big miscalculation. In contrast, here is a normal snitch: ``` | id | select_type | table | type | possible_keys | key | key_len | ref | rows | r_rows | filtered | r_filtered | Extra | +------+-------------+-------+--------+-----------------------------+---------------------+---------+-----------------------+-------+--------+----------+------------+-------------+ | 1 | SIMPLE | jse | ref | type_id,snitch_action_index | snitch_action_index | 5 | const | 54054 | 10.00 | 50.00 | 100.00 | Using where | | 1 | SIMPLE | jsa | eq_ref | PRIMARY | PRIMARY | 4 | jukealert.jse.type_id | 1 | 1.00 | 100.00 | 100.00 | | +------+-------------+-------+--------+-----------------------------+---------------------+---------+-----------------------+-------+--------+----------+------------+-------------+ ``` Interesting, the query planner drastically over-estimates the amount of rows it will scan. It thinks it will need to comb through 50K logs, but it actually ends up looking through 11. Perhaps an alternative solution could be trying to update the data analysis the query planner gets - it may be severely inaccurate. However, this fix should be sufficient as STRAIGHT_JOIN forces the join to be done in a specific order (big table joins small table), instead of the wrong order (small table joins big table), which is ALWAYS wrong. Database query planner bugs are just the best aren't they?
Civ
This monorepo will eventually contain all civ projects and development
Developing Locally
Plugins
Containers
A docker compose stack is provided to help test containers built from this repo. To start the stack, run the following commands:
gradle :ansible:builddocker compose up
Please note that this stack is NOT suitable for production use.
Container data (world, logs, etc.) are mounted at ./containers/data.
Optional services may be started by enabling the profile flag, e.g. --profile <name>
Current services and exposed ports are:
| Name | Ports | Description | Profile |
|---|---|---|---|
| proxy | 25565 | TCP, Minecraft | |
| paper | |||
| pvp | |||
| mariadb | 3306 | TCP, Database | |
| postgres | 5432 | TCP, Database | |
| rabbitmq | 5672 | TCP, AMQP | |
| 15672 | HTTP, Management UI | ||
| grafana | 3000 | HTTP, Grafana UI | monitoring |
Using the console
For the minecraft servers and other interactive containers, you can attach to the console to run commands:
- run
docker ps - Note the name of the container. By default, randomly generated.
- Run
docker attach <name>, for example:docker attach 81dcee85c1da
Licencing
This project and any subprojects not otherwise containing a licence file are licenced under the MIT licence. Individual plugins may be subject to their own licences, please check the respective plugin directories for details.