How to fix high memory usage of MariaDB? - mysql

I am using MariaDB(10.1.21) with following storage engines:
InnoDB
TokuDB
Spider Engine
System Configuration is :
3GB RAM
Dual Core Processor
I have tried pt-mysql-summary tool to identify the memory usage and it shows 90% of innodb buffer pool size is filled,when no process is running on server.
I have also tried restarting the MariaDB server and this reduces memory for about 1-2 hours only and after that it eats up memory.
Any clue why it is consuming too much memory?
Sharing my configurations below:
My.cnf
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
# Here is entries for some specific programs
# The following values assume you have at least 32M ram
# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
#performance_schema=ON
tmp_table_size=16M
max_heap_table_size=16M
skip-log-bin
#table_open_cache =16384
#table_definition_cache =16384
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc_messages_dir = /usr/share/mysql
lc_messages = en_US
skip-external-locking
#bind-address = 127.0.0.1
#skip-networking
# 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
# 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
# LOGGING #
log_warnings = 2
slow_query_log =1
log-output = TABLE
long_query_time = 5
log_slow_verbosity = query_plan
log-error =/var/log/mysql/system_error.err
# 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 = 1720M
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completion
[isamchk]
key_buffer = 16M
TokuDB.cnf
plugin-load-add=ha_tokudb.so
tokudb_data_dir=/var/lib/mysql/toku_db_data
tokudb_read_block_size=64k
tokudb_row_format=tokudb_zlib
tokudb_directio=on
Spider.cnf
[mariadb]
#spider_internal_limit =1
spider_direct_order_limit =1
spider_skip_default_condition =1
spider_casual_read =1
spider_bgs_mode =2
spider_direct_dup_insert =1
spider_auto_increment_mode =2
#optimizer_switch='engine_condition_pushdown=on'
#optimizer_switch='mrr=on,mrr_sort_keys=off'

innodb-buffer-pool-size = 1720M is much too large for a 3GB machine, especially if TokuDB and Spider are also in use.
The real question is, "is there any swapping"? If there is no swapping, then there is no problem. If there is swapping, then the first defense is to lower that setting. I suggest 500M. Swapping is very bad for performance of MySQL.
It is normal to see 90%. 92% is the median value for (Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size) a sampling of machines. Since the buffer_pool is a cache, it is normal to be "full" most of the time. (It rarely gets over 98% full -- probably leaving some space for quick reuse.) If it is below, say, 50% full after running for several hours, I would say the innodb_buffer_pool_size is too big for the dataset in question.
Suggest lowering to long_query_time = 2 in order to catch faster, but frequent, queries, too.

Related

Mariadb server constanlty crashing [Error 2013]

I know this problem was asked several times, but no solution worked for me so far. I am struggling with this for over 2 weeks and I am out of options.
System:Ubuntu 18.04 LTS
MySQL version:mysql Ver 15.1 Distrib 10.4.11-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
I suspect it may be a problem with one large database (over 4GB) I had to recover from frm idb. I know the method of recovery was successful after recovery of single table I checked and the data was there, not sure if with the other tables something is not corrupted BUT:
I tried recovery method described here and problem is even when I do mysqlcheck --all-databases I get error: 2013: Lost connection to MySQL server during query when executing 'CHECK TABLE ... ' so unable to check.
From what I see in syslog server also crashed when I log into mysql and do use epffilm;
Using other advice from SO i created /etc/my.cnf :
[mysql]
connect_timeout = 43200
max_allowed_packet = 2048M
net_buffer_length = 512M
debug-info = TRUE
also content of my /etc/mysql/my.cnf:
client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
#socket = /run/mysqld/mysqld.sock
# Here is entries for some specific programs
# The following values assume you have at least 32M ram
# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc_messages_dir = /usr/share/mysql
lc_messages = en_US
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
#
# * Fine Tuning
#
max_connections = 100
connect_timeout = 1000000
wait_timeout = 600
max_allowed_packet = 1073741824
thread_cache_size = 128
sort_buffer_size = 4M
bulk_insert_buffer_size = 16M
tmp_table_size = 32M
max_heap_table_size = 32M
net_read_timeout = 31536000
net_write_timeout = 31536000
#
# * MyISAM
#
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched. On error, make copy and try a repair.
myisam_recover_options = BACKUP
key_buffer_size = 128M
#open-files-limit = 2000
table_open_cache = 400
myisam_sort_buffer_size = 512M
concurrent_insert = 2
read_buffer_size = 2M
read_rnd_buffer_size = 1M
#
# * Query Cache Configuration
#
# Cache only tiny result sets, so we can fit more in the query cache.
query_cache_limit = 128K
query_cache_size = 64M
# for more write intensive setups, set to DEMAND or OFF
#query_cache_type = DEMAND
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
general_log_file = /var/log/mysql/mysql.log
general_log = 1
#
# Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf.
#
# we do want to know about network errors and such
log_warnings = 2
#
# Enable the slow query log to see queries with especially long duration
#slow_query_log[={0|1}]
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 10
log_slow_rate_limit = 1000
log_slow_verbosity = query_plan
#log-queries-not-using-indexes
#log_slow_admin_statements
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
#server-id = 1
#report_host = master1
#auto_increment_increment = 2
#auto_increment_offset = 1
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
# not fab for performance, but safer
#sync_binlog = 1
expire_logs_days = 7
max_binlog_size = 100M
# If applications support it, this stricter sql_mode prevents some
# mistakes like inserting invalid dates etc.
#sql_mode = NO_ENGINE_SUBSTITUTION,TRADITIONAL
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
default_storage_engine = InnoDB
innodb_buffer_pool_size = 6G
innodb_log_buffer_size = 512M
innodb_file_per_table = 1
innodb_open_files = 400
innodb_io_capacity = 400
innodb_flush_method = O_DIRECT
#
#
# Helpful with recovery
#
innodb_force_recovery=3
innodb_purge_threads=0
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem
#
# Allow server to accept connections on all interfaces.
#
#bind-address=0.0.0.0
#
# Optional setting
#wsrep_slave_threads=1
#innodb_flush_log_at_trx_commit=0
[mysqldump]
quick
quote-names
max_allowed_packet = 1024M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completion
[isamchk]
key_buffer = 16M
#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!include /etc/mysql/mariadb.cnf
!includedir /etc/mysql/conf.d/
Any insight is appreciated.
Update:
I put a crash log on pastenbin
Hello this has already occurred to me ...
In my case my server was low on memory ...
And my database was full of posts.
That is ... he had a lot of information on two types of decodes. (MyISAM & Innodb) in the same bank ...
The solution I found was to export this database ...
This is a backup ...
Create a database from scratch by deciding on single encoding (Innodb) only.
And doing the import little by little checking all the tables and possible errors.
Another option I made was to remove what was old and put it in another database. To be part of another site.
Data integration would be through links between the two sites ...
I hope it helped you!
Strong hug. Good luck!
Send news!
Where did you get these?? (I will comment on it.)
max_allowed_packet = 2048M
net_buffer_length = 512M
They are much too large. These could explain running out of memory and crashing.
Remove those from my.cnf. If some large values are needed for a single load, then set them only within that connection. And shrink innodb_buffer_pool_size by 2.5G to allow room for such a one-time task.
How much RAM do you have?

The problem with the load of RAM in the virtual machine where it is installed MySQL

Schedule for Hour
Daily Schedule
There is a virtual machine installed on the PROXMOX, MySQL is installed there.
For this VM allocated 30GB of RAM and 20 cores because it receives a lot of data.
The problem is that the load on the VM gradually increases, and I do not understand why.
After a reboot MySQL server, the data is processed very quickly, while the load on the RAM in the region of 3-4 GB.
After the server has been running for more than 24 hours, the data starts to be processed for a very long time, while the data arrive in the same amount.
The load on the RAM rises to 25GB.
What's wrong?
I attach a screenshot and my.cnf.
I'm sorry for my bad English.
Thanks for answers.
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
skip-name-resolve
event_scheduler = on
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 512K
thread_cache_size = 8
myisam-recover = BACKUP
max_connections = 700
#table_cache = 64
#thread_concurrency = 12
query_cache_limit = 1M
query_cache_size = 50M
innodb_buffer_pool_size = 16G
innodb_buffer_pool_instances = 16
innodb_additional_mem_pool_size=400M
innodb_log_buffer_size=80M
innodb_flush_log_at_trx_commit = 0
innodb_log_file_size = 128M
innodb_flush_method=O_DIRECT
innodb_autoinc_lock_mode = 2
innodb_thread_concurrency = 12
sort_buffer=512M
thread_concurrency=32
#record_buffer=128M
query_cache_type=2
tmp_table_size=1G
general_log_file = /var/log/mysql/mysql.log
general_log = 0
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 10 = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
[mysql]
[isamchk]
key_buffer = 16M
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[isamchk]
key_buffer = 16M
Rate Per Second=RPS - Suggestions to consider for your my.cnf [mysqld] section
key_cache_age_threshold=7200 # from 300 seconds to reduce key_reads RPS of 240123
thread_cache_size=100 # from 8 to reduce threads_created in 1 day
innodb_buffer_pool_size=20G # from 16G to reduce innodb_buffer_pool_reads RPS of 20
innodb_read_io_threads=64 # from 1 for improved read performance
innodb_write_io_threads=64 # from 1 for improved write performance
Please get in touch, there are many more opportunities available to improve your instance response time.

Setting Up my.cnf and Apache.conf on a Wordpress site with 40K monthly visitors

Since we are rookies on this, we are having a hard time trying to setup a Wordpress server to support around 200K monthly visiting users. We have two boxes (details below).
The issue here is when the users start accessing the server, MySQL CPU goes to 149%. Here is a copy of the apache2.conf and the mysql.cnf files. Our MySQL database is InnoDB. Any suggestions on how to fix it?
1. Apache Server
Configuration
8 GB Memory / 25 GB Disk + 200 GB / Ubuntu 16.04
apache.conf excerpt
Timeout 40
KeepAlive On
MaxKeepAliveRequests 500
KeepAliveTimeout 2
2. MySQL Server
Configuration
8 GB Memory / 25 GB Disk + 50 GB / Ubuntu 16.04
my.cnf file
root#mundo-mysql01-c-2-4gib-nyc3-01:/etc/mysql# cat my.cnf
#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
general_log_file = /var/log/mysql/mysql.log
general_log = 0
# CACHES AND LIMITS #
open_files_limit = 65535
table_definition_cache = 1024
table_open_cache = 2048
# MyISAM Settings
max_connections = 300
key_buffer_size = 256M
myisam_sort_buffer_size = 32M
join_buffer_size = 1M
read_buffer_size = 1M
sort_buffer_size = 16M
thread_cache_size = 32
wait_timeout = 300
connect_timeout = 300
tmp_table_size = 32M
max_heap_table_size = 128M
max_allowed_packet = 128M
max_connect_errors = 10000
read_rnd_buffer_size = 1M
bulk_insert_buffer_size = 1M
query_cache_limit = 4M
query_cache_size = 128M
query_cache_type = 1
query_prealloc_size = 65536
query_alloc_block_size = 131072
low_priority_updates = 1
max_write_lock_count = 1
# * InnoDB
innodb-flush-method = O_DIRECT
innodb-log-files-in-group = 2
innodb-log-file-size = 256M
innodb-flush-log-at-trx-commit = 1
innodb-file-per-table = 1
innodb-buffer-pool-size = 2048M

Finding right configuration for a dedicated mariadb server - for huge innodb tables

I have been working on a separate server to configure the mariadb but still queries are taking sooo long time to return and mostly not returning.
Mariadb version: 10.1.31-1
Server has 50GB Ram and 2200 Ghz * 10 core
Centos7 as OP
The target database currently has very huge innodb tables and not indexed well. there is no any other table type just innodb.
Currently i am making some nested select queries and saving results to another empty clone database with insert into or replace into.
as an example:
REPLACE INTO db1.table1
SELECT * FROM db0.table1 WHERE ART_ID IN (
SELECT ART_ID FROM db0.table2 WHERE BRA_ID IN (
SELECT BRA_ID FROM db0.table3 WHERE BRAND IN (
SELECT BRAND FROM db0.table4 WHERE ID IN (... bunch of comma seperated ids)
)
)
);
The only connection is from local and/or just one remote connection.
The only task of the server is to filter the huge data to another db, no web server etc.
I put the /etc/my.cnf file down below. I made lots of tests on this file so you may see some useless additions.
The question is: Is there any miss configurations in the cnf file; and is there any other configuration tips etc to run those bunch of queries in reasonable time.
It was working better but after i change the configurations or / and update the server everything got much slower. (yes i update the tables as well after updating db version)
# The MySQL server
[mysqld]
performance_schema=0
bind-address = 0.0.0.0
max_connections = 32
socket = /var/lib/mysql/mysql.sock
skip-external-locking
max_allowed_packet = 1024M
connect_timeout=300
wait_timeout=1200
interactive_timeout=300
key_buffer_size = 2G
bulk_insert_buffer_size=256M
sort_buffer_size = 32M
#read_buffer_size = 8M
#read_rnd_buffer_size = 32M
myisam_sort_buffer_size = 32M
join_buffer_size=32M
#max_heap_table_size= 8G
tmp_table_size=8G
concurrent_insert=2
#external-locking=FALSE
#open_files_limit=50000
default-storage-engine=innodb
innodb_file_per_table=1
#lower_case_table_names=1
# Try number of CPU's*2 for thread_concurrency
innodb_write_io_threads=10
innodb_read_io_threads=20
#innodb_buffer_pool_instances=8
#thread_stack = 1M
#thread_cache_size = -1
innodb_buffer_pool_size = 16G
#query_cache_limit = 1073741824
#query_cache_size = 1073741824
#query_cache_type = 1
query_cache_size=0
query_cache_type=0
#innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
innodb_fast_shutdown=0
#innodb_log_file_size = 1G
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 0
innodb_lock_wait_timeout = 1073741823
innodb_thread_concurrency=0
innodb_commit_concurrency=0
innodb_flush_method=O_DSYNC
innodb_log_compressed_pages = 0
#innodb_flush_neighbors = 0
#innodb_adaptive_hash_index_partitions = 8
log-bin=mysql-bin
server-id = 1
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[isamchk]
key_buffer = 384M
sort_buffer = 384M
read_buffer = 256M
write_buffer = 256M
[myisamchk]
key_buffer = 384M
sort_buffer = 384M
read_buffer = 256M
write_buffer = 256M
[mysqlhotcopy]
interactive-timeout
I used percona wizard and merge the advices.
the current my.cnf is below.
I run the php application yesterday night (2018-03-05 22:41:30 UTC), but still mysql could not return any result.
the application is only adding limit 10000 and offset (i did not want to start from beginning, i am currently tracking the last offset and starting from that point.)
currently i am planning to delete and reinstall mariadb :(
(it will be emotional reaction)
# Generated by Percona Configuration Wizard (http://tools.percona.com/) version REL5-20120208
[mysql]
# CLIENT #
port = 9999
socket = /var/lib/mysql/mysql.sock
[mysqld]
# GENERAL #
port = 9999
user = mysql
default-storage-engine = InnoDB
socket = /var/lib/mysql/mysql.sock
pid-file = /var/lib/mysql/mysql.pid
# MyISAM # - there is no myisam table
key-buffer-size = 32M
myisam-recover-options = FORCE,BACKUP
# SAFETY #
max-allowed-packet = 16M
max-connect-errors = 1000000
skip-name-resolve
# DATA STORAGE #
datadir = /var/lib/mysql/
# BINARY LOGGING #
log-bin = /var/lib/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 = 30
#thread-cache-size = 16
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 = 5G
innodb-flush-log-at-trx-commit = 1
innodb-file-per-table = 1
innodb-buffer-pool-size = 42G
innodb-buffer-pool-instances = 42
thread_cache_size=100
innodb_lru_scan_depth=100
innodb_purge_threads=4
innodb_read_io_threads=64
innodb_write_io_threads=64
innodb_thread_concurrency=0
max_seeks_for_key=32
max_write_lock_count=16
thread_concurrency=35
innodb_fast_shutdown=0
innodb_file_per_table=1
default-storage-engine=innodb
concurrent_insert=2
join_buffer_size=32M
tmp_table_size=8G
read_buffer_size = 8M
# LOGGING #
log-error = /var/lib/mysql/mysql-error.log
log-queries-not-using-indexes = 0
slow-query-log = 1
slow-query-log-file = /var/lib/mysql/mysql-slow.log
The my.cnf data in the Question does not match SHOW GLOBAL VARIABLES; values.
Please use this link
https://mariadb.com/kb/en/library/configuring-mariadb-with-mycnf/
to help get accurate matched values for assistance.
Then, Suggestions to consider for your my.cnf [mysqld] section include:
innodb_buffer_pool_size=8G # from > 40G (95% of RAM will not work well)
innodb_lru_scan_depth=100 # from 1024 see refman every second digging too deep
log_warnings=2 # from 1 to include connection errors more detail
max_connect_errors=10 # from 1,000,000 no need to waste a million cycles
thread_cache_size=100 # from 16 CAP per V8 MySQ to be prepared for volume
have_symlink=NO # to protect you server, unless you NEED it
innodb_purge_threads=4 # from 1 to accommodate when needed
innodb_read_io_threads=64 # from 4 see dba.stackexhange.com Q 5666 9/12/11 Rolando
innodb_write_io_threads=64 # from 4 per Rolando to use multi-core
innodb_thrad_concurrency=0 # another part of multi-core enabling
max_seeks_for_key=32 # from huge number, not found in 32, will not be found
max_write_lock_count=16 # give RD opportunity after nn locks
thread_concurrency=35 # to limit concurrent processing load
#Erce, To be applied in the correct active my.cnf, please. Withdrawn my offer to redo your mysqld section.
I used percona wizard and merge the advices. the current my.cnf is below.
I run the php application yesterday night (2018-03-05 22:41:30 UTC), but still mysql could not return any result.
the application is only adding limit 10000 and offset (i did not want to start from beginning, i am currently tracking the last offset and starting from that point.)
[mysql]
# CLIENT #
port = 9999
socket = /var/lib/mysql/mysql.sock
[mysqld]
# GENERAL #
port = 9999
user = mysql
default-storage-engine = InnoDB
socket = /var/lib/mysql/mysql.sock
pid-file = /var/lib/mysql/mysql.pid
# MyISAM # - there is no myisam table
key-buffer-size = 32M
myisam-recover-options = FORCE,BACKUP
# SAFETY #
max-allowed-packet = 16M
max-connect-errors = 1000000
skip-name-resolve
# DATA STORAGE #
datadir = /var/lib/mysql/
# BINARY LOGGING #
log-bin = /var/lib/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 = 30
#thread-cache-size = 16
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 = 5G
innodb-flush-log-at-trx-commit = 1
innodb-file-per-table = 1
innodb-buffer-pool-size = 42G
innodb-buffer-pool-instances = 42
thread_cache_size=100
innodb_lru_scan_depth=100
innodb_purge_threads=4
innodb_read_io_threads=64
innodb_write_io_threads=64
innodb_thread_concurrency=0
max_seeks_for_key=32
max_write_lock_count=16
thread_concurrency=35
innodb_fast_shutdown=0
innodb_file_per_table=1
default-storage-engine=innodb
concurrent_insert=2
join_buffer_size=32M
tmp_table_size=8G
read_buffer_size = 8M
# LOGGING #
log-error = /var/lib/mysql/mysql-error.log
log-queries-not-using-indexes = 0
slow-query-log = 1
slow-query-log-file = /var/lib/mysql/mysql-slow.log
#erce
These THREE lines NEED TO BE REMOVED (just before LOGGING area)
join_buffer_size=32M
tmp_table_size=8G
read_buffer_size = 8M
LOGGING
tmp_table_size was accurately matched earlier with max_heap_table_size.
This line later takes charge and get you unbalanced which is BAD.
The join_buffer_size and read_buffer_size are killing your RAM footprint.
Use mysqlcalculator.com to understand why, please.
The performance problem is primarily in the formulation of the query, not necessarily in the tuning or indexes.
Query Formulation
In general, turn IN ( SELECT ... ) into JOIN.
Tackling the last step:
SELECT bra_id
FROM t3
JOIN t4 ON t3.brand = t4.brand
WHERE t4.id IN (...commalist...)
with indexes:
t4: INDEX(id, brand)
t3: INDEX(brand, bra_id)
This starts with t4, looking for the various ids, then mapping them to brands. Then it reaches into t3 by brand to get bra_id.
I'll let you practice by doing the next two steps to get through t2 to t1.
Tuning advice
Don't blindly increase values in my.cnf, it can get you into trouble.
innodb_buffer_pool_size = 35G -- the most important
42G is probably OK -- if you don't have too many other apps running on the same server. 42 instances may work. Some say 16 instances should be the max.
The rest of the tunables can probably be left alone.
max_heap_table_size= 8G
tmp_table_size=8G
Those are dangerously high. With them, 8GB could be allocated once (or more than once) per connection. But you have only 50GB of RAM. It would be better to set them to no more than 1% of RAM (500M or less; 32M should be just fine).
#lower_case_table_names=1
Leave commented out. Any attempt to override what is needed for the OS is likely to get you into deep weeds.
port = 9999
What was wrong with the default 3306?
Other
"application grabbed 10000 items in 6 hours. for the next block of items 8 hour passed" -- Please provide SHOW CREATE TABLE for the 4 tables being read, plus the table being written to. And tell us how big the tables are. I suspect you are thrashing over index updates in the target table. There is a simple solution.
Check to see if mysqld is swapping.
I guess i need to change select query style, i will try the offered query alternatives because it did not work, queries are still to slow (i assume)
But these are current server stats (49GB ram, 10 core) and mysqls virtual memory is about 47~GB which is fine, no any other app is running. I think its alright ?
tuning-primer.sh
https://pastebin.com/bcjS1PWf
mysqltuner.pl
https://pastebin.com/mXUTLPQ6
my.cnf
https://pastebin.com/9jMLzhZS
Suggestions for your my.cnf-ini [mysqld] section using data posted 3/15/18
thread_cahce_size=40 # from 20, 8 required for overhead, room to wiggle
innodb_io_capacity=400 # from 200 new iostat -x will confirm use
# read_buffer_size=8388608 # lead with # for default of 128K - extreme at 8M
read_rnd_buffer_size=128K # from 256K will affect handler_read_rnd_next
sync_binlog=32 # from 1 sec frequency, unless you fear recovery required
# join_buffer_size=4M # lead with # for default of 128K
key_buffer_size=1M # from 32M less than 1M used - primarily Innodb tables
innodb_adapative_max_sleep_delay=15 # from 150000 (15 secs - n0 other users)
innodb_buffer_pool_instances=8 # from 42 to minimize mgmt. overhead
innodb_buffer_pool_size=40G # from 44G allow OS a little breathing room
innodb_change_buffer_max_size=3 # from 25% - no need to set aside 10G when not changing anything significant
innodb_doublewrite=OFF # from ON you are not a PROD effort - crash recovery NA for run of this instance
innodb_print_all_deadlocks=ON # from OFF you always need in error log
innodb_read_ahead_threshold=8 # from 56, why wait to read NXT extent?
innodb_stats_sample_pages=32 # from 8 for more accurate index cardinality
log_warnings=2 # from 1 to record addl connection error details
max_join_size=1000000000 # from more huge number to 1B rows max for join
sql_select_limit=1000000000 # from more huge number to 1B rows selected
query_alloc_block_size=32K # from 16K - minimize RAM alloc AvgQrySz 20K
query_cache_type=0 # for OFF, not used
query_cache_size=0 # from 8M not needed for one time selections
query_cache_limit=1K # from 256K, just to keep the framework, in case QC needed
query_cache_min_res_unit=512 # from 2K for optimal QC storage when QC used
query_prealloc_size=32K # from 24K to minimize RAM alloc for parsing
transaction_alloc_block_size=32K # from 8K to minimize RAM alloc
transaction_prealloc_size=32K # from 4K to minimize RAM alloc
updatable_views_with_limit=NO # from YES to reduce handler_external_lock count
this one could have to go back to YES - it is DYNAMIC variable
Please find your ONE com_stmt_prepare CODE and ensure it has CLOSE before leaving the session to release resources per refman PREPARE or mysql_stmt_prepare for API.
Once you are running, before running your troubled query, consider using
ALTER TABLE tbl_name ENGINE=INNODB
for each table to take advantage of additional pages for better cardinality,
then try your long running query.

Mysql is using system file cache, not RAM directly

I have an Ubuntu 64-bit system and running Mysql version 5.5.32-0ubuntu0.12.04.1-log. The machine has 64 GB ram.
I have a pretty huge database which almost has 90 GB of data and one table with 250.000.000 rows.
My problem is, that the mysqld process does not take much memory. Just between 2-5 GB. But the memory of the system is fully used for the file cache.
I restarted the server, there were 63 GB memory free. Once I started to execute larger queries, the amount of free memory decreases, while the amount of file cached increases.
So mysql is not loading the data in its RAM, but it uses the file cache.
Queries are very slow. When I query the big table, which - according to explain - uses an index and only has 500.000 rows to consider, it takes minutes.
Do you have any explanation for this phenomen?
Here is my my.cnf. (This is actually the config of my slave, but it shows exactly the same behaviour) My tables are all InnoDB:
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address = 127.0.0.1
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
log_error = /var/log/mysql/error.log
server-id = 2
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
[innodb]
innodb_buffer_pool_size = 55G
innodb_log_file_size = 256M
innodb_log_buffer_size = 4M
innodb_flush_log_at_trx_commit=2
innodb_thread_concurrency=0
innodb_file_per_table = 1 # (this is not respected as I changed it after the first database was created). So my ibdata1 file is over 80GB in size
max_connections = 1000 # wenn gleichzeitig viele User zugreifen
table_cache = 10000 # abgeleitet von max_connections, könnte sogar höher sein
tmp_table_size = 5000M # wichtig wg. JOINs, zu kleiner Wert macht die extrem langsam
max_heap_table_size = 5000M
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/
Increase the key_buffer size to 128M and max_allowed_packet to 128M, as this will speed up the execution of queries
I finally figured out was the problem was. The
innodb_buffer_pool_size = 55G
does not belong in the [innodb] section, but in the [mysqld] section.
All the innodb configs needed to be placed in the mysqld section.