A micro instância do Amazon EC2 possui 100% de uso da CPU

Minha micro instância do Amazon EC2 tem 100% de uso da CPU com muita frequência. Eu só tenho uma instalação wordpress nele. Ainda estou no modo de produção, então não há usuários, mas recebo 100% de uso da CPU.

Alguém sabe como reduzi-lo? Recebo notificações do Amazon Email a cada hora por causa disso que dura mais de 300 segundos.

Eu já mudei meu banco de dados para o RDS, mas não resolvi esse problema. Apenas tornou um pouco melhor. Antes de mudar para o RDS com meu banco de dados, meu site sempre falhou totalmente ao carregar apenas uma página da web.

Meu mysqld.log dá um erro errno 12, por isso eu também fiz innodb_buffer_pool_size = 256M no my.cnf, mas não trouxe nada.

Ficaria grato por cada dica.

amazon-ec2 central-processing-unit

— Jaba L
fonte

você precisa monitorar sua instância para ver o que está acontecendo. Você não diz qual sistema operacional está usando, mas se o Linux é rápido e fácil, ele é o melhor. A longo prazo, você deve considerar outra coisa.

— user9517

No comando linux top, que processo está consumindo sua CPU. Pressione (Shift + P) para classificar os processos de acordo com a utilização da CPU Thanks Sandeep

— ZVIK

Obrigado @lian! Sim, eu estou usando Linux. Portanto, é normal que muitas vezes suba até 100% da CPU? Já estou monitorando-o com um alarme e recebo essas notificações de alarme irritantes por e-mail algumas vezes por dia. Você quer dizer que o Ec2 não vale a pena, especialmente não com pacotes pequenos apenas quando se investe muito? Obrigado pela sua ajuda

— Jaba L

Obrigado @ZVIK pela sua ajuda! Poderia explicar um pouco mais detalhadamente. Acho que ainda não entendi direito. Onde posso pressionar (Shift + P). Na linha de comando SSH? Desculpe pela minha inexperiência. Outra coisa que parece é que meu terminal SSH fica muito lento depois de um tempo. Digitar um comando ssh e obter uma resposta às vezes leva muito tempo, é muito atrasado. Eu acho que é por causa do uso da CPU também. Somente reiniciando com os comandos "sudo service httpd stop / start" e "sudo service mysqld restart" eu consigo rodar mais rápido novamente. Mas isso não dura muito.

— Jaba L

@Jaba LI suponha que haja um vazamento de memória no código

— ZVIK

Respostas:

Lembre-se de que as m2.microinstâncias são apenas isso - são pequenas. Qualquer quantidade real de carga irá maximizá-los.

Como @zvik apontou em seus comentários, você deve descobrir quais processos estão consumindo mais memória e / ou ciclos de CPU. Ele recomendou a execução top, que é um comando encontrado nas distribuições Linux. Ao pressionar Shift-P, ele os classificará com base no uso da CPU. Você precisará usar essas informações para descobrir onde está o gargalo. Por exemplo, se estiver executando o Apache, a configuração padrão do Apache pode ser iniciar mais processos do que o servidor é capaz.

Tente executar tope ver quais comandos estão consumindo mais recursos.

— Andrew M.
fonte

Eu verifiquei e o Apache está aproveitando ao máximo os recursos. m2.micro realmente é carregado com tanta facilidade. Eu pensei que poderia usar micro para um pequeno local de produção, mas isso é infelizmente possível. Obrigado pela sua ajuda

— Jaba L

Na verdade, seu problema pode estar relacionado ao "roubo de CPU", que ocorre na pilha da Amazon (e, de fato, em qualquer infraestrutura virtualizada). Você pode ler mais sobre roubo de CPU aqui .

Essencialmente, sua VM está ociosa e a Amazon está "emprestando" alguns dos ciclos de sua CPU para dar a alguém que precisa dela - essa é uma prática padrão para um ambiente virtualizado em que os recursos físicos do servidor, como o uso de RAM e os ciclos de CPU, geralmente são comprometidos demais. .

Para verificar se há roubo de CPU, execute tope observe o %stvalor destacado aqui:

saída do comando top

Se esse valor for diferente de zero, significa que os ciclos de CPU da sua VM estão sendo "emprestados".

— Craig Watson
fonte

Muito obrigado @ craig-watson pela sua resposta. Acabei de verificar% st e está entre 0 e 5%. Obrigado pelo link também foi muito informativo

— Jaba L