Puppet Master Disk usage management

[Mark Rosedale]

Hello,

I'm running puppet  with puppetdb and puppet-dashboard all on my master.

I want to make sure that I don't get overrun with disk usage by either the master (storing reports) or the dbs for puppetdb (I'm running postgres) or puppet-dashboard (mysql). 

I'm wondering what some people do to manage disk usage for each of these? 

Thanks,

mjr 

 

[Dhaval Thakar]

Hi,

I run following commands to clean reports from mysql & filesystem.

I am still learning puppet, try this on your test setup. For my requirement dashboard reports for three days is enough.

cd /usr/share/puppet-dashboard ; export RAILS_ENV=production ; rake reports:prune upto=3 unit=day
cd /usr/share/puppet-dashboard ; export RAILS_ENV=production ; rake reports:prune:orphaned
find /var/lib/puppet/reports/ -mmin +300 -type f -print0 | xargs -0 -r rm > /dev/null 2>&1

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Mark Rosedale]

That is good information, though I find that the prune command for puppet-dashboard doesn't really seem to have a major impact on disk usage. 

I did find this as yet another directory where reports are stored 

/usr/share/puppet-dashboard/spool

Looks like that may need the same attention /var/lib/puppet/reports needs. 

[Ramin K]

In regards to Puppet Dashboard, the Mysql based one, I wrote this up
over a year ago
https://ask.puppetlabs.com/question/884/how-do-i-reduce-the-space-mysql-is-using-for-puppet-dashboard/

Remember just doing the prunes will not reclaim space. You must optimize
the table in order to shrink it. And running the optimize will not
reclaim space unless the table resides in its own file.

Ramin

[Mark Rosedale]

I went through your ask post. This was extremely helpful information. However, I wanted to add some updated information about reclaiming your space the hard way. 

According to the mysql documentation you can change the innodb_file_per_table setting and then run the following command to split the table off into its own file. 

ALTER TABLE report_logs ENGINE=InnoDB;

Then you can run the following and you'll see that there is in fact a new ibd file. 

ls -lah /var/lib/mysql/dashboard/report*

-rw-rw----. 1 mysql mysql 8.7K Oct 16 09:36 /var/lib/mysql/dashboard/report_logs.frm

-rw-rw----. 1 mysql mysql  36M Oct 16 09:40 /var/lib/mysql/dashboard/report_logs.ibd

So I don't think you have actually nuke your mysql configuration altogether. 

mjr

[Ramin K]

On 10/16/2014 6:51 AM, Mark Rosedale wrote:
> I went through your ask post. This was extremely helpful information.
> However, I wanted to add some updated information about reclaiming your
> space the hard way.
>
> According to the mysql documentation

> <http://dev.mysql.com/doc/refman/5.6/en/tablespace-enabling.html> you

> can change the innodb_file_per_table setting and then run the following
> command to split the table off into its own file.

I wasn't aware that it was that easy to break tables out. That appears
to be a 5.5+ feature based on docs, but maybe I just can't find the
reference to it in earlier versions. At first glance this looked like a
very simple way to solve the problem. However it will reclaim space in
the manner you're expecting. The problem is that space in the system
idbata files is never reclaimed. If you've allowed your Dashboard db to
grow to 80GB without innodb_file_per_table when you create the new table
with this method the new table will be the size of the data which is
what we expect because it was created new. Unfortunately the system
ibdata files will still be 80GB.

http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_system_tablespace

Ramin