jedberg's questions

I’m creating some dynamodb tables via CloudFormation, which will be accessed by Python lambdas. It looks like I have two choices in naming the tables — let CF do it, and therefore put a whole bunch of random characters on the name, or specify the name explictly, which gives me an easy to access name but means I can’t make changes via CF without replacing the table.

I think the downside to not having a simple name is that I either have to have a config file that is different for every account that I run the CF in (because they will have different random names) or I have to write code to detect the name on each invocation of the lambda.

So what do y’all do? Explicit names and then deal with replacement for changes, or let CF do it and deal with DB name discovery in the code? Or something else I’m not thinking of?

I'm currently running a reindex table command on one of my Postgres 8.3 databases. Unfortunately the command doesn't really tell you anything until it is done.

Is there any way to check the progress of this command? Maybe a system table I could read some useful stats out of?

Thanks!

I have a couple of postgres 8.3 databases, and they are showing symptoms of lack of vacuuming.

I've checked the config, and they are in the default state of having the autovacummer turned on. Also, I see in my postgres logs "autovacuum launcher started" when I start the database.

The problem is, I never actually see a vacuum running. I also never see anything in the logs about a vacuum taking place (should I be seeing anything?)

So how do I tell if the vacuumer is working? Is there a way to see when the last vacuum completed, for example? Better yet, is there some documentation someone can point me to with the answer to that question?

Thanks!

I'm running Ganglia 3.1.2 on a network where there is no multicast (nor can I turn it on). Does anyone have an elegant solution for getting ganglia to work correctly? I found this:

http://code.google.com/p/ganglia-multicast-hack/

but it does not scale very well.

Right now, I have separate data_source lines for each host on my network in my gmetad.conf file, but that too does not scale well, and I can't get accurate summary statistics, because it keeps overwriting the rrds (although the host statistics work just fine).

Any pointers would be greatly appreciated (or confirmation that I have found the best solution already).

Thanks!