I have a MySQL 5.7 server on Ubuntu 18. When the server starts it writes the following warnings in the error.log:
[Warning] Changed limits: max_open_files: 5000 (requested 7500)
[Warning] Changed limits: table_open_cache: 1745 (requested 2000)
Can somebody explain what is causing these warnings (and what I can do to make them go away)?
Answering my own question. The limit for max open files is defined in the systemd script /lib/systemd/system/mysql.service:
# MySQL systemd service file
[Unit]
Description=MySQL Community Server
After=network.target
....
LimitNOFILE=5000
Increasing the value of LimitNOFILE to 7500 solved both warnings.
Related
I am running MySQL on WSL2 for Windows. At WSL2 startup, MySQL does not start and I get the following error:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
I then run this command to get it going:
sudo service mysql start
And get the following output:
* Starting MySQL database server mysqld
su: warning: cannot change directory to /nonexistent: No such file or directory
[ OK ]
When I check my MySQL error logs, I see this error regarding max_open_files and table_open_cache:
2022-07-28T08:36:34.074107Z 0 [Warning] [MY-010139] [Server] Changed limits: max_open_files: 1024 (requested 8161)
2022-07-28T08:36:34.074111Z 0 [Warning] [MY-010142] [Server] Changed limits: table_open_cache: 431 (requested 4000)
My understanding is I need to edit my /lib/systemd/system/mysql.service file to change this, but when I check that file I see that LimitNOFILE is already set to 10000
# MySQL systemd service file
[Unit]
Description=MySQL Community Server
After=network.target
[Install]
WantedBy=multi-user.target
[Service]
Type=notify
User=mysql
Group=mysql
PIDFile=/run/mysqld/mysqld.pid
PermissionsStartOnly=true
ExecStartPre=/usr/share/mysql/mysql-systemd-start pre
ExecStart=/usr/sbin/mysqld
TimeoutSec=infinity
Restart=on-failure
RuntimeDirectory=mysqld
RuntimeDirectoryMode=755
LimitNOFILE=10000
# Set enviroment variable MYSQLD_PARENT_PID. This is required for restart.
Environment=MYSQLD_PARENT_PID=1
It's almost as if that setting get's ignored at service startup? Does anyone know where the right place is to set it if this isn't?
You need to check information in /etc/security/limits.conf
You can add something like (assuming you run mysqld as mysql user)
mysql hard nofile 10000
mysql soft nofile 8192
and in my.cnf
[mysqld]
open_files_limit = 10000
table_open_cache=4096
then logout, login and restart mysql
I am running a docker container locally on Ubuntu VM. The container is constantly getting restarted.
Logs while running pod
Error response from daemon: Container 8345404f85a30f71d18e420eb064ef2104748f1f7b6d3a is restarting, wait until the container is running
Output of docker ps
8345404f85a3 mysql:5.7.23 "docker-entrypoint.s…" 5 minutes ago Restarting (1) 29 seconds ago
POD Error logs
2020-09-23T05:00:35.302191Z 0 [Warning] option 'max_binlog_size': unsigned value 10485760000 adjusted to 1073741824
2020-09-23T05:00:35.302252Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2020-09-23T05:00:35.303732Z 0 [ERROR] Could not open file '/var/log/mysql/error.log' for error logging: Is a directory
2020-09-23T05:00:35.307546Z 0 [ERROR] Aborting
Initializing database
2020-09-23T05:01:01.866333Z 0 [Warning] option 'max_binlog_size': unsigned value 10485760000 adjusted to 1073741824
2020-09-23T05:01:01.866398Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2020-09-23T05:01:01.872326Z 0 [ERROR] Could not open file '/var/log/mysql/error.log' for error logging: Is a directory
2020-09-23T05:01:01.872464Z 0 [ERROR] Aborting
It looks like that the error cannot open file /var/log/mysql/error.log is the primary problem. Yo should check if that location exists, and the permissions on it are correct. See this for a similar case: https://support.plesk.com/hc/en-us/articles/115004039393-Unable-to-start-mysql-var-log-mysql-error-log-Permission-denied. Maybe the image expects that there is a volume mounted for logging. Is there something about that in the documentation?
Im going to install mysql to linux server. But I dont have root access to that server. So I created two folders called mysql and mysqldata. mysql folder holds binary files. mysqldata folder holds data and the logs.
my.cnf
[mysqld]
user = mysql
port = 3306
bind-address = localhost
basedir = /home/nwn/mysql/mysql-8.0
socket = /home/nwn/mysqldata/instA/socket/mysql.sock
datadir = /home/nwn/mysqldata/instA/data
tmpdir = /home/nwn/mysqldata/instA/tmp
secure_file_priv = /home/nwn/mysqldata/instA/mysql-files
max_connections = 150
# Logging
log-bin = /home/nwn/mysqldata/instA/logs/instA-binlog
log-error = /home/nwn/mysqldata/instA/logs/instA-errorlog.err
slow_query_log = 1
slow_query_log_file = /home/nwn/mysqldata/instA/logs/instA-slowquery.log
long_query_time = 0.5
# InnoDB
innodb_data_home_dir = /home/nwn/mysqldata/instA/innodb/data
innodb_data_file_path = ibdata1:50M;ibdata2:12M:autoextend:max:500M
innodb_log_group_home_dir = /home/nwn/mysqldata/instA/innodb/log
innodb_buffer_pool_size = 32M
# MyISAM
key_buffer_size = 16M
server_id = 1
I did all the other configurations.
when I run following command
mysql-8.0]$ bin/mysqld --defaults-file=~/mysqldata/instA/my.cnf --initialize-insercure
I have following logs in the error_log
cat ~/mysqldata/instA/logs/instA-errorlog.err
2018-10-09T10:39:51.127424Z 0 [Warning] [MY-010139] [Server] Changed limits: max_open_files: 1024 (requested 8160)
2018-10-09T10:39:51.127523Z 0 [Warning] [MY-010142] [Server] Changed limits: table_open_cache: 432 (requested 4000)
2018-10-09T10:39:51.383986Z 0 [Warning] [MY-010101] [Server] Insecure configuration for --secure-file-priv: Location is accessible to all OS users. Consider choosing a different directory.
2018-10-09T10:39:51.384043Z 0 [System] [MY-010116] [Server] /home/nwn/mysql/mysql-8.0/bin/mysqld (mysqld 8.0.12) starting as process 32654
2018-10-09T10:39:51.386625Z 0 [Warning] [MY-010122] [Server] One can only use the --user switch if running as root
2018-10-09T10:39:51.394675Z 1 [ERROR] [MY-011011] [Server] Failed to find valid data directory.
2018-10-09T10:39:51.394817Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2018-10-09T10:39:51.394831Z 0 [ERROR] [MY-010119] [Server] Aborting
2018-10-09T10:39:51.395363Z 0 [System] [MY-010910] [Server] /home/nwn/mysql/mysql-8.0/bin/mysqld: Shutdown complete (mysqld 8.0.12) MySQL Community Server - GPL.
Even though the post is very old, but posting my solution as it took me around 2 hours to figure it out and this can help someone save that time.
You can try doing :
shell> mysqld --initialize
This shall initialse the data directory in the path where you have installed MySql server. Generally placed at C:\Program Files\MySQL\MySQL Server 8.0.
Hope it helps someone.
Please follow these steps to reset your MySQL Password on Windows:
Stop MySQL Service # services.msc
Create file change_mysql_pwd.txt with following content (replase YourNewPassword with desired new password you want to have for root user:
ALTER USER 'root'#'localhost' IDENTIFIED BY 'YourNewPassword';
Save the file under C:\ change_mysql_pwd.txt
Run CMD.exe as Admin (Start->Cmd->Right Click->Run as Administrator)
Type in cmd: cd "C:\Program Files\MySQL\MySQL Server 8.0\bin"
Create “Data” Folder under "C:\Program Files\MySQL\MySQL Server 8.0\ (if already exists delete its contents!)
Type in cmd: mysqld --install
Type in cmd: mysqld --initialize
Type in cmd: mysqld --init-file=C:\\change_mysql_pwd.txt
Login with root user account and the password set above.
Delete C:\ change_mysql_pwd.txt file
Enjoy...
(context: new setup, mysql 8 on windows server 2016)
What really helped me to get rid of "Failed to find valid data directory" was:
mysqld --initialize --console
The --console part tells you straight away on the command line what is wrong and what to do. Because I had a clean install, i lacked the "data" directory. However if you have settings in your my.ini that are not supported in the newly installed version, a "data" directory will be generated nevertheless with the command listed above. If you have more then one faulty setting in my.ini, you'll need to delete the newly created "data" directory first.
CAUTION: check first if you have databases in the data directory, else you'll loose all your databases!! So only use this on fresh installs.
In steps:
run mysqld --initialize --console from a cmd as administrator
fix the my.ini faulty line, delete the data directory (ONLY IF YOU HAVE A NEW INSTALLATION: else you'll loose all your databases!)
rerun mysqld --initialize --console
repeat until all errors are fixed.
Now MySql should start.
As far as I understand from your console output you try to initialize the database while there exist files in your data directory. First you should remove all files (please be careful here, you may loss your data) in the data directory of your MySQL, and then you should run the command below
shell> mysqld --initialize --console
as stated by #Alex Karshin, #Lazycoder_0071 and #Freeze_H. MySQL should initialize the database seamlessly if there isn't another problem.
What Kevin Kopf and Lazycoder_007 indicate in https://stackoverflow.com/a/62003723/7733418 worked for me fine, along with
deleting the files within the "data" folder before initialization (thanks to P D)
running mysqld --initialize in cmd as administrator
While trying to repair a corrupted table which it stuck at optimizing stage for 12 hours, my smartness went ahead and rebooted the server
After reboot mysql won't start
Running mariadb 10.1.20
Storage Engine AREA
RAM 32 gb
OS: Centos 6.7
My.cnf
#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]
[mysqld]
port = 3306
default-storage-engine = aria
aria-pagecache-buffer-size = 1024M
skip_name_resolve
skip-networking
bulk_insert_buffer_size = 8M
connect_timeout = 10
interactive_timeout = 50
query_cache_type = 0
query_cache_limit = 10M
query_cache_min_res_unit = 2k
query_cache_size = 0
table_open_cache = 2048
thread_stack = 256K
transaction_isolation = REPEATABLE-READ
read_buffer_size = 2M
read_rnd_buffer_size = 16M
sort_buffer_size = 8M
table_cache = 4096
join_buffer_size = 10M
key_buffer_size = 512M
max_allowed_packet = 16M
bulk_insert_buffer_size = 64M
myisam_recover_options = BACKUP, FORCE
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 5G
thread_cache_size = 1024
max_heap_table_size = 64M
tmp_table_size = 64M
thread_handling = pool-of-threads
wait-timeout = 30
interactive-timeout = 30
concurrent_insert = 2
net_buffer_length = 2K
wait_timeout = 300
host_cache_size = 2000
max_connections = 1000
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
So i tried myisamchk
myisamchk --silent --force --fast --update-state /var/lib/mysql//.MYI
myisamchk: MyISAM file /var/lib/mysql/fmartinto2/core_members.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/fmartinto2/core_sessions.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/content_gener.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/content.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/content_playlist.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/content_views.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/emails_queue.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/episodes.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/links.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/link_votes.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/messages.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/playlists.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/playlist_views.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/users.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/watched_already.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/watchlist.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
Then used it again with more memory
myisamchk --silent --force --fast --update-state \
--key_buffer_size=512M --sort_buffer_size=512M \
--read_buffer_size=4M --write_buffer_size=4M \
/var/lib/mysql/*/*.MYI
Returned empty After i removed --silent and re run it again it return
MyISAM file: /var/lib/mysql/martin_new/users.MYI is already checked
Mysql Error log:
161221 20:30:55 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
/usr/sbin/mysqld: Can't read dir of '/etc/my.cnf.' (Errcode: 2 "No such file or directory")
Fatal error in defaults handling. Program aborted
161221 20:30:55 mysqld_safe mysqld from pid file /var/lib/mysql/martin.cr.pid ended
161221 20:35:00 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
/usr/sbin/mysqld: Can't read dir of '/etc/my.cnf.' (Errcode: 2 "No such file or directory")
Fatal error in defaults handling. Program aborted
161221 20:35:00 mysqld_safe mysqld from pid file /var/lib/mysql/martin.cr.pid ended
161221 20:50:32 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2016-12-21 20:50:32 140464028563488 [Note] /usr/sbin/mysqld (mysqld 10.1.20-MariaDB) starting as process 3489 ...
2016-12-21 20:50:32 140464028563488 [Note] mysqld: Aria engine: starting recovery
recovered pages: 0% 10% 20% 30% 40%161221 20:50:33 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.1.20-MariaDB
key_buffer_size=536870912
read_buffer_size=2097152
max_used_connections=0
max_threads=1001
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10795087 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0x7fc0552f85cb]
/usr/sbin/mysqld(handle_fatal_signal+0x4d5)[0x7fc054e51375]
/lib64/libpthread.so.0(+0x375780f7e0)[0x7fc0544537e0]
/usr/sbin/mysqld(+0x99f356)[0x7fc055222356]
/usr/sbin/mysqld(+0x9a09ad)[0x7fc0552239ad]
/usr/sbin/mysqld(+0x9a444c)[0x7fc05522744c]
/usr/sbin/mysqld(+0x9a4f0e)[0x7fc055227f0e]
/usr/sbin/mysqld(+0x97dc4d)[0x7fc055200c4d]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x68)[0x7fc054e538d8]
/usr/sbin/mysqld(+0x46ded5)[0x7fc054cf0ed5]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x8da)[0x7fc054cf1e3a]
/usr/sbin/mysqld(+0x3ce045)[0x7fc054c51045]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x1d9b)[0x7fc054c5395b]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7fc052865d1d]
/usr/sbin/mysqld(+0x3c4999)[0x7fc054c47999]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
161221 20:50:33 mysqld_safe mysqld from pid file /var/lib/mysql/martin.cr.pid ended
161221 20:56:50 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2016-12-21 20:56:51 140139510470688 [Note] /usr/sbin/mysqld (mysqld 10.1.20-MariaDB) starting as process 2830 ...
2016-12-21 20:56:51 140139510470688 [Note] mysqld: Aria engine: starting recovery
recovered pages: 0% 10% 20% 30% 40%161221 20:56:51 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.1.20-MariaDB
key_buffer_size=536870912
read_buffer_size=2097152
max_used_connections=0
max_threads=1001
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10795087 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0x7f74c66665cb]
/usr/sbin/mysqld(handle_fatal_signal+0x4d5)[0x7f74c61bf375]
/lib64/libpthread.so.0(+0x375780f7e0)[0x7f74c57c17e0]
/usr/sbin/mysqld(+0x99f356)[0x7f74c6590356]
/usr/sbin/mysqld(+0x9a09ad)[0x7f74c65919ad]
/usr/sbin/mysqld(+0x9a444c)[0x7f74c659544c]
/usr/sbin/mysqld(+0x9a4f0e)[0x7f74c6595f0e]
/usr/sbin/mysqld(+0x97dc4d)[0x7f74c656ec4d]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x68)[0x7f74c61c18d8]
/usr/sbin/mysqld(+0x46ded5)[0x7f74c605eed5]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x8da)[0x7f74c605fe3a]
/usr/sbin/mysqld(+0x3ce045)[0x7f74c5fbf045]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x1d9b)[0x7f74c5fc195b]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f74c3bd3d1d]
/usr/sbin/mysqld(+0x3c4999)[0x7f74c5fb5999]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
161221 20:56:51 mysqld_safe mysqld from pid file /var/lib/mysql/martin.cr.pid ended
161221 21:00:05 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2016-12-21 21:00:05 139723942508576 [Note] /usr/sbin/mysqld (mysqld 10.1.20-MariaDB) starting as process 3404 ...
2016-12-21 21:00:05 139723942508576 [Note] mysqld: Aria engine: starting recovery
recovered pages: 0% 10% 20% 30% 40%161221 21:00:06 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.1.20-MariaDB
key_buffer_size=536870912
read_buffer_size=2097152
max_used_connections=0
max_threads=1001
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10795087 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0x7f14049e85cb]
/usr/sbin/mysqld(handle_fatal_signal+0x4d5)[0x7f1404541375]
/lib64/libpthread.so.0(+0x375780f7e0)[0x7f1403b437e0]
/usr/sbin/mysqld(+0x99f356)[0x7f1404912356]
/usr/sbin/mysqld(+0x9a09ad)[0x7f14049139ad]
/usr/sbin/mysqld(+0x9a444c)[0x7f140491744c]
mysys/stacktrace.c:268(my_print_stacktrace)[0x7f1404917f0e]
maria/ha_maria.cc:3594(ha_maria_init)[0x7f14048f0c4d]
sql/handler.cc:513(ha_initialize_handlerton(st_plugin_int*))[0x7f14045438d8]
sql/sql_plugin.cc:1408(plugin_initialize)[0x7f14043e0ed5]
sql/sql_plugin.cc:1678(plugin_init(int*, char**, int))[0x7f14043e1e3a]
sql/mysqld.cc:5196(init_server_components)[0x7f1404341045]
sql/mysqld.cc:5787(mysqld_main(int, char**))[0x7f140434395b]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f1401f55d1d]
/usr/sbin/mysqld(+0x3c4999)[0x7f1404337999]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
161221 21:00:06 mysqld_safe mysqld from pid file /var/lib/mysql/martin.cr.pid ended
Use the myisamcheck tool to 'repair' the MyISAM tables. I don't know if there is a corresponding took for aria tables, but that seems to be where it blew up.
Suggest filing a bug report with mariadb.com
I searched about the topic subject and tested options, but I still cant increase the open-files-limit on my mariadb server that is used as remote database server for cpanel/whm server.
here is s good reference
http://duntuk.com/how-raise-ulimit-open-files-and-mysql-openfileslimit
I increased it in
/etc/my.cnf
open-files-limit=65550
here is some results
#ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63471
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65535
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 65535
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
#ulimit -Hn -Sn
open files (-n) 65535
open files (-n) 65535
cat /etc/systemd/system/mariadb.service.d/limits.conf
[Service]
LimitNOFILE=65500
cat /usr/lib/systemd/system/mariadb.service
[Unit]
Description=MariaDB database server
After=syslog.target
After=network.target
[Service]
Type=simple
User=mysql
Group=mysql
LimitNOFILE=infinity
LimitMEMLOCK=infinity
and still in mysql I get
show global variables like 'open%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| open_files_limit | 1024 |
+------------------+-------+
1 row in set (0.00 sec)
and im getting following error over and over after restart
60108 16:30:02 [ERROR] mysqld: Can't open file: './username_wp/wp_users.frm' (errno: 24)
160108 16:30:02 [ERROR] Error in accept: Too many open files
160108 16:30:04 [ERROR] Error in accept: Too many open files
160108 16:30:06 [ERROR] Error in accept: Too many open files
160108 16:30:11 [ERROR] mysqld: Can't open file: './username_db/strikes.frm' (errno: 24)
and here is the startup log of mariadb
[Warning] Could not increase number of max_open_files to more than 1024 (request: 132107)
RH/CentOS mariadb integration is quiet confusing, using in some places mariadb as its name, mysqld elsewhere...
You should edit(or create) a .conf file in
/etc/systemd/system/mariadb.service.d/
For eg: /etc/systemd/system/mariadb.service.d/centreon.conf
Then edit it as kujiy suggested
[Service]
LimitNOFILE=320000
Don't forget to reload systemd services files:
# systemctl daemon-reload
Cedric
This is an OS problem.
I think you have to increase the "hard limit" in /etc/security/limits.conf, something like this:
* hard nofile 65536
* soft nofile 16384
then use ulimit to increase the "soft limit".
finally i find solution but without any reasonable cause !
i was running MariaDB 5.5 and all settings where fine but the soft limit did not goes more than 1024 !
i was thinking my mariadb is 10.0 as i freshly installed it
after i find out that its 5.5 i tried to upgrade it to v10.0 ! and then BOOM ! problem solved without any extra action or setting ( kernel setting allows maximum files limit as described in reference link )
i hope it help other peoples have same problem ( but after try all other required settings )
You can see the official instruction in the mariadb.service file;
[root#db1 system]# 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
Though I think this should be written in the official manual...
I have CentOS 7.3 with MariaDB 10.0.29 installed from official repo.
For some reason, systemd unit is named mysql and I had to create /etc/systemd/system/mysql.service.d/oioki.conf:
[Service]
LimitNOFILE=500000
Don't forget to run systemctl daemon-reload after that.
open_files_limit is dynamic value that depends on next params:
#my.cnf file
# max connections
max_connections = 64
# table_open_cache = max_connections * tables used in one transaction + 5
table_open_cache = 800
# table_definition_cache = all tables(50) + max_connections + 5
table_definition_cache = 400
# open_files_limit = table_open_cache * 1.4
open_files_limit = 1120
To check the value of open_files_limit run this command from mysql:
mysql> select ##open_files_limit;
...it will output:
+--------------------+
| ##open_files_limit |
+--------------------+
| 12903 |
+--------------------+
1 row in set (0.000 sec)
I had this problem running RedHat Enterprise Linux 7.2 with Software Collections (SCL) and SystemD
rh-mariadb100-mariadb-server-10.0.20-1.el7.x86_64
In my case the hard limit was ok, but the soft limit was stuck on 1024
Summary of the old and new
old : RHEL6.x : MySQL : init.d : mysql_safe : 'root', mysqld : 'mysql'
new : RHEL7.x : MariaDB : SystemD : mysql_safe : 'mysql', mysqld 'mysql'
Note that the old initl.d wrapper script runs as root, but the new SystemD wrapper script runs as 'mysql'. This can cause mysql_safe to not make the call to ulimit. In my case setting LimitNOFILE in SystemD didn't help - all it did was increase the file limit for the wrapper, but NOT for the daemon itself.
I found a two step process to get it working
Step 1 - re-instate the mysqld_safe section to the conf file so that mysql_safe will read it
sudo vi /etc/opt/rh/rh-mariadb100/my.cnf.d/mariadb-server.cnf
[mysqld_safe]
open_files_limit=2048
Step 2 - create a SystemD drop-in to start the wrapper as root (the daemon will still run as 'mysql'). Note that LimitNOFILE is commented out.
/etc/systemd/system
mkdir rh-mariadb100-mariadb.service.d
cd rh-mariadb100-mariadb.service.d
vi limits.conf
[Service]
#LimitNOFILE=2048
User=
Group=
Reload SystemD service files
systemctl daemon-reload
now restart the service, check value of open_files_limit in mysql client
it should now say 2048 (new soft limit)
The proper solution would probably be to get rid of the wrapper and use native SystemD.
UPDATE
it looks like this is fixed in the more recent version, which no longer uses the mysql_safe wrapper
rh-mariadb101-mariadb-10.1.19-6.el7.x86_64
To increase open-files-limit in MySQL 5.6 on Centos 7 you must:
nano /usr/lib/systemd/system/mysqld.service
add at the end of the file:
LimitNOFILE=65535
LimitNPROC=65535
then:
systemctl daemon-reload
systemctl restart mysqld
Done! , I assume that for MariaDB is the same thing
Ensure that no other files exist in the:
/etc/systemd/system/mariadb.service.d
folder that might be limiting the number of files.
That was my case, there was another file that was reducing the limit I set :)