I noticed that the recent round of tests being discussed never
mentioned the file system used. Was it XFS? Does changing the
agcount change the behaviour?
It was ext4.
Regards,
Vitaliy
On Thu, Feb 8, 2018 at 11:40 AM, Vitaliy Garnashevich <
vgarnashev...@gmail.com> wrote:
> Anyway, there are still some strange things happening when
> effective_io_concurrency is non-zero.
>
> ...
>
> Vitaliy
>
>
I was researching whether I could optimize a concatenated lvm2 volume when
I have d
On Wed, Jan 31, 2018 at 04:34:18PM -0300, Claudio Freire wrote:
> In my experience playing with prefetch, e_i_c>0 interferes with kernel
> read-ahead. What you've got there would make sense if what postgres
> thinks will be random I/O ends up being sequential. With e_i_c=0, the
> kernel will optimi
On Mon, Feb 5, 2018 at 8:26 AM, Vitaliy Garnashevich
wrote:
>> I mean, that the issue is indeed affected by the order of rows in the
>> table. Random heap access patterns result in sparse bitmap heap scans,
>> whereas less random heap access patterns result in denser bitmap heap
>> scans. Dense sc
I mean, that the issue is indeed affected by the order of rows in the
table. Random heap access patterns result in sparse bitmap heap scans,
whereas less random heap access patterns result in denser bitmap heap
scans. Dense scans have large portions of contiguous fetches, a
pattern that is quite a
On Sat, Feb 3, 2018 at 8:05 PM, Vitaliy Garnashevich
wrote:
> Looks like this behavior is not caused by, and does not depend on:
> - variable performance in the cloud
> - order of rows in the table
> - whether the disk is EBS (backed by SSD or HDD), or ordinary SSD
> - kernel version
>
> Does this
I did some more tests. I've made an SQL dump of the table. Then used
head/tail commands to cut the data part. Then used shuf command to
shuffle rows, and then joined the pieces back and restored the table
back into DB.
Before:
select array_agg(aid) from (select aid from pgbench_accounts order
On Wed, Jan 31, 2018 at 11:21 PM, hzzhangjiazhi
wrote:
> HI
>
> I think this parameter will be usefull when the storage using RAID
> stripe , otherwise turn up this parameter is meaningless when only has one
> device。
Not at all. Especially on EBS, where keeping a relatively full queue
is ne
HI I think this parameter will be usefull when the storage using RAID stripe , otherwise turn up this parameter is meaningless when only has one device。
发自网易邮箱大师
On 2/1/2018 04:29，Vitaliy Garnashevich wrote：
On Wed, Jan 31, 2018 at 4:03 AM, Vitaliy Garnashevich <
vgarnashev...@gmail.com> wrote:
>
> The results look really confusing to me in two ways. The first one is that
> I've seen recommendations to set effective_io_concurrency=256 (or more) on
> EBS.
I would not expect this to make much of a dif
I've done some more tests. Here they are all:
io1, 100 GB SSD, 1000 IOPS
effective_io_concurrency=0 Execution time: 40333.626 ms
effective_io_concurrency=1 Execution time: 163840.500 ms
effective_io_concurrency=2 Execution time: 162606.330 ms
effective_io_concurrency=4 Execution time: 163670.405
On Wed, Jan 31, 2018 at 1:57 PM, Vitaliy Garnashevich
wrote:
> More tests:
>
> io1, 100 GB:
>
> effective_io_concurrency=0
> Execution time: 40333.626 ms
> effective_io_concurrency=1
> Execution time: 163840.500 ms
In my experience playing with prefetch, e_i_c>0 interferes with kernel
read-ahea
More tests:
io1, 100 GB:
effective_io_concurrency=0
Execution time: 40333.626 ms
effective_io_concurrency=1
Execution time: 163840.500 ms
effective_io_concurrency=2
Execution time: 162606.330 ms
effective_io_concurrency=4
Execution time: 163670.405 ms
effective_io_concurrency=8
Execution ti
> I've tried to re-run the test for some specific values of
> effective_io_concurrency. The results were the same.
> That's why I don't think the order of tests or variability in "hardware"
> performance affected the results.
We run many MS SQL server VMs in AWS with more than adequ
2018-01-31 14:15 GMT+01:00 Vitaliy Garnashevich :
> I've tried to re-run the test for some specific values of
> effective_io_concurrency. The results were the same.
>
> That's why I don't think the order of tests or variability in "hardware"
> performance affected the results.
>
AWS uses some int
I've tried to re-run the test for some specific values of
effective_io_concurrency. The results were the same.
That's why I don't think the order of tests or variability in "hardware"
performance affected the results.
Regards,
Vitaliy
On 31/01/2018 15:01, Rick Otten wrote:
We moved our stuff
We moved our stuff out of AWS a little over a year ago because the
performance was crazy inconsistent and unpredictable. I think they do a
lot of oversubscribing so you get strange sawtooth performance patterns
depending on who else is sharing your infrastructure and what they are
doing at the tim
Hi,
I've tried to run a benchmark, similar to this one:
https://www.postgresql.org/message-id/flat/CAHyXU0yiVvfQAnR9cyH%3DHWh1WbLRsioe%3DmzRJTHwtr%3D2azsTdQ%40mail.gmail.com#CAHyXU0yiVvfQAnR9cyH=HWh1WbLRsioe=mzRJTHwtr=2azs...@mail.gmail.com
CREATE TABLESPACE test OWNER postgres LOCATION '/path/
18 matches
Mail list logo
