MySQL сбой и невозможность перезапуска
Кажется, что MySQL дает сбой, обычно позже днем, но я не понимаю почему! Он говорит, что недостаточно памяти, но есть много свободной оперативной памяти и не используется пространство подкачки. Я использую Azure.
Вот журнал:
Oct 3 20:42:20 GenyxLive kernel: [787828.711240] Out of memory: Kill process 53891 (mysqld) score 84 or sacrifice child
Oct 3 20:42:20 GenyxLive kernel: [787828.714081] Killed process 53891 (mysqld) total-vm:871780kB, anon-rss:58164kB, file-rss:0kB
Oct 3 20:42:20 GenyxLive kernel: [787828.731974] init: mysql main process (53891) killed by KILL signal
Oct 3 20:42:20 GenyxLive kernel: [787828.733525] init: mysql main process ended, respawning
Oct 3 20:42:20 GenyxLive kernel: [787828.974636] init: mysql main process (24975) terminated with status 1
Oct 3 20:42:20 GenyxLive kernel: [787828.974666] init: mysql main process ended, respawning
Oct 3 20:42:21 GenyxLive kernel: [787829.937186] init: mysql post-start process (24976) terminated with status 1
Oct 3 20:42:22 GenyxLive kernel: [787830.103158] init: mysql main process (25002) terminated with status 1
Oct 3 20:42:22 GenyxLive kernel: [787830.103194] init: mysql respawning too fast, stopped
Вот график того, что происходит: 
Вы можете увидеть всплеск процессора, а затем служба mysql останавливается ...
Может ли кто-нибудь помочь мне понять, что происходит?
Ubuntu 12.04
Azure Small (ОЗУ 768 Мбайт, ЦП 1 ГГц)
РЕДАКТИРОВАТЬ
Существует задание cron, которое запускается каждые 5 минут, которое просто проверяет наличие новых доменов и т. Д. (С помощью zpanel).
Это 64-битная ОС
Linux GenyxLive 3.2.0-48-virtual #74-Ubuntu SMP Thu Jun 6 20:02:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
free -lm результат:
total used free shared buffers cached
Mem: 672 491 180 0 42 118
Low: 672 491 180
High: 0 0 0
-/+ buffers/cache: 330 341
Swap: 0 0 0
cat /proc/meminfo результат:
MemTotal: 688348 kB
MemFree: 186788 kB
Buffers: 43956 kB
Cached: 120988 kB
SwapCached: 0 kB
Active: 335908 kB
Inactive: 84924 kB
Active(anon): 255976 kB
Inactive(anon): 296 kB
Active(file): 79932 kB
Inactive(file): 84628 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 16 kB
Writeback: 0 kB
AnonPages: 255924 kB
Mapped: 18568 kB
Shmem: 376 kB
Slab: 51788 kB
SReclaimable: 37052 kB
SUnreclaim: 14736 kB
KernelStack: 1344 kB
PageTables: 7632 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 344172 kB
Committed_AS: 967220 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 13192 kB
VmallocChunk: 34359723128 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 51136 kB
DirectMap2M: 735232 kB
Ядро OOM срабатывает только тогда, когда оно считает, что ресурсы действительно ограничены ... так что вам должно быть не хватает памяти, но тогда диаграмма не имеет большого смысла.
Что значит free -lm шоу? Кроме того, что делает cat /proc/meminfo шоу?
Что касается триггера проблемы, выполняется ли в это время какой-либо процесс обслуживания или другое задание cron, которое может выполнять запросы, в которых mysql должен поддерживать временные таблицы в памяти?
Кстати ... это 32-битная версия ОС? Просто интересно, исчерпана ли ваша низкая память.
ИЗМЕНИТЬ 1 Хорошо. Что ж, mysqld будет единственным процессом, потребляющим больше всего памяти, поэтому, скорее всего, именно поэтому его выбирают. Проверьте свою конфигурацию apache, чтобы увидеть, как могут быть рабочие потоки, которые вы создаете ... у каждого из них будут накладные расходы на память, и возможно, что при следующем появлении у вас закончится память, поскольку у вас нет места для подкачки. Проверьте параметр MaxClients ... если у вас их больше 50 (приблизительная цифра), это может быть хорошим местом для поиска. Могу я порекомендовать взглянуть на Настройка производительности Apache.