I have just been looking into proxmox and planned to migrate my Windows Server 2022 to a KVM to have more flexibility in the choice of operating system. While testing, I noticed that A3 Server is not usable at all under KVM. As soon as a server-side sqf code is executed, the server becomes extremely slow. The code is executed, but takes forever. I have checked multiple times if it is a general problem with my VM setup, but all other applications are running fine. The problem seems to be worse when KVM is running debian/linux, windows seems to catch up with the open sqf threads and then hangs again, while linux doesn't run sqf at all after a minute.
Description
Details
- Severity
- Major
- Resolution
- Open
- Reproducibility
- Always
- Operating System
- Windows 11 x64
- Operating System Version
- Tested with Windows Server 2025 latest x64 and Debian 12.9 x64
- Category
- Server
Install and Run ArmA 3 Server in QEMU/KVM linux or windows and run server-side sqf code.
If the issue cannot be reproduced, i can provide logs or remote access to the servers.
Event Timeline
Update: Also tested LXC's and its the same issue. If it runs natively on the same server with a Debian operating system, it works perfectly.
Run profiling binary, and profile the game with captureFrame and see where the slowdown is.
It's Arma, not ArmA.
Not exactly sure, but the issue is either with extDB3 directly or with callExtension, as return value suggests some issues with getting the data. As there are no slow callExtension warnings in log, i guess its extDB3 issue so in that case Ticket could get closed.
Something is very wrong with that trace file.
The game failed to capture properly, it should not only contain extDB entries.
And no it doesn't seem to be a extDB issue, all the extDB scopes are very short, its just that everything inbetween is somehow missing.
Maybe the normal captureFrame log file shows better info, and its just the trace file that's bad?
Altis Life has this very "dangerous" code on server side:
//Make sure the data is received if (_queryResult isEqualTo "[3]") then { for "_i" from 0 to 1 step 0 do { if (!(_queryResult isEqualTo "[3]")) exitWith {}; _queryResult = EXTDB format ["4:%1", _key]; }; };
Since extDB triggers the [3] condition repeatedly (hundreds of thousands of times), I think it causes the server to hang, so extDB should be the problem, as natively on the same server this behavior doesn't happen.