Compreender e verificar os limites do CloudLinux LVE na hospedagem partilhada

O que limita um LVE no alojamento partilhado

Na hospedagem partilhada, vários clientes partilham os recursos de um servidor. O CloudLinux permite monitorizar a utilização de uma conta de cliente com um Ambiente Virtualizado Leve, abreviado LVE. O fornecedor define quais são os limites aplicáveis. Estes destinam-se a impedir que uma conta consuma recursos de forma ilimitada; por outro lado, o próprio site também pode atingir esses limites.

Um limite descreve um valor máximo e não significa automaticamente um serviço reservado. Um limite de CPU, por exemplo, não significa que um núcleo do processador te pertença em exclusivo nem que te seja garantido um determinado tempo de resposta. A velocidade com que uma aplicação funciona depende também da sua tarefa, do hardware e de outros componentes.

Um LVE também não transforma o teu pacote de alojamento num servidor próprio. O fornecedor continua a gerir o ambiente partilhado e a determinar a sua configuração. Enquanto cliente, só podes verificar os valores aplicáveis e as suas consequências na medida em que o teu plano e o painel de alojamento disponibilizem as informações correspondentes.

É preciso distinguir isto de CageFS: Trata-se do isolamento da visão do sistema de ficheiros, enquanto os limites LVE restringem a utilização dos recursos. Ambas as funções podem complementar-se, mas não são a mesma coisa. O fornecedor poderá confirmar quais os componentes que estão efetivamente ativos na tua oferta.

Podes encontrar uma análise mais aprofundada dos componentes no artigo sobre a Isolamento de processos com o CloudLinux SecureLVE. No entanto, para a resolução concreta de problemas, a configuração do teu próprio pacote é determinante: a interface e o nível de detalhe da visualização dos recursos podem variar consoante o painel e a ativação.

A quem se aplicam os limites?

O que é decisivo não é apenas o valor de um limite, mas também o seu Âmbito de aplicação. Se, por exemplo, gerires um blogue e uma loja na mesma conta de alojamento, ambos podem utilizar o mesmo orçamento de recursos numa configuração associada à conta. Uma importação na loja pode, então, ocupar capacidade de que o blogue também necessita ao mesmo tempo.

Isso não significa que cada página lenta seja causada por outro projeto na conta. No entanto, explica por que razão, num evento limite, não se deve considerar apenas o domínio afetado nesse momento. Também as tarefas agendadas e outros sites da mesma conta podem ser relevantes no período em questão.

A CloudLinux documenta com Isolados Além disso, existe a possibilidade de definir limites ao nível do site. A designação «CloudLinux», por si só, não permite determinar se esta funcionalidade é utilizada nem como é que a sua aplicação se traduz na oferta em questão. Por isso, mesmo uma análise isolada não substitui a consulta das condições específicas do plano.

Antes de comparar planos, pergunta ao fornecedor da forma mais concreta possível: os valores de SPEED, PMEM, IO, IOPS, EP e NPROC aplicam-se por conta de alojamento ou por site? Se vários projetos partilharem um orçamento, é também importante saber quais os domínios e tarefas que estão atribuídos a esse orçamento. Desta forma, evita-se incluir acidentalmente um valor indicado para cada site individualmente.

Caso o painel apresente apenas uma estatística agregada, esta ajuda, numa primeira fase, a delimitar o período, mas não necessariamente a atribuir os dados a uma aplicação específica. Nesse caso, solicite ao apoio técnico informações sobre quais as discriminações disponíveis e se a carga pode ser atribuída a um projeto ou a uma tarefa.

Distinguir entre CPU, memória e limites de acesso

Os vários limites da hospedagem partilhada restringem diferentes tipos de atividades. VELOCIDADE refere-se ao orçamento da CPU: se for esgotado, os processos que exigem muito poder de cálculo são limitados e as solicitações podem demorar mais tempo. Um limite de CPU na hospedagem é, portanto, apenas uma possível explicação para páginas lentas, não sendo sinónimo de todos os limites do LVE.

O PMEM limita a memória física do LVE. Em caso de pressão na memória, pode-se, em primeiro lugar, libertar a memória cache; se isso não for suficiente, os processos podem ser encerrados. Este valor deve ser distinguido do valor obsoleto VMEM, relativo à memória virtual. Da mesma forma, o PHP-memory_limit não deve ser equiparado ao orçamento total do PMEM do LVE.

No acesso a ficheiros, os parâmetros IO e IOPS medem aspetos diferentes: o IO diz respeito ao débito de dados, enquanto o IOPS se refere ao número de operações de leitura e escrita por segundo. Por isso, muitos ficheiros pequenos podem atingir um limite diferente do que alguns ficheiros grandes. Neste contexto, o IO não se refere à velocidade da tua ligação à Internet.

O EP conta as entradas no LVE e não constitui um limite geral para o número de visitantes simultâneos. A forma como as entradas são contadas depende, entre outros fatores, do servidor web e do modelo de processo. NPROC Por outro lado, limita os processos e os threads. Quando este limite é atingido, não é possível criar mais processos temporariamente; por isso, o EP e o NPROC não são intercambiáveis.

O espaço de armazenamento e os inodes são parâmetros de tarifação relacionados, mas distintos. Uma quota de ficheiros esgotada ou um limite de inodes atingido não constituem automaticamente um problema de CPU, PMEM ou EP. Os valores que podes ver no painel dependem do fornecedor e da interface disponibilizada.

Visão geral dos limites LVE e das suas consequências

Os limites LVE não funcionam todos da mesma forma: alguns travam o trabalho em curso, outros impedem novos processos ou podem encerrar processos existentes. A tabela ajuda-te a associar um recurso apresentado ao seu comportamento e a uma pista de auditoria adequada. Os valores-limite concretos são definidos pelo teu fornecedor.

Em Limite do PMEM Não é apenas a memória dos processos de aplicações individuais que conta. A memória partilhada e a cache de ficheiros também podem ser tidas em conta; o facto de a cache ser contabilizada depende da configuração. Quando os processos são encerrados, podem ocorrer erros HTTP, mas isso não é necessariamente a consequência visível.

Os dois limites de acesso aos ficheiros referem-se a dimensões diferentes: IO limita a taxa de transferência de dados, enquanto as IOPS limitam o número de operações. Por isso, muitos ficheiros pequenos podem, sobretudo, sobrecarregar as IOPS, enquanto os ficheiros grandes podem gerar uma elevada taxa de transferência. Aqui, «IO» não se refere à largura de banda da rede; segundo o CloudLinux, os acessos a partir da cache de ficheiros não contam para o limite de IO.

Calcular o limite da CPU com base num exemplo

Suponhamos que a tua encomenda tivesse um Limite de velocidade de 150 por cento. Uma vez que 100 por cento correspondem, em termos matemáticos, a um núcleo do processador, isso resulta num orçamento de CPU equivalente a um núcleo e meio. Exemplo de cálculo ilustrativo, não se trata de uma medição. O valor real do teu pacote pode ser diferente; o que prevalece é a informação fornecida pelo fornecedor.

Este exemplo descreve um limite máximo para o tempo de CPU utilizável, não uma reserva de um núcleo exclusivo. Também não significa que cada processo possa utilizar um núcleo e meio em simultâneo. A forma como o orçamento se distribui pelo trabalho em execução depende, entre outros fatores, do número de processos que necessitam efetivamente de tempo de computação em paralelo.

Um valor de 150 por cento não implica nem um tempo de resposta garantido nem um número específico de visitantes que possam ser atendidos simultaneamente. Uma chamada simples pode exigir pouca capacidade de processamento, ao passo que uma chamada dinâmica pode exigir significativamente mais. A isto acrescentam-se possíveis tempos de espera para o acesso a ficheiros ou para operações na base de dados, que um maior orçamento de CPU não elimina automaticamente.

Mesmo valores percentuais iguais em servidores diferentes não constituem uma comparação direta de velocidade: os núcleos do processador podem diferir em termos de desempenho. Para avaliar o teu limite de CPU, é, por isso, mais importante verificar se a utilização, durante um problema específico, se situa repetidamente no limite e se são visíveis eventos de limite correspondentes. Mesmo nesse caso, deves verificar outras causas possíveis.

Como interpretar corretamente a indicação de recursos

Caso o teu fornecedor tenha ativado a visualização de recursos, começa por identificar um incidente o mais específico possível. Anota o domínio, a data, a hora e o fuso horário, bem como, se for o caso, o estado HTTP apresentado. Descreve também o que estava lento ou falhou. Sem estas informações, é difícil associar um pico nas estatísticas a um problema específico.

Em seguida, selecione o mesmo período no ecrã e compare, para CPU, PMEM, IO, IOPS, EP e NPROC, respetivamente, a utilização, o limite definido e, se for o caso, os valores apresentados Falhas. Nem todas as interfaces apresentam os mesmos valores. Se faltar alguma estatística ou se não for claro a que conta se refere, consulta o fornecedor.

Presta atenção ao Resolução temporal: Um valor médio por hora baixo pode ocultar um pico de curta duração em que se atingiu um limite. Se estiver disponível, opta por um período de tempo mais curto ou por uma representação mais detalhada. Compara o pico com o tempo de erro registado, em vez de concluir, apenas com base numa média diária ou horária, que não houve um estrangulamento.

As falhas indicam eventos limite, mas não constituem uma contagem direta dos visitantes afetados ou das visualizações de páginas que falharam. Uma falha ocorrida num momento oportuno constitui uma indicação, mas não uma prova conclusiva da causa. Por isso, verifica também se, ao mesmo tempo, se realizou uma importação, uma cópia de segurança, uma tarefa agendada ou uma alteração na aplicação.

A interface e as suas funções dependem do painel e da ativação; por isso, não existe um caminho de menu universal. Para conhecer os aspetos técnicos da gestão, consulte o artigo sobre o CloudLinux LVE Manager e para a gestão de recursos Mais informações. No entanto, os passos de configuração administrativa aí descritos pressupõem a existência dos direitos de acesso adequados e não estão automaticamente disponíveis na tua conta de cliente.

Classificar páginas lentas e erros

Se o teu CMS estiver lento durante a edição ou nas visualizações dinâmicas de páginas, compara primeiro o período em questão com o indicador da CPU. Se a utilização se situar repetidamente no limite de SPEED e forem visíveis erros correspondentes, é necessário um Limitação da CPU plausível. A coincidência temporal torna-a um indício, mas ainda não prova qual foi a causa dessa carga.

Verifica, por exemplo, se há tarefas agendadas para a mesma hora a serem executadas ou se uma alteração nas extensões coincide com o problema. Também o trabalho com bases de dados, problemas de rede ou uma interface externa com resposta lenta podem causar atrasos nas páginas. Por isso, uma elevada utilização da CPU, por si só, não significa que o plano tenha sido mal escolhido, nem que uma determinada extensão seja necessariamente a culpada.

Se ocorrerem erros quando várias solicitações dinâmicas chegam simultaneamente, pode ocorrer um Falha no EP ajudar. As solicitações de longa duração mantêm as entradas ocupadas por mais tempo; ao mesmo tempo, um visitante pode gerar várias solicitações. O EP não é, portanto, uma contagem de visitantes. No Apache, o código de estado HTTP 508 é uma possível consequência da ultrapassagem do limite de EP, mas o código de estado, por si só, não comprova a causa.

Se, durante uma importação, o ecrã apresentar erros PMEM, o limite de memória do LVE pode ser a causa. Para além da importação, os processos PHP em execução simultânea podem ocupar memória; sem os dados de processo adequados, não é possível determinar qual foi a tarefa que causou o problema. Um erro HTTP 500 ou 503 também pode ter outras causas e, por si só, não constitui prova de falta de memória.

O valor PHP memory_limit Isto, por si só, não responde à pergunta: não descreve a utilização total da memória de todas as tarefas no LVE. Por isso, compara a hora da importação com a utilização de PMEM e as falhas e regista quais as outras tarefas que estavam a ser executadas em paralelo antes de alterares uma configuração ou a tarifa.

Verificar a carga de fundo e recorrer ao apoio técnico

Se um backup ou uma importação de ficheiros estiver a demorar, considere IO e IOPS separadamente. O IO limita o débito de dados nos acessos a discos rígidos, enquanto o IOPS indica o número de operações de leitura e escrita por segundo. Por isso, muitos ficheiros pequenos podem exigir um limite diferente do que a transferência de poucos ficheiros de grande dimensão; o IO não corresponde, neste contexto, à largura de banda da Internet.

Uma cópia de segurança pode exigir, simultaneamente, recursos da CPU e da memória. Por isso, além do IO e do IOPS, verifica também o SPEED e o PMEM para o mesmo período, em vez de deduzir a causa apenas com base na duração. Se os acessos forem atendidos a partir da cache de ficheiros, estes não contam para o limite de IO, de acordo com o CloudLinux; assim, a utilização de IO apresentada não descreve todos os acessos a ficheiros da mesma forma.

Se for possível adiar uma tarefa planeada, compare a sua execução normal numa fase menos ocupada com um período anterior semelhante. Tenha em conta o volume e as tarefas em execução paralela: uma importação de menor dimensão não é uma comparação direta com uma cópia de segurança completa. Não são necessários testes de carga produtivos adicionais nem a eliminação de ficheiros para esta avaliação.

O Carga da base de dados pode ter importância, mesmo que a utilização da CPU web apresentada seja baixa. A sua atribuição à conta e os eventuais limites separados do MySQL dependem da configuração. Pergunta ao fornecedor quais os valores da base de dados que podes ver no painel e se a atividade da base de dados é contabilizada no LVE ou se é limitada separadamente.

Para uma solicitação de suporte, é útil indicar o domínio, a hora com o fuso horário, o estado HTTP observado e o processo afetado. Acrescente os limites, valores de utilização e falhas visíveis no mesmo período, bem como importações ou cópias de segurança conhecidas. Solicite a identificação dos eventos que atingiram os limites e, se disponível, uma análise dos instantâneos do processo; desta forma, é possível verificar a hipótese de forma mais específica.

Otimizar, atualizar ou mudar de servidor?

Começa pela Otimização de uma tarefa identificada, caso seja possível reduzir de forma compreensível as suas necessidades de recursos. Verifique, por exemplo, as definições da cache, as extensões e as tarefas em segundo plano planeadas em paralelo. Em seguida, compare períodos semelhantes e preste atenção tanto aos problemas dos utilizadores como aos valores dos recursos afetados. Uma alteração única torna mais fácil identificar o que realmente mudou.

Uma atualização é uma alternativa quando os picos recorrentes e comprovados atingem os limites atribuídos, apesar de uma otimização adequada. Informe-se previamente sobre os valores concretos para SPEED, PMEM, IO, IOPS, EP e NPROC. Não se limite a comparar os nomes dos pacotes: um limite de CPU mais elevado não elimina nem um limite de EP existente de forma independente, nem uma falta de memória LVE.

Para o Comparação de tarifas Isso também faz parte do âmbito de aplicação. Informa o fornecedor sobre quantos sites a tua conta inclui e pergunta se utilizam um orçamento comum de recursos ou se existem limites por site. O CloudLinux oferece, com o Isolates, uma opção para esta última situação; no entanto, o nome do produto, por si só, não indica que o teu plano o utilize.

Um VPS ou um servidor gerido pode oferecer maior flexibilidade, mas não é uma solução automática para todos os sites lentos. Os fatores decisivos são os recursos disponíveis, a carga real e o modelo de funcionamento: no caso de um VPS, tens de esclarecer, em particular, quais as tarefas administrativas que irás assumir; no caso de um servidor gerido, quais as tarefas que o fornecedor irá assumir.

Se a causa permanecer por esclarecer, faz mais sentido consultar os dados recolhidos relativos aos momentos e às falhas do que proceder a uma mudança por mero suspeita. Mesmo abaixo de um limite de LVE, a aplicação, a rede ou a base de dados podem causar lentidão. Antes de tomares uma decisão, confirma quais as estatísticas e o apoio disponíveis na respetiva oferta.