Page MenuHomeFeedback Tracker

Arma 3 Server unuseable with QEMU/KVM
New, NormalPublic

Description

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.

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
Steps To Reproduce

Install and Run ArmA 3 Server in QEMU/KVM linux or windows and run server-side sqf code.

Additional Information

If the issue cannot be reproduced, i can provide logs or remote access to the servers.

Event Timeline

Tallion created this task.Mar 6 2025, 6:15 PM
Tallion added a comment.EditedMar 6 2025, 7:36 PM

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.

dedmen added a subscriber: dedmen.Mar 10 2025, 1:14 PM

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.