On Wed, Jul 1, 2020 at 11:41:23PM +0530, Nikhil Shetty wrote:
> Hi,
>
> The client has done benchmark tests on available storage using a storage
> benchmark tool and got IOPS of around 14k on iSCSI and around 150k on HBA
> channel, which seems a good number but pg_test_fysnc gives numbers which
Hi,
The client has done benchmark tests on available storage using a storage
benchmark tool and got IOPS of around 14k on iSCSI and around 150k on HBA
channel, which seems a good number but pg_test_fysnc gives numbers which
are not reflecting good op/sec. Though pg_test_fysnc result should not be
Hi Haroldo,
Thank you for the details.
We are using xfs on IBM Power Linux Rhel7 but I will check this in our
environment and get back to you with the results.
Thanks and Regards,
Nikhil
On Wed, Jul 1, 2020, 22:46 Haroldo Kerry wrote:
> Hello Nikhil,
> We had performance issues with our Dell
Hello Nikhil,
We had performance issues with our Dell SC2020 storage in the past. We had
a 6 SSD RAID10 setup and due all the latencies expected 20K IOPS but were
getting 2K...
After *a lot* of work the issue was not with the storage itself but with
the I/O scheduler of the filesystem (EXT4/Debian
Hi Jeff,
To avoid confusion, Hitachi Storage G900 has 41Gbps Performance bandwidth
(Throughput) and 10Gbps N/W bandwidth.
Thanks and Regards,
Nikhil
On Wed, Jul 1, 2020 at 10:36 PM Nikhil Shetty
wrote:
> Hi Jeff,
>
> Thank you for your inputs. We may stick with fdatasync for now. We will
> get
Hi Jeff,
Thank you for your inputs. We may stick with fdatasync for now. We will get
more details on connection details between SAN and server from the storage
team and update this thread.
Storage is Hitachi G900 with 41Gbps bandwidth.
Thanks and regards,
Nikhil
On Tue, Jun 30, 2020 at 9:51 P
Hi Bruce,
Thank you. We may stick with fdatasync for now.
Thanks and regards,
Nikhil
On Tue, Jun 30, 2020 at 8:54 PM Bruce Momjian wrote:
> On Tue, Jun 30, 2020 at 10:32:13AM +0530, Nikhil Shetty wrote:
> > Hi Bruce,
> >
> > Based on pg_test_fsync results, should we choose open_datasync or
> f
On Tue, Jun 30, 2020 at 1:02 AM Nikhil Shetty
wrote:
> Hi Bruce,
>
> Based on pg_test_fsync results, should we choose open_datasync or
> fdatasync as wal_sync_method? Can we rely on pg_test_fsync for choosing the
> best wal_sync_method or is there any other way?
>
Probably the default of fdatasy
On Mon, Jun 29, 2020 at 5:27 AM Nikhil Shetty
wrote:
> Hi Team,
>
> We have a PostgreSQL 11.5.6 database running on VM.
> RAM - 48GB
> CPU - 6 cores
> Disk - SSD on SAN
>
> We wanted to check how the WAL disk is performing using pg_test_fsync.We
> ran a test and got around 870 ops/sec for opendat
On Tue, Jun 30, 2020 at 10:32:13AM +0530, Nikhil Shetty wrote:
> Hi Bruce,
>
> Based on pg_test_fsync results, should we choose open_datasync or fdatasync as
> wal_sync_method? Can we rely on pg_test_fsync for choosing the best
I would just pick the fastest method, but if the method is _too_ fast
Hi Bruce,
Based on pg_test_fsync results, should we choose open_datasync or fdatasync
as wal_sync_method? Can we rely on pg_test_fsync for choosing the best
wal_sync_method or is there any other way?
Thanks and Regards,
Nikhil
On Mon, Jun 29, 2020 at 9:36 PM Bruce Momjian wrote:
> On Mon, Jun
On Mon, Jun 29, 2020 at 02:56:42PM +0530, Nikhil Shetty wrote:
> Hi Team,
>
> We have a PostgreSQL 11.5.6 database running on VM.
> RAM - 48GB
> CPU - 6 cores
> Disk - SSD on SAN
>
> We wanted to check how the WAL disk is performing using pg_test_fsync.We ran a
> test and got around 870 ops/sec
Hi Team,
We have a PostgreSQL 11.5.6 database running on VM.
RAM - 48GB
CPU - 6 cores
Disk - SSD on SAN
We wanted to check how the WAL disk is performing using pg_test_fsync.We
ran a test and got around 870 ops/sec for opendatasync and fdatasync and
just 430 ops/sec for fsync.We feel it is quite
13 matches
Mail list logo
