Voice of the DBA

Tag: Performance

  • The Load Poll

    Hopefully this isn't the load you see on your servers, but do you know what level of tps would cause this?
    Hopefully this isn’t the load you see on your servers, but do you know what level of tps would cause this?

    I was taking to someone recently and this person had a large transaction load on their SQL Server. At least, I thought it was a large load. This person said they experienced 1000tps most of the time and this made maintenance, DR planning, and more a challenge. That’s a lot lower than the TPCe performance system that has 4,614tps, but it’s nothing to sneer at. That feels like a significant load to me.

    However it’s been awhile since I worked on a variety of systems as a consultant. I often see the forums at SQLServerCentral showing only tens of transactions/sec, based on the performance data that you can see at monitor.red-gate.com. This is the actual data from our servers and it seems like a low number to me.

    This week I was trying to decide what 1000tps really means. Is this a busy system, maybe even an edge case if this is the average for your system over a week or month? Is it a representative system for many companies? I wanted to see what others report from their systems this week:

    What are your average and peak tps for most of the systems you manage?

    I’d like to hear about 1 or 2 systems that you consider to representative of the loads in your environment. Taken across your business time, whether that’s 9-5, 24×7 or something else, can you get the average and peak values for your transactions/sec and disclose them? You don’t need to let us know about your application or company, though industry would be nice.

    I’m curious how busy systems are for some of you and whether this presents you with challenges for migration, upgrades, virtualization, DR, maintenance or more.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Leaving Some Headroom

    Max Headroom
    You want to leave some headroom on your server, though perhaps not this kind of headroom.

    I was reading this piece on scaling Dropbox and something caught my eye. It’s a very interesting read, especially if you deal with scaling, and I’d encourage everyone that works with technology to read it. The one thing that really caught my eye, however, was the idea of running with extra load. In the piece, the author notes that they had a process running on their systems that consumed memory and CPU. If they ever reached their limit on the systems, they could stop the process, giving them a little more horsepower for the application.

    That’s interesting. It’s a take on similar techniques that we used on our SQL Servers in the past. We could keep a few 1GB files (in the days of 50GB disks) on each logical drive. If the drive somehow filled up, we could delete the file, giving us a little more space.

    Steve, that’s silly. You’d still need the same amount of space, so why does this help? It helps because it buys you time. If a process fills your log file, which fills the disk, the database stops. If you kill the process, and then delete the file, you’ve got space to clear your log, and keep your system running while you find out what went wrong. That’s the idea of artificial headroom. It allows you more time to respond in a crisis.

    I’m not sure how I’d want this to work on my SQL Servers. After all, any load I placed on them wouldn’t necessarily just occupy CPU. It would also impact the buffer pool, as the type of process I chose would influence what would stay (or go) in that bit of memory. However the idea of limiting my system slightly, maybe 5%, in a growth situation is interesting.

    At the very least it might appease my users while I get a purchase order for more resources approved.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • RECONFIGURE can flush the procedure cache

    I ran across this KB article the other day, which lists a few ways in which performance is affected by various maintenance or administrative type operations.

    In KB article 917818, it notes that some operations cause a performance issue. Some of the operations make sense (offline/online, restores, etc), but there were a few that surprised me. For example, did you know that Autoclose flushes the cache? Might not be a big deal, but it also might mean that your apps based on Express might end up running slowly each time the user accesses the databases.

    There are also a number of items which are implemented by a RECONFIGURE that will flush the cache. These are listed in the KB and are:

    • cross db ownership chaining
    • index create memory (KB)
    • remote query timeout (s)
    • user options
    • max text repl size (B)
    • cost threshold for parallelism
    • max degree of parallelism
    • min memory per query (KB)
    • query wait (s)
    • min server memory (MB)
    • max server memory (MB)
    • query governor cost limit

    Also, changing a filegroup to read-only will flush the cache.

    This is by design, and I wouldn’t expect it to change anytime soon. Since these options can affect query plans, it might make sense to flush the cache, but if you don’t agree, file a CONNECT item and stump for votes.

  • The Cost of Page Checksums

    What’s the overhead for a page checksum? I’ve seen various numbers thrown out, but I thought that Paul Randal had written at one point that it was around 1-2%. I can’t find a reference, but in this post, Paul doesn’t dispute that.

    In any case, it’s better to find corruption than save 2% of your CPU. I’d argue the same thing for performance monitoring, which I’ve often seen referenced at 5% of the load. If you don’t have 5% overhead, you have other problems.

    You need to measure things.