Fitting Into RAM

  • ZZartin - Friday, September 21, 2018 10:44 AM

    jarick 15608 - Friday, September 21, 2018 10:00 AM

    This is probably one of the better topics this year as it's a battle we all fight.  On one hand we have our developers and consultants demanding lots of resources but these come at a cost far greater than going to best buy and purchasing a $80 1TB hard disk.  They also use a lot of entity framework based development where they don't even see the database structure or code being sent to the database system.  Most modern database systems can crunch a lot of data on 4 cores and 16GB of RAM, it's all how you code the TSQL.  The other side of the argument is from the systems administrators who see the real costs of the infrastructure.  

    IMHO the best thing to come out of the cloud is the costs are directly retailed to resource use.  It's very viable when a server has bad code as the expense can go up dramatically.

    Yes hardware might be a little more expensive than normal consumer hardware but even enterprise level hd's and RAM are relatively cheap and it baffles me to no end that companies which won't bat an eye at 6 or 7 figure software licensing costs get stingy about a few grand more for adequate hardware.

    I have always seen that as the case.  This project is too expensive... how do we trim the costs... cut the hardware back....

  • On-prem virtualization and cloud hosting makes it easy to spin up new instances, but on the downside it can also lead to a sprawling ghetto of quickly prototyped databases that are underpowered and having no plans for long term funding and maintenance.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • My databases are stored on servers with 3TB of RAM. Yay! However, on average we get about 1TB of new data per day; our total compressed database size is around 700TB.

    RAM will never keep up with data, and honestly it's not supposed to. That's why we have super smart hard disks, optimization like look ahead reading, good code, good DBAs, alternative RDBMS layouts, [maybe] good data retention policies, and optimizations like map-reduce.

    As an aside, a colleague wanted to upgrade disks on his servers. His internal tech team quoted $20,000; he looked at the price on Amazon and the same uplift would have been $100/year. I hope and expect that commodity hardware will be the future.

  • Steve Jones - SSC Editor - Friday, September 21, 2018 10:26 AM

    Eric M Russell - Friday, September 21, 2018 9:54 AM

    However, I don't see stacking more memory as necessarily worthwhile. Only the data pages needed to cover queries are really needed in the buffer cache, and that's only a small fraction of the database

    And this is really the case with most systems. Write good code, tune queries, and maybe most importatly, prevent things like SELECT * with no, or very side, WHERE clauses. If you do this, then I think it's most of the time that 5-10% of the data is really needed.

    Is it me or does anyone else get a lot of consultants who come into a company and rather than do simple changes to their code to make it more efficient, they request more hardware.  One even told me that performance optimization was outside the scope of the data warehouse project and expected the DBA's to fix the performance of their 900+ lines of code by setting a couple of server flags.  I've seen a few bad queries kill a server with 24+ cores and 256GB of RAM.

  • jarick 15608 - Saturday, September 22, 2018 2:54 PM

    Is it me or does anyone else get a lot of consultants who come into a company and rather than do simple changes to their code to make it more efficient, they request more hardware.  One even told me that performance optimization was outside the scope of the data warehouse project and expected the DBA's to fix the performance of their 900+ lines of code by setting a couple of server flags.  I've seen a few bad queries kill a server with 24+ cores and 256GB of RAM.

    I did some part time work to help a small company that mostly deserved the help.  I sat in on a meeting where they were complaining that the customer didn't have the hardware they required.  I reminded them that even they didn't have the hardware that was needed to run their own software and that what they needed to do was fix their software.  They were doing things like intentionally using Cartesian Product code to generate a "starter set" of data based on the user inputs and then <insert drum roll here> they were sending the result set to the database using one Insert/Values row at a time... for 225 THOUSAND rows and wondered why it was taking so long.  Even if the customer had GIGA-bit transfer rates, it would still take a long time and they just couldn't understand the problem.  The only thing that could have been worse is if they used XML to do the transfers.  I fixed it by sending the original parameters to a stored procedure and then let the stored procedure do the data generation.  The customers no longer needed something like a CRAY with a data-pipe you could drive a semi through in order to get good performance.

    Another good example is with some current vendor code that we're using.  The vendor just can't understand why executing code that does one clustered index seek to return 1 to 300 rows would ever be a problem... even if they do call it 13 million times per hour (NOT a made up number, BTW) and most of the calls are duplicated. :sick:

    To your point, that's just two of many horror stories and most of them are based on just two things... not much idea on how to use an RDBMS correctly even though their products rely on it and a shocking lack common sense. 

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • The ridiculous thing is that the cost of peoples time arguing why you shouldn't have a RAM upgrade far exceeds the cost of that RAM upgrade.
    The cost of nursemaiding a system with insufficient RAM will exceed the money "saved" by many multiples.

    To Jeff's point on fixing code, new revenue generating opportunities always win out over cost saving tasks.  Tech debt fixing is cost saving.  That said, I don't get why the reaction to asking for stuff to be fixed is akin to that observed when baptizing a cat

  • David.Poole - Sunday, September 23, 2018 5:40 AM

    The ridiculous thing is that the cost of peoples time arguing why you shouldn't have a RAM upgrade far exceeds the cost of that RAM upgrade.
    The cost of nursemaiding a system with insufficient RAM will exceed the money "saved" by many multiples.

    To Jeff's point on fixing code, new revenue generating opportunities always win out over cost saving tasks.  Tech debt fixing is cost saving.  That said, I don't get why the reaction to asking for stuff to be fixed is akin to that observed when baptizing a cat

    Heh... SPOM!  ROFLMAO!  I got a real live picture of the baptizing a cat thing... and it's an accurate portrayal.  I'm definitely going to use than analogy in the future. 😀 

    And I totally agree.  While having a decent amount of RAM and headroom on the disks (physical or SSD) may not be the ultimate solution to performance problems, it DOES make life a whole lot easier.  A great example of that is it allows me to rebuild a 500GB Clustered Index without blowing out the MDF file because I asked for and got a 1TB "DBA work disk" (which will NEVER contain anything permanent).  Very justifiably, I knew that they were going to want to know how I was going to use it and what the ROI was going to be in some detail but I provided that without being asked.  That's the key for most people in charge of the purse strings.  They don't want to hear empty/non descript garbage about "Best Practices", etc.  They want something in writing that explains the benefit to the company both in the short term and, especially, in the long term even if they may not understand the nitty-gritty technical stuff.  It also helps if you can "bring it down to their level of understanding" without it making is sound like you're belittling their possible lack of knowledge on the given subject.  There is a bit of an art in making such requests palatable and well thought out because a lot of people think that IT people just want to live up to "He who dies with the most toys wins" attitude that so many people to put up without providing and adequate ROI.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • We've been discussing REDUCING our RAM on a test box and leveraging the flash drives which, rumor has it, may perform better than memory (with giant pagefiles).  Has anyone else had such crazy thoughts, or even followed through with some testing?

  • christopher.ivens - Tuesday, September 25, 2018 12:57 PM

    We've been discussing REDUCING our RAM on a test box and leveraging the flash drives which, rumor has it, may perform better than memory (with giant pagefiles).  Has anyone else had such crazy thoughts, or even followed through with some testing?

    Flash drives and other non-volatile memory will never out-perform volatile RAM.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden - Tuesday, September 25, 2018 2:54 PM

    Flash drives and other non-volatile memory will never out-perform volatile RAM.

    Yeah, let me guess, the flash drive vendor started the rumor!  I am amazed at what sales and marketing will say to generate income, knowing they won't be there when things don't work.  Support can handle that.

    Dave

  • djackson 22568 - Wednesday, September 26, 2018 7:25 AM

    Yeah, let me guess, the flash drive vendor started the rumor!  I am amazed at what sales and marketing will say to generate income, knowing they won't be there when things don't work.  Support can handle that.

    I'm an old guy, so I am not as gullible as I sound (when the infrastructure team asked me how much memory I wanted on the new data warehouse prod server, I said, straight-faced, 128-GB...after a long silence he countered with the 36-GB we ultimately got...why even ask?).  Our infrastructure guys and one of our SQL developers are cooking this up.  I am skeptical, but I am willing to run the experiment.  One of the drivers is this video from Robert Martin:  https://www.youtube.com/watch?v=Nsjsiz2A9mg  (don't watch the whole thing, just the last few minutes will get you the point).

  • christopher.ivens - Wednesday, September 26, 2018 10:17 AM

    I'm an old guy, so I am not as gullible as I sound (when the infrastructure team asked me how much memory I wanted on the new data warehouse prod server, I said, straight-faced, 128-GB...after a long silence he countered with the 36-GB we ultimately got...why even ask?).  Our infrastructure guys and one of our SQL developers are cooking this up.  I am skeptical, but I am willing to run the experiment.  One of the drivers is this video from Robert Martin:  https://www.youtube.com/watch?v=Nsjsiz2A9mg  (don't watch the whole thing, just the last few minutes will get you the point).

    Start at about 42:00, but that appears both naive and moronic to me.

  • christopher.ivens - Wednesday, September 26, 2018 10:17 AM

    djackson 22568 - Wednesday, September 26, 2018 7:25 AM

    Yeah, let me guess, the flash drive vendor started the rumor!  I am amazed at what sales and marketing will say to generate income, knowing they won't be there when things don't work.  Support can handle that.

    I'm an old guy, so I am not as gullible as I sound (when the infrastructure team asked me how much memory I wanted on the new data warehouse prod server, I said, straight-faced, 128-GB...after a long silence he countered with the 36-GB we ultimately got...why even ask?).  Our infrastructure guys and one of our SQL developers are cooking this up.  I am skeptical, but I am willing to run the experiment.  One of the drivers is this video from Robert Martin:  https://www.youtube.com/watch?v=Nsjsiz2A9mg  (don't watch the whole thing, just the last few minutes will get you the point).

    He seems to have confused SSD's are faster than spinning drives with SSD's are infinitely fast so it doesn't matter how we use or access them.

    In other words he's an idiot.

  • Steve Jones - SSC Editor - Wednesday, September 26, 2018 2:29 PM

    christopher.ivens - Wednesday, September 26, 2018 10:17 AM

    I'm an old guy, so I am not as gullible as I sound (when the infrastructure team asked me how much memory I wanted on the new data warehouse prod server, I said, straight-faced, 128-GB...after a long silence he countered with the 36-GB we ultimately got...why even ask?).  Our infrastructure guys and one of our SQL developers are cooking this up.  I am skeptical, but I am willing to run the experiment.  One of the drivers is this video from Robert Martin:  https://www.youtube.com/watch?v=Nsjsiz2A9mg  (don't watch the whole thing, just the last few minutes will get you the point).

    Start at about 42:00, but that appears both naive and moronic to me.

    My "favorite" part was when he talked about memory being so fast that you don't actually need indexes. because you can just go directly to the data.

    He really needs to think about how that's going to happen. 😀

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • christopher.ivens - Wednesday, September 26, 2018 10:17 AM

    djackson 22568 - Wednesday, September 26, 2018 7:25 AM

    Yeah, let me guess, the flash drive vendor started the rumor!  I am amazed at what sales and marketing will say to generate income, knowing they won't be there when things don't work.  Support can handle that.

    I'm an old guy, so I am not as gullible as I sound (when the infrastructure team asked me how much memory I wanted on the new data warehouse prod server, I said, straight-faced, 128-GB...after a long silence he countered with the 36-GB we ultimately got...why even ask?).  Our infrastructure guys and one of our SQL developers are cooking this up.  I am skeptical, but I am willing to run the experiment.  One of the drivers is this video from Robert Martin:  https://www.youtube.com/watch?v=Nsjsiz2A9mg  (don't watch the whole thing, just the last few minutes will get you the point).

    Heh... a data warehouse with less memory than my 5 year old phone.  Sounds like fun getting ready to happen. 😀  I'm with you... skeptical but also willing to learn something new.  Let's hope they feel the same way if it fails.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 15 posts - 16 through 30 (of 36 total)

You must be logged in to reply to this topic. Login to reply