8GB tmp fills up every day due to database after recent upgrades

tone

Member
Oct 20, 2010
16
0
51
Background
I created a support ticket about this issue, but the reply was lacklustre - basically 'it's not our fault', which is probably true, but the issue didn't exist before a major WHM version upgrade and the configuration has been the same for quite some time with no new databases added...

The Problem
Any way, the issue is that tmp is filled up every day or so - 100% filled. This causes all other websites to stop working (for obvious reasons) and I can't seem to extend tmp (my Linux skills are beginner).

The Temporary Fix
The 'fix' to this issue is simply restarting MySQL via WHM. That reduces the tmp use back to ~3%.

my.cnf File

I use MariaDB 10.0 and here's a copy of the my.cnf

Code:
# [mysqld]
# innodb_file_per_table=1

[mysqld]
performance-schema=0
local-infile=0
innodb-flush-method=O_DIRECT
innodb-flush-log-at-trx-commit=2
innodb-file-per-table=1
innodb-buffer-pool-size=8G
table_open_cache=1024
innodb_lock_wait_timeout=900
default-storage-engine=MyISAM
open_files_limit=15086
max_user_connections=3000
max_connections=1500
thread_cache_size=1000
query_cache_size=384M
query_cache_limit=4M
table_open_cache=512M
table_definition_cache=80MB
tmp_table_size=256M
wait_timeout=20000
max_allowed_packet=256M
innodb_buffer_pool_size=334217728
innodb_file_per_table=1
key_buffer_size=2048M
Content of tmp dir
A combination of large (180MB) .MAD files and 'csscache' files for Xenforo, but only ~200KB max.

Additional Information
Server has 32GB of RAM and 16 threads, I believe - possibly 8 threads. Any suggestions or advice are welcomed as I'm not really sure what to do. Thank you for taking the time to read this.
 
Last edited:

tone

Member
Oct 20, 2010
16
0
51
This thread reads like an optimization issue to me.
It's an issue with an update that your usually helpful support team decided to not address. This was not an issue for the years prior to one of the major updates. I don't class that as a matter of optimisation.
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,295
1,272
313
Houston
Hi @tone

Before I get into it too much, can you provide me the ticket ID number so that I can take a look over that (just to avoid providing double information as well). I've not seen this behavior occur during or after a cPanel update but I'd definitely want to see some further information to rule that out for you.

I'm sorry your experience with our support wasn't exceptional and I hope I can help!


Thanks!
 

xml

Well-Known Member
Jan 15, 2004
93
3
158
The best thing to do is create a directory like
mkdir /home/mysqltmp
chown mysql:mysql /home/mysqltmp
Then put the following in /etc/my.cnf under [mysqld]
tmpdir=/home/mysqltmp
and restart MySQL.

When you run
mysqladmin variables|grep tmpdir

you should now see this

# mysqladmin variables|grep tmpdir
| tmpdir | /home/mysqltmp |
#
 

tone

Member
Oct 20, 2010
16
0
51
Hi @tone

Before I get into it too much, can you provide me the ticket ID number so that I can take a look over that (just to avoid providing double information as well). I've not seen this behavior occur during or after a cPanel update but I'd definitely want to see some further information to rule that out for you.

I'm sorry your experience with our support wasn't exceptional and I hope I can help!


Thanks!
Thank you. The ticket number is #10934757.
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,295
1,272
313
Houston
Hi @tone

I just took a look at that ticket, and thank you for providing it. The information the Analyst (Roman) provided did indicate that you issue is related to tmpwatch which is an OS provided function but he also noted some things he'd like to look into further. The full response is below:
=======================================================================
Hello, Thank you for your patience while I investigated the issue for you. Please note that cPanel & WHM does not provide the tmpwatch command but the OS does.
I can see the tmpwatch command was updated on December the 3rd: ---
Code:
egrep tmpwatch /var/log/yum.log* /var/log/yum.log-20170101:Dec 03 10:00:13 Updated: tmpwatch-2.9.16-6.el6.x86_64
---
But the changelog does not show anything recently:
---
tmpwatch-2.9.16-6.el6.x86_64.rpm CentOS 6 Download
---
Looking at the cron task configured:
---
Code:
crontab  -u root -l|egrep tmp 0 * * * * /usr/sbin/tmpwatch --mtime --all 24 /tmp
---
And taking into consideration the fact the problematic files are related to a database makes me believe the problem might be that you have tmpwatch configured to delete files that have not been modified within the 24 hours but since database cache files are going to be modified/created with a high-frequency tmpwatchd might not be picking those up.
Would you be able to try with a different time frame? Please refer to:
---
How to use tmpwatch Command in Linux
---
Also, right now the /tmp directory does not have many files:
---
Code:
/dev/md5        7.8G  160M  7.3G   3% /tmp
---
If you are still experiencing the issue after adjusting the tmpwatch cron I will recommend you letting the /tmp directory grow a bit more so we can look at the files within.
I hope this helps!
Best Regards,

=======================================================================

Based on this response it looks like he did acknowledge there was an issue, he provided some suggestions but also he wasn't able to replicate a large amount of data in tmp at the time of login and requested you let it build up some before we looked at it again.

I'd like to see if it would be possible to reopen this ticket, especially if tmp is filling up again.