Em 9 de julho de 2013 10:38, Luiz Carlos L. Nogueira Jr. <
[email protected]> escreveu:

>
> (i) quanto de swap você tem?
> *free -m
>              total       used       free     shared    buffers     cached
> Mem:         32110      16735      15374          0         31       9884
> -/+ buffers/cache:       6819      25290
> Swap:         2559         11       2548
> *


Este valor de Swap é um pouco baixo. Eu costumo pensar em pelo menos 50% da
RAM disponível. Não é um pecado grava, mas seria bom ter pelo menos 16GB.
Veja, que se você tiver um surto de conexões encavalando de repente... a
quantidade de memória utilizada por conexão pode fazer o consumo aumentar
muito de repente.


> **
>
>
>
> (ii) qual o resultado de EXPLAIN ANALYZE da consulta?
>
> (iii) qual a saída do comando
>
> ulimit -s
>
> *10240
> *
>
>
> (iv) qual o valor do parâmetro vm.swapiness?
>
>
> sysctl vm.swappiness
>
> *vm.swappiness = 60*
>
>
> (v) qual a saída do comando
>
> cat /proc/meminfo
>
> *MemTotal:       32880848 kB
> MemFree:        15200452 kB
> Buffers:           32868 kB
> Cached:         10172808 kB
> SwapCached:         1164 kB
> Active:          9905792 kB
> Inactive:        6899428 kB
> Active(anon):    8541080 kB
> Inactive(anon):  1672148 kB
> Active(file):    1364712 kB
> Inactive(file):  5227280 kB
> Unevictable:           0 kB
> Mlocked:               0 kB
> SwapTotal:       2621424 kB
> SwapFree:        2609624 kB
> Dirty:              2120 kB
> Writeback:             0 kB
> AnonPages:       6592876 kB
> Mapped:          3573064 kB
> Shmem:           3613776 kB
> Slab:             153124 kB
> SReclaimable:      93848 kB
> SUnreclaim:        59276 kB
> KernelStack:        3480 kB
> PageTables:       352516 kB
> NFS_Unstable:          0 kB
> Bounce:                0 kB
> WritebackTmp:          0 kB
> CommitLimit:    19061848 kB
> Committed_AS:   13609336 kB
> VmallocTotal:   34359738367 kB
> VmallocUsed:      328592 kB
> VmallocChunk:   34359340400 kB
> HardwareCorrupted:     0 kB
> AnonHugePages:   3411968 kB
> HugePages_Total:       0
> HugePages_Free:        0
> HugePages_Rsvd:        0
> HugePages_Surp:        0
> Hugepagesize:       2048 kB
> DirectMap4k:       10240 kB
> DirectMap2M:    33544192 kB
> *


Aqui parece Ok. Mas o importante é saber como isto está momentos antes da
queda e logo depois da queda. Quando eu quero investigar isso e não tenho
uma ferramenta descente de monitoramento, eu deixo um JOB coletando isso
direto de X em X segundos.

>
> (vi) além do erro da alocação de memória, aparece alguma mensagem
> próximo a ela indicando a queda de um processo servidor ou mesmo algum
> outro erro relevante a questão? Algo como
>
> terminating connection because of crash of another server process
> ou traduzindo
> finalizando conexão por causa de uma queda de um outro processo servidor
>
> *Não*


Minha recomendação, para garantir que o processo server não caia é usar o
-DLINUX_OOM_SCORE_ADJ=0

Vide:
http://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT


-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// <http://www.midstorm.org/~telles/>s<http://tellesr.wordpress.com/>
avepoint.blog.br
e-mail / gtalk / MSN: [email protected]
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres
http://www.timbira.com.br
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a