mysql memory usage keeps growing without visible reason
We have LXC container running MariaDB.
It's dedicated to mysql use.
But for some reason it keeps crashing mysqld regularly when the memory peaks even though mysql does not seem to be doing anything much. Memory usage keeps growing slowly until mysql crashes.
I'm thinking it's a remnant of forge script somewhere. We removed the nginx and postgres that forge used to create the cluster. No need for those on dedicated DB server.
SHOW ENGINE INNODB STATUS;
| InnoDB | |
=====================================
2017-05-19 09:12:27 7fe4f56bc700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 12 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 3000 srv_active, 0 srv_shutdown, 20 srv_idle
srv_master_thread log flush and writes: 3020
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 11623
OS WAIT ARRAY INFO: signal count 174000
Mutex spin waits 195205, rounds 178858, OS waits 3736
RW-shared spins 57572, rounds 308469, OS waits 4515
RW-excl spins 22013, rounds 427244, OS waits 2373
Spin rounds per wait: 0.92 mutex, 5.36 RW-shared, 19.41 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 299252821
Purge done for trx's n:o < 299252819 undo n:o < 0 state: running but idle
History list length 48
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 602, OS thread handle 0x7fe4f56bc700, query id 1388395 localhost forge init
SHOW ENGINE INNODB STATUS
---TRANSACTION 0, not started
MySQL thread id 578, OS thread handle 0x7fe4f56fe700, query id 885293 192.168.14.12 forge cleaning up
---TRANSACTION 299251342, not started
MySQL thread id 501, OS thread handle 0x7fe4f5740700, query id 1382283 192.168.14.12 forge cleaning up
...
MySQL thread id 8, OS thread handle 0x7fe8794cb700, query id 1384304 192.168.14.12 forge cleaning up
---TRANSACTION 299251627, not started
MySQL thread id 2, OS thread handle 0x7fe879591700, query id 1383374 192.168.14.12 forge cleaning up
---TRANSACTION 299251397, not started
MySQL thread id 6, OS thread handle 0x7fe87950d700, query id 1382507 192.168.14.12 forge cleaning up
---TRANSACTION 299251798, not started
MySQL thread id 4, OS thread handle 0x7fe87954f700, query id 1384008 192.168.14.12 forge cleaning up
---TRANSACTION 298962435, not started
MySQL thread id 1, OS thread handle 0x7fe8795b2700, query id 0 Waiting for requests
---TRANSACTION 299252820, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 0
MySQL thread id 579, OS thread handle 0x7fe4f571f700, query id 1388394 192.168.14.12 forge Sending data
select * from `rebates` where `user_id` = 'aced8584-38c4-47ce-8822-e59ba73b0c7f' and `rebatestatus` = '0' and `rebates`.`deleted_at` is null
Trx read view will not see trx with id >= 299252821, sees < 299252821
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
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 627, free list len 3411, seg size 4039, 39712 merges
merged operations:
insert 51976, delete mark 25, delete 5
discarded operations:
insert 0, delete mark 0, delete 0
66892.34 hash searches/s, 3647.78 non-hash searches/s
---
LOG
---
Log sequence number 97482534696
Log flushed up to 97482534696
Pages flushed up to 97426813684
Last checkpoint at 97426779284
Max checkpoint age 848635454
Checkpoint age target 822115597
Modified age 55721012
Checkpoint age 55755412
0 pending log writes, 0 pending chkp writes
121101 log i/o's done, 90.58 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 12370575360; in additional pool allocated 0
Total memory allocated by read views 59176
Internal hash tables (constant factor + variable factor)
Adaptive hash index 1041590304 (186996664 + 854593640)
Page hash 1461976 (buffer pool 0 only)
Dictionary cache 50011652 (46750576 + 3261076)
File system 1114952 (812272 + 302680)
Lock system 29400808 (29219368 + 181440)
Recovery system 0 (0 + 0)
Dictionary memory allocated 3261076
Buffer pool size 720888
Buffer pool size, bytes 11811028992
Free buffers 18393
Database pages 650335
Old database pages 240144
Modified db pages 84859
Percent of dirty pages(LRU & free pages): 12.690
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 39535, not young 153840
7.17 youngs/s, 12.25 non-youngs/s
Pages read 652480, created 1775, written 26596
14.83 reads/s, 0.92 creates/s, 13.25 writes/s
Buffer pool hit rate 999 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 650335, unzip_LRU len: 0
I/O sum[8288]:cur[32], unzip sum[0]:cur[0]
mysql mariadb memory
edited May 19 '17 at 10:04
Marco
3,68731524
asked May 19 '17 at 9:30
SamTzuSamTzu
1
bumped to the homepage by Community♦ 1 hour ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
We have LXC container running MariaDB.
It's dedicated to mysql use.
But for some reason it keeps crashing mysqld regularly when the memory peaks even though mysql does not seem to be doing anything much. Memory usage keeps growing slowly until mysql crashes.
I'm thinking it's a remnant of forge script somewhere. We removed the nginx and postgres that forge used to create the cluster. No need for those on dedicated DB server.
SHOW ENGINE INNODB STATUS;
| InnoDB | |
=====================================
2017-05-19 09:12:27 7fe4f56bc700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 12 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 3000 srv_active, 0 srv_shutdown, 20 srv_idle
srv_master_thread log flush and writes: 3020
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 11623
OS WAIT ARRAY INFO: signal count 174000
Mutex spin waits 195205, rounds 178858, OS waits 3736
RW-shared spins 57572, rounds 308469, OS waits 4515
RW-excl spins 22013, rounds 427244, OS waits 2373
Spin rounds per wait: 0.92 mutex, 5.36 RW-shared, 19.41 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 299252821
Purge done for trx's n:o < 299252819 undo n:o < 0 state: running but idle
History list length 48
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 602, OS thread handle 0x7fe4f56bc700, query id 1388395 localhost forge init
SHOW ENGINE INNODB STATUS
---TRANSACTION 0, not started
MySQL thread id 578, OS thread handle 0x7fe4f56fe700, query id 885293 192.168.14.12 forge cleaning up
---TRANSACTION 299251342, not started
MySQL thread id 501, OS thread handle 0x7fe4f5740700, query id 1382283 192.168.14.12 forge cleaning up
...
MySQL thread id 8, OS thread handle 0x7fe8794cb700, query id 1384304 192.168.14.12 forge cleaning up
---TRANSACTION 299251627, not started
MySQL thread id 2, OS thread handle 0x7fe879591700, query id 1383374 192.168.14.12 forge cleaning up
---TRANSACTION 299251397, not started
MySQL thread id 6, OS thread handle 0x7fe87950d700, query id 1382507 192.168.14.12 forge cleaning up
---TRANSACTION 299251798, not started
MySQL thread id 4, OS thread handle 0x7fe87954f700, query id 1384008 192.168.14.12 forge cleaning up
---TRANSACTION 298962435, not started
MySQL thread id 1, OS thread handle 0x7fe8795b2700, query id 0 Waiting for requests
---TRANSACTION 299252820, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 0
MySQL thread id 579, OS thread handle 0x7fe4f571f700, query id 1388394 192.168.14.12 forge Sending data
select * from `rebates` where `user_id` = 'aced8584-38c4-47ce-8822-e59ba73b0c7f' and `rebatestatus` = '0' and `rebates`.`deleted_at` is null
Trx read view will not see trx with id >= 299252821, sees < 299252821
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
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 627, free list len 3411, seg size 4039, 39712 merges
merged operations:
insert 51976, delete mark 25, delete 5
discarded operations:
insert 0, delete mark 0, delete 0
66892.34 hash searches/s, 3647.78 non-hash searches/s
---
LOG
---
Log sequence number 97482534696
Log flushed up to 97482534696
Pages flushed up to 97426813684
Last checkpoint at 97426779284
Max checkpoint age 848635454
Checkpoint age target 822115597
Modified age 55721012
Checkpoint age 55755412
0 pending log writes, 0 pending chkp writes
121101 log i/o's done, 90.58 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 12370575360; in additional pool allocated 0
Total memory allocated by read views 59176
Internal hash tables (constant factor + variable factor)
Adaptive hash index 1041590304 (186996664 + 854593640)
Page hash 1461976 (buffer pool 0 only)
Dictionary cache 50011652 (46750576 + 3261076)
File system 1114952 (812272 + 302680)
Lock system 29400808 (29219368 + 181440)
Recovery system 0 (0 + 0)
Dictionary memory allocated 3261076
Buffer pool size 720888
Buffer pool size, bytes 11811028992
Free buffers 18393
Database pages 650335
Old database pages 240144
Modified db pages 84859
Percent of dirty pages(LRU & free pages): 12.690
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 39535, not young 153840
7.17 youngs/s, 12.25 non-youngs/s
Pages read 652480, created 1775, written 26596
14.83 reads/s, 0.92 creates/s, 13.25 writes/s
Buffer pool hit rate 999 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 650335, unzip_LRU len: 0
I/O sum[8288]:cur[32], unzip sum[0]:cur[0]
mysql mariadb memory
edited May 19 '17 at 10:04
Marco
3,68731524
asked May 19 '17 at 9:30
SamTzuSamTzu
1
bumped to the homepage by Community♦ 1 hour ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
We have LXC container running MariaDB.
It's dedicated to mysql use.
But for some reason it keeps crashing mysqld regularly when the memory peaks even though mysql does not seem to be doing anything much. Memory usage keeps growing slowly until mysql crashes.
I'm thinking it's a remnant of forge script somewhere. We removed the nginx and postgres that forge used to create the cluster. No need for those on dedicated DB server.
SHOW ENGINE INNODB STATUS;
| InnoDB | |
=====================================
2017-05-19 09:12:27 7fe4f56bc700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 12 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 3000 srv_active, 0 srv_shutdown, 20 srv_idle
srv_master_thread log flush and writes: 3020
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 11623
OS WAIT ARRAY INFO: signal count 174000
Mutex spin waits 195205, rounds 178858, OS waits 3736
RW-shared spins 57572, rounds 308469, OS waits 4515
RW-excl spins 22013, rounds 427244, OS waits 2373
Spin rounds per wait: 0.92 mutex, 5.36 RW-shared, 19.41 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 299252821
Purge done for trx's n:o < 299252819 undo n:o < 0 state: running but idle
History list length 48
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 602, OS thread handle 0x7fe4f56bc700, query id 1388395 localhost forge init
SHOW ENGINE INNODB STATUS
---TRANSACTION 0, not started
MySQL thread id 578, OS thread handle 0x7fe4f56fe700, query id 885293 192.168.14.12 forge cleaning up
---TRANSACTION 299251342, not started
MySQL thread id 501, OS thread handle 0x7fe4f5740700, query id 1382283 192.168.14.12 forge cleaning up
...
MySQL thread id 8, OS thread handle 0x7fe8794cb700, query id 1384304 192.168.14.12 forge cleaning up
---TRANSACTION 299251627, not started
MySQL thread id 2, OS thread handle 0x7fe879591700, query id 1383374 192.168.14.12 forge cleaning up
---TRANSACTION 299251397, not started
MySQL thread id 6, OS thread handle 0x7fe87950d700, query id 1382507 192.168.14.12 forge cleaning up
---TRANSACTION 299251798, not started
MySQL thread id 4, OS thread handle 0x7fe87954f700, query id 1384008 192.168.14.12 forge cleaning up
---TRANSACTION 298962435, not started
MySQL thread id 1, OS thread handle 0x7fe8795b2700, query id 0 Waiting for requests
---TRANSACTION 299252820, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 0
MySQL thread id 579, OS thread handle 0x7fe4f571f700, query id 1388394 192.168.14.12 forge Sending data
select * from `rebates` where `user_id` = 'aced8584-38c4-47ce-8822-e59ba73b0c7f' and `rebatestatus` = '0' and `rebates`.`deleted_at` is null
Trx read view will not see trx with id >= 299252821, sees < 299252821
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
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 627, free list len 3411, seg size 4039, 39712 merges
merged operations:
insert 51976, delete mark 25, delete 5
discarded operations:
insert 0, delete mark 0, delete 0
66892.34 hash searches/s, 3647.78 non-hash searches/s
---
LOG
---
Log sequence number 97482534696
Log flushed up to 97482534696
Pages flushed up to 97426813684
Last checkpoint at 97426779284
Max checkpoint age 848635454
Checkpoint age target 822115597
Modified age 55721012
Checkpoint age 55755412
0 pending log writes, 0 pending chkp writes
121101 log i/o's done, 90.58 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 12370575360; in additional pool allocated 0
Total memory allocated by read views 59176
Internal hash tables (constant factor + variable factor)
Adaptive hash index 1041590304 (186996664 + 854593640)
Page hash 1461976 (buffer pool 0 only)
Dictionary cache 50011652 (46750576 + 3261076)
File system 1114952 (812272 + 302680)
Lock system 29400808 (29219368 + 181440)
Recovery system 0 (0 + 0)
Dictionary memory allocated 3261076
Buffer pool size 720888
Buffer pool size, bytes 11811028992
Free buffers 18393
Database pages 650335
Old database pages 240144
Modified db pages 84859
Percent of dirty pages(LRU & free pages): 12.690
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 39535, not young 153840
7.17 youngs/s, 12.25 non-youngs/s
Pages read 652480, created 1775, written 26596
14.83 reads/s, 0.92 creates/s, 13.25 writes/s
Buffer pool hit rate 999 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 650335, unzip_LRU len: 0
I/O sum[8288]:cur[32], unzip sum[0]:cur[0]
mysql mariadb memory
edited May 19 '17 at 10:04
Marco
3,68731524
asked May 19 '17 at 9:30
SamTzuSamTzu
1
We have LXC container running MariaDB.
It's dedicated to mysql use.
But for some reason it keeps crashing mysqld regularly when the memory peaks even though mysql does not seem to be doing anything much. Memory usage keeps growing slowly until mysql crashes.
I'm thinking it's a remnant of forge script somewhere. We removed the nginx and postgres that forge used to create the cluster. No need for those on dedicated DB server.
SHOW ENGINE INNODB STATUS;
| InnoDB | |
=====================================
2017-05-19 09:12:27 7fe4f56bc700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 12 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 3000 srv_active, 0 srv_shutdown, 20 srv_idle
srv_master_thread log flush and writes: 3020
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 11623
OS WAIT ARRAY INFO: signal count 174000
Mutex spin waits 195205, rounds 178858, OS waits 3736
RW-shared spins 57572, rounds 308469, OS waits 4515
RW-excl spins 22013, rounds 427244, OS waits 2373
Spin rounds per wait: 0.92 mutex, 5.36 RW-shared, 19.41 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 299252821
Purge done for trx's n:o < 299252819 undo n:o < 0 state: running but idle
History list length 48
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 602, OS thread handle 0x7fe4f56bc700, query id 1388395 localhost forge init
SHOW ENGINE INNODB STATUS
---TRANSACTION 0, not started
MySQL thread id 578, OS thread handle 0x7fe4f56fe700, query id 885293 192.168.14.12 forge cleaning up
---TRANSACTION 299251342, not started
MySQL thread id 501, OS thread handle 0x7fe4f5740700, query id 1382283 192.168.14.12 forge cleaning up
...
MySQL thread id 8, OS thread handle 0x7fe8794cb700, query id 1384304 192.168.14.12 forge cleaning up
---TRANSACTION 299251627, not started
MySQL thread id 2, OS thread handle 0x7fe879591700, query id 1383374 192.168.14.12 forge cleaning up
---TRANSACTION 299251397, not started
MySQL thread id 6, OS thread handle 0x7fe87950d700, query id 1382507 192.168.14.12 forge cleaning up
---TRANSACTION 299251798, not started
MySQL thread id 4, OS thread handle 0x7fe87954f700, query id 1384008 192.168.14.12 forge cleaning up
---TRANSACTION 298962435, not started
MySQL thread id 1, OS thread handle 0x7fe8795b2700, query id 0 Waiting for requests
---TRANSACTION 299252820, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 0
MySQL thread id 579, OS thread handle 0x7fe4f571f700, query id 1388394 192.168.14.12 forge Sending data
select * from `rebates` where `user_id` = 'aced8584-38c4-47ce-8822-e59ba73b0c7f' and `rebatestatus` = '0' and `rebates`.`deleted_at` is null
Trx read view will not see trx with id >= 299252821, sees < 299252821
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
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 627, free list len 3411, seg size 4039, 39712 merges
merged operations:
insert 51976, delete mark 25, delete 5
discarded operations:
insert 0, delete mark 0, delete 0
66892.34 hash searches/s, 3647.78 non-hash searches/s
---
LOG
---
Log sequence number 97482534696
Log flushed up to 97482534696
Pages flushed up to 97426813684
Last checkpoint at 97426779284
Max checkpoint age 848635454
Checkpoint age target 822115597
Modified age 55721012
Checkpoint age 55755412
0 pending log writes, 0 pending chkp writes
121101 log i/o's done, 90.58 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 12370575360; in additional pool allocated 0
Total memory allocated by read views 59176
Internal hash tables (constant factor + variable factor)
Adaptive hash index 1041590304 (186996664 + 854593640)
Page hash 1461976 (buffer pool 0 only)
Dictionary cache 50011652 (46750576 + 3261076)
File system 1114952 (812272 + 302680)
Lock system 29400808 (29219368 + 181440)
Recovery system 0 (0 + 0)
Dictionary memory allocated 3261076
Buffer pool size 720888
Buffer pool size, bytes 11811028992
Free buffers 18393
Database pages 650335
Old database pages 240144
Modified db pages 84859
Percent of dirty pages(LRU & free pages): 12.690
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 39535, not young 153840
7.17 youngs/s, 12.25 non-youngs/s
Pages read 652480, created 1775, written 26596
14.83 reads/s, 0.92 creates/s, 13.25 writes/s
Buffer pool hit rate 999 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 650335, unzip_LRU len: 0
I/O sum[8288]:cur[32], unzip sum[0]:cur[0]
mysql mariadb memory
mysql mariadb memory
edited May 19 '17 at 10:04
Marco
3,68731524
asked May 19 '17 at 9:30
SamTzuSamTzu
1
edited May 19 '17 at 10:04
Marco
3,68731524
asked May 19 '17 at 9:30
SamTzuSamTzu
1
edited May 19 '17 at 10:04
Marco
3,68731524
edited May 19 '17 at 10:04
Marco
3,68731524
edited May 19 '17 at 10:04
Marco
3,68731524
3,68731524
asked May 19 '17 at 9:30
SamTzuSamTzu
1
asked May 19 '17 at 9:30
SamTzuSamTzu
1
asked May 19 '17 at 9:30
SamTzuSamTzu
1
1
bumped to the homepage by Community♦ 1 hour ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 1 hour ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
How much RAM do you have? What is the value of innodb_buffer_pool_size? The latter should be about 70% of the former.
Did you change any other settings in my.cnf? If so, beware -- you could be causing the crash.
Memory will increase until the buffer_pool is full size. Other 'caches' will also grow until full size. At that point, various smaller allocations will come and go. You should never run out of memory. If you do, then some setting(s) is too large.
I mentioned only one particular setting because that is the most useful for a dedicated mysql server. Leaving the rest alone is best practice until some particular need shows that something else needs tuning. This is rare.
answered May 19 '17 at 18:09
Rick JamesRick James
41.1k22258
Good points but what about the "forge cleaning up" mentioned in the TRANSACTIONS. There were over 500 of those. After mysql restart those disappear then start to grow again.
– SamTzu
May 19 '17 at 19:47
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f174018%2fmysql-memory-usage-keeps-growing-without-visible-reason%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
How much RAM do you have? What is the value of innodb_buffer_pool_size? The latter should be about 70% of the former.
Did you change any other settings in my.cnf? If so, beware -- you could be causing the crash.
Memory will increase until the buffer_pool is full size. Other 'caches' will also grow until full size. At that point, various smaller allocations will come and go. You should never run out of memory. If you do, then some setting(s) is too large.
I mentioned only one particular setting because that is the most useful for a dedicated mysql server. Leaving the rest alone is best practice until some particular need shows that something else needs tuning. This is rare.
answered May 19 '17 at 18:09
Rick JamesRick James
41.1k22258
Good points but what about the "forge cleaning up" mentioned in the TRANSACTIONS. There were over 500 of those. After mysql restart those disappear then start to grow again.
– SamTzu
May 19 '17 at 19:47
add a comment |
How much RAM do you have? What is the value of innodb_buffer_pool_size? The latter should be about 70% of the former.
Did you change any other settings in my.cnf? If so, beware -- you could be causing the crash.
Memory will increase until the buffer_pool is full size. Other 'caches' will also grow until full size. At that point, various smaller allocations will come and go. You should never run out of memory. If you do, then some setting(s) is too large.
I mentioned only one particular setting because that is the most useful for a dedicated mysql server. Leaving the rest alone is best practice until some particular need shows that something else needs tuning. This is rare.
answered May 19 '17 at 18:09
Rick JamesRick James
41.1k22258
Good points but what about the "forge cleaning up" mentioned in the TRANSACTIONS. There were over 500 of those. After mysql restart those disappear then start to grow again.
– SamTzu
May 19 '17 at 19:47
add a comment |
How much RAM do you have? What is the value of innodb_buffer_pool_size? The latter should be about 70% of the former.
Did you change any other settings in my.cnf? If so, beware -- you could be causing the crash.
Memory will increase until the buffer_pool is full size. Other 'caches' will also grow until full size. At that point, various smaller allocations will come and go. You should never run out of memory. If you do, then some setting(s) is too large.
I mentioned only one particular setting because that is the most useful for a dedicated mysql server. Leaving the rest alone is best practice until some particular need shows that something else needs tuning. This is rare.
answered May 19 '17 at 18:09
Rick JamesRick James
41.1k22258
How much RAM do you have? What is the value of innodb_buffer_pool_size? The latter should be about 70% of the former.
Did you change any other settings in my.cnf? If so, beware -- you could be causing the crash.
Memory will increase until the buffer_pool is full size. Other 'caches' will also grow until full size. At that point, various smaller allocations will come and go. You should never run out of memory. If you do, then some setting(s) is too large.
I mentioned only one particular setting because that is the most useful for a dedicated mysql server. Leaving the rest alone is best practice until some particular need shows that something else needs tuning. This is rare.
answered May 19 '17 at 18:09
Rick JamesRick James
41.1k22258
answered May 19 '17 at 18:09
Rick JamesRick James
41.1k22258
answered May 19 '17 at 18:09
Rick JamesRick James
41.1k22258
answered May 19 '17 at 18:09
Rick JamesRick James
41.1k22258
41.1k22258
Good points but what about the "forge cleaning up" mentioned in the TRANSACTIONS. There were over 500 of those. After mysql restart those disappear then start to grow again.
– SamTzu
May 19 '17 at 19:47
add a comment |
Good points but what about the "forge cleaning up" mentioned in the TRANSACTIONS. There were over 500 of those. After mysql restart those disappear then start to grow again.
– SamTzu
May 19 '17 at 19:47
Good points but what about the "forge cleaning up" mentioned in the TRANSACTIONS. There were over 500 of those. After mysql restart those disappear then start to grow again.
– SamTzu
May 19 '17 at 19:47
Good points but what about the "forge cleaning up" mentioned in the TRANSACTIONS. There were over 500 of those. After mysql restart those disappear then start to grow again.
– SamTzu
May 19 '17 at 19:47
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f174018%2fmysql-memory-usage-keeps-growing-without-visible-reason%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
