innodb table level lock - innodb

We face the table level lock issues, almost every day on our test servers.
TRANSACTION 0, not started
mysql tables in use 97, locked 97
MySQL thread id 429, OS thread handle 0x2aff6ff59700, query id 24900 ec2-*-*-*-*.compute-1.amazonaws.com *.*.*.* sminq cleaning up
---TRANSACTION 10631403, not started
MySQL thread id 321, OS thread handle 0x2aff7b359700, query id 24901 115.112.140.139 sminq init
show engine innodb status
---TRANSACTION 10632661, not started
MySQL thread id 13, OS thread handle 0x2aff4e39a700, query id 24817 localhost 127.0.0.1 rdsadmin cleaning up
---TRANSACTION 10632664, not started
MySQL thread id 6, OS thread handle 0x2aff396c5700, query id 24873 ec2-*-*-*-*.ap-southeast-1.compute.amazonaws.com *.*.*.* sminq cleaning up
---TRANSACTION 10632655, not started
MySQL thread id 7, OS thread handle 0x2aff39706700, query id 24783 ec2-*-*-*-*.ap-southeast-1.compute.amazonaws.com *.*.*.* sminq cleaning up
---TRANSACTION 10632652, not started
MySQL thread id 3, OS thread handle 0x2aff37d28700, query id 24745 ec2-*-*-*-*.ap-southeast-1.compute.amazonaws.com *.*.*.* sminq cleaning up
---TRANSACTION 10627075, not started
MySQL thread id 1, OS thread handle 0x2aff37ca6700, query id 0 Waiting for background binlog tasks
---TRANSACTION 10632663, ACTIVE 7 sec
mysql tables in use 1, locked 1
MySQL thread id 431, OS thread handle 0x2aff37daa700, query id 24863 172.31.3.120 sminq Waiting for table level lock
insert into `sminq`.`Queue_token` (`token_queue_id`, `total_process_time`, `token_user`, `created_on`, `join_date`, `join_time`, `app_type`, `token_user_group`, `uuid`) values (13, 10, 87, '2016-07-21 04:47:04.157000', '2016-07-21 10:17:04', '10:10:00', 1, NULL, 'D<??BY??7?gk?Uo')
Trx #rec lock waits 0 #table lock waits 0
Trx total rec lock wait time 0 SEC
Trx total table lock wait time 0 SEC
---TRANSACTION 10632646, ACTIVE 45 sec
These keep occurring for Inserts only, we have never faced the issue with Updates or deletes.
I have an Isolation level READ-COMMITTED, along with innodb_autoinc_lock_mode = 2
mysqltuner output for the same server
[--] Up for: 2h 11m 55s (25K q [3.230 qps], 478 conn, TX: 3M, RX: 1M)
[--] Reads / Writes: 82% / 18%
[--] Binary logging is enabled (GTID MODE: OFF)
[--] Total buffers: 1.5G global + 17.0M per thread (100 max threads)
[!!] Maximum reached memory usage: 3.0G (152.35% of installed RAM)
[!!] Maximum possible memory usage: 3.1G (156.50% of installed RAM)
[OK] Slow queries: 0% (0/25K)
[!!] Highest connection usage: 95% (95/100)
[OK] Aborted connections: 0.00% (0/478)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1K sorts)
[OK] Temporary tables created on disk: 24% (424 on disk / 1K total)
[OK] Thread cache hit rate: 80% (95 created / 478 connections)
[OK] Table cache hit rate: 129% (291 open / 224 opened)
[OK] Open file limit used: 0% (64/65K)
[OK] Table locks acquired immediately: 99% (6K immediate / 6K locks)
[OK] Binlog cache memory access: 100.00% ( 1618 Memory / 1618 Total)
-------- MyISAM Metrics -----------------------------------------------------
[!!] Key buffer used: 18.5% (1M used / 8M cache)
[OK] Key buffer size / total MyISAM indexes: 8.0M/2.4M
[!!] Read Key buffer hit rate: 82.2% (90 cached / 16 reads)
-------- InnoDB Metrics -----------------------------------------------------
[--] InnoDB is enabled.
[OK] InnoDB buffer pool / data size: 1.3G/29.0M
[!!] InnoDB buffer pool instances: 8
[!!] InnoDB Used buffer: 1.32% (1139 used/ 86584 total)
[OK] InnoDB Read buffer efficiency: 99.86% (713109 hits/ 714137 total)
[!!] InnoDB Write buffer efficiency: 0.00% (0 hits/ 1 total)
[OK] InnoDB log waits: 0.00% (0 waits / 4915 writes)
Since this is a test server we are running the tests on a t2.small

1.3G buffer_pool in 2GB of RAM? This probably leads to lots of swapping, which is really bad for performance.
For 2GB of RAM and only 29M of data, let's set innodb_buffer_pool_size = 100M. That should enough for now, and safe for later (as the data grows).
(The recommendation of 70% or 80% only applies for machines with at least 4GB of RAM.)
Fix that. If the problem continues, then update the question with newer values, plus SHOW CREATE TABLE for the table(s) involved.

An AUTO-INC lock is a special table-level lock taken by transactions inserting into tables with AUTO_INCREMENT columns. In the simplest case, if one transaction is inserting values into the table, any other transactions must wait to do their own inserts into that table, so that rows inserted by the first transaction receive consecutive primary key values.
The innodb_autoinc_lock_mode configuration option controls the algorithm used for auto-increment locking. It allows you to choose how to trade off between predictable sequences of auto-increment values and maximum concurrency for insert operations.
The permissible values are 0, 1, or 2, for “traditional”, “consecutive”, or “interleaved” lock mode
innodb_autoinc_lock_mode = 2 (“interleaved” lock mode)
In this lock mode, no “INSERT-like” statements use the table-level AUTO-INC lock, and multiple statements can execute at the same time. This is the fastest and most scalable lock mode, but it is not safe when using statement-based replication or recovery scenarios when SQL statements are replayed from the binary log.
In this lock mode, auto-increment values are guaranteed to be unique and monotonically increasing across all concurrently executing “INSERT-like” statements. However, because multiple statements can be generating numbers at the same time (that is, allocation of numbers is interleaved across statements), the values generated for the rows inserted by any given statement may not be consecutive.
If the only statements executing are “simple inserts” where the number of rows to be inserted is known ahead of time, there will be no gaps in the numbers generated for a single statement, except for “mixed-mode inserts”. However, when “bulk inserts” are executed, there may be gaps in the auto-increment values assigned by any given statement.
Refer the source Locking and modify the configuration based on your requirement.

Related

Dask job fails in Jupyter notebook cell with KilledWorker

I am running a join task in a Jupyter notebook which is producing many warnings from Dask about a possible memory leak before finally failing with a killed worker error:
2022-07-26 21:38:05,726 - distributed.worker_memory - WARNING - Worker is at 85% memory usage. Pausing worker. Process memory: 1.59 GiB -- Worker memory limit: 1.86 GiB
2022-07-26 21:38:06,319 - distributed.worker_memory - WARNING - Unmanaged memory use is high. This may indicate a memory leak or the memory may not be released to the OS; see https://distributed.dask.org/en/latest/worker-memory.html#memory-not-released-back-to-the-os for more information. -- Unmanaged memory: 1.59 GiB -- Worker memory limit: 1.86 GiB
2022-07-26 21:38:07,501 - distributed.worker_memory - WARNING - Worker tcp://127.0.0.1:46137 (pid=538697) exceeded 95% memory budget. Restarting...
2022-07-26 21:38:07,641 - distributed.nanny - WARNING - Restarting worker
KilledWorker: ("('assign-6881b18750807133ba976bf463a98c23', 0)", <WorkerState 'tcp://127.0.0.1:46137', name: 0, status: closed, memory: 0, processing: 50>)
This happens when I run my code on a laptop with 32GB RAM (Kubuntu 20). Maybe I have not configured Dask correctly for the environment? I can watch the memory usage go up and down in the system monitor but at no point does it consume all the memory. How can I tell Dask to use all the cores and as much memory as it can manage? It seems to be running in single processor mode, maybe because I'm running on a laptop rather than a proper cluster?
For context: I'm joining two datasets, both are text files with sizes 25GB and 5GB. Both files have been read into Dask DataFrame objects using dd.read_fwf(), then I transform a string field on one of the frames, then join (merge) on that field.
There are certain memory constraints for a particular worker, which you can read from here : https://distributed.dask.org/en/stable/worker-memory.html .
Apart from this, you can try increasing the number of workers, threads while initializing the dask client.

How should mysql my.cnf settings be? Innodb Mariadb 10 VestaCP

My.cnf
[mysql]
port = 3306
socket=/var/lib/mysql/mysql.sock
[mysqld]
# === Required Settings ===
basedir = /usr
bind_address = 127.0.0.1
datadir = /var/lib/mysql
max_allowed_packet = 1024M
max_connect_errors = 1000000
pid-file=/var/lib/mysql/mysql.pid
port = 3306
skip_name_resolve
socket=/var/lib/mysql/mysql.sock
tmpdir = /tmp
sql_mode = ""
thread_handling = pool-of-threads
# === InnoDB Settings ===
default_storage_engine = InnoDB
innodb_buffer_pool_size = 36G # Use up to 70-80% of RAM
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_log_buffer_size = 16M
innodb_log_file_size = 1G
innodb_sort_buffer_size = 4M # UPD - Defines how much data is read into memory for sorting operations before writing to disk (default is 1M / max is 64M)
innodb_stats_on_metadata = 0
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_io_capacity = 2000 # Depends on the storage tech - use 2000 for SSD, more for NVMe
innodb_io_capacity_max = 4000 # Usually double the value of innodb_io_capacity
# === Connection Settings ===
max_connections = 100 # UPD - Important: high no. of connections = high RAM consumption
back_log = 512
thread_cache_size = 100
thread_stack = 192K
interactive_timeout = 180
wait_timeout = 180
# === Buffer Settings ===
join_buffer_size = 4M # UPD
read_buffer_size = 3M # UPD
read_rnd_buffer_size = 4M # UPD
sort_buffer_size = 4M # UPD
# === Table Settings ===
table_definition_cache = 40000 # UPD
table_open_cache = 40000 # UPD
open_files_limit = 60000 # UPD
max_heap_table_size = 128M # Increase to 256M or 512M if you have lots of temporary tables because of missing indices in JOINs
tmp_table_size = 128M # Use same value as max_heap_table_size
# === Search Settings ===
ft_min_word_len = 3 # Minimum length of words to be indexed for search results
# === Binary Logging ===
disable_log_bin = 1
# === Error & Slow Query Logging ===
log_error = /var/lib/mysql/mysql_error.log
log_queries_not_using_indexes = 0 # Disabled on production
long_query_time = 5
slow_query_log = 0 # Disabled on production
slow_query_log_file = /var/lib/mysql/mysql_slow.log
[mysqldump]
quick
quote_names
max_allowed_packet = 1024M
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
My ram & cpu
[root#localhost ~]# cat /proc/cpuinfo | grep processor | wc -l
24
[root#localhost ~]# free -m
total used free shared buff/cache available
Mem: 48125 6136 12446 50 29541 41490
Swap: 0 0 0
mysqltuner
[root#localhost ~]# ./mysqltuner.pl
>> MySQLTuner 1.9.8
* Jean-Marie Renouard <jmrenouard#gmail.com>
* Major Hayden <major#mhtx.net>
>> Bug reports, feature requests, and downloads at http://mysqltuner.pl/
>> Run with '--help' for additional options and output filtering
[--] Skipped version check for MySQLTuner script
[!!] Your MySQL version 10.8.3-MariaDB is EOL software! Upgrade soon!
[OK] Operating on 64-bit architecture
-------- Log file Recommendations ------------------------------------------------------------------
[OK] Log file /var/lib/mysql/mysql_error.log exists
[--] Log file: /var/lib/mysql/mysql_error.log(70K)
[OK] Log file /var/lib/mysql/mysql_error.log is not empty
[OK] Log file /var/lib/mysql/mysql_error.log is smaller than 32 Mb
[OK] Log file /var/lib/mysql/mysql_error.log is readable.
[!!] /var/lib/mysql/mysql_error.log contains 339 warning(s).
[!!] /var/lib/mysql/mysql_error.log contains 51 error(s).
[--] 2 start(s) detected in /var/lib/mysql/mysql_error.log
[--] 1) 2022-06-19 16:42:05 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 2) 2022-06-17 21:30:12 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 1 shutdown(s) detected in /var/lib/mysql/mysql_error.log
[--] 1) 2022-06-19 16:42:04 0 [Note] /usr/sbin/mariadbd: Shutdown complete
-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +Aria +CSV +InnoDB +MEMORY +MRG_MyISAM +MyISAM +PERFORMANCE_SCHEMA +SEQUENCE
[--] Data in Aria tables: 32.0K (Tables: 1)
[--] Data in InnoDB tables: 1.7G (Tables: 845)
[OK] Total fragmented tables: 0
-------- Analysis Performance Metrics --------------------------------------------------------------
[--] innodb_stats_on_metadata: OFF
[OK] No stat updates during querying INFORMATION_SCHEMA.
-------- Views Metrics -----------------------------------------------------------------------------
-------- Triggers Metrics --------------------------------------------------------------------------
-------- Routines Metrics --------------------------------------------------------------------------
-------- Security Recommendations ------------------------------------------------------------------
[OK] There are no anonymous accounts for any database users
[OK] All database users have passwords assigned
[!!] There is no basic password file list!
-------- CVE Security Recommendations --------------------------------------------------------------
[--] Skipped due to --cvefile option undefined
-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 4d 6h 58m 28s (166M q [448.474 qps], 937K conn, TX: 203G, RX: 12G)
[--] Reads / Writes: 98% / 2%
[--] Binary logging is disabled
[--] Physical Memory : 47.0G
[--] Max MySQL memory : 137.9G
[--] Other process memory: 0B
[--] Total buffers: 36.4G global + 1.0G per thread (100 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[!!] Maximum reached memory usage: 93.2G (198.36% of installed RAM)
[!!] Maximum possible memory usage: 137.9G (293.37% of installed RAM)
[!!] Overall possible memory usage with other process exceeded memory
[OK] Slow queries: 0% (53/166M)
[OK] Highest usage of available connections: 56% (56/100)
[OK] Aborted connections: 0.01% (107/937871)
[OK] Query cache is disabled by default due to mutex contention on multiprocessor machines.
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 874K sorts)
[!!] Joins performed without indexes: 46708
[OK] Temporary tables created on disk: 2% (6K on disk / 305K total)
[--] Thread cache not used with thread pool enabled
[OK] Table cache hit rate: 99% (77M hits / 77M requests)
[OK] table_definition_cache(40000) is upper than number of tables(1137)
[OK] Open file limit used: 0% (29/32K)
[OK] Table locks acquired immediately: 100% (2K immediate / 2K locks)
-------- Performance schema ------------------------------------------------------------------------
[!!] Performance_schema should be activated.
[--] Sys schema is installed.
-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is enabled.
[--] Thread Pool Size: 24 thread(s).
[--] Using default value is good enough for your version (10.8.3-MariaDB)
-------- MyISAM Metrics ----------------------------------------------------------------------------
[--] No MyISAM table(s) detected ....
-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[OK] InnoDB File per table is activated
[OK] InnoDB buffer pool / data size: 36.0G/1.7G
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (2.77777777777778 %): 1.0G * 1/36.0G should be equal to 25%
[--] Number of InnoDB Buffer Pool Chunk : 64 for 1 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 100.00% (36551426226 hits/ 36551507601 total)
[OK] InnoDB Write log efficiency: 90.84% (7736631 hits/ 8516998 total)
[OK] InnoDB log waits: 0.00% (0 waits / 780367 writes)
-------- Aria Metrics ------------------------------------------------------------------------------
[--] Aria Storage Engine is enabled.
[OK] Aria pagecache size / total Aria indexes: 128.0M/344.0K
[!!] Aria pagecache hit rate: 82.5% (38K cached / 6K reads)
-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.
-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.
-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.
-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] Binlog format: MIXED
[--] XA support enabled: ON
[--] Semi synchronous replication Master: OFF
[--] Semi synchronous replication Slave: OFF
[--] This is a standalone server
-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
You are using n unsupported version for production environments
Upgrade as soon as possible to a supported version !
Check warning line(s) in /var/lib/mysql/mysql_error.log file
Check error line(s) in /var/lib/mysql/mysql_error.log file
Reduce your overall MySQL memory footprint for system stability
Dedicate this server to your database for highest performance.
We will suggest raising the 'join_buffer_size' until JOINs not using indexes are found.
See https://dev.mysql.com/doc/internals/en/join-buffer-size.html
(specially the conclusions at the bottom of the page).
Performance schema should be activated for better diagnostics
Before changing innodb_log_file_size and/or innodb_log_files_in_group read this:
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
join_buffer_size (> 4.0M, or always use indexes with JOINs)
performance_schema=ON
innodb_log_file_size should be (=9G) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
[root#localhost ~]#
Tuning Primer
[root#localhost ~]# ./tuning-primer.sh
-- MYSQL PERFORMANCE TUNING PRIMER --
- By: Matthew Montgomery -
MySQL Version 10.8.3-MariaDB x86_64
Uptime = 4 days 9 hrs 29 min 40 sec
Avg. qps = 454
Total Questions = 172718132
Threads Connected = 33
Server has been running for over 48hrs.
It should be safe to follow these recommendations
To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/10.8/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service
SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 5.000000 sec.
You have 53 out of 172718244 that take longer than 5.000000 sec. to complete
Your long_query_time seems to be fine
BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/10.8/en/point-in-time-recovery.html
WORKER THREADS
Current thread_cache_size = 100
Current threads_cached = 0
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine
MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 33
Historic max_used_connections = 56
The number of used connections is 56% of the configured maximum.
Your max_connections variable seems to be fine.
No InnoDB Support Enabled!
MEMORY USAGE
Max Memory Ever Allocated : 36.97 G
Configured Max Per-thread Buffers : 1.48 G
Configured Max Global Buffers : 36.14 G
Configured Max Memory Limit : 37.62 G
Physical Memory : 46.99 G
Max memory limit seem to be within acceptable norms
KEY BUFFER
No key reads?!
Seriously look into using some indexes
Current MyISAM index space = 0 bytes
Current key_buffer_size = 128 M
Key cache miss rate is 1 : 0
Key buffer free ratio = 81 %
Your key_buffer_size seems to be fine
QUERY CACHE
Query cache is enabled
Current query_cache_size = 1 M
Current query_cache_used = 16 K
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 1.65 %
Current query_cache_min_res_unit = 4 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size
SORT OPERATIONS
Current sort_buffer_size = 4 M
Current read_rnd_buffer_size = 4 M
Sort buffer seems to be fine
JOINS
./tuning-primer.sh: line 402: export: `2097152': not a valid identifier
Current join_buffer_size = 4.00 M
You have had 48458 queries where a join could not use an index properly
join_buffer_size >= 4 M
This is not advised
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
OPEN FILES LIMIT
Current open_files_limit = 32768 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine
TABLE CACHE
Current table_open_cache = 16319 tables
Current table_definition_cache = 40000 tables
You have a total of 957 tables
You have 1124 open tables.
The table_cache value seems to be fine
TEMP TABLES
Current max_heap_table_size = 128 M
Current tmp_table_size = 128 M
Of 315112 temp tables, 2% were created on disk
Created disk tmp tables ratio seems fine
TABLE SCANS
Current read_buffer_size = 3 M
Current table scan ratio = 155 : 1
read_buffer_size seems to be fine
TABLE LOCKING
Current Lock Wait ratio = 0 : 172720142
Your table locking seems to be fine
[root#localhost ~]#
I can allocate 40gb ram to mariadb server.
I need 8gb ram. We can use all 24 processors.
Please help me how to do the settings.
The site will be used for a web-based game.
The tables were all using MyISAM.
I converted all of them to innodb and it works fine.
If you need additional information, let me know in the comments.
These seem excessive:
table_definition_cache = 40000 # UPD
table_open_cache = 40000 # UPD
Will you have thousands of tables? Why? Even if you do have that many, these are caches, hence they don't have to be big enough to handle everything.
For better performance turn on the slowlog with a low value such as long_query_time = 1. After a few hours, use pt-query-digest. More on the SlowLog
For a deeper analysis of the settings: http://mysql.rjweb.org/doc.php/mysql_analysis#tuning
Rate Per Second = RPS
Suggestions to consider for your my.cnf [mysqld] section to improve performance
read_rnd_buffer_size=32K # from 4M to reduce handler_read_rnd_next RPS of 20,873
read_buffer_size=1M # from 3M to reduce handler_read_next RPS of 20,918
innodb_buffer_pool_size=4G # from 36G because you only have 1.7G of data and indexes
net_buffer_length=96K # from 16K to accommodate sending 700MB data per hr
Let us know how your system is performing in a few days, please. View profile for contact information and we do have FREE Utility Scripts to assist with performance tuning.
This is only the beginning of improving performance for your installation. As you get deeper into the environment you will find many opportunities to improve response time and reduce system overhead. We are available to assist.

MariaDB Server 10.6.7 stuck on INSERT query after computer resumes from sleep

I have a recent updated MariaDB installation that suddenly hangs on a every-minute-cronjob after my computer resumes from sleep. Configuration worked fine before latest apt upgrade.
Process list shows an insert query from a ~100 insert batch operation.
I tried cancelling all running scripts before sending the computer to sleep, but at the next wakeup it will still fail. I have to kill -9 the database to even get it to restart.
Id? User? Host? db? Command? Time? State? Info? Progress?
52 xxxxxx localhost xxxxxx Execute 4 Update INSERT INTO xxxxxxx
and it will never finish. This also happens if i wait ~30 seconds after wakeup and start the script manually, so i kinda guess MariaDB handles sleep/resume state not too well.
Is this a known bug? Any way around having my PC run 24/7 to get around this?
Server variables too much for this post, only changed
innodb_buffer_pool_size = 64G
innodb_log_file_size = 16G
As suggested, i checked SHOW ENGINE INNODB STATUS while the lock is happening, cannot post this as a comment due to length
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 0 srv_active, 0 srv_shutdown, 4664 srv_idle
srv_master_thread log flush and writes: 4663
----------
SEMAPHORES
----------
------------
TRANSACTIONS
------------
Trx id counter 314781977
Purge done for trx's n:o < 314781976 undo n:o < 0 state: running
History list length 142
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 314781976, ACTIVE 106 sec inserting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1128, 1 row lock(s), undo log entries 1
MariaDB thread id 57, OS thread handle 140131630528064, query id 273212 localhost xxx Update
INSERT INTO xyzxyz (`xyz`, `xyz`, `time`, `xyz`, `xyz`) VALUES (?,?,?,?,?)
--------
FILE I/O
--------
Pending flushes (fsync) log: 0; buffer pool: 0
19307 OS file reads, 24298 OS file writes, 24302 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 932, free list len 2162, seg size 3095, 1 merges
merged operations:
insert 11, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 44207022268
Log flushed up to 44207022268
Pages flushed up to 44197540796
Last checkpoint at 44197540784
0 pending log flushes, 0 pending chkp writes
24306 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 68753031168
Dictionary memory allocated 424873192
Buffer pool size 4153344
Free buffers 4133333
Database pages 20011
Old database pages 7367
Modified db pages 3024
Percent of dirty pages(LRU & free pages): 0.073
Max dirty pages percent: 90.000
Pending reads 1
Pending writes: LRU 0, flush list 0
Pages made young 32, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 19243, created 741, written 0
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 20011, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 read views open inside InnoDB
Process ID=0, Main thread ID=0, state: sleeping
Number of rows inserted 24161, updated 113, deleted 0, read 623966
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
Number of system rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
I checked whether it's a deadlock due to a bad update-query, but it's and INSERT-query with State update which just means mariadb is about to update the table (but never does). I use mariadb 10.6.7 on debian testing - i may need to use a stable release to sort this out. Sleeping happens from seconds (still happening) to hours.
I tried:
Removed PRIMARY and UNIQUE-key with the same indizes. Same problem
Change innodb_flush_log_at_trx_commit to zero to not have it update log after every insert - still stuck on first insert.

Mysterious mariadb 10.4.1 ram ussage

i have upgraded from mariadb 10.1.36 to 10.4.8 and i can see mysterious increasing ram ussage on that new version. I also edited innodb_buffer_pool_size ant seems there is no effect if its set to 15M or 4G, ram is just slowly increasing. After while it eat whole ram and oom killer kills mariadb and this is repeating.
My server has 8GB RAM and its increasing like 60-150MB per day. Its not terrible but i have around 150 database servers so its huge problem.
I can temporary fix problem by restarting mariadb and its start again.
Info about database server:
databases: 200+
tables: 28200(141 per database)
average active connections: 100-200
size of stored data: 100-350GB
cpu: 4
ram: 8GB
there is my config:
server-id=101
datadir=/opt/mysql/
socket=/var/lib/mysql/mysql.sock
tmpdir=/tmp/
gtid-ignore-duplicates=True
log_bin=mysql-bin
expire_logs_days=4
wait_timeout=360
thread_cache_size=16
sql_mode="ALLOW_INVALID_DATES"
long_query_time=0.8
slow_query_log=1
slow_query_log_file=/opt/log/slow.log
log_output=TABLE
userstat = 1
user=mysql
symbolic-links=0
binlog_format=STATEMENT
default_storage_engine=InnoDB
slave_skip_errors=1062,1396,1690innodb_autoinc_lock_mode=2
innodb_buffer_pool_size=4G
innodb_buffer_pool_instances=5
innodb_log_file_size=1G
innodb_log_buffer_size=196M
innodb_flush_log_at_trx_commit=1
innodb_thread_concurrency=24
innodb_file_per_table
innodb_write_io_threads=24
innodb_read_io_threads=24
innodb_adaptive_flushing=1
innodb_purge_threads=5
innodb_adaptive_hash_index=64
innodb_flush_neighbors=0
innodb_flush_method=O_DIRECT
innodb_io_capacity=10000
innodb_io_capacity_max=16000
innodb_lru_scan_depth=1024
innodb_sort_buffer_size=32M
innodb_ft_cache_size=70M
innodb_ft_total_cache_size=1G
innodb_lock_wait_timeout=300
slave_parallel_threads=5
slave_parallel_mode=optimistic
slave_parallel_max_queued=10000000
log_slave_updates=on
performance_schema=on
skip-name-resolve
max_allowed_packet = 512M
query_cache_type=0
query_cache_size = 0
query_cache_limit = 1M
query_cache_min_res_unit=1K
max_connections = 1500
table_open_cache=64K
innodb_open_files=64K
table_definition_cache=64K
open_files_limit=1020000
collation-server = utf8_general_ci
character-set-server = utf8
log-error=/opt/log/error.log
log-error=/opt/log/error.log
pid-file=/var/run/mysqld/mysqld.pid
malloc-lib=/usr/lib64/libjemalloc.so.1
I solved it! The problem is memory allocation library.
If you do this SQL query:
SHOW VARIABLES LIKE 'version_malloc_library';
You must to get value "jemalloc" library. If you get only "system", you may have problems.
To change that, you need edit any .conf file in this directory:
/etc/systemd/system/mariadb.service.d/
There, add this line:
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1"
(this library file may be in other folder)
Then you must to restart mysqld
service mysqld stop && systemctl daemon-reload && service mysqld start
You got carried away in increasing values in my.cnf.
Many of the caches grow until hitting their limit, hence the memory growth you experienced.
What is the value from SHOW GLOBAL STATUS LIKE 'Max_used_connections';? Having a large max_connections accentuates several of the other values; lower it.
But perhaps the really bad one(s) involve table caches -- which have units of tables, not bytes. Crank these down a lot:
table_open_cache=64K
innodb_open_files=64K
table_definition_cache=64K
I have exactly the same problem. Is it due to a bad configuration? Or is it a bug of the new version?
mariadb 10.1 was updated to 10.3 just when I upgraded Debian 9 to Debian 10. I tried solve the problem with mariadb 10.4 but nothing changed.
I want to downgrade version but I think it's neccesary dump all database and restore it, and that means being hours without service.
I don't think Debian 10 has to do with the issue
Please read my previous comments about alternative memory allocators...
When jemalloc is used:
When default memory allocator used:
Try with tcmalloc
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4.5.3.1"

Not enough space when running Hudson jobs

My Hudson jobs are crashing on each run with this error:
Caused by: java.io.IOException: error=12, Not enough space
at java.lang.UNIXProcess.forkAndExec(Native Method)
I found documention on StackOverflow and on the Jenkins website regarding this error, which indicate a problem of swap space (https://wiki.jenkins-ci.org/display/JENKINS/IOException+Not+enough+space).
However, maybe my problem is different or not, but if I launch the process manually it works fine.
A weird thing is I see different resuls from top of from prstat:
Specs:
Hudson processes are running in their own Unix user
OS: SunOS dc5c00-d12 5.10 Generic_147440-19 sun4v sparc sun4v
Memory:
from top:
32G phys mem, 6255M free mem, 16G total swap, 16G free swap
from prstat
NPROC USERNAME SWAP RSS MEMORY TIME CPU
50 user1 12G 12G 39% 89:02:31 0.3%
36 user2 11G 6779M 21% 155:17:41 0.0%
26 user3 10G 8509M 26% 4787:37:4 8.0%
6 hudson 572M 556M 1.7% 0:08:25 0.0%
57 root 280M 285M 0.9% 138:46:05 0.0%
Can anywone confirm if I have a swap issue? top shows 16GB free...
EDIT:
results from swap -s (after problem being remporarly resolved)
total: 19940168k bytes allocated + 12578048k reserved = 32518216k used, 4118208k available
.
It is certainly a swap issue.
top is reporting as free swap blocks that do not contain paginated data. However, even while unused, some of these blocks can be reserved (i.e untouched still allocated virtual memory). When you have no more blocks to back memory reservations, you got this "Not enough space" exception.
swap -s shows your applications are reserving more that 12 GB while your swap area is just 16 GB. I would double the size of your swap to prevent virtual memory shortage in your case.

Resources