All perguntas(dba)

Alguém pode resolver minhas dúvidas abaixo sobre o pg_stat_activitypostgres 9.5?

1. Alguns podem me informar o que significa o state IDLEdenota na linha de pg_stat_activity? É como verificar todas as conexões abertas para o postgres e se a conexão não estiver executando nenhuma consulta, IDLEdenota a última consulta executada pela conexão?
2. Na saída de select * from pg_stat_activityestou vendo linhas com state IDLEe com query_start_datemais de 2 dias? O que isso significa? Eu deveria me preocupar com isso?
3. Alguém pode me informar como pg_stat_activity é preenchido? Se estou executando uma consulta Select * from pg_stat_activity, ela produz os detalhes de algum instantâneo mantido pelo postgres ou verifica as conexões atuais abertas no postgres para fornecer os detalhes?

Existem muitos sinalizadores de rastreamento por aí. Alguns estão bem documentados, outros não, e outros chegaram ao status de comportamento padrão na versão 2016. Além dos canais de suporte oficiais, funcionários da Microsoft, etc., quais são as maneiras de encontrar novos sinalizadores de rastreamento?

Eu li algumas postagens recentes de Aaron Bertrand aqui e aqui , mas não vi nada sobre os novos sinalizadores de rastreamento.

Copiei os dados e o arquivo de log do mssqlsystemresource para um novo local e anexei-o como um banco de dados regular para vasculhar as tabelas e exibições do sistema, mas não localizei nada imediatamente. Considerei pegar uma lista de sinalizadores de rastreamento conhecidos e percorrer os números que não estão nessa lista para ver quais DBCC TRACEON permitiria, mas queria fazer a pergunta aqui primeiro.

Supondo que o comando DBCC para habilitá-los tenha que fazer check-in com algum recurso para garantir que o sinalizador de rastreamento seja válido, para onde ele chega? Existe um .dll ou algum outro arquivo de sistema que contenha uma lista?

Eu sei que a pergunta lança uma rede ampla, mas o que estimulou isso foi ler sobre um sinalizador de rastreamento com comportamento pretendido específico ao lado de um novo recurso em 2016 que não estava tendo o efeito descrito. Meu pensamento inicial foi que talvez os números tenham sido transpostos de alguma forma, como 7129 se tornando 7219. Eu esperava obter uma lista de sinalizadores de rastreamento válidos dentro de um intervalo, digamos 7000-7999, para procurar permutações. Testar todos eles, como sinalizadores DBCC TRACEON e parâmetros de inicialização, seria um incômodo, combinado com o teste dos resultados em relação ao comportamento do recurso.

Quando executo o código a seguir, leva 22,5 minutos e faz 106 milhões de leituras. No entanto, se eu executar apenas a instrução de seleção interna por si só, levará apenas 15 segundos e fará 264k leituras. Como observação, a consulta de seleção não retorna nenhum registro.

Alguma ideia de por que o IF EXISTSfaria funcionar por muito mais tempo e fazer muito mais leituras? Eu também mudei a instrução select para fazer SELECT TOP 1 [dlc].[id]e a matei após 2 minutos.

Como uma correção temporária, alterei para fazer um count(*) e atribuir esse valor a uma variável @cnt. Em seguida, ele faz uma IF 0 <> @cntdeclaração. Mas eu pensei EXISTSque seria melhor, porque se houvesse registros retornados na instrução select, ele pararia de executar o scan/seeks assim que encontrasse pelo menos um registro, enquanto o count(*)concluiria a consulta completa. o que estou perdendo?

IF EXISTS
   (SELECT [dlc].[ID]
   FROM TableDLC [dlc]
   JOIN TableD [d]
   ON [d].[ID] = [dlc].[ID]
   JOIN TableC [c]
   ON [c].[ID] = [d].[ID2]
   WHERE [c].[Name] <> [dlc].[Name])
BEGIN
   <do something>
END

Estou atualizando para 3.0 e tive alguns problemas com a atualização. Especificamente, recebi um erro ao tentar inicializar mongodvia ssh, ele tentou usar o padrão dbpathem vez do especificado no meu novo arquivo de configuração YAML. Eu fui em frente e reiniciei a máquina e agora mongodestá funcionando novamente. Estou um pouco paranóico neste momento e gostaria de saber se há uma maneira de garantir que o mecanismo de armazenamento seja wiredtigerdo shell.

Fundo

Eu tenho uma consulta em execução no SQL Server 2008 R2 que une e/ou une à esquerda cerca de 12 "tabelas" diferentes. O banco de dados é bastante grande, com muitas tabelas com mais de 50 milhões de linhas e cerca de 300 tabelas diferentes. É para uma grande empresa que tem 10 armazéns em todo o país. Todos os armazéns lêem e gravam no banco de dados. Então é bem grande e bem movimentado.

A consulta com a qual estou tendo problemas é algo assim:

select t1.something, t2.something, etc.
from Table1 t1
    inner join Table2 t2 on t1.id = t2.t1id
    left outer join (select * from table 3) t3 on t3.t1id = t1.t1id
    [etc]...
where t1.something = 123

Observe que uma das junções está em uma subconsulta não correlacionada.

O problema é que a partir desta manhã, sem nenhuma alteração (que eu ou alguém da minha equipe saiba) no sistema, a consulta que normalmente leva cerca de 2 minutos para ser executada, começou a levar uma hora e meia para ser executada - quando correu em tudo. O resto do banco de dados está funcionando bem. Eu tirei essa consulta do sproc em que ela geralmente é executada e a executei no SSMS com variáveis ​​de parâmetro codificadas com a mesma lentidão.

A estranheza é que, quando eu pego a subconsulta não correlacionada e a coloco em uma tabela temporária e, em seguida, uso isso em vez da subconsulta, a consulta funciona bem. Além disso (e isso é o mais estranho para mim) se eu adicionar este pedaço de código ao final da consulta, a consulta funciona muito bem:

and t.name like '%'

Concluí (talvez incorretamente) com esses pequenos experimentos que o motivo da lentidão é devido à forma como o plano de execução em cache do SQL é configurado - quando a consulta é um pouco diferente, é necessário criar um novo plano de execução.

Minha pergunta é esta: quando uma consulta que costumava ser rápida de repente começa a ser executada lentamente no meio da noite e nada mais é afetado, exceto esta consulta, como faço para solucioná-la e como evitar que isso aconteça no futuro ? Como sei o que o SQL está fazendo internamente para torná-lo tão lento (se a consulta incorreta fosse executada, eu poderia obter seu plano de execução, mas não será executado - talvez o plano de execução esperado me dê algo?)? Se esse problema for com o plano de execução, como evitar que o SQL pense que planos de execução realmente ruins são uma boa ideia?

Além disso, isso não é um problema com o sniffing de parâmetros. Eu já vi isso antes, e não é isso, pois mesmo quando codifico as variáveis ​​no SSMS, ainda obtenho um desempenho lento.

Eu sei que o comentário da tabela mysql pode ser definido na criação com:

create table (...)comment='table_comment';

E você pode exibir comentários por:

show table status where name='table_name';

Como você altera (altera?) o comentário da tabela após sua criação. Quero dizer, sem deixar cair e recriar a tabela novamente.

Esta manhã estou tentando conectar o banco de dados PostgreSQL na minha área de trabalho do Windows 7 Professional.

O valor padrão é 'postgres', mas com certeza esqueci qual senha usei quando a instalei originalmente.

Eu pesquisei e encontrei um post relacionado à redefinição de sua senha. Eu segui os passos, mas o resultado final é um pouco diferente do mencionado no post. Eu usei-

net user postgres postgres

para redefinir a senha do meu banco de dados, mas em vez de uma mensagem de sucesso estou recebendo:

"Ocorreu um erro de sistema 5. Acesso negado."

erro no sistema. Como evito esse erro e redefino a senha?

Tenho uma tabela com índice multicolunas, e tenho dúvidas sobre a ordenação adequada dos índices para obter o máximo desempenho nas consultas.

O cenário:

• PostgreSQL 8.4, tabela com cerca de um milhão de linhas

• Os valores na coluna c1 podem ter cerca de 100 valores diferentes . Podemos assumir que os valores são distribuídos uniformemente, então temos cerca de 10.000 linhas para cada valor possível.

• A coluna c2 pode ter 1.000 valores diferentes . Temos 1000 linhas para cada valor possível.

Ao pesquisar dados, a condição sempre inclui valores para essas duas colunas, portanto, a tabela tem um índice de várias colunas combinando c1 e c2. Eu li sobre a importância de ordenar corretamente as colunas em um índice de várias colunas se você tiver consultas usando apenas uma coluna para filtragem. Este não é o caso em nosso cenário.

A minha pergunta é esta:

Dado que um dos filtros seleciona um conjunto de dados muito menor, posso melhorar o desempenho se o primeiro índice for o mais seletivo (o que permite um conjunto menor)? Eu nunca havia considerado essa questão até ver os gráficos do artigo referenciado:

Imagem retirada do artigo referenciado sobre índices multicolunas .

As consultas usam valores das duas colunas para filtragem. Não tenho consultas usando apenas uma coluna para filtragem. Todos eles são: WHERE c1=@ParameterA AND c2=@ParameterB. Também existem condições como esta:WHERE c1 = "abc" AND c2 LIKE "ab%"

Executando a consulta daqui para retirar os eventos de impasse da sessão padrão de eventos estendidos

SELECT CAST (
    REPLACE (
        REPLACE (
            XEventData.XEvent.value ('(data/value)[1]', 'varchar(max)'),
            '<victim-list>', '<deadlock><victim-list>'),
        '<process-list>', '</victim-list><process-list>')
    AS XML) AS DeadlockGraph
FROM (SELECT CAST (target_data AS XML) AS TargetData
    FROM sys.dm_xe_session_targets st
    JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address
    WHERE [name] = 'system_health') AS Data
CROSS APPLY TargetData.nodes ('//RingBufferTarget/event') AS XEventData (XEvent)
    WHERE XEventData.XEvent.value('@name', 'varchar(4000)') = 'xml_deadlock_report';

leva cerca de 20 minutos para ser concluído na minha máquina. As estatísticas relatadas são

Table 'Worktable'. Scan count 0, logical reads 68121, physical reads 0, read-ahead reads 0, 
         lob logical reads 25674576, lob physical reads 0, lob read-ahead reads 4332386.

 SQL Server Execution Times:
   CPU time = 1241269 ms,  elapsed time = 1244082 ms.

Plano Lento XML

Se eu remover a WHEREcláusula, ela será concluída em menos de um segundo, retornando 3.782 linhas.

Da mesma forma, se eu adicionar OPTION (MAXDOP 1)à consulta original que acelera as coisas também, as estatísticas agora mostram muito menos leituras de lob.

Table 'Worktable'. Scan count 0, logical reads 15, physical reads 0, read-ahead reads 0,
                lob logical reads 6767, lob physical reads 0, lob read-ahead reads 6076.

 SQL Server Execution Times:
   CPU time = 639 ms,  elapsed time = 693 ms.

XML do plano mais rápido

Então minha pergunta é

Alguém pode explicar o que está acontecendo? Por que o plano original é tão catastroficamente pior e existe alguma maneira confiável de evitar o problema?

Adição:

Também descobri que alterar a consulta para INNER HASH JOINmelhorar as coisas até certo ponto (mas ainda leva> 3 minutos), pois os resultados do DMV são tão pequenos que duvido que o próprio tipo Join seja responsável e presumo que algo mais deva ter mudado. Estatísticas para isso

Table 'Worktable'. Scan count 0, logical reads 30294, physical reads 0, read-ahead reads 0, 
          lob logical reads 10741863, lob physical reads 0, lob read-ahead reads 4361042.

 SQL Server Execution Times:
   CPU time = 200914 ms,  elapsed time = 203614 ms.

(E planejar)

Depois de preencher o buffer de anel de eventos estendidos ( DATALENGTHdos XMLquais eram 4.880.045 bytes e continha 1.448 eventos.) e testar uma versão reduzida da consulta original com e sem a MAXDOPdica.

SELECT COUNT(*)
FROM   (SELECT CAST (target_data AS XML) AS TargetData
        FROM   sys.dm_xe_session_targets st
               JOIN sys.dm_xe_sessions s
                 ON s.address = st.event_session_address
        WHERE  [name] = 'system_health') AS Data
       CROSS APPLY TargetData.nodes ('//RingBufferTarget/event') AS XEventData (XEvent)
WHERE  XEventData.XEvent.value('@name', 'varchar(4000)') = 'xml_deadlock_report'

SELECT*
FROM   sys.dm_db_task_space_usage
WHERE  session_id = @@SPID 

Deu os seguintes resultados

+-------------------------------------+------+----------+
|                                     | Fast |   Slow   |
+-------------------------------------+------+----------+
| internal_objects_alloc_page_count   |  616 |  1761272 |
| internal_objects_dealloc_page_count |  616 |  1761272 |
| elapsed time (ms)                   |  428 |   398481 |
| lob logical reads                   | 8390 | 12784196 |
+-------------------------------------+------+----------+

Há uma clara diferença nas alocações de tempdb com a mais rápida mostrando que as 616páginas foram alocadas e desalocadas. Esta é a mesma quantidade de páginas usadas quando o XML também é colocado em uma variável.

Para o plano lento, essas contagens de alocação de página chegam a milhões. A pesquisa dm_db_task_space_usageenquanto a consulta está em execução mostra que parece estar constantemente alocando e desalocando páginas tempdbentre 1.800 e 3.000 páginas alocadas a qualquer momento.

Adicionado na edição, 29/05/2013: Como esta é uma longa pergunta e discussão, aqui está um breve resumo da pergunta e da solução. Tive problemas ao executar MySQL e Apache em um pequeno servidor Linux (1 GB de memória). O Apache continuou exigindo mais memória e, como consequência, o sistema operacional sempre matava o MySQL para recuperar sua memória. A solução foi substituir o Apache pelo Lighttpd. Depois que fiz isso, o uso de memória no servidor ficou completamente estável por vários meses e não tive nenhum tipo de travamento. fim da edição

Eu sou um administrador de sistema iniciante para um pequeno servidor virtual. A principal função do servidor é executar o software de sistema de gerenciamento de cursos Moodle de código aberto, escrito em PHP. Ele se baseia em um banco de dados, neste caso MySQL, e um servidor web, neste caso Apache.

O servidor está executando o CentOS versão 5.8 (Final) de 64 bits com 1 GB de memória e 200 GB de disco, versão do kernel 2.6.18-308.8.2.el5xen. A versão do MySQL é Ver 14.14 Distrib 5.5.25, para Linux (x86_64) usando readline 5.1.

Eu não acho que o software Moodle seja um usuário tão pesado do MySQL. Atualmente, apenas cerca de dez professores têm acesso a ele, e quando eu despejo e comprimi com bzip2 todo o banco de dados, o tamanho do despejo resultante é menor que 1 MB.

Eu configurei o sistema há alguns meses. O servidor Apache esteve estável todo esse tempo, mas o MySQL travou várias vezes. Eu tentei aprender sobre a configuração ideal da web, e a última vez que alterei o /etc/my.cnfarquivo, usei o arquivo /usr/share/doc/mysql55-server-5.5.25/my-large.cnfque vem com o MySQL como exemplo. O arquivo diz que é destinado a sistemas com 512 MB de memória, então pensei que usar seus parâmetros de configuração relacionados à memória seria seguro para este sistema. (Eu já havia configurado os parâmetros relacionados à memória do MySQL com números muito menores e pensei que isso poderia ter causado as falhas. Embora as falhas ainda ocorram, o sistema está pelo menos mais rápido agora.) Este é o conteúdo atual de /etc/my.cnf:

# /etc/my.cfg

# The main and only MySQL configuration file on [WEBSITE ADDRESS REDACTED].
# Last updated 2012-09-23 by Teemu Leisti.

# Most of the memory settings are set to be the same as the example setting file
# /usr/share/doc/mysql55-server-5.5.25/my-large.cnf, which is meant for systems
# with 512M of memory.  This server currently has twice that, i.e. 1G of memory,
# which should make these settings safe.


[client]
default_character_set           = utf8
port                            = 3306
socket                          = /var/lib/mysql/mysql.sock

[mysqld]
character_set_filesystem        = utf8
character_set_server            = utf8
datadir                         = /var/lib/mysql
innodb_additional_mem_pool_size = 20M
innodb_buffer_pool_size         = 256M # You can set .._buffer_pool_size up to
                                       # 50..80% of RAM, but beware of setting
                                       # memory usage too high
innodb_data_file_path           = ibdata1:10M:autoextend
innodb_data_home_dir            = /var/lib/mysql
innodb_flush_log_at_trx_commit  = 1
innodb_lock_wait_timeout        = 50
innodb_log_buffer_size          = 8M
innodb_log_file_size            = 64M # Set .._log_file_size to 25% of buffer
                                      # pool size
innodb_log_group_home_dir       = /var/lib/mysql
interactive_timeout             = 60
key_buffer_size                 = 256M
long_query_time                 = 10
max_allowed_packet              = 1M
max_connections                 = 30
port                            = 3306
query_cache_limit               = 2M # see http://emergent.urbanpug.com/?p=61
query_cache_size                = 16M
read_buffer_size                = 1M
read_rnd_buffer_size            = 4M
skip_networking                 # Only local processes need to use MySQL
skip_symbolic_links             # Disabling symbolic_links is recommended to
                                # prevent assorted security risks
slow_query_log_file             = /var/log/mysql-slow-queries.log
socket                          = /var/lib/mysql/mysql.sock
sort_buffer_size                = 1M
table_open_cache                = 256
thread_cache_size               = 8
thread_concurrency              = 2 #    = number of CPUs * 2
user                            = mysql
wait_timeout                    = 10

[mysqld_safe]
log_error                       = /var/log/mysqld.log
open_files_limit                = 4096
pid_file                        = /var/run/mysqld/mysqld.pid

[mysqldump]
quick
max_allowed_packet              = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
safe-updates

[myisamchk]
key_buffer_size                 = 128M
sort_buffer_size                = 128M
read_buffer                     = 2M
write_buffer                    = 2M

[mysqlhotcopy]
interactive-timeout

Como você pode ver na configuração, a configuração usa o mecanismo InnoDB e atende apenas solicitações do localhost. Além do administrador do sistema (eu), o Moodle é o único usuário do MySQL.

Quando o MySQL trava, o seguinte é invariavelmente gravado no arquivo de log /var/log/mysqld.log(exceto os carimbos de data e hora, é claro):

120926 08:00:51 mysqld_safe Number of processes running now: 0
120926 08:00:51 mysqld_safe mysqld restarted
120926  8:00:53 [Note] Plugin 'FEDERATED' is disabled.
120926  8:00:53 InnoDB: The InnoDB memory heap is disabled
120926  8:00:53 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120926  8:00:53 InnoDB: Compressed tables use zlib 1.2.3
120926  8:00:53 InnoDB: Using Linux native AIO
120926  8:00:53 InnoDB: Initializing buffer pool, size = 256.0M
InnoDB: mmap(274726912 bytes) failed; errno 12
120926  8:00:53 InnoDB: Completed initialization of buffer pool
120926  8:00:53 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120926  8:00:53 [ERROR] Plugin 'InnoDB' init function returned error.
120926  8:00:53 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120926  8:00:53 [ERROR] Unknown/unsupported storage engine: InnoDB
120926  8:00:53 [ERROR] Aborting

120926  8:00:53 [Note] /usr/libexec/mysqld: Shutdown complete

120926 08:00:53 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

Às vezes, posso reiniciar o MySQL comandando service mysqld restart, mas às vezes esse comando falha com esta saída: mysqld dead but subsys locked. Nesses casos, a única coisa que consegui pensar para recuperar a situação é reiniciar o servidor, após o que o MySQL pode ser reiniciado. Nesses casos, a saída fica assim:

120926 11:43:48 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120926 11:43:48 [Note] Plugin 'FEDERATED' is disabled.
120926 11:43:48 InnoDB: The InnoDB memory heap is disabled
120926 11:43:48 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120926 11:43:48 InnoDB: Compressed tables use zlib 1.2.3
120926 11:43:48 InnoDB: Using Linux native AIO
120926 11:43:48 InnoDB: Initializing buffer pool, size = 256.0M
120926 11:43:48 InnoDB: Completed initialization of buffer pool
120926 11:43:48 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
120926 11:43:48  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
120926 11:43:51  InnoDB: Waiting for the background threads to start
120926 11:43:52 InnoDB: 1.1.8 started; log sequence number 466807107
120926 11:43:52 [Note] Event Scheduler: Loaded 0 events
120926 11:43:52 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.25'  socket: '/var/lib/mysql/mysql.sock'  port: 0  MySQL Community Server (GPL)

Aqui está o que o comando free -mproduz atualmente:

# free -m
             total       used       free     shared    buffers     cached
Mem:          1024        869        154          0         70        153
-/+ buffers/cache:        644        379
Swap:            0          0          0

Normalmente a coluna "livre" tem entre 50 e 100 MB.

A saída do comando ulimit -a:

# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 8192
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 8192
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Não alterei nenhuma configuração ou arquivo de código do Moodle, exceto /var/www/html/moodle/config.php, que se parece com isso (linhas de comentários excluídas para economizar espaço):

<?php
unset($CFG);  // Ignore this line
global $CFG;  // This is necessary here for PHPUnit execution
$CFG = new stdClass();
$CFG->dbtype    = 'mysqli';           // 'pgsql', 'mysqli', 'mssql', 'sqlsrv' or 'oci'
$CFG->dblibrary = 'native';           // 'native' only at the moment
$CFG->dbhost    = 'localhost';        // eg 'localhost' or 'db.isp.com' or IP
$CFG->dbname    = 'moodle';           // database name, eg moodle
$CFG->dbuser    = 'moodleuser';       // your database username
$CFG->dbpass    = '[REDACTED]';       // your database password
$CFG->prefix    = 'moodle_';          // prefix to use for all table names
$CFG->dboptions = array(
    'dbpersist' => false,       // should persistent database connections be
                                //  used? set to 'false' for the most stable
                                //  setting, 'true' can improve performance
                                //  sometimes
    'dbsocket'  => true,        // should connection via UNIX socket be used?
                                //  if you set it to 'true' or custom path
                                //  here set dbhost to 'localhost',
                                //  (please note mysql is always using socket
                                //  if dbhost is 'localhost' - if you need
                                //  local port connection use '127.0.0.1')
    'dbport'    => '',          // the TCP port number to use when connecting
                                //  to the server. keep empty string for the
                                //  default port
);
$CFG->passwordsaltmain = '[REDACTED]';
$CFG->wwwroot   = 'http://[REDACTED]';
$CFG->dataroot  = '/var/moodledata';
$CFG->directorypermissions = 02777;
$CFG->admin = 'admin';
date_default_timezone_set('Europe/Helsinki');
$CFG->disableupdatenotifications = true;
require_once(dirname(__FILE__) . '/lib/setup.php'); // Do not edit

(No entanto, instalei dois plugins do Moodle, o módulo Attendance e o block , mas não vejo como eles podem estar envolvidos com esse problema.)

Mesmo depois de atualizar /etc/my.cnfpara seu estado atual há uma semana, o MySQL travou algumas vezes com os sintomas fornecidos acima. Sendo um iniciante em administração de banco de dados e depois de pesquisar muito sobre esse problema, não sei o que fazer a seguir. Alguma sugestão? Devo postar mais dados de configuração?

Adição na edição:

O conteúdo do arquivo /var/log/messages.1é:

Sep 23 04:02:18 [machine name] syslogd 1.4.1: restart.
Sep 26 08:00:51 [machine name] kernel: mysqld invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Sep 26 08:00:51 [machine name] kernel:
Sep 26 08:00:51 [machine name] kernel: Call Trace:
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff802c1bd5>] out_of_memory+0x8b/0x203
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff8020fa49>] __alloc_pages+0x27f/0x308
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff802139c9>] __do_page_cache_readahead+0xc8/0x1af
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff8021423a>] filemap_nopage+0x14c/0x360
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff80208e9d>] __handle_mm_fault+0x444/0x144f
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff80263929>] _spin_lock_irqsave+0x9/0x14
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff8023f468>] lock_timer_base+0x1b/0x3c
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff80266d94>] do_page_fault+0xf72/0x131b
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff802e5f4f>] sys_io_getevents+0x311/0x359
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff802e4e56>] timeout_func+0x0/0x10
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff8025f82b>] error_exit+0x0/0x6e
Sep 26 08:00:51 [machine name] kernel:
Sep 26 08:00:51 [machine name] kernel: Mem-info:
Sep 26 08:00:51 [machine name] kernel: DMA per-cpu:
Sep 26 08:00:51 [machine name] kernel: cpu 0 hot: high 0, batch 1 used:0
Sep 26 08:00:51 [machine name] kernel: cpu 0 cold: high 0, batch 1 used:0
Sep 26 08:00:51 [machine name] kernel: DMA32 per-cpu:
Sep 26 08:00:51 [machine name] kernel: cpu 0 hot: high 186, batch 31 used:117
Sep 26 08:00:51 [machine name] kernel: cpu 0 cold: high 62, batch 15 used:53
Sep 26 08:00:51 [machine name] kernel: Normal per-cpu: empty
Sep 26 08:00:51 [machine name] kernel: HighMem per-cpu: empty
Sep 26 08:00:51 [machine name] kernel: Free pages:        7256kB (0kB HighMem)
Sep 26 08:00:51 [machine name] kernel: Active:241649 inactive:0 dirty:0 writeback:0 unstable:0 free:1814 slab:4104 mapped-file:1153 mapped-anon:240592 pagetables:3298
Sep 26 08:00:51 [machine name] kernel: DMA free:3268kB min:32kB low:40kB high:48kB active:0kB inactive:0kB present:9068kB pages_scanned:0 all_unreclaimable? yes
Sep 26 08:00:51 [machine name] kernel: lowmem_reserve[]: 0 994 994 994
Sep 26 08:00:51 [machine name] kernel: DMA32 free:3988kB min:4016kB low:5020kB high:6024kB active:966596kB inactive:0kB present:1018080kB pages_scanned:6327262 all_unreclaimable? yes
Sep 26 08:00:52 [machine name] kernel: lowmem_reserve[]: 0 0 0 0
Sep 26 08:00:52 [machine name] kernel: Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Sep 26 08:00:52 [machine name] kernel: lowmem_reserve[]: 0 0 0 0
Sep 26 08:00:52 [machine name] kernel: HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Sep 26 08:00:52 [machine name] kernel: lowmem_reserve[]: 0 0 0 0
Sep 26 08:00:52 [machine name] kernel: DMA: 1*4kB 2*8kB 1*16kB 1*32kB 2*64kB 2*128kB 1*256kB 1*512kB 2*1024kB 0*2048kB 0*4096kB = 3268kB
Sep 26 08:00:52 [machine name] kernel: DMA32: 17*4kB 2*8kB 2*16kB 1*32kB 0*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 3988kB
Sep 26 08:00:52 [machine name] kernel: Normal: empty
Sep 26 08:00:52 [machine name] kernel: HighMem: empty
Sep 26 08:00:52 [machine name] kernel: 1214 pagecache pages
Sep 26 08:00:52 [machine name] kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0
Sep 26 08:00:52 [machine name] kernel: Free swap  = 0kB
Sep 26 08:00:52 [machine name] kernel: Total swap = 0kB
Sep 26 08:00:52 [machine name] kernel: Free swap:            0kB
Sep 26 08:00:52 [machine name] kernel: 262144 pages of RAM
Sep 26 08:00:52 [machine name] kernel: 8320 reserved pages
Sep 26 08:00:52 [machine name] kernel: 22510 pages shared
Sep 26 08:00:52 [machine name] kernel: 0 pages swap cached
Sep 26 08:00:52 [machine name] kernel: Out of memory: Killed process 1371, UID 27, (mysqld).

e, em seguida, linhas relacionadas à reinicialização às 11:42.

Adição na edição nº 2:

Tentei comentar a resposta de Michael, mas entrei em conflito com o limite de caracteres de comentários, então estou respondendo aqui.

Obrigado pela resposta, Miguel. Acabei de editar minha pergunta para incluir o conteúdo do log do sistema da máquina no momento da falha. (O CentOS parece chamar seu log do sistema /var/log/messages.)

Sim, os logs do MySQL e do sistema parecem quase idênticos aos da pergunta à qual você vinculou. E agora que você mencionou, é meio óbvio que a mysql restartedmensagem significa que o MySQL já havia travado. O log do sistema indica que foi isso oom_killerque deu origem ao processo. Em sua resposta anterior, você escreve: "Primeiro palpite: os processos filho do apache ficam loucos". Parece-me que o Apache é o suspeito óbvio aqui também.

Anteriormente, encontrei o artigo Optimizing MySQL and Apache for Low Memory Usage, Part 1 . Para configurar o Apache, o autor recomenda: "Primeiro, Apache. Minha primeira declaração é, se você puder evitá-lo, tente. Lighttpd e thttpd são ambos servidores web muito bons, sem frescuras, e você pode executar lighttpd com PHP. Mesmo se você estiver executando um site de alto volume, você pode obter algum desempenho seriamente passando o conteúdo estático (imagens e arquivos javascript, geralmente) para um servidor HTTPd leve e super-rápido, como o Lighttpd."

Estou pensando em seguir o conselho do autor e concordei com meu cliente que, no próximo fim de semana, substituirei o Apache por Lighttpd no servidor. Espero que isso resolva os problemas. O uso de dois servidores virtuais provavelmente não é possível.

Eu não pensei que usar dois servidores de código aberto estáveis ​​e maduros, como MySQL e Apache na mesma máquina, com uma quantidade razoável de memória, seria tão problemático.