Question: Database queue size

[bobhenl]

Hello, is here something that could be done about this?
[13:13:44] [Plan Non critical-pool-3/WARN]: [Plan] Database queue size: 500, dropping some unimportant transactions. If this keeps happening disable some extensions or optimize MySQL.

I don't think I have so many extensions, or how to optimize MYSQL?

my extensions:

[13:11:51] [Server thread/INFO]: [Plan] Enabling Plan v5.7 build 3198
[13:11:51] [Server thread/INFO]: [Plan] 
[13:11:51] [Server thread/INFO]: [Plan]            ██▌
[13:11:51] [Server thread/INFO]: [Plan]      ██▌   ██▌
[13:11:51] [Server thread/INFO]: [Plan]   ██▌██▌██▌██▌  Player Analytics
[13:11:51] [Server thread/INFO]: [Plan]   ██▌██▌██▌██▌  v5.7 build 3198
[13:11:51] [Server thread/INFO]: [Plan] 
[13:11:51] [Server thread/INFO]: [Plan] Locale: 'English' by AuroraLS3
[13:11:51] [Server thread/INFO]: [Plan] Downloading MySQL Driver, this may take a while...
[13:11:52] [Plan MySQLDB-transaction-thread-1/INFO]: [Plan] Database: Making sure schema is up to date..
[13:11:52] [Server thread/INFO]: [Plan] MySQL-database connection established.
[13:11:52] [Server thread/INFO]: [Plan] WebServer was not initialized. (WebServer.DisableWebServer: true)
[13:11:52] [Server thread/INFO]: [Plan] Loading server identifying information
[13:11:52] [Server thread/INFO]: [Plan] Server identifier loaded: 16c675ed-a925-4261-ad15-bba9677a45f9
[13:11:52] [Server thread/INFO]: [Plan] Registered extension: DiscordSRV
[13:11:52] [Server thread/INFO]: [DiscordSRV] API listener net.playeranalytics.extension.discordsrv.DiscordSRVListener subscribed (2 methods)
[13:11:52] [Server thread/INFO]: [Plan] Registered extension: CMI
[13:11:52] [Plan Non critical-pool-5/INFO]: [Plan] Proxy server detected in the database - Proxy Webserver address is 'http://localhost:41164'.
[13:11:52] [Server thread/INFO]: [Lands] [Integrations] 3rd party plugin hooking into Lands: Plan
[13:11:52] [Server thread/INFO]: [Plan] Registered extension: Lands
[13:11:52] [Server thread/INFO]: [Plan] Registered extension: LuckPerms
[13:11:52] [Server thread/INFO]: [Plan] Registered extension: PlaceholderAPI
[13:11:52] [Server thread/INFO]: [Plan] Registered extension: Economy (Vault)
[13:11:52] [Server thread/INFO]: [Plan] Registered extension: Permission Groups (Vault)
[13:11:52] [Server thread/INFO]: [Plan] Registered extension: ViaVersion

[AuroraLS3]

If you're booting up multiple servers at the same time the write performance of the database may suffer temporarily.

I suggest a ladder reboot approach where there is some delay between starting each server

[bobhenl]

Usually, I restart only the Proxy & Main server, where the proxy loads much faster than the main server.

I restart it at once to prevent two restarts, as on pvp server it could be dangerous to restart firstly the one server, and then after it loads restart the proxy, as players could be already in PvP & loose items, same if I restart firstly proxy (which kicks them & can cause loss of items due to combat log), not really good neither, that's why I restart at once.

But maybe I can make the main server restart, lock joining for like 2 mins after the start, and then restart proxy.

Not really sure, probably need to think a bit more about it.

Also, what is the issue? Is it trying os many transactions just in Plan, or overall in the database @AuroraLS3 ? Like, what are we trying to solve by this, just the Plan owhole MYSQL?

And does it cause any issues when the error is displayed, or will it just delay the transactions?

[AuroraLS3]

I'm not sure what is causing the large queue, but it could also have been related to the other issue you had open - there's a small problem where Plan does make a lot of extension related transactions during server enable, especially if players join in large batches at the same time.

If there's few transactions that take longer time (like player extension table transactions) they might hold up the queue until it logs the warning.

Warning level in Plan is usually used as extra information rather than something going wrong - like an anticipated issue like this one.

[AuroraLS3]

Opening the website without cache enabled (or when new version is installed) also produces a lot of transactions since each request is logged to plan_access_log

Ideally they would be batched, but that has not been implemented

[AuroraLS3]

I decided to implement the batching, this should occur less frequently