Greg,
> I'm not fooled--secretly you and your co-workers laugh at how easy this
> is on Solaris and are perfectly happy with how difficult it is on Linux,
> right?
Don't I wish. There's issues with getting CPU info on Solaris, too, if you
get off of Sun Hardware to generic white boxes. The base issue is that
there's no standardization on how manufacturers report the names of their
CPUs, 32/64bit, or clock speeds. So any attempt to determine "how fast"
a CPU is, even on a 1-5 scale, requires matching against a database of
regexes which would have to be kept updated.
And let's not even get started on Windows.
> I joke becuase I've been re-solving some variant on this problem every
> few years for a decade now and it just won't go away. Last time I
> checked the right answer was to find someone else who's already done it,
> packaged that into a library, and appears committed to keeping it up to
> date; just pull a new rev of that when you need it. For example, for
> the CPU/memory part, top solves this problem and is always kept current,
> so on open-source platforms there's the potential to re-use that code.
> Now that I know that's one thing you're (understandably) fighting with
> I'll dig up my references on that (again).
Actually, total memory is not an issue, that's fairly straight forwards.
Nor is # of CPUs. Memory *used* is a PITA, which is why I'd ignore that
part and make some assumptions. It would have to be implemented in a
per-OS manner, which is what bogged me down.
> I would advocate focusing on iterative improvements to an existing
> configuration rather than even bothering with generating a one-off
> config for exactly this reason. It *is* hard/impossible to get it right
> in a single shot, because of how many parameters interact and the way
> bottlenecks clear, so why not assume from the start you're going to do
> it several times--then you've only got one piece of software to write.
Sounds fine to me.
> To argue against myself for a second, it may very well be the case that
> writing the simpler tool is the only way to get a useful prototype for
> building the more complicated one; very easy to get bogged down in
> feature creep on a grand design otherwise.
It's certainly easy for me. ;-)
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco