le service mysqld s'arrête une fois par jour sur le serveur ec2

Détails D'Environnement:

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

ci-dessous, j'ai trouvé dans le mysql_err.le fichier de 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

semble comme la mémoire du système n'est pas suffisante pour allouer la mémoire au pool de mémoire tampon. La même erreur se produit lorsque j'utilisais Amazon ec2 micro instance , donc je suis passé au small instance . Il fonctionne bien pendant quelques jours, mais maintenant il se brise une fois par jour à nouveau. Est-il une solution permanente pour qui? Je peux passer à l'instance moyenne mais le problème est qui sera fixe ou pas? Devrais-je diminuer le innodb_buffer_pool_size , Quelle est la taille préférée?

Le résultat de cat /proc/meminfo , est le suivant (peut-être ça peut aider):

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

version OS (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

j'ai vérifié la commande ps aux si le serveur n'a plus que 15 Mo de mémoire et il s'agit du processus httpd en cours d'exécution à ce moment-là:

le résultat de free -m

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

le résultat de 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

est-ce que quelqu'un peut savoir pourquoi il y a tant de processus httpd??

38
demandé sur Aamir Adnan 2012-08-24 22:23:56

5 réponses

utiliser 50% de la mémoire vive disponible pour tester:

vous pouvez diminuer l'innodb_buffer_pool_size très faible pour voir si elle aide:

#/etc/my.cnf 
innodb_buffer_pool_size = 1M

une règle empirique est de définir innodb_buffer_pool_size à 50% de la RAM disponible pour votre test de mémoire basse. Cela signifie que vous démarrez le serveur et tout sauf MySQL InnoDB. Voir combien de RAM vous avez. Puis utilisez 50% de cela pour InnoDB.

pour essayer beaucoup de mémoire basse paramètres à la fois:

un coupable plus probable est tout ce qui se trouve sur ce serveur, tel qu'un serveur web.

Apache?

utilisez-vous Apache et/ou un autre serveur web? Si c'est le cas, essayez de réduire l'utilisation de sa RAM. Par exemple, dans le conf D'Apache, les paramètres de RAM sont bas. comme ceci:

StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5

et capter les requêtes comme ceci:

MaxRequestsPerChild 300

puis redémarrez Apache.

mod_wsgi:

si vous utilisez Apache avec mod_python, passez à Apache avec mod_wsgi.

Pympler:

si c'est toujours le cas, il est possible que votre Django soit en pleine croissance. Essayez le profilage de la mémoire de Django avec Pympler:

SAR:

votre rapport sur les échecs une fois par jour, puis une fois par semaine, pourrait indiquer une sorte de travail quotidien ou hebdomadaire. Par exemple, il y a peut-être un processus par lot qui prend beaucoup de mémoire vive, ou un dump de base de données, etc.

pour suivre L'utilisation de la mémoire vive et rechercher des pointes de mémoire vive dans l'heure avant que MySQL meurt, jetez un coup d'oeil à SAR, qui est un grand outil: http://www.thegeekstuff.com/2011/03/sar-examples /

34
répondu joelparkerhenderson 2012-10-02 03:00:34

Vous avez à diminution que vous innodb_buffer_pool_size = <60 à 80% de votre mémoire principale)

Solution pour Erreur Innodb:

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

[root@xxx mysql]# mv ib_logfile0 ib_logfile0-bak
[root@xxx mysql]# mv ib_logfile1 ib_logfile1-bak

Source: http://www.onaxer.com/tag/error-plugin-innodb-init-function-returned-error /

9
répondu Rush 2012-10-24 22:06:52

comme d'autres l'ont mentionné, le problème semble être que votre système fonctionne à bas niveau sur la RAM et MySQL explose à cause de cela. Ci-dessous est la façon d'aller au rétrécissement où la mémoire de votre système est utilisé et comment récupérer à partir de la base de données descendre.

regardez collectd et ses plugins. Certains de l'applicables peuvent l'être les processus plugin et le mémoire plugin . Avec ceux que vous pouvez voir l'utilisation de la mémoire de vos systèmes et quels processus prennent la plupart de lui.

en fonction de la façon dont vous exécutez Django, vous pouvez configurer les processus du worker pour ne traiter qu'un certain nombre de requêtes, puis terminer. De cette façon, s'il y a une sorte de fuite de mémoire dans votre application, elle ne persistera pas au-delà de ce nombre de requêtes. Par exemple, si vous utilisez Gunicorn , vous pouvez utiliser le bouton --max-demandes option. Le réglage à 500 laissera tomber le worker après qu'il ait traité 500 requêtes.

ce qui précède combiné avec la collection de statistiques vous montrera quelques tendances intéressantes d'utilisation de la mémoire.

pour ce qui est de la base de données, vous pouvez configurer la supervision du processus de sorte que si MySQL meurt, il sera relancé automatiquement. MySQL dans la dernière version D'Ubuntu utilise Upstart pour faire exactement cela. Si le processus meurt, Upstart le relèvera immédiatement. Si vous utilisez une autre distro qui n'a pas ce intégré, jetez un oeil à superviseur . Bien que cela ne règle pas le problème, cela atténuera au moins ses effets. Cela ne doit pas être considéré comme la solution, mais plutôt comme un moyen de garder votre application en marche au cas où quelque chose tourne mal.

2
répondu berto 2012-10-08 06:29:26

une fois que j'ai été bloqué dans des problèmes similaires, j'ai été vraiment frustré que mes utilisateurs voient ce message laid que erreur établissant la connexion DB . Au lieu de résoudre les problèmes exacts, j'ai trouvé ce rapport à travailler comme un charme pour moi (Temporairement). Après cela, j'ai été débogué par mon ami et il a juste mis au point mon serveur avec quelques changements de configuration. Mais j'ai quand même ajouté ce script à mon crontab toutes les 10 minutes et ensuite vérifier si le serveur est écrasé (qui pour mon cas s'est éventuellement écrasé chaque fois que j'exécute VNCServer sur mon serveur) et puis redémarrez-le

1
répondu Hammad 2015-09-09 13:21:41

augmenter la RAM disponible en ajoutant de l'espace de pagination pourrait aussi aider. Les étapes sont ici

assurez-vous que vous créez / swapfile de la taille inférieure à l'espace disponible indiqué par

df -h

par exemple pour la sortie me de df-h était:

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

donc j'ai créé en utilisant 2 g

sudo fallocate -l 2G /swapfile

et puis juste démarrer le service

sudo /etc/init.d/mysql restart

Espérons que cette aide. Le meilleur de tous.

0
répondu Vivek 2016-06-21 10:10:50