Минимальные Требования

Железо:
Процессор - 4х ядерный x64/ARM
Память RAM - 5 гигабайт (на процесс явы)
Винчестер - 20 ГБ, желательно с большим кешем или SSD

Софт:
Oracle Java SE Runtime Environment 17 или выше
MySQL 5.7 или MariaDB 10.5 или выше (Минимум 5.7, Рекомендуется ставить последнюю версию с сайта разработчика).

Операционные системы:
Та операционная система с которой вам комфортно работать и вы оперируете в ней свободно!
Это может быть любая свежая Server/обычная Win OS или Linux или Unix.

Сторона человека:
Минимальное знание английского языка, знать алгебру и геометрию на уровне минимум 7мого класса

 

[gplw]

Добрый вечер!
что-то поменялось в технических характеристиках?

 

[Deazer]

Добрый вечер!
что-то поменялось в технических характеристиках?

нет

 

[bysouza]

нет

In your opinion and experience, how many players could a dedicated machine with these specifications support?
CPU AMD RYZEN 9 9900X
12 cores / 24 threads
4.4 GHz / 5.6 GHz
RAM
64 GB
Storage
2 x 512 GB
Bandwidth
Public 1 Gbps
Private 1 Gbps

 

[Deazer]

In your opinion and experience, how many players could a dedicated machine with these specifications support?
CPU AMD RYZEN 9 9900X
12 cores / 24 threads
4.4 GHz / 5.6 GHz
RAM
64 GB
Storage
2 x 512 GB
Bandwidth
Public 1 Gbps
Private 1 Gbps

That’s enough for 5-6 servers with 5,000 concurrent players each.

 

[HSTQ]

For that Ryzen configuration, I would validate the estimate with your actual revision, geodata and extensions before placing several realms on it. A crowded siege and a login wave are useful test cases; the same population spread across separate maps produces a different workload.

Record CPU usage per core, GC pauses, database query times and disk latency during those runs. Also leave RAM for the database, operating system and native allocations outside the Java heap. Those measurements should help decide how many realms fit while keeping headroom for peak events.

 

[Deazer]

For that Ryzen configuration, I would validate the estimate with your actual revision, geodata and extensions before placing several realms on it. A crowded siege and a login wave are useful test cases; the same population spread across separate maps produces a different workload.

Record CPU usage per core, GC pauses, database query times and disk latency during those runs. Also leave RAM for the database, operating system and native allocations outside the Java heap. Those measurements should help decide how many realms fit while keeping headroom for peak events.

You probably used to work only with l2j, in our system, everything is kept in the cache and written to the database only when a player logs out, disconnects, and so on. You can also run a debug session to check the GC pauses - there are practically none, as they consistently occur within milliseconds. We don't have a lot of garbage buildups because I clean everything up immediately.