BigFix Red hat OS patching slow compare to Satellite/Repository method

I was comparing the Linux OS patching BigFix and Red Hat Satellite server.

for me Big Fix takes approximately 1 minute to install one red hat errata Fixlet at the same Errata can be installed from the red hat satellite server in microseconds.

I understand BigFix has a strict relevance check and verification but the huge difference in timing in large number of servers group patching I am bit worried it may take long time to finish

Appreciate any thoughts on BigFix vs Red Hat satellite server OS pathing time duration

Yep, your observations look correct.

BigFix does a lot to make sure it runs slower. It throttles the CPU usage on its process. It runs on a single thread. It throttles its bandwidth on network connections. It caches downloads on the relays to keep the network usage lower.

In short, the goals of a Bigfix deployment are much different from many other products. Bigfix is built to run at a scale other products simply can’t touch. It’s not unusual to hear a Bigfix deployment is running a quarter million endpoints. And that RPM still takes about one minute to install…on all of them.

2 Likes

The best way to handle RPM patching is to check the ‘Multi-package installation’ tasks in the RHEL or CentOS.patching sites.
A lot of the overhead in RHEL/CentOS patching is in getting RPM repository metadata down to tge client and parsing it. With the multi-pkg method, your client downloads that metadata once, at the start of the baseline, and reuses the same metadata for each rpm package. The last component of the baseline should be ‘execute multi-package install’, that task will then download & install all of the needed packages in a single batch operation.

In my experience, a monthly RHEL or CentOS baseline should take anywhere from 5 to 15 minutes to run.

1 Like

Many thanks for the response . Let me try the multi-pkg method and see the difference with a bunch of fixlet . I will keep post you .thanks again for your time.

So if we schedule a base line for multiple servers are they going to apply one server after another or it will be start applying all servers same time in a parallel way trying to understand.

They would apply in parallel across each target machine.

Thank you.
IBM recommends 75-150 Fixlets in a base line for a better deployment turnaround I was wondering how many servers we can accommodate in a single shot schedule could you have any experience with more number of servers .

There are a lot of factors there, such as whether they’re physical or virtual, shared network pipes, etc.

Generally we break systems up into several groups for testing & staging rollouts (test, preprod, production).

With a huge number of systems we usually use the “stagger start times over X minutes” option to reduce their contention with each other.

Given something like a 4-hour maintenance window, with 10 minute action stagger times, and caching downloads ahead of time, I’ve know customers to do tens of thousands of systems at a time.
I’m sure Bigfix could do more, but there’s always the question of how many systems you can roll back if the patch ends up crashing the machines.

2 Likes

Have you ever deployed a baseline which consist more than 75 baseline ? and were all the patches deployed successfully.

re-opening this discussion with a point that , if I am using patch policy is it possible to add multipackage base installation tasks ?