Just couchdb. It's certainly not ideal, but its kept the monster at bay. Sent from a phone
On Nov 16, 2012, at 8:32 PM, Spike Grobstein <
">
> wrote: when you say restart, do you mean restarting the daemon or restarting the whole server?
...spike On Nov 16, 2012, at 11:31 PM, Chris wrote: I've run into this as well and came up with the same script. I've ended up resorting to nightly restarts to keep the disk usage in line. Without the restarts the view files stick around, sounds like that's what's happen here On Nov 16, 2012, at 7:09 PM, Spike Grobstein <
">
> wrote: I've added that line to my script and run it, but it doesn't appear to have done anything.
I'll keep an eye on my disk usage and see if that stifles the growth. I've got around 20GB free on the partition, so I should be safe for the next week while I observe.
...spike On Nov 16, 2012, at 10:05 PM, Peter Struijk wrote: It's been awhile since I looked at this but here's my couchdb compact recipe. It's similar in functionality to yours except for the last 5 lines:
http_request "cleanup chef couchDB" do
action :post url "#{Chef::Config[:couchdb_url]}/chef/_view_cleanup" end
Full recipe: https://gist.github.com/4092905
Our chef couchdb uses around 100mb. On Fri, Nov 16, 2012 at 5:01 PM, Spike Grobstein <
" target="_blank">
> wrote:
also, regarding the sandbox documents, I have a TON of documents that look like this:
{
"_id": "ffe7561e-0065-4396-9638-bb1a23cae511",
"_rev": "2-cfde619b3a2cd62afb8767d838b00712",
"create_time": "2012-03-26T21:05:42+00:00",
"json_class": "Chef::Sandbox",
"is_completed": true,
"name": "8311466ba0b845788c33bc7ef2fcdacf",
"checksums": [
],
"chef_type": "sandbox",
"guid": "8311466ba0b845788c33bc7ef2fcdacf"
}
is there any reason for these? Is there an easy way to safely delete them?
...spike
On Nov 16, 2012, at 7:50 PM, Spike Grobstein wrote: Hi Mark, I did that and ran my compaction script again... in the couchdb web UI, the size of the DB went from 41.9GB to 41.3GB and doesn't seem to be getting smaller. Additionally I did:
$ curl localhost:5984/chef {"db_name":"chef","doc_count":11178,"doc_del_count":204,"update_seq":497447,"purge_seq":0,"compact_running":false,"disk_size":44302975077,"instance_start_time":"1353113098236259","disk_format_version":5,"committed_update_seq":497447}
and it says it's does not have a compact_running. Is there anything else I can do? Is there any chance that this will reduce the amount of space used on-disk? I know some database systems will keep the space on-disk requisitioned, but I'm not super experienced with couchdb.
Thanks. ...spike On Nov 16, 2012, at 7:36 PM, Mark Anderson wrote: Check that you've set the _revs_limit for the db, otherwise compaction
will retain more versions than you need.
Something like:
% curl -X PUT -d '1' 'localhost:5984/chef/_revs_limit'
Sets it to 1, which is fine for chef.
From: Spike Grobstein <
" target="_blank">
>
Reply-To: "
" target="_blank">
" <
" target="_blank">
>
Date: Friday, November 16, 2012 4:26 PM
To: "
" target="_blank">
" <
" target="_blank">
>
Subject: [chef] Re: disk running out of space
Hi Ranjib,
I may have had 20 version bumps ever. I only just recently started
versioning as I needed to keep separate versions for prod and staging
environments.
I can't imagine version bumps causing 40GB+ of disk usage, though. I may
have uploaded my cookbooks a few thousand times, but I've only made 2 or 3
changes in the last month.
could there be something else?
...spike
On Nov 16, 2012, at 7:23 PM, Ranjib Dey wrote:
Do you bump up the cookbook versions too often? Check if you have older
versions of cookbooks thst you dont use,
On Nov 16, 2012 3:40 PM, "Spike Grobstein" <
" target="_blank">
>
wrote:
btw, this is my chef compaction script:
https://gist.github.com/4091940
forgot to include that before.
...spike
On Nov 16, 2012, at 6:38 PM, Spike Grobstein wrote:
Hi
I've been running chef-server since about March of this year on our
infrastructure for 81 nodes. After running out of space twice due to
couchDB compaction being incorrectly configured, I finally got it working
right, but I'm still beginning to run out of space
at a rate of around 1.5GB per week.
I began poking around in the couchDB web UI and we've got over 11,000
documents stored in the 'chef' database taking up 42GB. Looking at the
docs, they're mostly 'sandbox' objects from what I can tell, with the
occasional 'data_bag' object. Also, the vast majority
of the sandbox objects I've looked at have a 'create_time' of march or
april of this year.
So my questions are:
1. is there any way to clean up these old documents
2. is there any way to prevent couchdb from getting larger? I have a 60GB
disk allocated exclusively for couchdb data and that's a lot larger than
I'd really like
3. could it be something else that's misconfigured?
Some details about the installation:
The server is Ubuntu and chef-server was installed via the OpsCode PPA.
We're running chef 0.10.8.
I've got a couple of recipes that set node attributes when they run;
primarily datestamps for when some recipes are run so they don't get run
on a regular basis and things like that, but I'm not aware of anything
else I could be doing that would cause such
growth in the database.
Hopefully you guys can shed some light on this.
Thanks!
...spike
|