memória do servidor ocupada quase até 8GB

Question

Ultimamente, nosso servidor enfrenta problemas com a memória. Iniciado há algumas semanas, nosso servidor estava carregando muito lento. Acessando e-mails e sites foram realmente demorar muito. Em seguida, pedimos ao suporte técnico do servidor para reiniciar o servidor para nós. Após a reinicialização, as coisas voltaram ao normal. Nós pensamos que era hora de atualizar a memória RAM. Originalmente, temos apenas 2GB de RAM em nosso servidor, portanto atualizamos em 8GB.

Achamos que o problema foi resolvido. No entanto, depois de atualizar a RAM, o uso da memória foi ficando cada vez maior. Era como sempre chegar ao seu uso máximo (ex. 456,5 MB livre de 7,8 GB de memória). No dia seguinte, o servidor estava totalmente desligado, e tivemos que pedir ao suporte técnico para reiniciar o servidor para nós novamente. Toda vez que enfrentamos o problema, temos que pedir à equipe de suporte para reiniciar o servidor para nós. De acordo com a equipe de suporte, se eles tiverem acesso ao SQL, a memória voltará ao normal. Mas se eles voltarem, a memória ficará mais alta novamente. Então, eles suspeitam que o problema é com a consulta SQL.

Eu quero perguntar, é realmente a consulta SQL que dá o problema? Ou foi o problema de hardware? Se é o SQL, como sei que tipo de consultas que ocupam uma memória tão grande? Como posso verificar isso? Nosso servidor está executando os detalhes abaixo:

OS: Linux 2.6.18
CPU: GenuineIntel, Intel(R)Xeon(R)CPU W3550 @ 3.07GHz
Average Load: 808.18;674.21;587.18
database records: 421,031 with 58 tables

Consultar estatísticas que posso fornecer do PHPMyAdmin:

select  314 k   11.98 k 66.37%
set option  34 k    1,296.59    7.18%
show fields 19 k    712.00  3.94%
update  16 k    620.61  3.44%
alter table 16 k    610.32  3.38%
change db   15 k    569.08  3.15%
insert  15 k    560.20  3.10%
show variables  11 k    434.01  2.40%
show tables 9,752   371.66  2.06%
begin   7,172   273.33  1.51%

resultado da realização de 'top':

top - 15:20:07 up 1 day,  6:13,  1 user,  load average: 497.30, 512.17, 542.15
Tasks: 7743 total,   5 running, 7738 sleeping,   0 stopped,   0 zombie
Cpu(s): 23.9%us, 50.9%sy,  0.1%ni, 25.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8173372k total,  8048380k used,   124992k free,  1816952k buffers
Swap:  2096376k total,      216k used,  2096160k free,   533876k cached

Espero que alguém possa me dar alguns conselhos, já que enfrento este problema há algum tempo e não tenho ninguém que possa pedir orientação. Obrigado antecipadamente.

update: dmesg

CPU5: Temperature above threshold, cpu clock throttled
CPU7: Temperature/speed normal
CPU2: Temperature/speed normal
CPU6: Temperature/speed normal
CPU1: Temperature above threshold, cpu clock throttled
CPU3: Temperature/speed normal
CPU0: Temperature/speed normal
CPU4: Temperature/speed normal
CPU6: Temperature/speed normal
CPU5: Temperature/speed normal
CPU1: Temperature/speed normal
CPU2: Temperature/speed normal
CPU4: Temperature/speed normal
CPU7: Temperature/speed normal
CPU0: Temperature/speed normal
CPU3: Temperature/speed normal
brute[19592]: segfault at 0000000000000028 rip 00000000080a592f rsp 00000000ffae3a28 error 6
brute[19539]: segfault at 0000000000000028 rip 00000000080a592f rsp 00000000ffae3a28 error 6
CPU2: Temperature/speed normal
CPU4: Temperature/speed normal
CPU7: Temperature/speed normal
CPU1: Temperature/speed normal
CPU5: Temperature/speed normal
CPU3: Temperature/speed normal
CPU6: Temperature/speed normal
CPU0: Temperature/speed normal
CPU0: Temperature/speed normal
CPU7: Temperature/speed normal
CPU6: Temperature/speed normal
CPU1: Temperature/speed normal
CPU2: Temperature/speed normal
CPU3: Temperature/speed normal
CPU5: Temperature/speed normal
CPU4: Temperature/speed normal
brute[21368]: segfault at 0000000000000000 rip 0000000008048f03 rsp 00000000ffb82db0 error 4

resultado TOP de hoje:

top - 10:42:47 up 3 days,  1:35,  1 user,  load average: 4.35, 4.53, 4.59
Tasks: 187 total,   5 running, 182 sleeping,   0 stopped,   0 zombie
Cpu(s): 12.7%us, 38.5%sy,  0.0%ni, 48.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8173372k total,  7800156k used,   373216k free,  1653768k buffers
Swap:  2096376k total,      216k used,  2096160k free,  2723732k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27913 consulti  25   0 31096 3700 1172 R 100.2  0.0   1484:40 perl
27916 consulti  25   0 31096 3732 1204 R 100.2  0.0   1051:59 perl
28213 consulti  25   0 31096 3736 1204 R 100.2  0.0   1073:30 perl
28210 consulti  23   0 31096 3740 1204 S 86.9  0.0   1016:23 perl
 3205 mysql     15   0  333m  55m 5416 S 13.6  0.7 143:36.73 mysqld
14616 apache    15   0  333m  33m 6056 S  4.7  0.4   1:02.12 httpd
25104 consulti  18   0 31096 3732 1204 R  4.7  0.0 486:12.74 perl
 2702 root      15   0 12744 1148  808 R  0.3  0.0   0:00.01 top
    1 root      15   0 10352  696  588 S  0.0  0.0   0:01.62 init
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.07 migration/0
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.07 ksoftirqd/0
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/1
    6 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/1
    7 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/1
    8 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/2
    9 root      34  19     0    0    0 S  0.0  0.0   0:00.02 ksoftirqd/2
   10 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/2
   11 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/3
   12 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/3
   13 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/3
   14 root      RT  -5     0    0    0 S  0.0  0.0   0:00.05 migration/4
   15 root      34  19     0    0    0 S  0.0  0.0   0:00.01 ksoftirqd/4
   16 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/4
   17 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/5

    

Answer 1

Em primeiro lugar, como alguns outros nos comentários, estou muito preocupado com os processos minerd e brute . Um pequeno trabalho de detetive do Google mostra que esses nomes estão associados à mineração de bitcoins e geração automatizada de tráfego de rede (como em: um nó em um ataque DDoS), respectivamente, indicando que outra pessoa pode estar usando seu servidor para seus próprios propósitos.

Tire isso do caminho (e, por favor, corrija isso rapidamente), e você também pode melhorar as coisas com um pequeno ajuste de banco de dados. Dada a análise postada por RandomSeed de que você provavelmente tem RAM não usada e, ao invés disso, está aguardando no disco, e a nota que você adicionou RAM para o servidor sem comentar sobre quaisquer outras alterações, eu suspeito que o seu buffer pool do MySQL é muito pequeno.

Isso se resume ao ajuste de desempenho do servidor de banco de dados 101: os discos são lentos, a memória é rápida. Bancos de dados gostam de pré-carregar ou armazenar dados e índices na memória, a fim de reduzir a necessidade de ir para o disco rígido mais lento. O MySQL tem algumas configurações que controlam a quantidade de dados que podem ser armazenados em cache. Se você adicionar memória ao servidor, mas não alterar essas configurações, isso ajudará um pouco, garantindo que outros processos (não MySQL) tenham RAM suficiente, mas isso não ajudará muito o desempenho do banco de dados ; você também precisa informar ao MySQL sobre a nova memória que você adicionou.

Então, como fazer isso? No caso do MySQL, é um pouco complicado, porque o MySQL suporta vários mecanismos de armazenamento. Você provavelmente está usando InnoDB, mas também pode ter MyISAM, ou até mesmo uma mistura dos dois para diferentes tabelas. Infelizmente, sem saber que tabelas usam o mecanismo de armazenamento e (se houver um mix) com quais tamanhos e volumes de consulta, é difícil informar com precisão sobre como alterar sua configuração do MySQL.

    

Answer 2

Seu problema não é vinculado à RAM (não mais):

• você tem cerca de 2,5 GB de RAM "disponível" (124992k livres + 1816952k buffers + 533876k em cache)
• seu swap é dificilmente usado (216k usado)

No entanto, provavelmente não era o caso antes de você atualizar para 8 GB.

Agora é provável que esteja ligado a E / S, e o MySQL é provavelmente o culpado ::

• a média da carga é desastrosamente alta (média da carga: 497,30, 512,17, 542,15)
• 58 minutos de tempo de CPU (TIME 57:59) vs 1 dia de tempo de atividade do sistema (acumulando 1 dia, 6:13)

A causa mais comum para uma consulta aparentemente intensa da CPU é muito tempo na espera de E / S (isto é, leitura de dados do disco). Tais consultas normalmente não possuem indexação de pop-up e / ou extraem muitos dados.

Agora, você precisa determinar quais são essas consultas. Um bom ponto de partida é monitorar seu tempo de execução .

    

Answer 3

De sua descrição, acho que seu sistema está trocando. Você provavelmente precisará diminuir algumas alocações de memória configuradas em /etc/my.cnf

Você pode ver quais processos estão usando a memória física executando:

ps aux --sort=-rss|head -10