Normal [VPS] Servidor com lag

[Fabianuh 4]

Como o nome do tópico já diz, o servidor fica com lag.. vamos as configurações do VPS:

OpenStack KVM
1 vCore
2.4 GHz
4 GB RAM
20 GB SSD
Local RAID 10
Link: 100 mbps
  
SO: Linux Ubuntu 16.04 (x64)

O servidor pesa 50 MB's.

Uso TFS 0.4 (3777)

 

Já revisei todo e qualquer script do servidor.

O VPS tem mais de 2 GB de memoria ram sobrando.

 

Teste de PING:

 

O ping aqui de casa pro servidor, fica em média de 170~180 ms.

Caso necessite posso ceder os dados do VPS para testes e afins.

 

Toda e qualquer ajuda é bem vinda! até breve.

 

[KotZletY 1095]

@Fabianuh revisou, mais as vezes não se trata do script funcionar, e sim como o script foi escrito. Muito grande, usando muitas funções desnecessária, script mal feito, ou algum script que está sendo executado muito rapido.

Algum player possa está executando uma ação no jogo muito rápido para sobrecarregar o server e então causando o lag.

É permitido usar bot no seu servidor ? Que tipo de server é ? Será que ele não está sendo nukado ?

[theheroesoftime 7]

Ponto muito importante que reparei: não pegue vps com virtualizacao KVM! Os recursos da maquina nao sao devidamente aproveitados por essa virtualizacao. Pesquise VPS que use VMWare ou ProxMox, mas fique longe de KVM, OpenVZ e SolusVM.

 

Ou às vezes é tua distro, tente mudar. Teste OTX, por exemplo, os parametros de protocolo e envio de pacotes são um pouco alterados no OTX, deixando o "andar" do personagem mais fluido.

 

Outro ponto importante é o Ubuntu 16.04 e o 16.10 que apresentam as libboost mais atuais. Quando você segue os tutoriais de compilacao para linux, sabe que tem que instalar tais libboosts, certo? O problema é que as muito antigas e as muito novas resultam em instabilidade. Recomendo o Ubuntu 12.10 (ou 12.04) e o 14.04... ou até Debian 7 ou 8.

 

Verifique, também, os parametros de compilação (flags para x64, flags de otimizacao, etc). Isso é um pouco mais avançado, mas o senhor Google ajuda

 

Verifique, ainda, os packetsPerSecond do config.lua. Cada servidor tem um numero certo, mas recomendo deixar entre 50 e 200 (tente 100, por exemplo).

 

Desabilite a utilizacao  de memoria swap no linux (porque ele dá preferencia à swap em relacao à RAM em situacoes de alto uso):

   sysctl vm.swappiness=0

[Fabianuh 4]

@KotZletY

Em relação aos scripts, não tem nada além do necessário. posso executar o datapack do theforgottenserver crú que ainda vai continuar a lagar.

E sobre players, somente eu estou testando o server.

 

@mameca123

Vou rodar o OTX pra ver se muda alguma coisa, caso não mude vou reinstalar a maquina com ubuntu 12.04/14.04 ou Debian.

packetsPerSecond, não está presente no theforgottenserver 0.4;

E a memoria ram, creio que não seja necessário já que só eu estou testando o server, e ainda sobre 2 GB livres.

 

O VPS que possuo é da mesma empresa que você, poderia me dizer qual serviço você possui? VPS SSD? VPS Cloud? VPS Cloud RAM? ou possui um Public Cloud? ou um Dedicated Server?

 

Até breve, e obrigado pelas respostas. :]

 

 

 

[theheroesoftime 7]

Veja então maxAllowedPackets, pois tenho quase certeza que as distros 0.4 vêm com essa diretiva, tente adicionar as duas (pegue em um config.lua que as tenha) e experimente deixar em 50~200.

 

Utilizo o Dedicated Server da OVH com o i7 6770K Overclocked, é o terceiro dedicado da lista de dedicados. Certamente não recomendaria um dedicado desse a ti com menos de 300 online. O meu mapa é pesado, tem cerca de 170000 monstros espalhados e isso exige muita memória pois tenho alguns creaturescripts vinculados ao onTarget dos monstros então um vps não aguentaria.

 

Enfim, se você for pegar direto da OVH, aconselho um VPS SSD. Veja isso da virtualização que é o que mais influencia num VPS no que tange a utilização dos recursos dele.

Memória RAM interessa sim! Eu pensava o mesmo que você... ao dar load em todos os módulos do servidor e no mapa, perceba que a utilização de memória RAM sobe demais (principalmente no período em que o servidor está dando load no mapa). Mas quando o servidor está online, a quantidade de memória RAM em uso permanece fixa e próxima àquela utilizada para dar load no map.

 

No entanto, já fiz o teste em vários VPS:

 

512MB RAM, 1GB RAM, 2GB RAM, 4GB RAM, 8GB RAM, 16GB RAM, 32GB RAM e atualmente uso 64GB RAM.

 

E adivinha o que descobri? Quanto mais memória RAM disponível para dar load no mapa e nos módulos, menos travado o servidor rodará.

Pelo comando "top" do linux, percebi que o server utiliza quase sempre ~30% da RAM total para rodar (pelo menos o meu é assim).

Ou seja, com 512MB de RAM, a distro estava utilizando ~150MB. Com 1GB, estava utilizando ~300MB. Com 64GB de RAM, ele utiliza apenas 8GB de RAM (que não chega a ser 30% de 64GB), então presumo que conforme a memória RAM cresca, o servidor tende a cair esse "30% de utilização". Então você pensou "ah, tenho 2GB de RAM mas o meu server usa menos que 2GB então está OK".... beleza! Mas se você tivesse 64GB de RAM ele alocaria muito mais RAM (no meu caso, 8GB) para seu funcionamento.

Editado Janeiro 8, 2017 por mameca123 (veja o histórico de edições)

[Fabianuh 4]

@mameca123 peguei o VPS SSD 2, direto da OVH.

 

maxAllowedPackets também não existe, procurei no config.lua e nos arquivos .h, .cpp;

 

A questão é muito estranha, pois até com mapa pequeno o mesmo laga, talvez seja por ser VPS e não ter recursos 100% garantidos.

O mesmo acontece com distros do TFS 1.3, como cita-se, possuem protocolo de enviar/receber dados diferentes dos do TFS 0.4.

 

Estou pensando em alugar um public cloud, já que o mesmo possui recursos 100% garantidos, e uma banda de 250 mbps.

O que mais me deixa revoltado, é pelo fato de pessoas terem um VPS, mesma distro.. e o servidor rodar liso.

de qualquer forma, te agradeço pelo tempo respondendo as minhas perguntas.

 

[theheroesoftime 7]

Bem estranho mesmo... leve em conta os outros fatores que eu disse, na ordem:

 

1) Virtualizacao;

2) Sistema operacional e versão de suas libboosts;

3) Flags (parametros) de compilacao (-O2 ou até -O3 é interessante.. use -O0 apenas para debugar seu codigo para ter acesso, com o GDB, às causas de alguma queda no servidor e fazer uma source estável... isso você aprende com o tempo...... existem outras variaveis de compilacao que podem deixar o server liso. Pesquise sobre funroll loops por exemplo);

4) Veja o OTX como eu disse, sempre rodou mais liso aqui, mas eu sempre pesquisei nas sources e nunca encontrei algo que explicasse o porquê (a nao ser umas alteracoes no envio de pacotes no protocolgame e em outros .cpp que nao me lembro direito);

5) As outras coisas que eu disse.

 

 

Extra:

 

Use o "renice" no linux para deixar seus processos rodando em tempo real. Se nao me engano é assim que usa: renice -20 PID  (PID = id do processo da distro)

 

Ative o parametro low_latency pelo sysctl tambem (tem no google)

 

E alguns VPS permitem que voce instale e utilize o ethtool para modificar parametros de rede no linux (desative auto-negotiation, ativar rx e ativar tx ambos para 4096MB é uma boa... para ativar/desativar é pelo ethtool -a SUAREDE PARAMETRO off/on .... exemplo: ethtool -a eth0 autoneg off). E para setar o tx e rx, que sao parametros que ditam como os recursos de rede devem ser alocados para condicionar a maneira como chegam e partem os pacotes, é pelo ethtool -g SUAREDE PARAMETRO VALOR, exemplo: ethtool -g eth0 tx 4096). Sei que tudo isso pode parecer estranho, mas sao parametros de rede que podem ajudar no desempenho, reducao de latencia, melhorar a transmissao de dados, reduzir a perda de pacotes, etc.. Mais uma vez, o doutor google te ajuda com tudo isso hahaha

 

Qualquer duvida, só mandar, abraço.

[klessio 1]

Em 09/01/2017 ás 23:19, mameca123 disse:

Bem estranho mesmo... leve em conta os outros fatores que eu disse, na ordem:

 

1) Virtualizacao;

2) Sistema operacional e versão de suas libboosts;

3) Flags (parametros) de compilacao (-O2 ou até -O3 é interessante.. use -O0 apenas para debugar seu codigo para ter acesso, com o GDB, às causas de alguma queda no servidor e fazer uma source estável... isso você aprende com o tempo...... existem outras variaveis de compilacao que podem deixar o server liso. Pesquise sobre funroll loops por exemplo);

4) Veja o OTX como eu disse, sempre rodou mais liso aqui, mas eu sempre pesquisei nas sources e nunca encontrei algo que explicasse o porquê (a nao ser umas alteracoes no envio de pacotes no protocolgame e em outros .cpp que nao me lembro direito);

5) As outras coisas que eu disse.

 

 

Extra:

 

Use o "renice" no linux para deixar seus processos rodando em tempo real. Se nao me engano é assim que usa: renice -20 PID  (PID = id do processo da distro)

 

Ative o parametro low_latency pelo sysctl tambem (tem no google)

 

E alguns VPS permitem que voce instale e utilize o ethtool para modificar parametros de rede no linux (desative auto-negotiation, ativar rx e ativar tx ambos para 4096MB é uma boa... para ativar/desativar é pelo ethtool -a SUAREDE PARAMETRO off/on .... exemplo: ethtool -a eth0 autoneg off). E para setar o tx e rx, que sao parametros que ditam como os recursos de rede devem ser alocados para condicionar a maneira como chegam e partem os pacotes, é pelo ethtool -g SUAREDE PARAMETRO VALOR, exemplo: ethtool -g eth0 tx 4096). Sei que tudo isso pode parecer estranho, mas sao parametros de rede que podem ajudar no desempenho, reducao de latencia, melhorar a transmissao de dados, reduzir a perda de pacotes, etc.. Mais uma vez, o doutor google te ajuda com tudo isso hahaha

 

Qualquer duvida, só mandar, abraço.

 

Você poderia dar mais informações de como ativar o low_latency ?