Nodes with Different CPU's - Adjusting the load

Mark_F

I have a 4 node configuration and have a range of CPU specs for the nodes. I believe that Vertica is treating each node the same and distributing the load not based on performance. - 2 Nodes have the same CPU Specs and are the strongest in the bunch. They hardly ever work at full capacity and usually finish much faster than the other nodes and just wait until the other nodes are finished. - The other 2 Nodes have similar CPU specs, but are not identical. - I get almost the same results running the same script on all 4 Nodes as I do when I run it on 2 (using the first 2 strongest nodes) - Is there a way to optimize the setup where the load will be configured and dispersed based on Hardware Performance?

[Deleted User]

Hi Mark, you're correct -- Vertica nodes within a cluster are expected to all be the same. Our official recommendation is that all nodes in the cluster be the same; performance of the whole cluster will, as you've observed, tend to be gated by the slowest node. The amount of work that is performed by any given node is approximately governed by how much data is stored on that node. (With the exception that, for some operations, the initiator node will perform extra work regardless of how much data it has locally.) In theory, you could adjust this by playing with the segmentation expressions on your projections. That's not something I've personally tried to do, though. When sorting this out, note that CPU is not necessarily the limiting specification. Disk I/O bandwith and available RAM are both also very important. Figuring out which matters most can be a tricky business; it depends heavily on your query workload. If your faster nodes are twice as fast as your slower nodes, you might consider splitting the faster nodes in half by running two virtual machines on them, each with a Vertica installation. Note that this has impact to Vertica's high-availability: If one of the physical machines goes down, that takes out two nodes in your cluster, which may take down the whole cluster at the default K=1. All that said, I would encourage you to consider getting a third machine that is comparable to your first two nodes. I don't know the details of your situation; that might not make sense for you. But it's certainly the simplest solution. And I suspect that the three-node cluster of faster machines might well meet your needs more effectively than the four-node mixed cluster that you have now. And that would leave you with two spare machines, for a development cluster or whatever other purpose you might have for them.