Merken

Balancing Database Storage Latency And Throughput

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
so OK everyone started here analogous 315 which is when this actually start and I'm Grace Smith I work for a continuous solutions uh talkative Otero talk a little bit about post-stressed storage latency and throughput and how those 2 things relate to 1 another how you can tune for the 2 of them at once because they do interact but the 1st
thing that I wanna make sure I defined for you in this context is group or but throughput is how much work you get accomplished at some task but normally you measure throughput in some sort of operations per 2nd contacts Archimedes PG bench for all the examples here so little benchmarking fully comes with pulse graphs in in PG bench the specific specific tasks that it runs are referred to as transactions because most of them wrapped in a little transaction block and so it shows you transactions per 2nd for whatever it is you ask it to run lots more talk about group here we would basically mean how many transactions per 2nd we get work I How many operations 2nd to begin 1 this thing so that the reason why this is interesting to talk about now i in the context of PostgreSQL 9 for coming out earlier versions of PG back to post-process the wave PG benched worked is it always rainy and has fantasies could you start some number of clients opt and it just as it finishes a transaction immediately tries to do another so this this is interesting for stress testing your hardware and it's useful measurement of this type of bursts speed for how they ask the hardware can go under maximum load but it's not really realistic or were like anyone's real-world workload all the time may periods like this but around like this constantly is is not really been a good representation of the real world for people so I'll
start by showing a little bit about how PG bench has worked and what you might be use same you played with that already for these examples I'm I'm picking up a basic middle or server for reality is 24 64 gigabytes of RAM and just to keep things simple lists the single standard 72 70 200 rpm drive up post post stresses PG bench ESFRI scaled that determines how big the databases all these examples are using a scale of 100 gives you roughly 1 . 5 gigabyte database so all of this fits easily in RAM of but it's interesting anyway the the basic settings for the database to just get normal performance and utilized as much RAM the the buffers that are dedicated to the database the shared buffers I'm saying that a gigabyte so again more than fits everything I'm going to do the the database in RAM hot and checkpoints segments all talk about a little bit more and will actually see why it's an interesting thing to work on I and that the graphs that you're seeing are all coming out of of small PG bench tool kit that I've least for while else called PG vegetables just helps 1 lots of PG bench tests in get graphs of things like latency and what not Louverture really important in this context so
this is what PG bench look like when you ran it but in earlier versions of post graphs are the idea is you give it some number of clients you give it some number of threads which of the threads are actually how many PG bench processes are driving those clients and you duration all of these tasks are running for 10 minutes about which is enough time to consider database go through at least 1 full cycle of the activity it does and at the bottom of this the number that most people start staring at is this TPS number so here for this example again this is running flat out as fast as database can go it's it's getting just over 17 hundred transactions per 2nd is the throughput on this task but what I did is I
took this and I ran it on 3 different driver to give a measure of what the throughput looks like as a starting point for the discussion and so this the blue line at the bottom here that's the single 70 200 rpm drive the 1 that's above that a good bit faster I've added a piece of hardware called a battery-backed right half to abbreviate the BTWC and all of us on that's something that when you write something the disk and say you know I need this flushed adorable desk you will see that in memory in a way that it won't get lost if you lose power and this actually accelerates a lot of writing operations in the database and as you can see here it easily make some operations more than twice as fast in this context and then final data point the thing at the top that's in Intel I datacenters series drive their DCs 37 100 so s is these sometimes you see crazy claims forum this this I think is what I'm saying witches but it's easily 5 to 10 times faster than a regular hard drive you know but it's not it's not like unbelievably faster and the gap from a battery-backed right cashed it is is not even necessarily huge especially if you only have a small concurrency so this is again this is the throughput transactions per 2nd how fast can we get work done on PG benches simple transactions but it does running as fast as it can so this this is interesting in its place useful data but I don't really think all at many people care about maximum throughput when you're running transactions all the time a lot more people ask me questions about latency and the problem with this is testing this way and optimizing for this it doesn't really tell you anything interesting about now the
latency as I'm using it here the idea is that's how long does it take any client to get a response back from the server when it asks for something to get done now you when you see the transactions per 2nd number that comes out of this you can turn that into an average latency just by converting it from transactions per 2nd in 2 seconds per transaction I do that can rescale this year just get it in milliseconds which is normally what makes sense for latency numbers so if you have a thousand transactions per 2nd that's 1 millisecond per transaction as an average the thing is that average latency is interesting and so it's a single number you can use but again most people don't really care about average latency they wanna know about worst-case latency instead and that's where things a lot more interesting so
if I if I take this same sort of PG bench tests that I to show the results from an ironic up that comes back and 1339 transactions per 2nd that's an average latency of of 3 quarters of a millisecond but if you actually graph the latency on that you'll find the transactions that take over 3 . 8 seconds mixed in with that so this is why you can't just take a number out of PG bench and look at it and do anything with that TPS number on its own but when you start looking at the latency you discover that's actually a much more complicated and difficult thing to get a picture of this is why
through what looks like if you actually graphic every 2nd instead and you should be pretty obvious what the problem is here OK this was averaging into
13 hundred transactions per 2nd but that's not a steady 13 hundred transactions per 2nd that's actually sections of alternating between this really high speed writing where we're getting our sometimes over 2 thousand transactions per 2nd with these just complete dead periods and forcefully my graph got a little bit botched here but each of these each of these major agreed divisions here running 1 there's is what I mean it worth of test time so when when you see something like this this big thing down there that is a significant chunk of the middle where it's stock with like barely making progress through the whole thing so you might wonder why is this happening well when you run PostgreSQL 1 of the things that it has to do is worry about thing was better in memory ultimately need to get to this dimension but you don't necessarily want to write those things every single time someone updates them so we have this write-ahead log mechanism that keeps it so this stuff will be safe if you crash 3 right stuff the bear and then later we write it out to the main desks the process that worries about making sure that all of those things are written to disk safely is this process called checkpoints so checkpoint in the database and goes through the the memory that you've assigned to it which in this set up that on describing was 8 gigabytes it's going to scan through all the gigabyte and anything that has been modified since the previous checkpoint it's written and when it's finished it can say OK everything up to this point in time is now written on this so when you see the cycles like this coming out of a throughput graph like this but this is the classical look of a system that has problems with checkpoints in the database so when you're seeing it run really fast at the beginning this is the time when it is not actually doing any checkpoint work is just a buffering stuff in memory it just let it pile up and keep going and it's not worrying about it yet so the the big drops data showing up on the 1st of them is like right when see this big drop their that's basically when it starts writing out so throughput drops immediately there and then the vigor drop is there's there's 2 phases the checkpoints in the database 1st it rights everything out to the operating system have that steps back and says OK now I need this to really get flushed to disk the flushing to disk part just what it calls the same phase this is the part that really hammers the hard drives and when this gets going on our performance tends to find 1st of all this this 1 is coming from just the basic simple hard drive so this is if you're wondering how is it that this system ended up with things like of 3 . 8 seconds wait for a transaction at some point in that's part of the mass that's in a slow period and so
this turns out around this is this is basically the same graph is what I just showed you accept inverted rather than showing transactions-per-second were showing the latency for every individual transactions future I want you can realize those are you know the inverse of 1 another in these in these graphs are
basically graphing the same thing it's just the only CPU is is what I think more people are interested in from like application perspective because how long of individual clients going is more usefully measured by most people in the form of latency so we see right here where the problem lies right right up here at the top that guy right there there is lot of 30 hundred and millisecond latency guy ends up what this is showing the same sort of flow these periods here it's just writing in the operating system cache and then it starts flushing that stuff disk latency goes up and then you can only tell when this process of seeking stuff is finished because the latency drops again so just guessing right here is probably 1 the checkpoint finished need internal logging of checkpoints and double check and see whether that's the case and this is partly why people tend to make recommendations like well if you start turning on logging in things like slow queries in your database and so it's a good idea to try logging of checkpoints so the the way you would work that is if you got a big latency spike you know like 1 of these periods up in here you could go back and say OK what was there a checkpoint happening during that time period and if that happens consistently it's pretty good evidence that these 2 these checkpoints bikes are are a problem so some of the basics of of checkpoints it's a it's a big topic in our argument of some of the more interesting parts relative to today's topic
on so here's a different view on this what I'm doing here again this is the same task again releasing a different perspective on this is on a Linux system on most operating systems expose this in some way in Linux Dino that you have written to the operating system so that it has not written to disk yeah act is referred to as during the day others a systems view of our approach and put it in here it's called slash rocks slashing and all it will show you that and 1 of the 1 of the tables in the PG benched is a little collector just wanderers often grabs that thing every 2nd seeds of the disk and then generate a graph like this at the end so this is this is showing a different view on 1 this same problem we've been talking about which is when when we're having these periods before checkpoint has happened up posts that's basically is a writing anything to the operating system at the beginning because all the rights it's doing it in its own catch doesn't need to put in that as just keeps overriding copies in RAM so when it when we see this start to pick up and that's when the checkpoints started it's now aggressively writing memory in shared buffers to Linux is operating system cache this goes on for a good number of seconds we tried this out over time and I'll I'll get back to the concept of that so that the high water mark that there is this point up here but if you look at that this is in kilobytes over here overlap so we are are almost hitting a a gigabyte worth of dirty memory on this so basically at the point when the checkpoint is over we've got 1 . 5 gigabyte database and an entire gigabyte of it has been off the beaten by PG venture it dumps the whole thing out as part of the checkpoint and then once the whole thing is there it switches over to these sinkholes calls to get it for students 1st will this test right here the checkpoints are showing up of 1 2 like 2 and a half minutes apart which is basically the it's above the point where would warn you about by people but you could to that like I'm so so what we're seeing here is basically 1 2 3 in the beginning of the 4th checkpoint are all happening during this 10 minute test on so seeing 1 roughly every 2 and a half minutes and this kind of love where you've got a system can adjust ones at top speed for a while and it just grinds to a halt and everything ships from the database over in the Linux this is a pretty common sort of thing and and this is how it works and I think it shouldn't be a surprise to you when I say that there's over a this is over 900 megabytes of idea that it is writing to Linux and then saying now take that 900 gigabytes and flushing out to desk they should really be a surprise if you're familiar with this disks that this might take several seconds before that'll finishes so this has been basically what PG bench lets you do PG bench lets you take a system which is completely filled up all the RAM with 30 days and and eventually when it's been running for long enough that that that when these checkpoints has to happen it will just dump it out fairly quickly to the operating system and in the operating system just chokes on it for a while while weights for all this the play out but this is classic checkpointing problems and this has been visible to some extent I don't know that a lot of people live ever graph this during memory that over time but this makes it really obvious from where the stuff is getting stuck at if we say OK what's happening during the slow periods of ago if I go
back to here clearly those slow periods up at the top
part right after it stopped of 900 megabytes worth of stuff into the right of you want to ask here is the order of production so we have some some of these things that you to see you have the freedom to the user some problems you all that so feature yet there's there's 2 interfaces to get this data right now and post-stressed neither of them are great but they are available 1 is I mentioned there is a a long checkpoint parameter that when you said that the 1 you will get a text format note saying that the checkpoint started then another 1 saying it finished and gives the timing information and after you get some practice reading those you can sometimes spotless slow this just from what appears in the timing and 5 and the other thing is there's a systems view that's more like work weight interface it's not exactly like that we're moving toward so as weeks following face and the system using a PG stand at BG right here just short for background writers whenever a checkpoint finishes it updates statistics in there you can if you graph that over time you can tell where the checkpoints happened because the spot where it jumps up on when it finished a chapter so that it's it's just it's not it's not really tell you anything about latency it's just showing you that checkpoint finished unfortunately you still have a job and posters blindness this up with other events to to kind of see how they are connected so we should better answer working on a better answer is just not ready yet but so this has been where we've been on the wall now and this
just takes these graphs and overlays them again OK it's pretty clear that the weights are coming from the back end of the chapter points it's all spiking off on and basically I'm knowing tell you what to do about this in particular want talk about is the fact that this is not even really appropriate because we're only seeing this gets so bad because we're running this thing flat out as best as little go all the time and that's not really realist but if you do
that all your caches will film and then state filled until each checkpoint is over but the hardware is never going completely catch up with everything is always going to have stop there and here's the here's 1 of the really important points here if you take this work load and you to your system you do things like a just a checkpoint parameters to do all this other stuff if you optimize for this piece you are only optimizing 4th throughput for getting lots of transactions per 2nd process is really easy in fact likely that if you do that you will actually make latency worse because latency and throughput are connected to 1 another and I will show you how that works here in a 2nd so tuning of forward the traditional PG bench case is not necessarily productive and if you're doing that because you want we can see get matter step back because you can easily make latency worse all you're doing the tuned for that is fitting for maximum throughput instead not the the latency of any individual thing so we
are this is sort of amplifying this behavior but there's a there's a parameter in the database that people have have really good visibility into the concept is rather than writing all the data all at once we see we can spread the checkpoint out over a period of time and the parameter for this thing is called checkpoint completion target it is specified as a person it's a per cent of the total time the system spends in between checkpoints so the idea is the graphs that I've been showing you included the database trying to spread the audio out over there if you're skeptical that that really helps what we're doing here is just turning it off altogether if you turn off altogether we get this from really sharp discontinuity where it just don't see all the data down even faster than it did before and then goes as fast as it can to it's getting all out the desk and and what's interesting about this and this this will happen all time and it's it's 1 of the key points of 1 community here doing that you look at this graph on the on the right and I mean nothing is just the that's transactions per 2nd things just act right like if you're if you're system perform like that you know you'd be out the door by the interesting part is the throughput of that PG bench on its transactions per 2nd number is faster than the 1 that I showed you before so that's actually more than 1300 is about 15 16 hundred transactions per 2nd and this is the weird thing that is important to realize that if you take your data and you write it in 1 giant burst and you combine a lot of things goes into that operation the more stuff Ukrainian into all the more efficient gets and the throughput goes on so even now this thing is just sitting sucking when when it is running is running so much more efficiently than the gains in transactions from that out way how long it spends doing nothing so this is this is it when I was just warning about if you took your system and all you look that was transaction rate throughput number and you to system like this 1 I'm showing on the slide if all you looked that was transactions per 2nd it would say you just made the system bad but this is clearly not better than what we have before you can think of it I this has some characteristics of the folktale load but typically a bulk data load will not be running you know 24 processes it once and kind of killing everything up like this you you can get a parallel ball could be a little bit will look like this but I mean you you really gonna work loaded to be born and as hard as PG ventures so I think I've been on this so that the main the main point here so that the 1st lesson is optimizing for throughput will do bad things your latency and you need to really be aware of which you do it so what's new
well impose personal knowing were there was a feature submitted that the minute I saw a jump right on it's something waiting for for a while it lets you limit on how much work PG bench dollars during any period of time but to me we refer to as a rate limit sometimes called the throttle when when it was originally submitted the idea is in this example are running 16 clients for 30 seconds and i'll limiting it to 50 transactions per 2nd that's it if if it's it because it creates a schedule to come like from something out every 5th 50 times a 2nd and if it's not time yet sleeps and weights and all the clients do this in a way that on average works out like that so these examples of switched over a bit these these battery-backed write caches of this talk about the work of I'm adding 1 now to the drive and this is 1 that's capable of holding 256 megabytes a lot of people think well if I put that in there as long as the checkpoints are writing less than an and maybe half that might be used for rights that states have reads half right OK so theoretically I can absorb 128 megabytes of rights without overloading right well at the early work out like that I in the real world unfortunately see how
work out and checkpoints spreading I it's a long topic which again is going to well actually I I may be the only 1 which is I could go on and even more about it but but by default we do a 50 % spread and that's probably find it's really it's not a big deal to to get crazy about that the more important stuff is we these 2 parameters checkpoints segments and check time they determine how often checkpoints happened and those are the those are the important things the normal good practice is increased checkpoints segments until you're getting a checkpoint it's based on the time how and give you an idea that the full time not a Spiderman it's so increased checkpoints segments until you get a checkpoint every 5 minutes that's a decent way to spot on your checkpoint timing but if you if you get to that point and there's other things that you might think would help like sometimes people go well my latency is so let me reduce the size of some of the caches were they'll do things like go well this Linux scheduler thing I have this choice of CF a deadline no are up and maybe you know what sounds more like it's right into my rate controller and maybe deadline sounds better for latency purposes but it turns out all this stuff is like we a down the chain of things that matter but what really matters is how big the caches are and how stock things move between them and how those things related to each other so
here's our p is an example so this this thing I've now moved to the 50 transactions a 2nd that's all impression through this now so otherwise the same sort of test that was doing before so where you can see what's happened here is now with only 50 transactions a 2nd coming through but the amount of of memory that Linux is getting 30 is usually not even registering here now instead of peaking at 900 gigabytes we're only seeing her 900 megabytes Willie peaking at 30 megabytes here OK so this shows that limiting the rate does what you'd expect if it's now generating so much less stuff that for the most part the disks writing it out as fast as it comes in they're keeping up now so this is why this is a more useful thing than what we had in earlier PG benches this is now showing us something that the this can keep up with so if we can see what the disks can keep up with and then we make a change and now the disk can't keep up with that we now learn something useful about the capacity of the system more useful probably than what its maximum throughput is we have completely overloaded and so this is this is why I think it's interesting to use this I'm starting to do most of my latency tests where have basically the smallest transaction-per-second 2nd part that I can't law that doesn't seem completely trivial and I'm trying to work through and see what how low can I get latency whether that's almost trivial seeming workload there's a numerical things here that to 2 interesting facts about these this paragraph of the 1st is the spikes are only getting to just over 30 megabytes but if we look at the the latency graph on the right and it's still getting hung up for over 2 and a half seconds so the 1st thing to realize here is that the fact that the battery-backed right cash is capable of holding the 20 megabytes worth of rights that doesn't mean it's going to absorb them on checkpoint rights because by the time you get to the checkpoint you have already been writing to that system 4 minutes worth of time and so by the time you get to wear checkpoint happens it's often the case that like the right caches on your disk or a rate control those things tend to be filled before you even get to starting a checkpoint so that's why they don't save you can't just look at that number and it to the size of the cache and your control it's a 0 to fit or not fit you have to ask how filled was it before you got there and unfortunately no 1 really has good visibility and into that even than I know a lot of our I wish when I got rate cards there was a nice easy interface where I could say how much of your passion is currently being used for writing you know it's it's not it's generally a black box we through right into we don't see what happens to so that's that's an interesting thing and the other thing is just a step back and go well I am I'm only writing 50 transactions per 2nd but I am this whole system is backing up for 2 and a half seconds local part of why that's happening now is because I specifically turned off checkpoints spreading by tweaking this checkpoint completion target so this is basically this is the demonstrate to you that checkpoint spreading those something useful but even with the battery Rokkasho all this other stuff we can still get hung up for for 2 and a half seconds here on this simple example but well I
forgot to do that we try this
again on this clearly still point there were about this to some extent because it's still get stuck so let me let me go through some discussions of the
things that I have to worry about here so 1 thing you might think for how we get rid of this 2 and a half 2nd gap is well maybe we could change how big the the right caches in the Linux write caches there's parameters with names like 30 background ratio what people get to this point sigh Alameda straight out of the find that doesn't actually work out of sheer what happens is that the problem is if you decrease the size of a cat it makes it less efficient vigor year caches that the more room it has to make things more efficient so when you reduce the size of the cache that doesn't necessarily make things faster because small caches also have slower throughput so there is a trade off here you might think I use a small patch I get i've west of building up I'll get lower latency but if you actually hurt throughput the process again in the being sorry we started so why is this
there's actually a couple of mechanisms this is a whole other topic altogether but just to give a brief flavor of them you do I O in big chunks it does this thing called elevator sorting where tries to take things that are on the same area distant from altogether but it does this thing called right combining the 2 things they're writing to adjacent chunks so just do them together as 1 operation but also if you write something and then you really you write it again a later or if you write something and you read it again that really have to read it just grabs it from the cache again basically all of these things the bigger your cashier's I sometimes call this a caching horizon the idea is how far can the cash see how much of visibility does it have been to what's coming up as that number goes up it actually makes the throughput go up as well
so this is really important if you try to defeat this by saying well let's get less 30 memory in the system began when it doesn't really work because the efficiency drops you get less of all these things and now when you get a backlog you can't get through it anymore and similarly some people think well why hasn't posts Christians use direct die out and you know it's schedules all writing goes from there the thing is the model that we have for help us Christos rights at this point expects that this operating system caching is going to be there and if you take it out of the system there are all kinds of things just become absolutely terrible absolutely terrible I mean that I'm showing you things where I'm seeing 2 3 4 seconds worth of latency try switching oppose graphs system is heavily on rights over to direct dialing you'll see that number jumped to like 40 50 60 seconds instead you stop for a full minute trying to write out stuff if you don't get at least a little help from the operating system with the cell
and so what I wanted to do to to kind give reasonable intron what this feels like in the real world for you is already give some examples of how the storage latencies work out the idea is right I picked a low transaction rate this 50 transactions a 2nd I small number medium number of clients in-memory database and what I'm looking at now is how the Iast information is moving through this whole system kept its total across all the points and so was see how fast things move through this whole mass up so
here's my 1st example the single best our even now I I've I've got this very small amount of work I'm doing I'm no matter how I shuffle things I still get periods where there's there's a roughly a 2nd worth of the line element and normally a single desks have roughly 10 ms worth of Ohio is a worst case so so what this is saying here it's very easy even on this kind of simple workload hard to get roughly 100 of those in the queue the you get stopped leading war in in the worst case scenario Severe doing capacity planning 1st often you wanna know some people are used to working in like I used 2nd and stuff like that I like to work now in terms of what's the latency pocket verses what we're getting you know seeing the occasional spikes as high as 100 ms is not unusual to actually hard to do much better than me with just regular disk now I mentioned we
put a battery-backed right passion that helps it does it actually makes a lot better at the same system same hard drive but do all that I'm looking at lower like a 3rd of the 2nd is one-dimensional my system so about what's interesting about that is that saying that were were roughly stuck behind about 32 operations might be ahead of us in the queue of the directly related or not but most hard drives are actually scheduling roughly half 31 operations at time inside the disk itself so I think I think this is this is close to optimal mean this is basically if you have a hard drive it has 32 random queued up and it already it will take about 300 ms for those 2 q and this is this is a very realistic it matches what I expected here and this is what real world this behavior looks like let's 1
argues that in toxicity again us several times faster but it's it doesn't make the problem go away it on average this Intel thing is is cranking through most transactions in a fraction of a millisecond you can only see all this crap but I mean almost all of these things are actually very low latencies but you know there's a few of them they're in this this chunky part at the bottom and then just occasionally you'll you'll see these little stutters pop up and it's it's rare that I see them get much below 100 ms so you people think of of of SSB I always this kind of 3 when it's random it's really not when you're writing when you're writing there's it's not clear cache blocks out it's going to do a lot of work under the hood and that I O per 2nd you get which are actually achieve on a real system with the other latency in the stack and everything but it looks like this for me a lot more often than it looks like you know right sir free because random cost I hope I I don't actually know there are occasional hot peaks in this data at 10 ms their occasional things that look like heart little spike 100 ms also some kernel of 1 of the reasons I wanted to share this year at PG con in particular is to try to make more people who were working with post-stressed seriously aware of how I'm running these tasks what the idea is because I'd like to give more people doing this the help me figure out like why some of these weird things happen so major will be the case that the real cause of this is not the storage all of these latency measurements or or real world from post stresses perspective and I try to point a finger at any component to being going here you know this is showing real world this is the whole stack put together this is the database side that we may very well be able to engineer some of these things out of post-processing to me when Linux that you better try other operating systems but I don't think anybody that me has been looking at the data like this and this is a lot more interesting to look at this way than that I think most people were looking at well yeah the right
log files another thing I can try to seperate out to see how those work and the whole thing is a lot of all of this is kind of like a missing graph
confusion there's 1 more
graphic kind of pulled all this together to move the
heating In your I'm using
all the faults except for the things that I and I
mentioned on area of so this is the is slide this for some reason the same for the other version that talk on and this is this is only my final topic here if you look at this stuff you can figure that is kind of like a storage stack its feeding through these multiple layers of caching shared buffers at the top of its lighting to Linux's right catch feeding into the battery-backed right catch on the thing that the thing that is worth highlighting is if I tried to make this thing smaller people think that making that's smaller will then make it draining faster but the the problem that I'm warning you about is if you make this smaller in hopes of getting it to drain faster this is what
actually happens when actually happens with a small right catch is dream rate drops to so we might have been getting only 6 megabytes per 2nd out of the and it took a couple of seconds to drain but but the latency throughput trade off here says if you try to make latency loved by making all the is small what actually happens is your throughput can drop so far the you'd have been better off with the bigger catch the whole time and this is really not obvious thing and I run into in the real world it seems so obvious 0 caches take too long to clear make the is smaller but it doesn't work out that way in this this phenomenon is is the thing that's really hard to really hard to nail down in that regard I'm so sorry about the sort asylum that that would a full advantage of it the right spot and basically the context were at the time of the women who are less was a 15 minutes for questions or OK yeah so work is is the next 1 450 values for again so I'm not going so I guess I'll take questions for a couple of minutes you're always shuffle around the starting off the projector that's the main topic I want to go over some people only useful and slides ago website there this is the what could you be the 1st part of that but what what happens during a checkpoint is there's a single process the checkpoint process it stands all the memory in the system finds everything that's sturdy writes and then it applies a little bit a logic to decide whether it should write more of it now the land and it's it's it's it's aiming to hit a schedule for how long it's close to take and spread it out over time and that's basically all tapping it's not co-occur in it's 1 process going through this whole note this is this is completely asynchronous with everything else happening in the system the process itself is written moved on and go on this is kind of clean up later this the things is always the problem the the reason thing was gets lower when the chair when the checkpoints are happened is there there are deadlines on things like what I O has to get done and what will happen is that you'll have like rights to the right ahead log and some other things that it does have to to wait for when you feel that you saw things will get stuck waiting for them even know they are not that transaction so once a few fills you can end up waiting for someone even know you don't really care about them simply because the q that's in the middle is is full stuff it be different but it doesn't actually change all that much because the right log traffic is or is not what's driving this what's driving the performance is normally random I O to the database not the sequential I O to the right plot and that the results of the all of this the only thing we talking about here and then have here we can we can try to isolate out which of these are like CPU oriented things which are just so I I suspect a lot of these are actually curl level things went because we don't have anything in post-stressed that runs it interval like that we we have things around intervals but not that match the heartbeat of what's shown on the hand and I'll I'll take 1 question you think every time they have become a
Bit
Extrempunkt
Wellenlehre
Selbstrepräsentation
Gruppenkeim
Versionsverwaltung
Zahlenbereich
Ungerichteter Graph
Computeranimation
Datenhaltung
Unternehmensarchitektur
Task
Client
Softwaretest
Puls <Technik>
Reelle Zahl
Korrelation
Datentyp
Skript <Programm>
Speicher <Informatik>
Transaktionsverwaltung
Einflussgröße
Softwaretest
Nichtlinearer Operator
Hardware
Hough-Transformation
p-Block
Kontextbezogenes System
Frequenz
Quick-Sort
Beanspruchung
Transaktionsverwaltung
Last
Datenspeicherung
Bitrate
Versionsverwaltung
Normalspannung
Normalspannung
Retrievalsprache
Bit
Server
Prozess <Physik>
Versionsverwaltung
Zahlenbereich
Ungerichteter Graph
Extrempunkt
Computeranimation
Datenhaltung
Task
Puffer <Netzplantechnik>
Client
Softwaretest
Minimum
Speicherabzug
Thread
Transaktionsverwaltung
Softwaretest
Zentrische Streckung
Teilbarkeit
Datentyp
Datenhaltung
Mailing-Liste
Gemeinsamer Speicher
Störungstheorie
Kontextbezogenes System
Software Development Kit
Transaktionsverwaltung
Thread
Menge
Zahlenbereich
ATM
Dreiecksfreier Graph
Client
Server
Mini-Disc
Bitrate
Prozessautomation
Mittelwert
Bit
Punkt
Datenparallelität
Zahlenbereich
Extrempunkt
Computeranimation
Rechenzentrum
Festplattenlaufwerk
Client
Webforum
Minimum
Endogene Variable
Transaktionsverwaltung
Gerade
Einflussgröße
Leistung <Physik>
Nichtlinearer Operator
Hardware
Zwei
Reihe
Gleitendes Mittel
Kontextbezogenes System
Endogene Variable
Transaktionsverwaltung
Druckertreiber
Rechter Winkel
Festspeicher
Client
Server
Bitrate
Mittelwert
Softwaretest
Resultante
Transaktionsverwaltung
Thread
Graph
Zahlenbereich
Zwei
Client
Zahlenbereich
Extrempunkt
Bitrate
Quick-Sort
Computeranimation
Bit
Punkt
Prozess <Physik>
VHDSL
Hausdorff-Dimension
Ungerichteter Graph
Division
Computeranimation
Festplattenlaufwerk
Arithmetische Folge
Virtual Home Environment
Netzbetriebssystem
Mini-Disc
Tropfen
Phasenumwandlung
Softwaretest
Kraftfahrzeugmechatroniker
Graph
Datenhaltung
Inverse
Ruhmasse
Einfache Genauigkeit
Physikalisches System
Frequenz
Transaktionsverwaltung
Rechter Winkel
Festspeicher
Dreiecksfreier Graph
Mereologie
Garbentheorie
Gewicht <Mathematik>
Prozess <Physik>
Punkt
t-Test
Zahlenbereich
Kartesische Koordinaten
ROM <Informatik>
Computeranimation
Eins
Task
Puffer <Netzplantechnik>
Bildschirmmaske
Client
Perspektive
Mini-Disc
Netzbetriebssystem
Delisches Problem
Maßerweiterung
Caching
Softwaretest
Schreiben <Datenverarbeitung>
Parametersystem
Sichtenkonzept
Graph
Datenhaltung
Güte der Anpassung
Zwei
Klassische Physik
Abfrage
Physikalisches System
Datenfluss
Frequenz
Quick-Sort
Rechter Winkel
Festspeicher
Caching
Mereologie
Ablöseblase
Tabelle <Informatik>
Caching
Schreiben <Datenverarbeitung>
Parametersystem
Statistik
Gewicht <Mathematik>
Graph
Physikalisches System
Biprodukt
ROM <Informatik>
Frequenz
Ereignishorizont
Computeranimation
Prozess <Informatik>
Rechter Winkel
Mereologie
Information
Ordnung <Mathematik>
Schnittstelle
Lesen <Datenverarbeitung>
Caching
Parametersystem
Prozess <Physik>
Punkt
Gewicht <Mathematik>
Hardware
Extrempunkt
Physikalisches System
Ungerichteter Graph
Zwölf
Overlay-Netz
Computeranimation
Overloading <Informatik>
Beanspruchung
Transaktionsverwaltung
TUNIS <Programm>
Front-End <Software>
Caching
Hardware
Aggregatzustand
Bit
Punkt
Gewicht <Mathematik>
Zahlenbereich
Oval
Ungerichteter Graph
Computeranimation
Wechselsprung
Client
Mittelwert
Inverser Limes
Caching
Schreiben <Datenverarbeitung>
Parametersystem
Nichtlinearer Operator
Vervollständigung <Mathematik>
Graph
Datenhaltung
Physikalisches System
Bitrate
Frequenz
Quick-Sort
Inverser Limes
Rechenschieber
Scheduling
Transaktionsverwaltung
Last
Rechter Winkel
Caching
Mereologie
Hilfesystem
Vollständigkeit
Charakteristisches Polynom
Bitrate
Aggregatzustand
Reihenfolgeproblem
Punkt
Extrempunkt
Blackbox
Mathematisierung
IRIS-T
Zahlenbereich
Computeranimation
Mini-Disc
Default
Auswahlaxiom
Schnittstelle
Caching
Softwaretest
Parametersystem
Vervollständigung <Mathematik>
Graph
Default
Zwei
Stellenring
Kanalkapazität
Physikalisches System
Bitrate
Quick-Sort
Chipkarte
Scheduling
Beanspruchung
Transaktionsverwaltung
Verkettung <Informatik>
Rechter Winkel
Caching
Festspeicher
Mereologie
Gamecontroller
Vollständigkeit
Kernel <Informatik>
Prozess <Physik>
Punkt
Schreiben <Datenverarbeitung>
Extrempunkt
ROM <Informatik>
Computeranimation
Datenhaltung
Metropolitan area network
Last
Ordnungsreduktion
Gruppoid
Maßerweiterung
Ideal <Mathematik>
Transaktionsverwaltung
Caching
Parametersystem
Horizontale
Warteschlange
Patch <Software>
Caching
Client
Vollständigkeit
Computerunterstützte Übersetzung
Mini-Disc
Bitrate
Caching
Schreiben <Datenverarbeitung>
Nichtlinearer Operator
Kraftfahrzeugmechatroniker
Gerichtete Menge
Punkt
Zwei
Zahlenbereich
Zellularer Automat
Physikalisches System
Ungerichteter Graph
ROM <Informatik>
Computeranimation
Warteschlange
Scheduling
Informationsmodellierung
Rechter Winkel
Netzbetriebssystem
Festspeicher
Caching
Gruppoid
Horizontale
Mini-Disc
Ideal <Mathematik>
Hilfesystem
Punkt
Automatische Handlungsplanung
Zahlenbereich
Element <Mathematik>
Extrempunkt
Term
ROM <Informatik>
Computeranimation
Datenhaltung
Metropolitan area network
Last
Client
Mini-Disc
Warteschlange
Speicher <Informatik>
Transaktionsverwaltung
Gerade
Caching
Ruhmasse
Kanalkapazität
Physikalisches System
Bitrate
Frequenz
Beanspruchung
Transaktionsverwaltung
Ablöseblase
Client
Datenspeicherung
In-Memory-Datenbank
Information
Mini-Disc
Bitrate
Freeware
Computeranimation
Kernel <Informatik>
Task
Festplattenlaufwerk
Reelle Zahl
Perspektive
Mittelwert
Mini-Disc
Minimum
Randomisierung
Zusammenhängender Graph
Warteschlange
Speicher <Informatik>
Einflussgröße
Hilfesystem
Nichtlinearer Operator
Bruchrechnung
Physikalischer Effekt
Datenhaltung
Physikalisches System
p-Block
Arithmetisches Mittel
Transaktionsverwaltung
Rechter Winkel
Caching
Mereologie
Mittelwert
Retrievalsprache
Gewichtete Summe
Content <Internet>
Extrempunkt
Bildschirmfenster
ROM <Informatik>
Computeranimation
Datenhaltung
TUNIS <Programm>
Metropolitan area network
Last
Softwaretest
Transaktionsverwaltung
Modallogik
Tabelle <Informatik>
Caching
Schreiben <Datenverarbeitung>
URN
Elektronische Publikation
Teilbarkeit
Datentyp
Graph
Datenlogger
Applet
Sichtenkonzept
Speicherbereichsnetzwerk
Einfache Genauigkeit
Gesetz <Physik>
Inverser Limes
Portscanner
Thread
Touchscreen
Zahlenbereich
ATM
Client
Datenspeicherung
Laufwerk <Datentechnik>
Hilfesystem
Bildschirmsymbol
Vollständigkeit
Bitrate
Beweistheorie
Caching
Mittelwert
Retrievalsprache
Datentyp
Teilbarkeit
Gewichtete Summe
Versionsverwaltung
Ausnahmebehandlung
Extrempunkt
Computeranimation
Rechenschieber
Puffer <Netzplantechnik>
Puffer <Netzplantechnik>
Flächeninhalt
Thread
Rechter Winkel
Zahlenbereich
ATM
Client
Mini-Disc
Speicher <Informatik>
Bitrate
Transaktionsverwaltung
Resultante
Kernel <Informatik>
Bit
Web Site
Prozess <Physik>
Mathematische Logik
Computeranimation
Übergang
Ordnungsreduktion
Beamer
Caching
Matching <Graphentheorie>
Datenhaltung
Zwei
Physikalisches System
Kontextbezogenes System
Bitrate
Quick-Sort
Warteschlange
Rechenschieber
Scheduling
Transaktionsverwaltung
Puffer <Netzplantechnik>
Rechter Winkel
Festspeicher
Caching
Mereologie
Mini-Disc

Metadaten

Formale Metadaten

Titel Balancing Database Storage Latency And Throughput
Untertitel PostgreSQL for Secure Enterprises
Serientitel PGCon 2014
Anzahl der Teile 31
Autor Smith, Greg
Mitwirkende Crunchy Data Solutions (Support)
Lizenz CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
DOI 10.5446/19074
Herausgeber PGCon - PostgreSQL Conference for Users and Developers, Andrea Ross
Erscheinungsjahr 2014
Sprache Englisch
Produktionsort Ottawa, Canada

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract by Greg Smith The easiest type of benchmark to run on a database is checking its throughput: the total transactions processed during some period of time. But throughput isn't what application users care about. They want low latency. Latency and throughput have a complex dependency on each other, and you'll need a whole new type of test to balance them well. Recent advances in benchmarking tools, like the rate limit in pgbench 9.4, make it possible to analyze latency in a way that highlights this difficult to see area. The graphics and reports of the pgbench-tools package make it possible to see how tuning changes impact both latency and throughput. That that lets you test the "lore" for how best to tune your PostgreSQL server to find out what really works. Using these new tools, this talk will look at the tricky correlation between throughput and latency and how to measure each usefully in common situations. We'll look at three different storage stacks with very different latency profiles: regular disk, disk with battery-backed write cache, and SSD. We'll then look at exactly how checkpoint spikes play out on each and what you can do about them. You'll never trust a simple transactions per second count again!

Ähnliche Filme

Loading...