Служба mysqld останавливается один раз в день на сервере ec2

Подробности среды:

Server: Amazon ec2 Linux
Web Server: Apache
Web Framework: Django with mod_wsgi

Следующее, что я нашел в файле mysql_err.log.

The InnoDB memory heap is disabled
120823  3:21:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120823  3:21:40 InnoDB: Compressed tables use zlib 1.2.3
120823  3:21:40 InnoDB: Using Linux native AIO
120823  3:21:41 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
120823  3:21:41 InnoDB: Completed initialization of buffer pool
120823  3:21:41 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120823  3:21:41 [ERROR] Plugin 'InnoDB' init function returned error.
120823  3:21:41 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120823  3:21:41 [ERROR] Unknown/unsupported storage engine: InnoDB
120823  3:21:41 [ERROR] Aborting

Похоже, системной памяти недостаточно для выделения памяти пулу буферов. То же самое происходит при использовании Amazon ec2 micro instance, поэтому я перешел к small instance. Он работает отлично в течение нескольких дней, но теперь он ломается один раз в день. Есть ли постоянное исправление для этого? Я могу перейти к среднему экземпляру, но проблема будет исправлена ​​или нет? Должен ли я уменьшить innodb_buffer_pool_size, какой предпочтительный размер?

Результат cat /proc/meminfo следующий (может быть, это поможет):

MemTotal:        1697824 kB
MemFree:          125744 kB
Buffers:          109704 kB
Cached:           481408 kB
SwapCached:            0 kB
Active:          1212396 kB
Inactive:         266840 kB
Active(anon):     888192 kB
Inactive(anon):       76 kB
Active(file):     324204 kB
Inactive(file):   266764 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 4 kB
Writeback:             0 kB
AnonPages:        888144 kB
Mapped:            15604 kB
Shmem:               144 kB
Slab:              63752 kB
SReclaimable:      53680 kB
SUnreclaim:        10072 kB
KernelStack:         800 kB
PageTables:        16436 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      848912 kB
Committed_AS:    1417140 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       10988 kB
VmallocChunk:   34359725168 kB
DirectMap4k:     1748992 kB
DirectMap2M:           0 kB

Версия ОС (uname -a): Linux ip-10-246-134-149 3.2.21-1.32.6.amzn1.x86_64 #1 SMP Sat Jun 23 02:32:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Я проверил команду ps aux, потому что сервер имеет только оставшуюся 15 МБ памяти, и это процесс httpd, запущенный в это время:

Результат free -m

total       used       free     shared    buffers     cached
Mem:          1657       1628         29          0          3         19
-/+ buffers/cache:       1605         51
Swap:          895        875         20

Результат ps aux

apache   21123  0.1  1.2 394652 20464 ?        S    19:35   0:06 /usr/sbin/httpd
apache   21146  0.1  1.2 394280 20796 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21152  0.1  1.2 394284 21560 ?        S    19:38   0:05 /usr/sbin/httpd
apache   21155  0.2  1.4 396244 24528 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21156  0.1  1.1 392552 20344 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21157  0.1  1.1 394284 18884 ?        S    19:38   0:05 /usr/sbin/httpd
apache   21159  0.1  1.4 396200 25040 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21161  0.1  1.2 394856 21724 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21162  0.1  1.3 394864 22400 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21163  0.1  1.3 394860 22204 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21164  0.1  1.1 392560 19204 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21165  0.1  1.3 394832 22280 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21166  0.1  1.3 395276 22932 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21172  0.2  1.4 396320 24820 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21174  0.2  1.7 400672 29452 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21178  0.1  1.4 400540 25304 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21179  0.2  1.6 400580 27856 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21184  0.1  1.7 400628 29320 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21185  0.1  1.6 397944 27292 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21186  0.1  1.5 397960 25648 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21187  0.1  1.7 400576 29120 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21191  0.1  1.4 400576 24400 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21193  0.1  1.4 400536 24940 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21194  0.1  1.5 400572 26096 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21203  0.1  1.6 400580 28808 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21206  0.1  1.7 400584 29732 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21207  0.1  1.6 400576 27940 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21224  0.1  1.2 400624 20768 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21225  0.1  1.6 400576 28468 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21226  0.1  1.6 400576 28048 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21228  0.1  1.4 400572 23880 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21237  0.1  1.5 400628 26124 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21265  0.1  1.6 400536 28592 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21276  0.1  1.2 400544 21456 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21277  0.1  1.3 400624 22676 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21278  0.1  1.6 400536 27360 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21282  0.1  1.4 400612 24996 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21292  0.1  1.4 400532 24780 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21302  0.2  1.2 400540 21332 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21303  0.1  1.3 400628 22228 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21305  0.2  1.2 400536 21116 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21306  0.1  1.3 400572 22380 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21307  0.1  1.1 397956 20056 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21308  0.1  1.2 400624 21520 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21319  0.1  1.1 400540 19468 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21320  0.1  1.3 400628 22712 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21335  0.1  1.0 400540 17236 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21336  0.1  1.3 400628 22188 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21352  0.1  1.1 394276 18972 ?        S    19:40   0:04 /usr/sbin/httpd
apache   21356  0.1  1.1 394280 19028 ?        S    19:40   0:05 /usr/sbin/httpd
apache   21358  0.1  1.1 394280 19004 ?        S    19:40   0:05 /usr/sbin/httpd
apache   21361  0.2  0.7 400452 12632 ?        S    19:40   0:06 /usr/sbin/httpd
apache   21610  0.2  1.6 400536 27660 ?        S    19:46   0:06 /usr/sbin/httpd
apache   21643  0.2  1.3 400156 23272 ?        S    19:55   0:04 /usr/sbin/httpd
apache   21647  0.2  1.0 400544 17556 ?        S    19:57   0:05 /usr/sbin/httpd
apache   21654  0.2  1.5 400188 26884 ?        S    19:58   0:05 /usr/sbin/httpd
apache   21719  0.3  1.9 400192 32264 ?        S    20:14   0:03 /usr/sbin/httpd
apache   21725  0.2  2.0 400044 35340 ?        S    20:15   0:03 /usr/sbin/httpd
apache   21738  0.0  0.8 257648 13792 ?        S    20:26   0:00 /usr/sbin/httpd

Может ли кто-нибудь задуматься о том, почему так много httpd-процесса?

ОТВЕТЫ

Ответ 1

Используйте 50% доступной ОЗУ для тестирования:

Вы можете уменьшить innodb_buffer_pool_size очень низко, чтобы узнать, помогает ли это:

#/etc/my.cnf 
innodb_buffer_pool_size = 1M

Эмпирическое правило - установить innodb_buffer_pool_size на 50% доступной ОЗУ для тестирования вашей низкой памяти. Это означает, что вы запускаете сервер и все, кроме MySQL InnoDB. Посмотрите, сколько у вас RAM. Затем используйте 50% для InnoDB.

Чтобы попробовать сразу несколько настроек низкой памяти:

Более вероятным виновником является то, что еще есть на этом сервере, например, веб-сервер.

Apache?

Используете ли вы Apache и/или другой веб-сервер? Если это так, попробуйте уменьшить использование ОЗУ. Например, в Apache conf, рассмотрите небольшие настройки RAM, такие как:

StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5

И закройте запросы следующим образом:

MaxRequestsPerChild 300

Затем перезапустите Apache.

mod_wsgi:

Если вы используете Apache с mod_python, переключитесь на Apache с mod_wsgi.

Pympler:

Если это все еще происходит, возможно, ваш Django неуклонно растет. Попробуйте профилирование памяти Django с помощью Pympler:

SAR:

Ваш отчет о неудачах раз в день, а затем один раз в неделю сбои, может указывать на какую-то работу cron, выполняемую ежедневно или еженедельно. Например, возможно, существует пакетный процесс, который занимает много оперативной памяти или дампа базы данных и т.д.

Чтобы отслеживать использование ОЗУ и искать всплески ОЗУ за час до смерти MySQL, взгляните на SAR, что является отличным инструментом: http://www.thegeekstuff.com/2011/03/sar-examples/

Ответ 2

Вам нужно уменьшить ваш innodb_buffer_pool_size = < 60-80% от вашей основной памяти)

Решение для Innodb Error:

110603  7:34:15 [ERROR] Plugin ‘InnoDB’ init function returned error.
110603  7:34:15 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
110603  7:34:15 [ERROR] Unknown/unsupported storage engine: InnoDB
110603  7:34:15 [ERROR] Aborting

10603  7:34:15 [Note] /usr/sbin/mysqld: Shutdown complete

I moved the ib_logfile0 and ib_logfile01 to bak and start Mysql again. Now this time, it is working fine

[[email protected] mysql]# mv ib_logfile0 ib_logfile0-bak
[[email protected] mysql]# mv ib_logfile1 ib_logfile1-bak

Источник: http://www.onaxer.com/tag/error-plugin-innodb-init-function-returned-error/

Ответ 3

Как и многие другие, проблема заключается в том, что ваша система работает на низком уровне оперативной памяти, и MySQL из-за этого взрывается. Ниже приведено описание того, как сужаться, где используется ваша системная память, и как восстанавливаться из базы данных.

Посмотрите collectd и его плагины. Некоторые из применимых могут быть процессы плагина и плагин памяти. С ними вы можете видеть использование памяти вашей системы и какие процессы занимают большинство из них.

В зависимости от того, как вы запускаете Django, вы можете настроить рабочие процессы только на обработку определенного количества запросов, а затем завершить работу. Таким образом, если в вашем приложении есть какая-то утечка памяти, он не будет продолжать проходить столько запросов. Например, если вы используете Gunicorn, вы можете использовать - max-requests. Установка его на 500 приведет к отбрасыванию работника после обработки 500 запросов.

Вышеуказанное в сочетании с коллекцией статистики покажет вам некоторые интересные тенденции использования памяти.

Что касается базы данных, то вы можете настроить контроль процесса, чтобы, если MySQL действительно умер, он будет перезапущен автоматически. MySQL в последней версии Ubuntu использует Upstart для этого. Если процесс умирает, Upstart немедленно вернет его. Если вы используете другой дистрибутив, который не имеет этого встроенного, взгляните на Supervisor. Хотя это не устраняет проблему, это, по крайней мере, смягчит ее последствия. Это не следует рассматривать как исправление, а скорее способ поддерживать работу вашего приложения в случае, если что-то пойдет не так.

Ответ 4

Как только я столкнулся с подобными проблемами, я был очень расстроен тем, что мои пользователи видят это уродливое сообщение, что Ошибка установления соединения с БД. Вместо того, чтобы решать точные проблемы, я нашел это репо, чтобы работать как прелесть для меня (временно). После этого я отладил его у моего друга, и он просто настроил мой сервер с некоторыми изменениями конфигурации. Но я все еще добавлял этот script к моему crontab каждые 10 минут, а затем проверял, был ли разбит сервер (что для моего случая разбилось в конце концов, когда я запускаю VNCServer на моем сервере), а затем перезагружаю его

Ответ 5

Увеличение доступной ОЗУ путем добавления нового пространства подкачки также может помочь. Шаги здесь

Убедитесь, что вы создаете /swap файл меньшего размера, чем доступное пространство, показанное

df -h

Например, для меня вывод df-h был:

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  1.2G  6.3G  16% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            492M   12K  492M   1% /dev
tmpfs           100M  336K   99M   1% /run

Итак, я создал с помощью 2 G

sudo fallocate -l 2G /swapfile

А затем просто запустите сервис

sudo /etc/init.d/mysql restart

Надеюсь, это поможет. Все лучшее.

Ответ 6

Я нашел ответ на этот вопрос и работал на меня: https://www.digitalocean.com/community/questions/mysql-server-keeps-stopping-unexpectedly?answer=26016

вам нужно сделать оба innodb_buffer_pool_size для чего-то разумного, например, 32M на my.conf в /etc/mysql/my.cnf, и вам также может понадобиться изменить /etc/apache2/mods-enabled/mpm_prefork.conf чтобы уменьшить количество соединений запущено apache;

<IfModule mpm_prefork_module>
    StartServers     3
    MinSpareServers  3
    MaxSpareServers  5
    MaxRequestWorkers 25
    MaxConnectionsPerChild  0
</IfModule>

Ответ 7

Я нашел ответ на этот вопрос и работал на меня: https://www.digitalocean.com/community/info/mysql-server-keeps-stopping-unexpectedly?answer=26016

вам нужно сделать оба innodb_buffer_pool_size для чего-то разумного, например, 32M на my.conf в /etc/mysql/my.cnf, и вам также может понадобиться изменить /etc/apache2/mods-enabled/mpm_prefork.conf чтобы уменьшить количество соединений запущено apache;

<IfModule mpm_prefork_module>
    StartServers     3
    MinSpareServers  3
    MaxSpareServers  5
    MaxRequestWorkers 25
    MaxConnectionsPerChild  0
</IfModule>