Zurück zum Blog

FiveM Optimierung: Von 30 auf 60 FPS auf einem vollen Server

FiveM-Performance ist eine Server-und-Client-Verschwörung: ein einziges schlechtes Script killt allen die FPS, dann lassen schlechte Client-Settings die Spieler den Server beschuldigen. Dieser Guide trennt beide Themen, gibt dir ein Mess-zuerst-Playbook und deckt die Fixes ab, die 2026 tatsächlich was bewegen — nicht die Placebo-Tweaks, die YouTube-Videos füllen.

„FiveM läuft mit 30 FPS" ist fast nie das eigentliche Problem. Das echte Problem ist meist eines von:

Unser empfohlener FiveM-Hoster

Für die CPU-Performance und den DDoS-Schutz, den FiveM braucht, empfehlen wir Avoro — Deutscher Hoster, Ryzen 9 7950X3D Nodes, Always-on-DDoS, echter Unmetered-Traffic. Siehe unseren FiveM Hosting-Vergleich.

  1. Ein einziges fehlverhaltendes Server-seitiges Script verursacht Client-seitige Stalls.
  2. Zu viel gestreamter Content (Autos, MLOs, Custom-Peds) für den VRAM des Clients.
  3. Database-Queries blockieren den Server-Hauptthread.
  4. Game-Settings höher gestellt, als die GPU dauerhaft halten kann.
  5. Anti-Cheat- oder „Loop-Hooking"-Overhead, den niemand profiliert hat.

Dieser Guide geht erst die Server-Seite durch (die gehört dir), dann die Client-Seite (du kannst beraten). Spring zum für dich relevanten Abschnitt.

Schritt 0: messen, bevor du optimierst

Optimierung ohne Messung ist Aberglaube. Zwei Tools brauchst du:

resmon (ingame, F8)

Öffne die Konsole mit F8, tippe resmon, Enter. Du bekommst eine Live-Tabelle jeder laufenden Resource, ihre CPU-Zeit pro Tick (ms), Memory-Nutzung und Netzwerk-Nutzung.

  • Idle-resmon pro Resource sollte unter 0,10 ms sein. Alles über 0,30 ms ist verdächtig. Über 1,0 ms ist ein Problem.
  • Nach CPU sortieren (Spalten-Header), um die schlimmsten Übeltäter zu finden.
  • Zwischen Server- und Client-View wechseln — das sind unterschiedliche Tabellen.

txAdmin Live-Konsole + Perf-Monitor

txAdmin trackt Server-Thread-Hitches. Schau auf server thread hitch warning: timer interval of XXX ms in deiner Konsole. Über 200 ms ist schlecht, über 1000 ms fühlt sich für Spieler kaputt an. Hitches korrelieren meist mit einer DB-Query oder einem synchronen HTTP-Call. Identifiziere die Resource, die genau vor/während des Hitches feuert.

Server-seitige Optimierung

1. resmon-Fresser finden und killen

Öffne resmon während der Server idle ist (keine Spieler). Jede Resource bei >0,30 ms idle macht etwas falsch. Häufige Übeltäter:

  • Ein CreateThread mit einer tight while true do-Loop und Wait(0) statt Wait(500). Such nach diesem Pattern im Client-Code.
  • Ein Blip-Update-Thread, der jedes Frame pollt statt bei Player-Position-Change.
  • Ein „Anti-Cheat"-Script, das per-Tick globale Checks macht (die laufen oft bei 0,50-2,0 ms idle).
  • Tote Scripts aus alten Experimenten, die niemand aus server.cfg entfernt hat.

2. Langsame Database-Queries fixen

oxmysql loggt langsame Queries by default. Schau in deiner Konsole nach Zeilen wie:

[oxmysql] [12.0.2-MariaDB] devCon_factions took 16472.2469ms to execute a query!

16 Sekunden für eine Query ist ein server-killendes Event — alle hitchen für die Dauer. Häufige Ursachen:

  • Fehlender Index auf einer JOIN-Spalte. Schau dir die Query an, identifiziere die Spalten in WHERE / JOIN, fahr SHOW INDEX FROM <tabelle>. Falls die Spalte nicht indexiert ist, leg einen an: CREATE INDEX idx_x ON tab(col);
  • SELECT * auf einer riesigen Tabelle. Ersetze mit expliziter Spaltenliste.
  • JOIN ohne LIMIT. Profil mit EXPLAIN.
  • oxmysql-Warning: oversized result set. Bedeutet, du ziehst die komplette Tabelle in Lua. Füg einen Date-Filter oder Pagination hinzu.

Einzelner größter Win für die meisten Server: indiziere die Spalten, nach denen deine Scripts queryen. 10 Minuten Arbeit, verwandelt 16-Sekunden-Hitches in 2-ms-Queries.

3. OneSync Infinity Tuning

set onesync on
sv_maxclients 64
set sv_enforceGameBuild 3258
set onesync_distanceCullVehicles true
set onesync_radiusFrequency 50
set onesync_population true

Der größte Population-Hebel ist, ob du überhaupt NPCs streamst. Viele RP-Server fahren mit deaktivierten Scenarios via Client-Mod oder Entity-Streaming-Script. Die Hälfte des FPS-Budgets auf vollen Servern geht in NPC-Simulation, mit der niemand roleplayt.

4. Resource-Streaming-Hygiene

Jedes Custom-Vehicle, Ped, MLO, Weapon kostet VRAM auf jedem Client. Das Asset ist nicht kostenlos, auch wenn niemand hinschaut — FiveM preloadet gestreamte Assets beim Resource-Start.

Taktiken: Audit deine stream/ Folder. Alles nicht aktiv genutzte raus. YFT/YTD-Assets in komprimiertes Format konvertieren wo möglich. cl_data-Packs für nicht immer benötigte Assets — on-demand statt eager.

5. Der Cache-Server-Trick

Ein externer nginx-Caching-Proxy ist der größte Spielerlebnis-Win für jeden Server über 50 Spieler. Spieler, die ein 3-GB-Asset-Pack von deinem FXServer laden, killen Join-Times. Vom Cache-Server fertig in 1/4 der Zeit und dein Main-Server ist nicht mehr asset-bound.

Wir haben einen vollständigen Guide zum FiveM-Cache-Server-Setup — typischer ROI ist 5 €/Monat für einen Hetzner CX22 und du holst 40 % der CPU deines FXServers während Peak-Join-Times zurück.

6. Voice auf eigenem Server

pma-voice auf dem Main-FXServer kämpft mit jeder anderen Resource um CPU auf vollen Servern. Auf einen dedizierten Voice-Server verlegen (5 €/Monat VPS) holt ein messbares Stück Main-Server-Budget zurück. Voll Setup-Guide hier.

7. Anti-Cheat-Overhead

Die meisten „Anti-Cheat"-Scripts fügen 0,5-2,0 ms Client-seitig resmon pro Tick hinzu. Multipliziert mit jedem Client und der Overhead ist real. Auditiere deinen: öffne resmon auf einem Client, find den Namen deines AC, check die Kosten. Wenn über 1,0 ms idle, überlege zu wechseln.

Client-seitige Optimierung

1. Keinen Streamer-Overlay-Mod nutzen

NVIDIA ShadowPlay, OBS, Discord-Overlay kosten alle FPS. Wenn ein Spieler 30 FPS hat, frag ihn, Overlays zu deaktivieren und nochmal zu checken. Oft bringt das allein 50+ FPS.

2. Grafik-Settings, die tatsächlich zählen

Im GTA-V-Settings-Menü sind das die Hebel, die's wert sind:

  • Populationsdichte / Vielfalt — auf 50 % runter. RP-Server brauchen keine NPC-Massen.
  • Distance Scaling — auf 60-70 % runter. Massiver FPS-Win, kaum bemerkbar in vollen Straßen.
  • Schattenqualität — Normal, nicht Hoch. Shadow-Rendering ist einer der größten GPU-Verbraucher.
  • Grasqualität — Normal oder weniger.
  • Reflektionsqualität — Normal. Hohe Reflektionen kosten 10-15 % FPS für marginalen visuellen Gewinn.
  • MSAA — aus. FXAA reicht für FiveM.
  • Advanced Graphics → Long Shadows — aus. Das ist der größte versteckte FPS-Killer.
  • Tessellation — Normal.

3. Auflösungs-Scale

Spieler mit 4K auf einer 1080-Tier-GPU sollten Render Scale auf 0,75 stellen. FiveMs TXAA scalt gut hoch — die meisten Spieler merken den Unterschied nicht.

4. FiveM-spezifische Client-Tweaks

In FiveM-Settings (F1-Menü vor Connect):

  • Streaming-Memory-Limit — auf etwa 60 % deines VRAMs. Zu hoch verursacht Streaming-Stalls; zu niedrig Pop-In.
  • GPU-Usage-Policy — FiveM in NVIDIA Control Panel explizit auf diskrete GPU stellen. Laptop-Spieler mit iGPU+dGPU laufen oft auf der falschen GPU.

5. „FiveM ist unspielbar auf meiner CPU"

FiveM ist hauptsächlich CPU-bound, nicht GPU-bound. Eine 4-Kern-CPU von 2018 wird auf jedem vollen Server kämpfen, egal welche Grafik-Settings. Quad-Core-Spieler müssen wissen: Grafik-Tweaks helfen ihnen nicht; CPU-Upgrade schon.

Moderner Threshold (2026): 6 Kerne, 3,5+ GHz Base, 16 GB RAM, GTX 1660 / RX 5600 oder besser. Darunter optimierst du in abnehmenden Erträgen.

Häufige Mythen

„GTA5.exe -no_browser boostet FPS"

Das stimmte 2018-2019. Heute ist FiveMs Browser-Prozess gut eingedämmt und der Flag bricht tatsächlich mehrere Scripts. Nicht nutzen.

„NUI deaktivieren gibt mehr FPS"

Du kannst NUI nicht deaktivieren — das ist, was die meisten Ingame-Menüs rendert, inklusive F8-Konsole, ESX/QBCore-HUDs, Phone-Apps. Deaktivieren macht den Server unspielbar.

„Custom-DLLs machen FiveM schneller"

Alles, was via injizierter DLL „FPS-Boost" verspricht, ist entweder nutzlos oder ein Token-Stealer. Der Cfx.re-Client ist bereits optimiert.

„CPU-Affinität auf FiveM setzen"

Moderner Windows-Scheduler handhabt das einwandfrei. Manuelle Affinity-Änderungen machen es meist schlechter. Skip.

Workflow: eine echte Optimierungs-Session

  1. SSH in den Server, tail txAdmin-Konsole. Notiere Hitch-Warnings >500 ms.
  2. Server beitreten. Öffne F8 → resmon. Nach CPU sortieren. Top 5 client-seitige Resources notieren.
  3. Auf resmon server wechseln. Top 5 server-seitige Resources notieren.
  4. Reproduziere ein Problem (Heavy-Job-Site, Server-Restart-Join-Welle). Schau welche Resources spiken.
  5. Check oxmysql-Logs auf langsame Queries während des Spikes.
  6. Pick den schlimmsten Übeltäter. Stop. Re-test.
  7. Entweder: (a) fix dein Code, (b) ersetze mit besserem Script, (c) frag Script-Anbieter nach Fix.
  8. Wiederholen bis idle resmon < 5 ms total über alle Resources.

Hardware: wann upgraden

Server-Hardware

FXServer ist hauptsächlich single-threaded für die Main-Game-Loop. Single-Thread-CPU-Performance zählt mehr als Core-Count. Ein moderner Ryzen 5/7 oder Intel i5/i7 mit hoher Base-Clock (4,0+ GHz) schlägt einen 32-Kern-Xeon fürs FiveM-Hosting.

RAM: 16 GB Minimum, 32 GB komfortabel für 100-Spieler-Server mit vielen Resources.

Disk: NVMe SSD Pflicht. SATA SSD akzeptabel für Cache-Server, Main-FXServer will NVMe.

Netzwerk: 1 Gbps Uplink Minimum. Unmetered Traffic essenziell — volle Server pushen 5-15 TB/Monat.

Hetzner / OVH / Server4You

Für die meisten DACH-Communities ist Hetzner der sichere Default — gute Single-Thread-CPUs, 1 Gbps unmetered, zentrale deutsche DC-Lage für niedrigen Ping. OVH hat DDoS-Schutz, aber günstigere Pläne haben schlechtere Single-Thread-Performance. Server4You ist fein für kleine Server; nicht für 100+ Slots empfohlen.

Was wir bei devCon machen

Wir hosten unsere eigenen Scripts auf einem Hetzner AX52 (8 Kerne, 64 GB RAM, NVMe), 130 Resources mit 80 simultanen Spielern, Peak-resmon unter 3 ms total. Der Weg dahin: jeder Schritt aus diesem Guide — Cache-Server, Voice auf dedizierter Box, indizierte DB-Queries, 40 Garbage-Scripts gedroppt, die wir über Jahre angesammelt hatten.

Wenn du unser Script-Bundle willst, das wir mit dieser Performance-Philosophie gebaut haben — jedes Script getestet für <0,05 ms idle resmon — das verkaufen wir auf devCon Studio.

Weiterführende Artikel