[chef] Re: Re: Re: chef-client memory usage


Chronological Thread 
  • From: Chris < >
  • To:
  • Subject: [chef] Re: Re: Re: chef-client memory usage
  • Date: Thu, 8 Dec 2011 14:38:16 -0800

I think that might end up being the plan. We deploy our application with some code i wrote to pulled stored configuration from a role, each deploy run calls the chef-client to make sure the role is up to date. The thing that worries me is that some applications can go months with out any updates, which means those VMs could be really out of date the next time we touch them. The ops team has problems patching Linux systems, so a while a cookbook change works on 1 set of VMs it might not work on something older etc. 

On Thu, Dec 8, 2011 at 2:17 PM, Erik Hollensbe < "> > wrote:
You could also schedule chef-client runs when they're necessary, e.g. design hooks for controlled deployments.

-Erik

On Dec 8, 2011, at 1:46 PM, Alex Soto wrote:

> maybe run the client via cron instead of a daemon so the memory use is only during client runs.
>
> On Dec 8, 2011, at 1:43 PM, Chris wrote:
>
>> My company is pretty late to the Chef party, only getting things started about 6 months ago (after a year of asking for it), but now that we have things up and running we've run into a bit of a problem. The client consumes a fairly large amount of memory, between 175-250m per server. This has caused a lot of concern from the Operations team since that amount * N VMs can get quite expensive. I've been doing some research into this and noticed that the amount of resident memory can depend on how many recipes are loaded on a node, and Opscode docs seem to confirm this. Right now these cookbooks are loaded into a single base role and added to each node for ease of use. They're all OS level recipes to manage hostfiles, resolv.conf etc.. etc.. There are 20 total. We also have application roles that can add another 3 or 4 recipes.
>> I've hacked around a bit on the Samba cookbook and removed all the code used to create users, which has lowered the memory foot print down to a steady 192m, but i fear this won't be enough to convince my ops team to keep chef. They want to dump it and go back to using shell and perl scripts for everything.
>>
>> My question is, does anyone have any tips for reducing the memory usage? I'd like to be able to keep Chef around.
>>
>> Thanks!
>>
>>
>




--
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.



Archive powered by MHonArc 2.6.16.

§