Skip to main content

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

tone
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 # [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.

Comments

7 comments

Date Votes
  • tone
    Why was this moved from the database sub-forum to this one?
    0
  • Infopro
    This thread reads like an optimization issue to me.
    0
  • tone
    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.
    0
  • cPanelLauren
    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!
    0
  • xml
    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 | #
    0
  • tone
    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.
    0
  • cPanelLauren
    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: --- 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: --- 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: --- /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.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post