There’s no relationship between the two. Conueries are just our silly metric for roughly assessing MySQL usage; the “CPU minutes” comes from process accounting on your web machine iteself, and reflects your resource consumption (in terms of CPU) on your web machine itself.
You have to use up a lot of system resources before we’ll flag you.
We don’t do this just because we like to charge people more money or screw them over, but because in a shared hosting environment, we need to ensure that one user isn’t adversely affecting a machine’s stability and ruining things for all of the other users. Generally, static sites don’t cause big problems.
I know some people are probably going to get upset and / or worried about this, so please remember that this is /never/ going to affect 99.9% of you.
Basically, if we notice that a user is using up too many resources, we move their site to one of two special holding machines. These have much fewer users than the regular hosting machines, and hold up better under the load. At that point, we can make some tools available to them to gauge their usage, and we give them a time period (currently a couple of weeks) in which to make adjustments and reduce their resource consumption, switch to a dedicated machine with us, or move their site elsewhere. If it’s a mistake (i.e., badly written or inefficient code), or if the user removes the software that’s causing the problem or otherwise manages to reduce their usage – no problem.
I’d say by far the biggest problem I see are sites which are entirely or mostly dynamically generated. Much of the time this isn’t necessary, or it would be possible to cache / rebuild the site dynamically on a periodic basis. Dynamic content doesn’t scale as well. Obviously there are cases where it’s necessary or desirable - however if it’s a busy site, shared hosting is probably not the place for it.
A site we host got slashdotted over the weekend (linked to from the main page of Yahoo! news and Google News - and subsequently Slashdot)… with a wordpress installation as its main page. This caused such instability that the server was grinding to a halt as soon as the Apache instance started. Switching to a dynamic page fixed the problem almost immediately - the server load was completely normal even though the site was taking a pretty good pounding.