September 25, 2011

Workload management and RAM

Closing out my recent round of Teradata-related posts, here’s a little anomaly:

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”

  1. Scott Gnau on September 26th, 2011 12:12 pm

    Curt,
    In the Teradata Database, by managing cpu, we effectively manage memory also because our DB threads each manage ram themselves.
    Scott

  2. TDAT Dev on September 26th, 2011 1:28 pm

    “…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.

  3. Paul Johnson on September 26th, 2011 2:33 pm

    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.

  4. Curt Monash on September 26th, 2011 3:22 pm

    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. ;)

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.