Re: UPDATEDs slowing SELECTs in a fully cached database
От | Ivan Voras |
---|---|
Тема | Re: UPDATEDs slowing SELECTs in a fully cached database |
Дата | |
Msg-id | ivhhr6$rin$1@dough.gmane.org обсуждение исходный текст |
Ответ на | UPDATEDs slowing SELECTs in a fully cached database (lars <lhofhansl@yahoo.com>) |
Ответы |
Re: UPDATEDs slowing SELECTs in a fully cached database
|
Список | pgsql-performance |
On 08/07/2011 01:56, lars wrote: > Setup: > PostgreSQL 9.1beta2 on a high memory (~68gb, 12 cores) EC2 Linux > instance (kernel 2.6.35) with the database and > WAL residing on the same EBS volume with EXT4 (data=ordered, barriers=1) > - yes that is not an ideal setup > (WAL should be on separate drive, EBS is slow to begin, etc), but I am > mostly interested in read performance for a fully cached database. I know you said you know these things - but do you really know the (huge) extent to which all your IO is slowed? Even context switches in a virtualized environment are slowed down by a huge margin - which would make practically all in-memory lock operations very slow - much slower than they would be on "real" hardware, and EBS by definition is even slower then regular private virtual storage environments. I regrettably didn't bookmark the page which did exact measurements of EBS, but http://www.google.com/search?q=how+slow+is+ec2 will illustrate my point. (of course, you may already know all this :) ).
В списке pgsql-performance по дате отправления: