Re: How to improve db performance with $7K?
От | Mohan, Ross |
---|---|
Тема | Re: How to improve db performance with $7K? |
Дата | |
Msg-id | CC74E7E10A8A054798B6611BD1FEF4D30625DA61@vamail01.thexchange.com обсуждение исходный текст |
Ответ на | How to improve db performance with $7K? (Steve Poe <spoe@sfnet.cc>) |
Список | pgsql-performance |
Greg, et al. I never found any evidence of a "stop and get an intermediate request" functionality in the TCQ protocol. IIRC, what is there is 1) Ordered 2) Head First 3) Simple implemented as choices. *VERY* roughly, that'd be like (1) disk subsystem satisfies requests as submitted, (2) let's the "this" request be put at the very head of the per se disk queue after the currently-running disk request is complete, and (3) is "let the per se disk and it's software reorder the requests on-hand as per it's onboard software". (N.B. in the last, it's the DISK not the controller making those decisions). (N.B. too, that this last is essentially what NCQ (cf. TCQ) is doing ) I know we've been batting around a hypothetical case of SCSI where it "stops and gets smth. on the way", but I can find no proof (yet) that this is done, pro forma, by SCSI drives. In other words, SCSI is a necessary, but not sufficient cause for intermediate reading. FWIW - Ross -----Original Message----- From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Greg Stark Sent: Friday, April 15, 2005 2:02 PM To: Tom Lane Cc: Kevin Brown; pgsql-performance@postgresql.org Subject: Re: [PERFORM] How to improve db performance with $7K? Tom Lane <tgl@sss.pgh.pa.us> writes: > Yes, you can probably assume that blocks with far-apart numbers are > going to require a big seek, and you might even be right in supposing > that a block with an intermediate number should be read on the way. > But you have no hope at all of making the right decisions at a more > local level --- say, reading various sectors within the same cylinder > in an optimal fashion. You don't know where the track boundaries are, > so you can't schedule in a way that minimizes rotational latency. > You're best off to throw all the requests at the drive together and > let the drive sort it out. Consider for example three reads, one at the beginning of the disk, one at the very end, and one in the middle. If the threeare performed in the logical order (assuming the head starts at the beginning), then the drive has to seek, say, 4msto get to the middle and 4ms to get to the end. But if the middle block requires a full rotation to reach it from when the head arrives that adds another 8ms of rotationaldelay (assuming a 7200RPM drive). Whereas the drive could have seeked over to the last block, then seeked back in 8ms and gotten there just in time to performthe read for free. I'm not entirely convinced this explains all of the SCSI drives' superior performance though. The above is about a worst-casescenario. should really only have a small effect, and it's not like the drive firmware can really schedule thingsperfectly either. I think most of the difference is that the drive manufacturers just don't package their high end drives with ATA interfaces.So there are no 10k RPM ATA drives and no 15k RPM ATA drives. I think WD is making fast SATA drives but most ofthe manufacturers aren't even doing that. -- greg ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
В списке pgsql-performance по дате отправления: