Workload management and RAM
Closing out my recent round of Teradata-related posts, here’s a little anomaly:
- Teradata is proud that Teradata 14’s workload management now explicitly manages I/O, to go with Teradata’s long-standing management of CPU. Teradata’s WLM still does not explicitly manage RAM.
- Aster is proud that Aster 5’s workload management now explicitly manages RAM, to go along with the WLM capabilities Aster has had for a while managing CPU and I/O. Aster’s Tasso Argyros believes this is an important capability, at least in some edge cases.
- Mike Pilcher of SAND emailed me that SAND’s WLM capabilities to explicitly manage CPU, I/O, and RAM are very well-received by the marketplace.
One would think that Teradata’s workload management is more sophisticated and powerful than Aster Data’s.* So I asked Scott Gnau what gives (he was pretty much the ideal guy to comment, since he runs development for Teradata and oversees Teradata’s Aster acquisition as well).
*Except, of course, that Aster was a pioneer in having workload management cover all kinds of analytic processes, rather than just traditional database requests.
Scott’s main response was that Aster’s system was much more consumptive of RAM than Teradata’s; indeed, he reminded me that in the very old days, Teradata could make do with as little as 4 megabytes. Scott also did not argue when I suggested that Aster’s not-just-database analytic processes might require large amounts of RAM as well.
Comments
4 Responses to “Workload management and RAM”
Leave a Reply
Curt,
In the Teradata Database, by managing cpu, we effectively manage memory also because our DB threads each manage ram themselves.
Scott
“…in the very old days, Teradata could make do with as little as 4 megabytes.”
Tiny nit… Actually, Release 1.0 shipped with 2MB. Of course this was 1984 and those 2MB completely filled the memory board which was larger than an ATX motherboard. I think the main barrier to going up to 4MB at that time was strictly real estate on the board.
Until the relatively recent adoption (~5 years ago) of 64bit SLES, Teradata systems chugged along quite happily on NCR’s 32bit MP-RAS, typically with 2GB or 4GB of RAM per node.
Workload management via the CPU always felt like a bit of a blunt instrument when it came to managing IO resource. Far better than nothing though.
Direct control of IO resource is very welcome.
Scott,
Is each query being workload-managed on its own thread, or is it more like one thread per AMP?
If it’s the former I don’t immediately see how that would make them well-behaved in terms of memory consumption. Actually, if it’s the latter I don’t immediately see either. 😉