MySQL max_open_files więcej niż 1024


11

Podczas uruchamiania MariaDB otrzymałem [Ostrzeżenie] Nie mogłem zwiększyć liczby max_open_files do więcej niż 1024 (żądanie: 4607)

$ sudo systemctl status mysqld
● mysqld.service - MariaDB database server
  Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
  Active: activating (start-post) since Tue 2014-08-26 14:12:01 EST; 2s ago
Main PID: 8790 (mysqld);         : 8791 (mysqld-post)
  CGroup: /system.slice/mysqld.service
      ├─8790 /usr/bin/mysqld --pid-file=/run/mysqld/mysqld.pid
      └─control
    ├─8791 /bin/sh /usr/bin/mysqld-post
    └─8841 sleep 1

Aug 26 14:12:01 acpfg mysqld[8790]: 140826 14:12:01 [Warning] Could not increase number of max_open_files to more than 1024 (request: 4607)

Próbowałem bezskutecznie rozwiązać problem z max_open_files w tym pliku:

$ sudo nano /etc/security/limits.conf 
mysql           hard    nofile          8192
mysql           soft    nofile          1200

Zrestartowałem nawet komputer, ale mam ten sam problem.

Plik /etc/mysql/my.cnf wygląda następująco:

[mysql]

# CLIENT #
port                           = 3306
socket                         = /home/u/tmp/mysql/mysql.sock

[mysqld]

# GENERAL #
user                           = mysql
default-storage-engine         = InnoDB
socket                         = /home/u/tmp/mysql/mysql.sock
pid-file                       = /home/u/tmp/mysql/mysql.pid

# MyISAM #
key-buffer-size                = 32M
myisam-recover                 = FORCE,BACKUP

# SAFETY #
max-allowed-packet             = 16M
max-connect-errors             = 1000000
skip-name-resolve
sql-mode                       = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY
sysdate-is-now                 = 1
innodb                         = FORCE
innodb-strict-mode             = 1

# DATA STORAGE #
datadir                        = /home/u/tmp/mysql/

# BINARY LOGGING #
log-bin                        = /home/u/tmp/mysql/mysql-bin
expire-logs-days               = 14
sync-binlog                    = 1

# CACHES AND LIMITS #
tmp-table-size                 = 32M
max-heap-table-size            = 32M
query-cache-type               = 0
query-cache-size               = 0
max-connections                = 500
thread-cache-size              = 50
open-files-limit               = 65535
table-definition-cache         = 1024
table-open-cache               = 2048

# INNODB #
innodb-flush-method            = O_DIRECT
innodb-log-files-in-group      = 2
innodb-log-file-size           = 128M
innodb-flush-log-at-trx-commit = 1
innodb-file-per-table          = 1
innodb-buffer-pool-size        = 2G

# LOGGING #
log-error                      = /home/u/tmp/mysql/mysql-error.log
log-queries-not-using-indexes  = 1
slow-query-log                 = 1
slow-query-log-file            = /home/u/tmp/mysql/mysql-slow.log

Jak można rozwiązać problem z max_open_files?


Czy zrestartowałeś mySql od czasu zmiany limitów? Te rzeczy na ogół nie są po prostu propozycją zmiany pliku, proces zwykle musi zostać ponownie uruchomiony, aby odebrać zmianę. Możesz również sprawdzić limity za pomocą polecenia ulimit. Czy zrestartowałeś się od czasu zmiany?
mdpc

Ponownie uruchomiłem komputer, zmieniłem limity. Patrząc na wynik ulimit, moje zmiany nie zadziałały: $ ulimit unlimited $ ulimit -Sa | grep „otwórz pliki” otwórz pliki (-n) 1024 $ ulimit -Ha | grep „otwórz pliki” otwórz pliki (-n) 4096. Co może być nie tak?
user977828,

Odpowiedzi:


17

Edytuj /etc/security/limits.confi dodaj następujące wiersze

mysql soft nofile 65535
mysql hard nofile 65535

następnie uruchom ponownie.

Następnie edytuj /usr/lib/systemd/system/mysqld.servicelub /usr/lib/systemd/system/mariadb.servicedodaj

LimitNOFILE=infinity
LimitMEMLOCK=infinity

Następnie uruchom ponownie usługę db:

systemctl reload mariadb.service

1
Pamiętaj, że przynajmniej w wersji systemowej 209 nieskończoność oznacza 65535. Jeśli chcesz więcej, po prostu podaj numer, a nie nieskończoność.
sivann

3
W przypadku Mariadb 5.5 w wersji RHEL 7 komentarze w tym pliku (/usr/lib/systemd/system/mariadb.service) ostrzegają, aby nie edytować samego pliku, ale raczej utworzyć katalog service.d zawierający plik jak: /etc/systemd/system/mariadb.service.d/foo.conf. Pamiętaj, aby dodać „[Service]” na górze tego pliku, przed tymi dwiema liniami Limit. Zaleca także „systemctl --system daemon-reload” po każdej zmianie. Te szczegóły doprowadziły mnie do szału o dodatkową godzinę ciągnięcia włosów!
IcarusNM

To nie działa w Ubuntu 14.04 z MySQL 5.7. Pliki usługi nie istnieją, a pakiet systemctl nie jest zainstalowany.
Ty.

Check /etc/systemd/system/mysql.service.d/limits.confor /etc/systemd/system/mariadb.service.d/limits.conf It działało dla mnie bezbłędnie
Luka

2

Innym powodem jest to, że:
Musisz zwrócić uwagę natable_open_cach

kod mysql w mysqld.cc

wanted_files= 10 + max_connections + table_cache_size * 2;

spróbuj z niższą table_open_cachwartością


1

Oficjalną instrukcję można zobaczyć w pliku mariadb.service;

[root@mariadb5.5 /]# cat /usr/lib/systemd/system/mariadb.service | grep exam -A 5
# For example, if you want to increase mariadb's open-files-limit to 10000,
# you need to increase systemd's LimitNOFILE setting, so create a file named
# "/etc/systemd/system/mariadb.service.d/limits.conf" containing:
#       [Service]
#       LimitNOFILE=10000

Musi zrestartować system operacyjny. Chociaż myślę, że należy to zapisać w oficjalnym podręczniku ...


1
Nie musiałem restartować się na Fedorze 28. Poprosiłem tylko o uruchomienie systemctl daemon-reloadpodczas restartowania MariaDB.
DanMan,

0

Miałem ten sam problem z Ubuntu 15.10 i mysql i naprawiłem go z poprzednią odpowiedzią z niewielkimi różnicami.

Najpierw zmieniłem /etc/security/limits.confjak wyżej.

Dodałem (nic więcej)

LimitNOFILE=infinity

do /lib/systemd/system/mysql.service(mała różnica lokalizacji)

a potem zrobił

systemctl daemon-reload
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.