Clicky

Ir para conteúdo
PedroHenrique

Ajustar vps

Posts Recomendados

Depois de muito sofrer com VPS na BudgetVm, resolvi arrisca e contratei um dedicado em parceria com um amigo meu.

Configurações: Xeon E3-1230 V2, 4 cores, 32GB ram, 2x2TB sata3. Vamos criar 2 vps de 2 cores, 8GB ram e 500GB disco, para trabalhar como hospedagem usando o cPanel.

Os vps serão em KVM, ai lendo a respeito parece que esse tipo de virtualização exige algumas configurações específicas, afim de que os vps não consumam muitos recursos e não fiquem com altos níveis de processamento e acabem atrapalhando um ao outro ou até mesmo caindo.

O que li foi que ao criar vps com KVM deve se habilitar a tecnologia Virtio tanto para discos quanto para rede e que deve habilitar o cache de disco, caso contrário os VPS ficam sem controle e querem "sugar" cada vez mais do dedicado, o que prejudica a ele mesmo, a outros vps e ao dedicado. Onde li fala que esse tal de Virtio é um tipo de driver que faz com que o vps entenda que está em um ambiente virtual e assim se comporte como uma máquina virtual não abusando, e dessa forma mantendo sua carga e consumo de recursos baixos e controlados.

A pergunta é: isso procede?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Cara, na verdade o Virtio é um framework de I/O , ele é uma camada abstrata que emula dispositivos em paravirtualização. Logo ao utilizar o virtio como como controlador você terá um maior I/O resultando em um melhor desempenho. 

Para a configuração de seu servidor VPS em KVM, sugiro utilizar o virtio, com cache writeback e o IO como nativo, logo o dumpxml de sua instância deve ficar igual ao abaixo: 

<driver name='qemu' type='raw' cache='writeback' io='native'/>
<source dev='/dev/storage/instance-seuservidorvps_disk'/>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>

 

E o I/O scheduler como noop, pois é provável que seja criado como cfq que realiza um balanço entre leitura e escrita e irá conflitar com o do host que utiliza deadline. 

E caso achar que o desempenho ainda não esteja como o esperado, sugiro desativar o tickless kernel que pode causar um delay extra em certas situações, para isso basta adicionar na linha de comando do kernel localizado no grub.conf  o nohz=off 

Qualquer dúvida estou a disposição e boa virtualização! 

 

Compartilhar este post


Link para o post
Compartilhar em outros sites
9 horas atrás, chattrbr disse:

Cara, na verdade o Virtio é um framework de I/O , ele é uma camada abstrata que emula dispositivos em paravirtualização. Logo ao utilizar o virtio como como controlador você terá um maior I/O resultando em um melhor desempenho. 

Para a configuração de seu servidor VPS em KVM, sugiro utilizar o virtio, com cache writeback e o IO como nativo, logo o dumpxml de sua instância deve ficar igual ao abaixo: 

<driver name='qemu' type='raw' cache='writeback' io='native'/>
<source dev='/dev/storage/instance-seuservidorvps_disk'/>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>

 

E o I/O scheduler como noop, pois é provável que seja criado como cfq que realiza um balanço entre leitura e escrita e irá conflitar com o do host que utiliza deadline. 

E caso achar que o desempenho ainda não esteja como o esperado, sugiro desativar o tickless kernel que pode causar um delay extra em certas situações, para isso basta adicionar na linha de comando do kernel localizado no grub.conf  o nohz=off 

Qualquer dúvida estou a disposição e boa virtualização! 

 

Bom dia

Muito obrigado pelas dicas. Ainda tenho algumas dúvidas pois como só tenho experiência em criar VM no Virtualbox, pegar uma ferramenta profissional é complicado.

Fiquei a madrugada inteira fazendo uns testes, para começar criamos um dos vps (sem habilitar o Virtio) e instalamos o cpanel trial. Então meu colega teve a "ideia" de migrar uma loja virtual opencart de em cliente dele que trabalha com venda de quentinhas e tem acessos e pedidos praticamente 24hrs por dia. Já imaginei que isso poderia dar m@#$%¨, mas já que o cliente é dele kkkk vamos la.

Resultado foi que após instalar o cpanel como o vps não tinha nenhum site o load ficava sempre em 0.2, 0.1, 0.0 etc. Então migrou o site do cliente dele, depois que propagou o load foi para 1.5, 5.7 teve horas que chegou a 9 isso durante a madrugada. Depois disso apontamos o site novamente para o antigo servidor. Será que isso foi por que não tem o Virtio?

Vamos criar a VM toda seguindo suas dicas, mas tenho uma dúvida em relação a esse cache do disco. Eu li no fórum oficial que o recomendado é usar no KVM o cache de disco default e que nesse tipo de cache writeback pode haver perda ou corromper dados em caso de falhas de hardware ou energia. Veja o link http://www.softaculous.com/board/index.php?tid=4953&title=Best_Config_KVM,_Benchmark_Disk_Speed Outra coisa que não entendi é que no final o membro da equipe do softaculous fala que se deixar cache em none, os porcessos i/o srão feitos na memória do vps. No caso cache na memória não seria mais rápido do que no disco?

Enfim, para criar o VPS novamente porém habilitando o Virtio estamos fazendo conforme imagem  http://prnt.sc/d01fwk  O que devemos selecionar em Disck Cache e I/O Policy?

Compartilhar este post


Link para o post
Compartilhar em outros sites
Em 28/10/2016 at 09:57, PedroHenrique disse:

Bom dia

Muito obrigado pelas dicas. Ainda tenho algumas dúvidas pois como só tenho experiência em criar VM no Virtualbox, pegar uma ferramenta profissional é complicado.

Fiquei a madrugada inteira fazendo uns testes, para começar criamos um dos vps (sem habilitar o Virtio) e instalamos o cpanel trial. Então meu colega teve a "ideia" de migrar uma loja virtual opencart de em cliente dele que trabalha com venda de quentinhas e tem acessos e pedidos praticamente 24hrs por dia. Já imaginei que isso poderia dar m@#$%¨, mas já que o cliente é dele kkkk vamos la.

Resultado foi que após instalar o cpanel como o vps não tinha nenhum site o load ficava sempre em 0.2, 0.1, 0.0 etc. Então migrou o site do cliente dele, depois que propagou o load foi para 1.5, 5.7 teve horas que chegou a 9 isso durante a madrugada. Depois disso apontamos o site novamente para o antigo servidor. Será que isso foi por que não tem o Virtio?

Vamos criar a VM toda seguindo suas dicas, mas tenho uma dúvida em relação a esse cache do disco. Eu li no fórum oficial que o recomendado é usar no KVM o cache de disco default e que nesse tipo de cache writeback pode haver perda ou corromper dados em caso de falhas de hardware ou energia. Veja o link http://www.softaculous.com/board/index.php?tid=4953&title=Best_Config_KVM,_Benchmark_Disk_Speed Outra coisa que não entendi é que no final o membro da equipe do softaculous fala que se deixar cache em none, os porcessos i/o srão feitos na memória do vps. No caso cache na memória não seria mais rápido do que no disco?

Enfim, para criar o VPS novamente porém habilitando o Virtio estamos fazendo conforme imagem  http://prnt.sc/d01fwk  O que devemos selecionar em Disck Cache e I/O Policy?

Isso pode está ligado a falta de otimização do servidor ou até mesmo da configuração do servidor.

Quais as especificações da VPS?

Existe algum tipo de otimização?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Cara, sim o writeback pode causar perda de dados, no entanto acredito que por se tratar de um ambiente de produção backup não será problema, correto? Backup do virtualizor, ou um NAS voltado para backup

Sugiro utilizar o writeback e o I/O policy como nativo, igual o dumpxml que informei acima. Em produção utilizamos o openstack com as configurações que lhe passei, writeback e native e possuímos mais de 800 servidores com kvm orquestrados pelo openstack e nunca tivemos problemas com desempenho. 

Quanto ao load de 9 é importante investigar a causa e trabalhar nela, acredito que por ser uma loja virtual possa ser o mysql ou os processos PHP, para isso sugiro verificar com o sar a causa, contudo acredito que seja o consumo de memória pelo mysql ou processos PHP. Para ver o consumo de memória na hora em que o load subir, sugiro verificar com o comando no link abaixo, tive que jogar para o paste pois o firewall do sucuri interpretava como exploit, ele irá mostrar o consumo de memória tabulado. 

https://pastecry.pt/htTDds#Deh3Rug1En2Yz4Hua6Ud9Ev8Ac

Compartilhar este post


Link para o post
Compartilhar em outros sites
1 hora atrás, Joel Emanoel disse:

Isso pode está ligado a falta de otimização do servidor ou até mesmo da configuração do servidor.

Quais as especificações da VPS?

Existe algum tipo de otimização?

Então, não sou experiente nesse assunto de VPS, mas eu acho que não tem a ver com otimização. Nós refizemos o mesmo teste hoje durante a manhã só que dessa vez criamos o VPS em Opennvz e para a surpresa o Load não passou de 1.7!

Eu tenho hoje dois VPS na Budgetvm, um openvz e outro Xen que eles nem vendem mais. O Openvz tem 1Core e 1GB de ram + Cpanel + 4 sites, no geral deve tem em torno de 2k hora e em momentos de pico o load vai em 3 e segura de boa. O Xen tem 56 sites, não sei ao certo a quantidade de acessos mas o load nunca passou de 2, na verdade só passa disso quando faz backup, ai chega em 3.5 - 3.8. Detalhes: os dois só tem otimização do MariaDB.

Voltando ao assunto do post, o dedicado que alugamos tem 4 cores e 4 threads + 32GB de ram, o VPS criado tem 2cores e 6GB. Essa configuração com KVM sem virtio e apenas com cache de disco em modo "defaut" ficou horrível, load altíssimo. A mesma configuração em Openvz foi de boa. AI bagunçou geral as nossas cabeças.

4 minutos atrás, chattrbr disse:

Cara, sim o writeback pode causar perda de dados, no entanto acredito que por se tratar de um ambiente de produção backup não será problema, correto? Backup do virtualizor, ou um NAS voltado para backup. 

Sugiro utilizar o writeback e o I/O policy como nativo, igual o dumpxml que informei acima. Em produção utilizamos o openstack com as configurações que lhe passei, writeback e native e possuímos mais de 800 servidores com kvm orquestrados pelo openstack e nunca tivemos problemas com desempenho. 

Quanto ao load de 9 é importante investigar a causa e trabalhar nela, acredito que por ser uma loja virtual possa ser o mysql ou os processos PHP, para isso sugiro verificar com o sar a causa, contudo acredito que seja o consumo de memória pelo mysql ou processos PHP. Para ver o consumo de memória na hora em que o load subir, sugiro verificar com o comando no link abaixo, tive que jogar para o paste pois o firewall do sucuri interpretava como exploit, ele irá mostrar o consumo de memória tabulado. 

https://pastecry.pt/htTDds#Deh3Rug1En2Yz4Hua6Ud9Ev8Ac

Então@chattrbr a possível perda de dados existe correto? Mas pera ai, pensado bem essa perda de dados não seria dos dados em cache referentes aos processos sendo executados?  Pois não faz sentido nenhum um processo de cache de disco corromper ou perder dados de arquivos ou sites salvos no VPS.

A loja em questão tem muitos acessos, mas é em Opencart e atualmente ele roda em um VPS Xenpv com 1 core e 2GB de ram.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Sim, por isso indiquei o virtio com writeback. 

Quanto ao openvz, o pessoal costuma falar mal sem conhecer corretamente. O desempenho do openvz pode ser superior ao KVM pois ele é uma "virtualização" a nível de SO, consumindo menos recursos do que um ambiente em "virtualização" completo. Pois ele não precisa executar diversos kernels pois ele compartilha um único kernel entre diversas VPS, logo o resultado é uma redução no consumo de memória e CPU. 

Esses 2 cores que você informa estão configurados como 200%? 

Desde 2014, utilizando writeback em mais de 800 servidores nunca tivemos problemas com perda de dados. 

O writeback é o famoso cache escreva de volta, configuração bastante utilizada em raid 0 para melhora de desempenho.

@PedroHenrique caso desejar conversar, me adiciona no skype ou manda mensagem no hangout chattrbr@gmail.com

 

 

Compartilhar este post


Link para o post
Compartilhar em outros sites
1 hora atrás, chattrbr disse:

Sim, por isso indiquei o virtio com writeback. 

Quanto ao openvz, o pessoal costuma falar mal sem conhecer corretamente. O desempenho do openvz pode ser superior ao KVM pois ele é uma "virtualização" a nível de SO, consumindo menos recursos do que um ambiente em "virtualização" completo. Pois ele não precisa executar diversos kernels pois ele compartilha um único kernel entre diversas VPS, logo o resultado é uma redução no consumo de memória e CPU. 

Esses 2 cores que você informa estão configurados como 200%? 

Desde 2014, utilizando writeback em mais de 800 servidores nunca tivemos problemas com perda de dados. 

O writeback é o famoso cache escreva de volta, configuração bastante utilizada em raid 0 para melhora de desempenho.

@PedroHenrique caso desejar conversar, me adiciona no skype ou manda mensagem no hangout chattrbr@gmail.com

 

 

Não tem limites do core deixamos 0. Se colocar em 200% certamente vai piorar. Não?

O dedicado tem discos em Raid 1.

Compartilhar este post


Link para o post
Compartilhar em outros sites
Em 29/10/2016 at 22:19, chattrbr disse:

200% irá utilizar os cores full, ou seja sem limitação.

Mas nesse caso fica na mesma, pois no Virtualizor informa que para ficar sem limites basta setar 0.

Não testamos corretamente o VPS mas criamos com cache writeback e io native, e agora a memória swap do dedicado ficou 100% utilizada!

Compartilhar este post


Link para o post
Compartilhar em outros sites

Participe da conversa

Você pode postar agora e se cadastrar mais tarde. Se você tem uma conta, faça o login para postar com sua conta.

Visitante
Responder

×   Você colou conteúdo com formatação.   Remover formatação

  Apenas 75 emojis são permitidos.

×   Seu link foi automaticamente incorporado.   Mostrar como link

×   Seu conteúdo anterior foi restaurado.   Limpar o editor

×   Não é possível colar imagens diretamente. Carregar ou inserir imagens do URL.


  • Quem Está Navegando   0 membros estão online

    Nenhum usuário registrado visualizando esta página.



O Portal do Host

Dicas para sua empresa de hospedagem. Artigos, notícias, tutoriais e os aspectos da indústria de hospedagem.

Limestone Networks

A LSN tem sido parceira e patrocinadora do PDH, fornecendo uma plataforma segura e confiável.

Cloud - Servidores decicados - Co-location
×
×
  • Criar Novo...