> Here are several general tips: Thanks!!
We're using all of 24.8rc1. > * use InnoDB for better concurrency, and data persistance > * use a recent mysql version (ie 5.0 or 5.1) > * properly size your innodb_buffer_pool to the rough size of your > on-disk database to not be I/O bound We need to fix this one. But that won't stop all of the UPDATEs :) > * use a dedicated server for mysql (and not a VM or the same host as > your master). Use decent hardware. > * put your databases files on a RAID10 (or RAID1) with Battery Backed > Cache (that's actually really important to absorb the fsyncs without > being detrimental to the performance) > * use as more spindles as you can for better concurrency Our database is currently on an internal hardware RAID1 controller with two disks. We've talked about moving the database to our SAN but the disks aren't *that* slow. Our stats say that when storeconfigs is on there's very little iowait--just lots of CPU. > > FWIW, we turned on query logging > > and there are 17k lines in the log associated with a single host. > > Which is not normal. With the perf path I contributed, you should see at > most for one host, if nothing has changed: > * 1 SELECT request for the querying the host > * n SELECT request for exported resources (n == the number of exported > resources) > * a few request to get the facts > * 1 SELECT request to retrieve parameters > * 1 SELECT request to retrieve tags > * a few update > > If you made changes to the manifests, then that's normal to see more > insert requests. > > > About half are SELECTs and the other half UPDATEs. We have about 400 > > hosts and, according to our stats based on puppet reports, we have > > about 1.5 million resources total. > > You can > select count(*) from resources group by host_id > > to get the number of resources per host. Cool. Most of the 17 hosts that made it into the DB before we turned storeconfigs back off have about 750 resources. One has 5800 :) > On which tables do you see the UPDATES? It's only the resources table. Perhaps our entire problem is getting over the initial hump. That is, we're starting from scratch so every host needs to UPDATE all of its info. > I'd be interested in helping diagnose the issue (and/or provide any > possible fix), feel free to contact me privately or on #puppet (I'm > masterzen) if you want to discuss this. Thanks very much! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
