Preface

_{Disclaimer: Unlike other types of flags, this one is very server-specific. Results may greatly vary between hardware configurations.}

Scenario

I have a VPS, 16GBs of RAM, 6 vCPU and NVMe SSD storage.
Between 5-10 users connected concurrently on the server, that like to spread and explore, mostly alone, between all dimensions.
Forge 1.19.2 server configured with hilltty flags, 10 chunk view distance, and 8 chunk simulation distance.
Tried all kinds of both mods, and flags configurations (GCs, -Xmx, Aikars, etc..), to have stable tps on the server.
So far, Hilltty flags have been the ones to better perform on this environment.

Background

Minecraft is a game that, as versions increase, so do they're object allocation rates.
In my 1.19.2 client, over 50 MBs are being thrown into the heap every second, to be descarded soon after.
This increase affects servers, as well.

ShenandoahGC default heuristic, adaptive, does a good enough job with this allocations, during normal gameplay.
However, once chunkloading starts to happen, it quickly begins to be not enought to free java heap, and heavy GC pauses (>1s) will be present, resulting in rubberbanding, and the infamous "Server can't keep up" and "Player moved too quickly" events spamming your server console.

The solution to this issue, may very well be the compact heuristic.

Flags

To enable compact heuristics:
-XX:ShenandoahGCHeuristics=compact
To select number of GC Threads
-XX:ConcGCThreads=#

Compact heuristic

Unlike adaptative, that tries to have a balance between GC pause time, and amount of GC passes, compact tries to run GC as much as possible.
This results in java heap almost never reaching the maximum capacity, greatly reducing the heavy GC pauses.
As a side effect, max heap can be greatly reduced, due to the more common GC passes.
Example: On my server, memory allocation went tfrom 3.7 GBs, to only 664MBs. ^*1
It also decreased mspt^*2 from 19.9ms, to 13.3ms..
..and completely tanked my chunk loading speed.

Concurrent Garbage Collectors Threads

In my environment, the default behaviour of the JVM is to use as much threads for garbage collection as possible.
This causes Minecraft to have less processing power available, generating processes like chunkloading to lag behind, even if TPS is still in perfect 20.
To fix this issue, you can follow documentation provided on the Shenandoah wiki, to decrease the number of threads used for GC.
1/3 or 1/2 of the available cores should be enough, for most servers.
Example: In my server, I have 2 threads assigned to Concurrent GC, from 6 vCPUs available.

TLDR

Try -XX:ShenandoahGCHeuristics=compact on your server, and tinker with -XX:ConcGCThreads=#
It may do wonders on your server, or completely tank your tps. Testing is the only way to know for sure.

Documentation

https://wiki.openjdk.org/display/shenandoah/Main#Main-Heuristics

Annotations

*1 Value using Spark, with -Xmx flag removed, so JVM can allocate memory as needed
*2 MiliSeconds Per Tick

OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking was deprecated in version 15.0 and will likely be removed in a future release.
Error occurred during initialization of VM
Option -XX:+UseShenandoahGC not supported

https://imgur.com/a/njpxU8K

Все флаги использовал ваши. (Только без больших страниц, потому что у меня виндовс 7)
OpenJDK 17.0.1
Paper 1.18.2 312

When starting the server I get

OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking was deprecated in version 15.0 and will likely be removed in a future release.