Puppet is stuck on mongodb machines

I haven't written any technical content for a long time. I want to write an article today (my colleagues found that I am only a porter): I ran puppet and giant cards on some machines running mongodb, it takes tens of minutes to run, and the top seems to be the cpu resources occupied by the system instead of the user. solution: Run mong for a well-known reason.

I haven't written any technical content for a long time. I want to write an article today (my colleagues found that I am only a porter): I ran puppet and giant cards on some machines running mongodb, it takes tens of minutes to run, and the top seems to be the cpu resources occupied by the system instead of the user. solution: Run mong for a well-known reason.

I haven't written any technical content for a long time. It's time to grow... Just write an article about today (found by a colleague... I am just a porter)

Symptom: The puppet and giant card run on some mongodb-running machines takes dozens of minutes, and the top seems to be the cpu resources occupied by the system instead of the user.

Solution:

As we all know, when running mongodb, you must disable NUMA to start it. After reading the following page, you can see that you still need to disable it? Zone_reclaim_mode. This value is always disabled by default, so it has never been intended.

Http://docs.mongodb.org/manual/administration/production-notes/#production-numa

For some reason, we enabled/proc/sys/vm/zone_reclaim_mode last week, resulting in problems.

Http://www.kernel.org/doc/Documentation/sysctl/vm.txt, has reminded everyone, it is best to close.

Http://www.poempelfox.de/blog/2010/03/, explained the most complete .? I explained a variety of symptoms, and we all hit... For example, a common system call takes a long time.

Alas, close? Zone_reclaim_mode is enough.

Original article address: puppet is stuck on the mongodb machine. Thank you for sharing it with me.