# Chef-client memory usage

**URL:** <https://discourse.chef.io/t/chef-client-memory-usage/2319>\
**Category:** Chef Infra (archive)\
**Created:** [December 8, 2011, 9:43pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319 "2011-12-08T21:43:56Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Chris](https://avatars.discourse-cdn.com/v4/letter/c/958977/32.png) [@Chris](https://discourse.chef.io/u/Chris)\
**Post date:** [December 8, 2011, 9:43pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/1 "2011-12-08T21:43:56Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![Brad\_Knowles](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/brad_knowles/32/716_2.png) [@Brad\_Knowles](https://discourse.chef.io/u/Brad_Knowles)\
**Post date:** [December 8, 2011, 11:00pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/2 "2011-12-08T23:00:29Z")

</div>

On Dec 8, 2011, at 3: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.

We've been doing chef since August using 0.10.4 on CentOS 5.6. We currently have 43 cookbooks and 37 roles across all of our machines, but I use roles very heavily (I'll test a new cookbook as a new role on a new machine and then when I'm happy I might include that role as part of another larger role). We just spun up a "staging" environment today, which added twelve new nodes, taking us up to 33 total being managed by chef. On one of our most complex nodes, the run\_list has five main roles loaded, while the expanded run\_list is sixteen roles and comprises thirty recipes.

I checked, and when chef-client is active, we hit a VSS of about 195MB, but a Resident (working) Set Size of 60-70MB. Even a dry run includes multiple invocations of Python, Perl, and various other programs and languages, many of which have VSS & RSS that are almost as big as chef-client, even though they might only persist for a few seconds during the run.

In comparison, the RevealCloud agent that we run on every machine has a VSS of ~160MB, although the RSS is just over 2MB. This machine is brand-new and is virtually idle, but each httpd process has a VSS of ~150MB and an RSS of just under 5MB, and we spin up a total of seventeen of them.

This is on a Rackspace "flavor 3" VM which has allocated to it 1GB of RAM, 40GB of hard disk space (~35GB usable), etc.... There are only two VM images that Rackspace makes available that are smaller than this -- a "flavor 2" with 512MB of RAM, and a "flavor 1" with 256MB of RAM.

Compared to all the other things that this VM is doing, the overhead of chef-client seems pretty reasonable to me -- not really any more than another httpd process, or the overhead from the RevealCloud monitoring system. Not something that I would consider totally negligible, but also not that significant.

Speaking only for myself, I believe that if you've got systems where you really are this tightly constrained for memory, then I think you've got much bigger problems than whether or not you can afford to run chef-client.

--  
Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com)  
SAGE Level IV, Chef Level 0.0.1

---

<div class="post-metadata">

**Author:** ![Chris](https://avatars.discourse-cdn.com/v4/letter/c/958977/32.png) [@Chris](https://discourse.chef.io/u/Chris)\
**Post date:** [December 8, 2011, 11:09pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/3 "2011-12-08T23:09:38Z")

</div>

Hi Brad,

I agree with you, there are other problems surrounding our memory  
constraints. Namely, I'm not allowed to take memory away from Java and Java  
is never allowed to go into swap. We routinely provision 8GB VMs and give  
Java 7 of that, and the Java dev teams won't budge on that.

I'm really surprised that your client is so lean, but you're CentOS version  
is also newer then ours. We have systems ranging from 5.2-5.5, most have  
never been patched. I'm pretty sure we're missing out on some  
optimizations. I'm curious, are most of your cookbooks from Opscode or home  
grown?

On Thu, Dec 8, 2011 at 3:00 PM, Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com) wrote:

> On Dec 8, 2011, at 3: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.
> 
> We've been doing chef since August using 0.10.4 on CentOS 5.6. We  
> currently have 43 cookbooks and 37 roles across all of our machines, but I  
> use roles very heavily (I'll test a new cookbook as a new role on a new  
> machine and then when I'm happy I might include that role as part of  
> another larger role). We just spun up a "staging" environment today, which  
> added twelve new nodes, taking us up to 33 total being managed by chef. On  
> one of our most complex nodes, the run\_list has five main roles loaded,  
> while the expanded run\_list is sixteen roles and comprises thirty recipes.
> 
> I checked, and when chef-client is active, we hit a VSS of about 195MB,  
> but a Resident (working) Set Size of 60-70MB. Even a dry run includes  
> multiple invocations of Python, Perl, and various other programs and  
> languages, many of which have VSS & RSS that are almost as big as  
> chef-client, even though they might only persist for a few seconds during  
> the run.
> 
> In comparison, the RevealCloud agent that we run on every machine has a  
> VSS of ~160MB, although the RSS is just over 2MB. This machine is  
> brand-new and is virtually idle, but each httpd process has a VSS of ~150MB  
> and an RSS of just under 5MB, and we spin up a total of seventeen of them.
> 
> This is on a Rackspace "flavor 3" VM which has allocated to it 1GB of RAM,  
> 40GB of hard disk space (~35GB usable), etc.... There are only two VM  
> images that Rackspace makes available that are smaller than this -- a  
> "flavor 2" with 512MB of RAM, and a "flavor 1" with 256MB of RAM.
> 
> Compared to all the other things that this VM is doing, the overhead of  
> chef-client seems pretty reasonable to me -- not really any more than  
> another httpd process, or the overhead from the RevealCloud monitoring  
> system. Not something that I would consider totally negligible, but also  
> not that significant.
> 
> Speaking only for myself, I believe that if you've got systems where you  
> really are this tightly constrained for memory, then I think you've got  
> much bigger problems than whether or not you can afford to run chef-client.
> 
> --  
> Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com)  
> SAGE Level IV, Chef Level 0.0.1

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

---

<div class="post-metadata">

**Author:** ![Brad\_Knowles](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/brad_knowles/32/716_2.png) [@Brad\_Knowles](https://discourse.chef.io/u/Brad_Knowles)\
**Post date:** [December 8, 2011, 11:34pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/4 "2011-12-08T23:34:02Z")

</div>

On Dec 8, 2011, at 5:09 PM, Chris wrote:

> I agree with you, there are other problems surrounding our memory constraints. Namely, I'm not allowed to take memory away from Java and Java is never allowed to go into swap. We routinely provision 8GB VMs and give Java 7 of that, and the Java dev teams won't budge on that.

Ouch. Yeah, politics is going to hurt.

> I'm really surprised that your client is so lean, but you're CentOS version is also newer then ours. We have systems ranging from 5.2-5.5, most have never been patched. I'm pretty sure we're missing out on some optimizations. I'm curious, are most of your cookbooks from Opscode or home grown?

We started with the Opscode cookbooks, but some of them have been modified pretty heavily, and we've created a few of our own. Some of the cookbooks have come from elsewhere on github, with some local modifications.

I'm hoping that I will be able to get up to speed enough on git in the near future that we can contribute pretty much all our work back to github, so that the community can upgrade the Opscode cookbooks as appropriate, or the few non-Opscode cookbooks that we have used. Most importantly, I think we may be the first non-Ubuntu site to make use of the edelight cookbook for MongoDB, and I'd really like to get our enhancements folded back in.

We've already signed all the CLA and CCLA forms, so now it's more a matter of me finding the time and inclination to "git" up to speed.

One other observation I'd like to make about VSS & RSS -- I think this might depend on your HyperVisor implementation, but I would be surprised if you didn't get "shared" pages with multiple different VMs on the system each with their own copy of chef-client that is running.

So, the real memory impact would not be the number of VMs times the VSS (as they claimed), but more like some cost-reduction factor times the number of VMs times the RSS for each of those chef-client instances. The more VMs you've got on a single machine, I think the more memory overall that you would save as a result of getting something akin to deduplication being performed by the HyperVisor in conjunction with whatever OS is running in Ring Zero. All they need to do is implement standard "copy-on-write" functionality for each of the affected pages.

--  
Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com)  
SAGE Level IV, Chef Level 0.0.1

---

<div class="post-metadata">

**Author:** ![Jesse\_Nelson](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jesse_nelson/32/262_2.png) [@Jesse\_Nelson](https://discourse.chef.io/u/Jesse_Nelson)\
**Post date:** [December 9, 2011, 5:59am UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/5 "2011-12-09T05:59:43Z")

</div>

Manage the ammouny of data being shoved into your node object. This is  
typically where the memory is being consumed. Disabling ohai plugins you  
don't use might help.

Also pay attention to how your cookbooks are using search. Search results  
can get very large depending on node size and nodes returned.  
On Dec 8, 2011 3:34 PM, "Brad Knowles" [bknowles@ihiji.com](mailto:bknowles@ihiji.com) wrote:

> On Dec 8, 2011, at 5:09 PM, Chris wrote:
> 
> > I agree with you, there are other problems surrounding our memory  
> > constraints. Namely, I'm not allowed to take memory away from Java and Java  
> > is never allowed to go into swap. We routinely provision 8GB VMs and give  
> > Java 7 of that, and the Java dev teams won't budge on that.
> 
> Ouch. Yeah, politics is going to hurt.
> 
> > I'm really surprised that your client is so lean, but you're CentOS  
> > version is also newer then ours. We have systems ranging from 5.2-5.5, most  
> > have never been patched. I'm pretty sure we're missing out on some  
> > optimizations. I'm curious, are most of your cookbooks from Opscode or home  
> > grown?
> 
> We started with the Opscode cookbooks, but some of them have been modified  
> pretty heavily, and we've created a few of our own. Some of the cookbooks  
> have come from elsewhere on github, with some local modifications.
> 
> I'm hoping that I will be able to get up to speed enough on git in the  
> near future that we can contribute pretty much all our work back to github,  
> so that the community can upgrade the Opscode cookbooks as appropriate, or  
> the few non-Opscode cookbooks that we have used. Most importantly, I think  
> we may be the first non-Ubuntu site to make use of the edelight cookbook  
> for MongoDB, and I'd really like to get our enhancements folded back in.
> 
> We've already signed all the CLA and CCLA forms, so now it's more a matter  
> of me finding the time and inclination to "git" up to speed.
> 
> One other observation I'd like to make about VSS & RSS -- I think this  
> might depend on your HyperVisor implementation, but I would be surprised if  
> you didn't get "shared" pages with multiple different VMs on the system  
> each with their own copy of chef-client that is running.
> 
> So, the real memory impact would not be the number of VMs times the VSS  
> (as they claimed), but more like some cost-reduction factor times the  
> number of VMs times the RSS for each of those chef-client instances. The  
> more VMs you've got on a single machine, I think the more memory overall  
> that you would save as a result of getting something akin to deduplication  
> being performed by the HyperVisor in conjunction with whatever OS is  
> running in Ring Zero. All they need to do is implement standard  
> "copy-on-write" functionality for each of the affected pages.
> 
> --  
> Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com)  
> SAGE Level IV, Chef Level 0.0.1

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [December 9, 2011, 7:37am UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/6 "2011-12-09T07:37:44Z")

</div>

Also, what version of ruby are you running?

Adam

* * *

Opscode, Inc.  
Adam Jacob, Chief Customer Officer  
T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

On Dec 8, 2011, at 4:09 PM, Chris wrote:

> Hi Brad,
> 
> I agree with you, there are other problems surrounding our memory constraints. Namely, I'm not allowed to take memory away from Java and Java is never allowed to go into swap. We routinely provision 8GB VMs and give Java 7 of that, and the Java dev teams won't budge on that.
> 
> I'm really surprised that your client is so lean, but you're CentOS version is also newer then ours. We have systems ranging from 5.2-5.5, most have never been patched. I'm pretty sure we're missing out on some optimizations. I'm curious, are most of your cookbooks from Opscode or home grown?
> 
> On Thu, Dec 8, 2011 at 3:00 PM, Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com) wrote:
> 
> On Dec 8, 2011, at 3: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.
> 
> We've been doing chef since August using 0.10.4 on CentOS 5.6. We currently have 43 cookbooks and 37 roles across all of our machines, but I use roles very heavily (I'll test a new cookbook as a new role on a new machine and then when I'm happy I might include that role as part of another larger role). We just spun up a "staging" environment today, which added twelve new nodes, taking us up to 33 total being managed by chef. On one of our most complex nodes, the run\_list has five main roles loaded, while the expanded run\_list is sixteen roles and comprises thirty recipes.
> 
> I checked, and when chef-client is active, we hit a VSS of about 195MB, but a Resident (working) Set Size of 60-70MB. Even a dry run includes multiple invocations of Python, Perl, and various other programs and languages, many of which have VSS & RSS that are almost as big as chef-client, even though they might only persist for a few seconds during the run.
> 
> In comparison, the RevealCloud agent that we run on every machine has a VSS of ~160MB, although the RSS is just over 2MB. This machine is brand-new and is virtually idle, but each httpd process has a VSS of ~150MB and an RSS of just under 5MB, and we spin up a total of seventeen of them.
> 
> This is on a Rackspace "flavor 3" VM which has allocated to it 1GB of RAM, 40GB of hard disk space (~35GB usable), etc.... There are only two VM images that Rackspace makes available that are smaller than this -- a "flavor 2" with 512MB of RAM, and a "flavor 1" with 256MB of RAM.
> 
> Compared to all the other things that this VM is doing, the overhead of chef-client seems pretty reasonable to me -- not really any more than another httpd process, or the overhead from the RevealCloud monitoring system. Not something that I would consider totally negligible, but also not that significant.
> 
> Speaking only for myself, I believe that if you've got systems where you really are this tightly constrained for memory, then I think you've got much bigger problems than whether or not you can afford to run chef-client.
> 
> --  
> Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com)  
> SAGE Level IV, Chef Level 0.0.1
> 
> --  
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent  
> permitted by applicable law.

---

<div class="post-metadata">

**Author:** ![Chris](https://avatars.discourse-cdn.com/v4/letter/c/958977/32.png) [@Chris](https://discourse.chef.io/u/Chris)\
**Post date:** [December 9, 2011, 3:46pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/7 "2011-12-09T15:46:08Z")

</div>

ruby 1.8.7 (2011-02-18 patchlevel 334) -- CentOS 5.5(mostly)

On Thu, Dec 8, 2011 at 11:37 PM, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:

> Also, what version of ruby are you running?
> 
> Adam
> 
> * * *
> 
> Opscode, Inc.  
> Adam Jacob, Chief Customer Officer  
> T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)
> 
> On Dec 8, 2011, at 4:09 PM, Chris wrote:
> 
> Hi Brad,
> 
> I agree with you, there are other problems surrounding our memory  
> constraints. Namely, I'm not allowed to take memory away from Java and Java  
> is never allowed to go into swap. We routinely provision 8GB VMs and give  
> Java 7 of that, and the Java dev teams won't budge on that.
> 
> I'm really surprised that your client is so lean, but you're CentOS  
> version is also newer then ours. We have systems ranging from 5.2-5.5, most  
> have never been patched. I'm pretty sure we're missing out on some  
> optimizations. I'm curious, are most of your cookbooks from Opscode or home  
> grown?
> 
> On Thu, Dec 8, 2011 at 3:00 PM, Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com) wrote:
> 
> > On Dec 8, 2011, at 3: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.
> > 
> > We've been doing chef since August using 0.10.4 on CentOS 5.6. We  
> > currently have 43 cookbooks and 37 roles across all of our machines, but I  
> > use roles very heavily (I'll test a new cookbook as a new role on a new  
> > machine and then when I'm happy I might include that role as part of  
> > another larger role). We just spun up a "staging" environment today, which  
> > added twelve new nodes, taking us up to 33 total being managed by chef. On  
> > one of our most complex nodes, the run\_list has five main roles loaded,  
> > while the expanded run\_list is sixteen roles and comprises thirty recipes.
> > 
> > I checked, and when chef-client is active, we hit a VSS of about 195MB,  
> > but a Resident (working) Set Size of 60-70MB. Even a dry run includes  
> > multiple invocations of Python, Perl, and various other programs and  
> > languages, many of which have VSS & RSS that are almost as big as  
> > chef-client, even though they might only persist for a few seconds during  
> > the run.
> > 
> > In comparison, the RevealCloud agent that we run on every machine has a  
> > VSS of ~160MB, although the RSS is just over 2MB. This machine is  
> > brand-new and is virtually idle, but each httpd process has a VSS of ~150MB  
> > and an RSS of just under 5MB, and we spin up a total of seventeen of them.
> > 
> > This is on a Rackspace "flavor 3" VM which has allocated to it 1GB of  
> > RAM, 40GB of hard disk space (~35GB usable), etc.... There are only two VM  
> > images that Rackspace makes available that are smaller than this -- a  
> > "flavor 2" with 512MB of RAM, and a "flavor 1" with 256MB of RAM.
> > 
> > Compared to all the other things that this VM is doing, the overhead of  
> > chef-client seems pretty reasonable to me -- not really any more than  
> > another httpd process, or the overhead from the RevealCloud monitoring  
> > system. Not something that I would consider totally negligible, but also  
> > not that significant.
> > 
> > Speaking only for myself, I believe that if you've got systems where you  
> > really are this tightly constrained for memory, then I think you've got  
> > much bigger problems than whether or not you can afford to run chef-client.
> > 
> > --  
> > Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com)  
> > SAGE Level IV, Chef Level 0.0.1
> 
> --  
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent  
> permitted by applicable law.

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

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [December 9, 2011, 4:34pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/8 "2011-12-09T16:34:57Z")

</div>

On Friday, December 9, 2011 at 7:46 AM, Chris wrote:

> ruby 1.8.7 (2011-02-18 patchlevel 334) -- CentOS 5.5(mostly)

Disabling unneeded ohai plugins will probably provide the biggest benefit:

[http://wiki.opscode.com/display/chef/Disabling+Ohai+Plugins](http://wiki.opscode.com/display/chef/Disabling+Ohai+Plugins)

You can also experiment with Ruby Enterprise Edition. The changes to memory allocation and GC tend to reduce heap fragmentation, which will in turn reduce RSS when chef-client is sleeping.

--  
Dan DeLeo

---

<div class="post-metadata">

**Author:** ![Chris](https://avatars.discourse-cdn.com/v4/letter/c/958977/32.png) [@Chris](https://discourse.chef.io/u/Chris)\
**Post date:** [December 9, 2011, 4:45pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/9 "2011-12-09T16:45:01Z")

</div>

I've been working on disabling plugins, but it doesn't seem to be working.  
I've added these to client.rb, but when running the client with debug  
output they still get loaded. Does order matter?

Ohai::Config[:disabled\_plugins] = ["passwd"]  
Ohai::Config[:disabled\_plugins] = ["rackspace"]  
Ohai::Config[:disabled\_plugins] = ["dmi"]  
Ohai::Config[:disabled\_plugins] = ["dmi\_common"]  
Ohai::Config[:disabled\_plugins] = ["erlang"]  
Ohai::Config[:disabled\_plugins] = ["groovy"]  
Ohai::Config[:disabled\_plugins] = ["php"]  
Ohai::Config[:disabled\_plugins] = ["eucalyptus"]  
Ohai::Config[:disabled\_plugins] = ["network\_listeners"]  
Ohai::Config[:disabled\_plugins] = ["mono"]

On Fri, Dec 9, 2011 at 8:34 AM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:

> On Friday, December 9, 2011 at 7:46 AM, Chris wrote:
> 
> > ruby 1.8.7 (2011-02-18 patchlevel 334) -- CentOS 5.5(mostly)
> 
> Disabling unneeded ohai plugins will probably provide the biggest benefit:
> 
> [http://wiki.opscode.com/display/chef/Disabling+Ohai+Plugins](http://wiki.opscode.com/display/chef/Disabling+Ohai+Plugins)
> 
> You can also experiment with Ruby Enterprise Edition. The changes to  
> memory allocation and GC tend to reduce heap fragmentation, which will in  
> turn reduce RSS when chef-client is sleeping.
> 
> --  
> Dan DeLeo

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

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [December 9, 2011, 4:46pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/10 "2011-12-09T16:46:11Z")

</div>

Ohai::Config[:disable\_plugins] = ["password", "rackspace", "dmi", "dmi\_common"]

Instead of N calls to Ohai::Config, which is over-writing the value.

Adam

* * *

Opscode, Inc.  
Adam Jacob, Chief Customer Officer  
T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

On Dec 9, 2011, at 9:45 AM, Chris wrote:

> I've been working on disabling plugins, but it doesn't seem to be working. I've added these to client.rb, but when running the client with debug output they still get loaded. Does order matter?
> 
> Ohai::Config[:disabled\_plugins] = ["passwd"]  
> Ohai::Config[:disabled\_plugins] = ["rackspace"]  
> Ohai::Config[:disabled\_plugins] = ["dmi"]  
> Ohai::Config[:disabled\_plugins] = ["dmi\_common"]  
> Ohai::Config[:disabled\_plugins] = ["erlang"]  
> Ohai::Config[:disabled\_plugins] = ["groovy"]  
> Ohai::Config[:disabled\_plugins] = ["php"]  
> Ohai::Config[:disabled\_plugins] = ["eucalyptus"]  
> Ohai::Config[:disabled\_plugins] = ["network\_listeners"]  
> Ohai::Config[:disabled\_plugins] = ["mono"]
> 
> On Fri, Dec 9, 2011 at 8:34 AM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:
> 
> On Friday, December 9, 2011 at 7:46 AM, Chris wrote:
> 
> > ruby 1.8.7 (2011-02-18 patchlevel 334) -- CentOS 5.5(mostly)
> 
> Disabling unneeded ohai plugins will probably provide the biggest benefit:
> 
> [http://wiki.opscode.com/display/chef/Disabling+Ohai+Plugins](http://wiki.opscode.com/display/chef/Disabling+Ohai+Plugins)
> 
> You can also experiment with Ruby Enterprise Edition. The changes to memory allocation and GC tend to reduce heap fragmentation, which will in turn reduce RSS when chef-client is sleeping.
> 
> --  
> Dan DeLeo
> 
> --  
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent  
> permitted by applicable law.

---

<div class="post-metadata">

**Author:** ![Chris](https://avatars.discourse-cdn.com/v4/letter/c/958977/32.png) [@Chris](https://discourse.chef.io/u/Chris)\
**Post date:** [December 9, 2011, 4:58pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/11 "2011-12-09T16:58:07Z")

</div>

Yep, that worked. Thanks.

Client is sitting at 138m RSS now, which is a lot better. Hopefully it will  
stop creeping up over time as well.

Thanks for all the help everyone.

On Fri, Dec 9, 2011 at 8:46 AM, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:

> Ohai::Config[:disable\_plugins] = [ "password", "rackspace", "dmi",  
> "dmi\_common" ]
> 
> Instead of N calls to Ohai::Config, which is over-writing the value.
> 
> Adam
> 
> * * *
> 
> Opscode, Inc.  
> Adam Jacob, Chief Customer Officer  
> T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)
> 
> On Dec 9, 2011, at 9:45 AM, Chris wrote:
> 
> I've been working on disabling plugins, but it doesn't seem to be working.  
> I've added these to client.rb, but when running the client with debug  
> output they still get loaded. Does order matter?
> 
> Ohai::Config[:disabled\_plugins] = ["passwd"]  
> Ohai::Config[:disabled\_plugins] = ["rackspace"]  
> Ohai::Config[:disabled\_plugins] = ["dmi"]  
> Ohai::Config[:disabled\_plugins] = ["dmi\_common"]  
> Ohai::Config[:disabled\_plugins] = ["erlang"]  
> Ohai::Config[:disabled\_plugins] = ["groovy"]  
> Ohai::Config[:disabled\_plugins] = ["php"]  
> Ohai::Config[:disabled\_plugins] = ["eucalyptus"]  
> Ohai::Config[:disabled\_plugins] = ["network\_listeners"]  
> Ohai::Config[:disabled\_plugins] = ["mono"]
> 
> On Fri, Dec 9, 2011 at 8:34 AM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:
> 
> > On Friday, December 9, 2011 at 7:46 AM, Chris wrote:
> > 
> > > ruby 1.8.7 (2011-02-18 patchlevel 334) -- CentOS 5.5(mostly)
> > 
> > Disabling unneeded ohai plugins will probably provide the biggest benefit:
> > 
> > [http://wiki.opscode.com/display/chef/Disabling+Ohai+Plugins](http://wiki.opscode.com/display/chef/Disabling+Ohai+Plugins)
> > 
> > You can also experiment with Ruby Enterprise Edition. The changes to  
> > memory allocation and GC tend to reduce heap fragmentation, which will in  
> > turn reduce RSS when chef-client is sleeping.
> > 
> > --  
> > Dan DeLeo
> 
> --  
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent  
> permitted by applicable law.

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

---

<div class="post-metadata">

**Author:** ![Brian\_Akins](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/brian_akins/32/298_2.png) [@Brian\_Akins](https://discourse.chef.io/u/Brian_Akins)\
**Post date:** [December 13, 2011, 12:34am UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/12 "2011-12-13T00:34:33Z")

</div>

On Dec 9, 2011, at 11:58 AM, Chris wrote:

> Yep, that worked. Thanks.
> 
> Client is sitting at 138m RSS now, which is a lot better. Hopefully it will stop creeping up over time as well.

Lately, we've been running monit (for various services) and we have it restart chef-client when memory is above x MB for n minutes.

--Brian

---

<div class="post-metadata">

**Author:** ![Chris](https://avatars.discourse-cdn.com/v4/letter/c/958977/32.png) [@Chris](https://discourse.chef.io/u/Chris)\
**Post date:** [December 13, 2011, 1:32am UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/13 "2011-12-13T01:32:45Z")

</div>

That's not a bad idea either, we already have monit running on each client node to restart the client when it crashes

Sent from a phone

On Dec 12, 2011, at 4:34 PM, Brian Akins [brian@akins.org](mailto:brian@akins.org) wrote:

> On Dec 9, 2011, at 11:58 AM, Chris wrote:
> 
> > Yep, that worked. Thanks.
> > 
> > Client is sitting at 138m RSS now, which is a lot better. Hopefully it will stop creeping up over time as well.
> 
> Lately, we've been running monit (for various services) and we have it restart chef-client when memory is above x MB for n minutes.
> 
> --Brian

---

<div class="post-metadata">

**Author:** ![Sean\_OMeara](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sean_omeara/32/435_2.png) [@Sean\_OMeara](https://discourse.chef.io/u/Sean_OMeara)\
**Post date:** [December 20, 2011, 4:56pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/14 "2011-12-20T16:56:55Z")

</div>

I haven't actually had a chance to play with these myself, but if  
you're on a modern linux distro, you may be able to use cgroups to  
isolate memory usage on a per process basis. (ie, keep your Java  
processes safe)

> **[cgroups](https://en.wikipedia.org/wiki/Cgroups)**
>
> cgroups (abbreviated from control groups) is a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, etc.) of a collection of processes.
> Engineers at Google started the work on this feature in 2006 under the name "process containers". In late 2007, the nomenclature changed to "control groups" to avoid confusion caused by multiple meanings of the term "container" in the Linux kernel context, and the control groups functionality was merged into t...

> **[Control-groups in rhel6 - All things sysadmin](http://northernmost.org/blog/control-groups-in-rhel6/)**
>
> One new feature that I’m very enthusiastic about in RHEL6 is Control Groups
> (cgroup for short). It allows you to create groups and allocate resources …

-s

On Mon, Dec 12, 2011 at 8:32 PM, Chris [grocerylist@gmail.com](mailto:grocerylist@gmail.com) wrote:

> That's not a bad idea either, we already have monit running on each client node to restart the client when it crashes
> 
> Sent from a phone
> 
> On Dec 12, 2011, at 4:34 PM, Brian Akins [brian@akins.org](mailto:brian@akins.org) wrote:
> 
> > On Dec 9, 2011, at 11:58 AM, Chris wrote:
> > 
> > > Yep, that worked. Thanks.
> > > 
> > > Client is sitting at 138m RSS now, which is a lot better. Hopefully it will stop creeping up over time as well.
> > 
> > Lately, we've been running monit (for various services) and we have it restart chef-client when memory is above x MB for n minutes.
> > 
> > --Brian

---

<div class="post-metadata">

**Author:** ![Chris](https://avatars.discourse-cdn.com/v4/letter/c/958977/32.png) [@Chris](https://discourse.chef.io/u/Chris)\
**Post date:** [December 20, 2011, 7:29pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/15 "2011-12-20T19:29:07Z")

</div>

Yeah, I wouldn't call centos 5.5 modern, I'll have to look and see if we can even support cgroups

Sent from a phone

On Dec 20, 2011, at 8:56 AM, Sean OMeara [someara@gmail.com](mailto:someara@gmail.com) wrote:

> I haven't actually had a chance to play with these myself, but if  
> you're on a modern linux distro, you may be able to use cgroups to  
> isolate memory usage on a per process basis. (ie, keep your Java  
> processes safe)
> 
> [cgroups - Wikipedia](http://en.wikipedia.org/wiki/Cgroups)  
> [Control-groups in rhel6 - All things sysadmin](http://northernmost.org/blog/control-groups-in-rhel6/)
> 
> -s
> 
> On Mon, Dec 12, 2011 at 8:32 PM, Chris [grocerylist@gmail.com](mailto:grocerylist@gmail.com) wrote:
> 
> > That's not a bad idea either, we already have monit running on each client node to restart the client when it crashes
> > 
> > Sent from a phone
> > 
> > On Dec 12, 2011, at 4:34 PM, Brian Akins [brian@akins.org](mailto:brian@akins.org) wrote:
> > 
> > > On Dec 9, 2011, at 11:58 AM, Chris wrote:
> > > 
> > > > Yep, that worked. Thanks.
> > > > 
> > > > Client is sitting at 138m RSS now, which is a lot better. Hopefully it will stop creeping up over time as well.
> > > 
> > > Lately, we've been running monit (for various services) and we have it restart chef-client when memory is above x MB for n minutes.
> > > 
> > > --Brian

---

<div class="post-metadata">

**Author:** ![Bryan\_Berry](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bryan_berry/32/213_2.png) [@Bryan\_Berry](https://discourse.chef.io/u/Bryan_Berry)\
**Post date:** [December 21, 2011, 12:34pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/16 "2011-12-21T12:34:24Z")

</div>

sadly, cgroups are only available on centos 6

I run chef-client under a cron job rather than under a daemon, that  
will reduce memory usage over time but not protect you from spikes.

I don't know if ruby's vm take gc tuning options like java but that could help

On Tue, Dec 20, 2011 at 8:29 PM, Chris [grocerylist@gmail.com](mailto:grocerylist@gmail.com) wrote:

> Yeah, I wouldn't call centos 5.5 modern, I'll have to look and see if we can even support cgroups
> 
> Sent from a phone
> 
> On Dec 20, 2011, at 8:56 AM, Sean OMeara [someara@gmail.com](mailto:someara@gmail.com) wrote:
> 
> > I haven't actually had a chance to play with these myself, but if  
> > you're on a modern linux distro, you may be able to use cgroups to  
> > isolate memory usage on a per process basis. (ie, keep your Java  
> > processes safe)
> > 
> > [cgroups - Wikipedia](http://en.wikipedia.org/wiki/Cgroups)  
> > [Control-groups in rhel6 - All things sysadmin](http://northernmost.org/blog/control-groups-in-rhel6/)
> > 
> > -s
> > 
> > On Mon, Dec 12, 2011 at 8:32 PM, Chris [grocerylist@gmail.com](mailto:grocerylist@gmail.com) wrote:
> > 
> > > That's not a bad idea either, we already have monit running on each client node to restart the client when it crashes
> > > 
> > > Sent from a phone
> > > 
> > > On Dec 12, 2011, at 4:34 PM, Brian Akins [brian@akins.org](mailto:brian@akins.org) wrote:
> > > 
> > > > On Dec 9, 2011, at 11:58 AM, Chris wrote:
> > > > 
> > > > > Yep, that worked. Thanks.
> > > > > 
> > > > > Client is sitting at 138m RSS now, which is a lot better. Hopefully it will stop creeping up over time as well.
> > > > 
> > > > Lately, we've been running monit (for various services) and we have it restart chef-client when memory is above x MB for n minutes.
> > > > 
> > > > --Brian

---

<div class="post-metadata">

**Author:** ![Brian\_Akins](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/brian_akins/32/298_2.png) [@Brian\_Akins](https://discourse.chef.io/u/Brian_Akins)\
**Post date:** [December 21, 2011, 2:50pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/17 "2011-12-21T14:50:12Z")

</div>

On Dec 21, 2011, at 7:34 AM, Bryan Berry wrote:

> sadly, cgroups are only available on centos 6

Wouldn't cgroups just limit the amount of memory chef could use? It wouldn't really "solve" the problem.

Just run chef-client from cron and come up with a simple way to trigger it. Simple thing in (x)inetd should be good enough.

FWIW, a few weeks into using monit with chef-cient - so far so good.

---

<div class="post-metadata">

**Author:** ![Chris](https://avatars.discourse-cdn.com/v4/letter/c/958977/32.png) [@Chris](https://discourse.chef.io/u/Chris)\
**Post date:** [December 21, 2011, 3:32pm UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/18 "2011-12-21T15:32:47Z")

</div>

That would actually help, since the client memory can balloon to 400m on some systems  
I suggested running from cron with a random interval, but the spike issue came up. I think we're just going to have to buy more memory

Sent from a phone

On Dec 21, 2011, at 6:50 AM, Brian Akins [brian@akins.org](mailto:brian@akins.org) wrote:

> On Dec 21, 2011, at 7:34 AM, Bryan Berry wrote:
> 
> > sadly, cgroups are only available on centos 6
> 
> Wouldn't cgroups just limit the amount of memory chef could use? It wouldn't really "solve" the problem.
> 
> Just run chef-client from cron and come up with a simple way to trigger it. Simple thing in (x)inetd should be good enough.
> 
> FWIW, a few weeks into using monit with chef-cient - so far so good.

---

<div class="post-metadata">

**Author:** ![Alex\_Howells](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/alex_howells/32/664_2.png) [@Alex\_Howells](https://discourse.chef.io/u/Alex_Howells)\
**Post date:** [December 23, 2011, 12:43am UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/19 "2011-12-23T00:43:34Z")

</div>

On 21 December 2011 15:32, Chris [grocerylist@gmail.com](mailto:grocerylist@gmail.com) wrote:

> That would actually help, since the client memory can balloon to 400m on some systems  
> I suggested running from cron with a random interval, but the spike issue came up. I think we're just going to have to buy more memory

Buying a little more memory is probably a very quick ROI versus _not_  
having automation.

---

<div class="post-metadata">

**Author:** ![Chris](https://avatars.discourse-cdn.com/v4/letter/c/958977/32.png) [@Chris](https://discourse.chef.io/u/Chris)\
**Post date:** [December 23, 2011, 12:52am UTC](https://discourse.chef.io/t/chef-client-memory-usage/2319/20 "2011-12-23T00:52:09Z")

</div>

I agree, but my ops team does not

Sent from a phone

On Dec 22, 2011, at 4:43 PM, Alex Howells [lists@howells.me](mailto:lists@howells.me) wrote:

> On 21 December 2011 15:32, Chris [grocerylist@gmail.com](mailto:grocerylist@gmail.com) wrote:
> 
> > That would actually help, since the client memory can balloon to 400m on some systems  
> > I suggested running from cron with a random interval, but the spike issue came up. I think we're just going to have to buy more memory
> 
> Buying a little more memory is probably a very quick ROI versus _not_  
> having automation.

[Next page](https://discourse.chef.io/t/chef-client-memory-usage/2319.md?page=2)