Munki Server Specifications

316 views
Skip to first unread message

Robert B Sandkam

unread,
Dec 9, 2016, 4:47:54 PM12/9/16
to munki-discuss
We have approximately 900 computers being managed by munki.

Most of the time, munki is great and just does its thing.
But, when we post large packages to the munki repo, the download speed from the server to each client becomes very slow.
And because it is slow, the clients remain connected to the server for a long time.
So, after an hour or so, a large percentage of the clients are simultaneously connected to the server and downloading.

An example of this scenario would be when we post MS Office updates.
Or, today I posted a GarageBand update.
Both of the are in the vicinity of 1 GB.

So, I am interested in hearing from anyone with a similar number of clients about what your server configuration is.

Real hardware or virtual machine?
Apache or Windows IIS (or something else)?
How much memory?
etc...

Thanks for any feedback.

b0b
--
VCUarts Technology Support

Rick Heil

unread,
Dec 9, 2016, 5:08:49 PM12/9/16
to munki-...@googlegroups.com

Bob,

 

The best advice I can give is to measure performance during an update push and look at what your bottleneck is. This will let you know your focus area more accurately. In our case, it was disk, and a solid state drive was the solution. We still occasionally run into CPU issues (it’s a 2008 Mac Mini / 8GB of RAM with about 100 clients), but only on the heaviest days, and that’s mostly acceptable to us so far.

 

-R

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To post to this group, send email to munki-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/2cdfc4df-f512-4ebb-b0ac-1854aadb48f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mike Solin

unread,
Dec 9, 2016, 8:18:32 PM12/9/16
to munki-...@googlegroups.com
According to MunkiReport, we currently have 721 active clients (out of 805 total, but there might be some stale data in there).  We had the same problem for a while - at 2-3 GB each, and released monthly, those Office 2016 updates would cause the server to crawl for about 24 hours after we’d test and release them to campus.  I mostly blame the ~250 lab Macs, all hitting the server at once.

We settled on these specs: Windows Server 2012 R2 (VM), Quad-core 2.69 GHz processor, and 16 GB of RAM.  Since then, we haven’t seen any speed issues at all.  It might be overkill, but hopefully it helps point you in the right direction.


To unsubscribe from this group and stop receiving emails from it, send an email to munki-discuss+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discuss+unsubscribe@googlegroups.com.

To post to this group, send email to munki-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/5E787132-EAC5-410B-88E1-A096B611ABCD%40partnersandsimons.com.

Mike Solin

unread,
Dec 9, 2016, 8:21:29 PM12/9/16
to munki-...@googlegroups.com
Also, Alan Siu wrote this Munki conditional script I was thinking about using:


Ultimately, the specs bump for the VM fixed the problem, but it’s nice to know other people have solved the same problem in different ways. :)


On Fri, Dec 9, 2016 at 8:18 PM, Mike Solin <mi...@mikesolin.com> wrote:
According to MunkiReport, we currently have 721 active clients (out of 805 total, but there might be some stale data in there).  We had the same problem for a while - at 2-3 GB each, and released monthly, those Office 2016 updates would cause the server to crawl for about 24 hours after we’d test and release them to campus.  I mostly blame the ~250 lab Macs, all hitting the server at once.

We settled on these specs: Windows Server 2012 R2 (VM), Quad-core 2.69 GHz processor, and 16 GB of RAM.  Since then, we haven’t seen any speed issues at all.  It might be overkill, but hopefully it helps point you in the right direction.

David Nelson

unread,
Dec 9, 2016, 10:26:32 PM12/9/16
to munki-...@googlegroups.com
My Munki server has almost 10,000 clients with ~1-1.5k active per hour. 

It's virtualized CentOS 7 with 32GB RAM, 2xCPU, Nginx for the repo, and Apache for MunkiReport. 

It performs just fine BUT we aren't auto-installing anything large. Mostly browsers, Flash, etc. 

Before switching the repo to Nginx it had occasional lag but not anymore. 

Not sure if that would help or not, given that you have way larger updates but way less clients… 
--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.

lists.mac

unread,
Dec 11, 2016, 12:03:07 PM12/11/16
to munki-...@googlegroups.com
Packages don’t have to live in the munki repo or even be on the same sever as the repo. You can setup another location to host the packages and use the PackageCompleteURL or PackageURL pkginfo keys to point to the alternate location. See the wiki for the notes on these two keys: https://github.com/munki/munki/wiki/Supported-Pkginfo-Keys and search munki-dev for further discussion on their use: https://groups.google.com/forum/#!forum/munki-dev 


Marnin



Predrag

unread,
Dec 12, 2016, 10:31:43 AM12/12/16
to munki-discuss
b0b, can't help with the specs, but...

take a look at sharding -

<key>deploy_percent</key>
<integer>20</integer>

This would initially only deploy the given package to 20% of your fleet.  From there, increase the value to incrementally ramp up your deployment and watch the results.


bryan...@gmail.com

unread,
Dec 12, 2016, 11:45:05 AM12/12/16
to munki-discuss
We have 19,000 macs managed by Munki in ~75 locations (schools)

Each school has it's own "server" and I use that term loosely.  No server has more than about 1,000 clients. (Well I think one has 1400, then the next highest is around 900. Most are closer to 500 max)

In some cases the server is an old Xserve still running 10.5.8. In some cases it's an old 2006 white iMac running 10.6.8.  In some cases it's a shiny brand new Mac mini running 10.11.6 and Server 5.x. Some of the old iMacs are stuck with 2 GB of RAM, most everything else has at least 4 GB. A few Mac minis have 8 GB.

Since all that is needed is a web server, we're not picky about what hardware we use - it's whatever we have available at a school.

Everything is 1000 Gbps networking, no 100 Mbps anywhere. We have fiber between schools.

We have one master Munki repo and each school's server syncs via a morning sync script that just uses rsync.

Been running fine for almost three years now.

Is it ideal? no. Optimal? Heck no. Does it work? Yup.

Bryan

Mike Solin

unread,
Dec 12, 2016, 12:13:09 PM12/12/16
to munki-...@googlegroups.com
Sharding hasn’t been merged into Munki yet:



--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discuss+unsubscribe@googlegroups.com.

To post to this group, send email to munki-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/de040397-beee-49ec-b48d-d55ebd3acf55%40googlegroups.com.

Gregory Neagle

unread,
Dec 12, 2016, 12:36:26 PM12/12/16
to munki-...@googlegroups.com
Pretty sure the consensus was to _not_ merge this since there were a lot of opinions on how exactly it should work, and it is possible to implement sharding today with no Munki code changes using admin-provided conditions.

-Greg

To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.

To post to this group, send email to munki-...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages