Ubuntu 16.04 Server MySql open_file_limit ne dépassera pas 65536


16

J'utilise Ubuntu 16.04 Server sur XenServer et je rencontre un problème avec la limite de fichiers ouverts de MySql.

Voici ce que j'ai fait jusqu'à présent:

sudo nano /etc/security/limits.conf (référence)

* soft nofile 1024000
* hard nofile 1024000
* soft nproc 102400
* hard nproc 102400
mysql soft nofile 1024000
mysql hard nofile 1024000

sudo nano /etc/init/mysql.conf (référence)

limit nofile 1024000 1024000
limit nproc 102400 102400

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf (référence)

[mysqld_safe]
open_files_limit = 1024000


[mysqld]
open_files_limit = 1024000

Lorsque ce qui précède n'a pas fonctionné, je suis passé à ce qui suit:

sudo nano /etc/sysctl.conf

fs.file-max = 1024000

sudo nano /etc/pam.d/common-session

session required pam_limits.so

sudo nano /etc/pam.d/common-session-noninteractive

session required pam_limits.so

sudo nano /lib/systemd/system/mysql.service

LimitNOFILE=infinity
LimitMEMLOCK=infinity

Lorsque je me connecte à mon compte utilisateur, tout semble correct:

ulimit -Hn
1024000
ulimit -Sn
1024000

Si je me connecte en tant que mysql, cela semble bien aussi:

mysql@server:~$ ulimit -Hn
1024000
mysql@server:~$ ulimit -Sn
1024000

Cependant, quand je regarde le proc:

ps -ef | grep mysql
cat /proc/1023/limits | grep open
Max open files  65536 65536 files   

Ou quand je le regarde dans MySql:

mysql> show global variables like 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 65536 |
+------------------+-------+

Depuis les journaux (/var/log/mysql/error.log):

2016-07-25T05: 44: 35.453668Z 0 [Avertissement] Impossible d'augmenter le nombre de max_open_files à plus de 65536 (demande: 1024000)

Je suis complètement à court d'idées ici. Au début, j'ai commencé avec open_files_limit à 1024, et l'un des éléments ci-dessus a dû le changer, mais j'en ai besoin pour aller plus haut. J'atteins déjà cette limite car j'ai beaucoup de bases de données et de tables qui ont parfois beaucoup de partitions.

J'ai même essayé des nombres moins agressifs que 1024000, sans succès.

Des idées?

Réponses:


24

Cela a fonctionné pour moi sur Ubuntu Xenial 16.04:

Créez le répertoire /etc/systemd/system/mysql.service.d

Mettez /etc/systemd/system/mysql.service.d/override.conf:

[Service]
LimitNOFILE=1024000

Maintenant, exécutez

systemctl daemon-reload
systemctl restart mysql.service

Oui en effet, LimitNOFILE=infinitysemble effectivement le mettre à 65536.

Vous pouvez valider ce qui précède après avoir démarré MySQL en faisant:

cat /proc/$(pgrep mysql)/limits | grep files

1
Depuis que je suis arrivé ici en premier, mais que je ne me sentais pas satisfait de l'ajustement d'un fichier système, j'ai trouvé un autre fil expliquant comment corriger sans risque le fichier de service écrasé lors de la prochaine mise à niveau: stackoverflow.com/questions/27849331/…
Thomas Urban

Merci @cepharum. J'ai mis à jour la réponse. En effet nous avons déjà rencontré des problèmes sur nos serveurs car nous avons mis à jour le fichier repo /lib/systemd/system/mysql.service. Nous sommes donc déjà passés à la méthode à laquelle vous avez fait référence. J'ai oublié de mettre à jour ma réponse ici. Merci encore pour le rappel.
Jeroen Vermeulen - MageHost

Cette commande ne fonctionne pas: cat / proc / $ (pgrep mysql) / limits | fichiers grep
Basil A

1
@BasilA Cette commande ne fonctionne que lorsque MySQL est en cours d'exécution. Je viens de le tester sur Ubuntu 16.04.
Jeroen Vermeulen - MageHost
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.