Amazon EC2, mysql abandon de commencer parce que InnoDB: mmap (x octets) a échoué; errno 12

Question

J'ai mis en place un micro instance de serveur sur EC2 basé sur ce que j'ai lu ici

mysql server échoue fréquemment et pour la troisième fois que le serveur mysql est allé. Les journaux ne montre

120423 09:13:38 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
120423 09:14:27 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120423  9:14:27 [Note] Plugin 'FEDERATED' is disabled.
120423  9:14:27 InnoDB: The InnoDB memory heap is disabled
120423  9:14:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120423  9:14:27 InnoDB: Compressed tables use zlib 1.2.3
120423  9:14:27 InnoDB: Using Linux native AIO
120423  9:14:27 InnoDB: Initializing buffer pool, size = 512.0M
InnoDB: mmap(549453824 bytes) failed; errno 12
120423  9:14:27 InnoDB: Completed initialization of buffer pool
120423  9:14:27 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120423  9:14:27 [ERROR] Plugin 'InnoDB' init function returned error.
120423  9:14:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120423  9:14:27 [ERROR] Unknown/unsupported storage engine: InnoDB
120423  9:14:27 [ERROR] Aborting

Ce qui est vraiment failed; errno 12? Et comment pourrais-je donner plus d'espace mémoire/ou tout ce qui est nécessaire pour faire cette installation.

- Je résoudre ce problème à chaque fois par le redémarrage de l'ensemble du système et la suppression de tous les journaux et redémarrer le serveur mysql. Mais je sais que quelque chose est incorrect avec ma configuration.

Aussi mon " mon.cnf' est comme ci-dessous :

[mysqld]
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under different user or group,
# customize your systemd unit file for mysqld according to the
# instructions in http://fedoraproject.org/wiki/Systemd
# max_allowed_packet=500M
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0


innodb_buffer_pool_size         = 512M


[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Answer 1

J'ai rencontré le même problème quand j'ai essayé d'exécuter un wordpress sur mon micro instance sans RDS.

L'ajout d'un Swap page résolu le problème pour moi.

Vous pouvez suivre cette configuration le swap page:

http://www.prowebdev.us/2012/05/amazon-ec2-linux-micro-swap-space.html

Si cela ne fonctionne toujours pas pour vous, pensez à utiliser le service RDS.

===============================================

Le lien vers le blog échoue parfois. J'ai copié le contenu ci-dessous pour l'enregistrement. Le crédit va à l'auteur du blog Pedram Moubed:

Micro Instance Amazon EC2 de l'Espace de Swap de Linux

J'ai un Micro Linux Amazon EC2 instance. Depuis les Micro-instances ont seulement 613MB de mémoire, MySQL s'est écrasé à chaque maintenant et puis. Après une longue recherche sur MySQL, Micro Instance et de Gestion Mémoire, je l'ai découvert il n'y a pas de valeur par défaut de l'espace de SWAP pour les Micro-instance. Donc, si vous voulez éviter le crash, vous devrez peut-être configurer un espace d'échange pour votre micro instance. Effectivement performance sage est préférable d'activer le swap.

Les étapes ci-dessous montrent comment faire un espace d'échange pour votre Micro instance. Je suppose que vous avez de Compte AWS avec un Micro instance en cours d'exécution.

1. Exécutez dd if=/dev/zero of=/swapfile bs=1M count=1024
2. Exécutez mkswap /swapfile
3. Exécutez swapon /swapfile
4. Ajoutez cette ligne, /swapfile swap swap defaults 0 0 de /etc/fstab

L'étape 4 est nécessaire si vous souhaitez activer automatiquement le fichier d'échange après chaque redémarrage.

Certains de commande utiles liées à l'espace de SWAP:

$ swapon -s   
$ free -k

$ swapoff -a
$ swapon  -a

Références:

1. http://www.thegeekstuff.com/2010/08/how-to-add-swap-space/
2. http://cloudstory.in/2012/02/getting-the-best-out-of-amazon-ec2-micro-instances/
3. http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/
4. http://aws.amazon.com/ec2/instance-types/

Answer 2

J'ai eu ce problème aussi sur un micro instance Amazon EC2. J'ai essayé la diminution de inno_db l'utilisation de la mémoire par adjonction d' /etc/my.cnf

innodb_buffer_pool_size = 64M

Cela ne fonctionne pas, j'ai essayé de le laisser tomber vers le bas à 16M et toujours il n'a pas fonctionné. Puis j'ai réalisé que l'instance avait essentiellement à zéro de la mémoire libre. J'ai donc essayé de redémarrer apache

sudo système httpd restart
sudo système de mysqld restart

Et tout a bien fonctionné. Peut-être une autre solution est de configurer apache de ne pas consommer beaucoup de mémoire en quelque sorte.

Answer 3

Il semble que vous demandez 128MO de mémoire pour les innodb_buffer_pool_size dans le mon.fichier cfg de vous montrer dans le post, mais MySQL pense que vous demandez 512M de mémoire:

L'initialisation de pool de mémoire tampon, taille = 512.0 M

Quelques lignes plus bas, le message d'erreur vous indique que MySQL ne démarre pas, car il est impossible de réserver suffisamment (512 MO) de mémoire pour le InnoDB pool de mémoire tampon:

Erreur fatale: impossible d'allouer de la mémoire pour le pool de mémoire tampon

Qui se pose trois questions:

1. La quantité de mémoire sur votre instance? Devrait-il y avoir suffisamment de mémoire pour le 512M InnoDB essaie de saisir pour le pool de mémoire tampon, en plus de tout ce MySQL alloue, en plus de votre application(s), en plus du système d'exploitation?
2. Pourquoi est-InnoDB essaie de prendre plus que ce que vous pensez qu'il devrait?
3. Pourquoi est-MySQL redémarrage de toute manière?

Vous pouvez répondre à 1.

De 2., il y a peu d'endroits différents MySQL fichiers d'options peut être situé. Par la suite trouvé les fichiers d'options de remplacement spécifié précédemment fichiers trouvés. Voir

http://dev.mysql.com/doc/refman/5.5/en/option-files.html

Question 3. pourrait être due à une erreur de mémoire insuffisante qui se produit peu de temps après le démarrage. Vous devriez voir une indication de la plus en arrière dans les journaux, si c'est le cas.

Enfin, mais un peu non, êtes-vous à l'aide de l'EBS adossés à des instances? C'est généralement fortement recommandé pour les serveurs de base de données (en fait, pour toutes les instances sauf circonstances particulières). Pour en savoir plus voir

http://stackoverflow.com/a/3630707/141172

Answer 4

Pour moi, ce problème a été corrigé par l'ajout d'un swap de volume à mon instance EC2. Mes services ont été tout simplement consommer toute la mémoire sur la boîte, et le crash. Pas quelque chose qui m'a été utilisé pour, être une RedHat/CentOS admin pendant des années - Anaconda est BEAUCOUP de travail que la libre Ubuntu instance EC2 ne le fait pas.

J'ai tout simplement créé un 2 go de volume par l'intermédiaire de la console web, attaché à mon exemple, et n'a "mkswap /dev/[]", édité le fichier /etc/fstab, et le bruit s'est arrêté.

Ces instances ne PAS installer comme un support à base installation du système d'exploitation que la plupart d'entre nous sont utilisés - c'est dépouillé avec pas de colis, pas de système de fichiers, et des choses comme AppArmor, ce qui cause toutes sortes de problèmes si vous n'êtes pas conscient de lui-même et/ou ne savent pas comment le configurer.