le service mysqld s'arrête une fois par jour sur le serveur ec2
Détails sur l'environnement:
Server: Amazon ec2 Linux
Web Server: Apache
Web Framework: Django with mod_wsgi
Après j'ai trouvé dans le fichier 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
Il semble que la mémoire système ne soit pas suffisante pour allouer de la mémoire au pool de mémoire tampon. La même erreur se produit lorsque j’utilisais Amazon ec2 micro instance, j’ai donc migré vers le small instance. Cela fonctionne bien pendant quelques jours, mais maintenant, il se brise à nouveau une fois par jour. Y at-il une solution permanente pour cela? Je peux passer à l'instance moyenne, mais le problème est de savoir si cela sera corrigé ou non. 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 (cela aidera peut-être):
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 du système d'exploitation (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 du serveur comme il ne lui reste que 15 Mo de mémoire et voici le processus httpd en cours d'exécution à ce moment:
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
Quelqu'un peut-il avoir une idée à ce sujet, pourquoi il y a tant de processus httpd ??
Utilisez 50% de la RAM disponible pour tester:
Vous pouvez diminuer très faiblement innodb_buffer_pool_size pour voir si cela aide:
#/etc/my.cnf
innodb_buffer_pool_size = 1M
En règle générale, définissez innodb_buffer_pool_size sur 50% de la RAM disponible pour vos tests de mémoire insuffisante. Cela signifie que vous démarrez le serveur et tout sauf MySQL InnoDB. Voir combien RAM vous avez. Ensuite, utilisez 50% de cela pour InnoDB.
Pour essayer plusieurs paramètres de mémoire faible à 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 tel est le cas, essayez de réduire sa consommation RAM. Par exemple, dans Apache conf, considérez les paramètres RAM faibles, comme ceux-ci:
StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5
Et coiffez 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 cela se produit encore, votre Django est peut-être en croissance constante. Essayez de profiler la mémoire de Django avec Pympler:
SAR:
Votre rapport d'échecs une fois par jour, puis une fois par semaine, pourrait indiquer une sorte de travail cron exécuté quotidiennement ou hebdomadairement. Par exemple, il existe peut-être un processus de traitement par lots prenant beaucoup de RAM, un vidage de la base de données, etc.
Pour suivre l'utilisation de RAM et rechercher les pointes de RAM dans l'heure qui précède la mort de MySQL, jetez un œil à SAR, qui est un outil formidable: http://www.thegeekstuff.com/2011/ 03/sar-exemples/
Vous devez vous diminuer 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/
Comme d'autres l'ont mentionné, le problème semble être que votre système manque de mémoire RAM et que MySQL explose à cause de cela. Vous trouverez ci-dessous comment procéder pour réduire l'utilisation de la mémoire de votre système et pour restaurer la base de données.
Regardez collectd et ses plugins. Certains de ceux applicables peuvent être le plugin -processus et le plugin mémoire . Avec ceux-ci, vous pouvez voir l'utilisation de la mémoire de vos systèmes et quels processus en prennent la majeure partie.
Selon la manière dont vous exécutez Django, vous pouvez configurer les processus de travail pour ne traiter qu'un certain nombre de demandes, puis pour les terminer. Ainsi, s'il existe une fuite de mémoire dans votre application, celle-ci ne persistera pas après le nombre de demandes. Par exemple, si vous utilisez Gunicorn , vous pouvez utiliser l’option --max-request . Si vous le définissez à 500, le travailleur sera abandonné après avoir traité 500 demandes.
La combinaison ci-dessus avec la collecte de statistiques vous montrera certaines tendances d'utilisation de la mémoire intéressantes.
Pour ce qui est de la base de données en panne, vous pouvez configurer le processus de supervision de sorte que si MySQL meurt, il sera automatiquement relancé. MySQL dans la dernière version d'Ubuntu utilise Upstart pour faire exactement cela. Si le processus meurt, Upstart le remettra immédiatement. Si vous utilisez une autre distribution ne disposant pas de cette fonctionnalité, consultez Supervisor . Bien que cela ne résolve pas le problème, il en atténuera au moins les effets. Cela ne doit pas être considéré comme une solution, mais plutôt comme un moyen de garder votre application en marche au cas où quelque chose se passerait mal.
Une fois que je me suis retrouvé coincé dans des problèmes similaires, j'étais vraiment frustré que mes utilisateurs voient ce message déplaisant Erreur lors de l'établissement de la connexion à la base de données. Au lieu de résoudre les problèmes exacts, j'ai trouvé ce dépôt fonctionner comme un charme pour moi (temporairement). Après cela, mon ami l’a débogué et il vient de peaufiner les modifications apportées à la configuration de mon serveur. Mais j'ai quand même ajouté ce script à ma crontab toutes les 10 minutes, puis je vérifie si le serveur est en panne (ce qui pour mon cas s'est éventuellement arrêté lorsque j'exécute VNCServer sur mon serveur), puis le redémarre
Augmenter la RAM disponible en ajoutant un nouvel espace de swap peut également aider. Les étapes sont ici
Assurez-vous de créer un fichier/fichier d'échange d'une taille inférieure à l'espace disponible indiqué par
df -h
Par exemple, pour moi, la sortie 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
J'ai donc créé en utilisant 2 G
Sudo fallocate -l 2G /swapfile
Et puis juste commencer le service
Sudo /etc/init.d/mysql restart
J'espère que cela t'aides. Bonne chance.