web-dev-qa-db-fra.com

MySQL (InnoDB) ferme tous les jours à la même heure

Ok, j'ai récemment envoyé une grosse mise à jour de mon projet sur mon serveur Ubuntu 14.

Jusqu'à présent, il est stable, mais depuis la poussée à exactement :36 GMT chaque jour mysql est tué !! Ce n’est pas idéal, car nous avons besoin du maximum de temps de disponibilité. J'ai accéléré la consignation des erreurs pour voir si je peux le récupérer la prochaine fois.

Pas lié aux ressources, je ne pense pas ...

J'ai vérifié les éléments suivants:

  • Ressources du serveur. Rien ne pique, c'est stable et plus que suffisant RAM disponible ~ 200 Mo au moins libre. Utiliser Scoutapp pour suivre cela.
  • Aucun cron ne court à l'heure exacte.
  • Le key_buffer_size faisait 16 Mo. Je viens de le mettre à 32 Mo. Mais je ne vois rien qui pourrait causer cela.

Journal des erreurs

Cependant, j'ai vérifié les journaux au moment de l'accident et voici ce qu'il y a dedans:

141123 00:36:47 mysqld_safe Number of processes running now: 0 
141123 00:36:47 mysqld_safe mysqld restarted
141123  0:36:48 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead. 
141123  0:36:48 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead. 
141123  0:36:48 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead. 
141123  0:36:48 [Note] Plugin 'FEDERATED' is disabled. 
141123  0:36:48 InnoDB: The InnoDB memory heap is disabled 
141123  0:36:48 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
141123  0:36:48 InnoDB: Compressed tables use zlib 1.2.8 
141123  0:36:48 InnoDB: Using Linux native AIO 
141123  0:36:48 InnoDB: Initializing buffer pool, size = 128.0M InnoDB: mmap(137363456 bytes) failed; errno 12 
141123  0:36:48 InnoDB: Completed initialization of buffer pool 
141123  0:36:48 InnoDB: Fatal error: cannot allocate memory for the buffer pool 
141123  0:36:48 [ERROR] Plugin 'InnoDB' init function returned error. 
141123  0:36:48 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 
141123  0:36:48 [ERROR] Unknown/unsupported storage engine: InnoDB 
141123  0:36:48 [ERROR] Aborting

141123  0:36:48 [Note] /usr/sbin/mysqld: Shutdown complete

141123 00:36:48 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

Donc, cela signifie-t-il ...?

Cela signifie-t-il que le moteur InnoDB doit être configuré? J'ai réalisé que les variables my.cnf doivent être modifiées mais ce ne sont que des avertissements.

Fatal error: cannot allocate memory for the buffer pool me fait penser que je dois définir une taille de pool de mémoire tampon pour InnoDB qui est plus petite, si oui, comment?

En outre, cela ne se produisait pas avant la mise à jour. Mais le VPS ne compte que 512 Mo RAM et le trafic augmente ainsi que la complexité des applications, en particulier avec la nouvelle mise à jour.

Ce que je ne comprends pas, c’est pourquoi il se passe le exact à la même heure chaque jour. Ubuntu exécute-t-il des mises à jour ou existe-t-il un calendrier sur Ubuntu que je devrais connaître, cela consomme peut-être de la mémoire?

Merci

-Stefan

14.04servermysqlwebserver
4
Stefan

Je suggère que vous devez vérifier le ci-dessous fourni dans votre serveur.

  1. Si un cron est en cours d'exécution sur le serveur. Vous pouvez utiliser le fichier journal du travail cron pour le vérifier. Le fichier journal se trouve dans le chemin:/var/log/syslog

  2. Le contrôle de la charge moyenne à ce moment précis vous aidera également si un autre processus consommateur de charge a été lancé à ce moment. Vous pouvez consulter le syslog à l’emplacement/var/log pour le tracer.

  3. Essayez de réduire votre taille key_buffer_ à 1Mo et observez si elle se plante encore. Si vous rencontrez toujours un problème, la mise à niveau RAM devrait être la dernière option.

  4. Je vous recommande également de lancer un script mysqltuner et de me laisser savoir le résultat.

1
Jaison V John