Ypu wouldn't get an increasing running two instances on the same server.
Distributed database severs is a complex application and tuning it will
depend on storage and CPU capacity. It could be as simple as a bus. Are you
running this locally or on the cloud? Are you running this on a distributed
fi
Clearly, I have only supplied half of the information there. I'm really sorry
about that. The TPS measurement of the application does in no way correspond to
the TPS of Postgres.
They are measured completely different but it's the measure we actually are
interested in - as we want to assess the
Em qua., 20 de abr. de 2022 às 12:16, Sbob
escreveu:
>
> On 4/19/22 22:17, Jeff Janes wrote:
>
> On Tue, Apr 19, 2022 at 5:00 PM Sbob wrote:
>
>>
>> However if we move the file to another server in the same network and
>> run with a psql -h then it runs for more than 10min.
>
>
> What is the pin
On Wed, Apr 20, 2022 at 5:13 AM wrote:
>
> The next thing I did was starting two independent Postgres instances on
> the same server and run independent client applications against each of
> them. This resulted in our application getting almost double of the TPS
> compared to running a single ins
On 4/19/22 22:17, Jeff Janes wrote:
On Tue, Apr 19, 2022 at 5:00 PM Sbob wrote:
However if we move the file to another server in the same network and
run with a psql -h then it runs for more than 10min.
What is the ping time? Packet loss? You can't take for granted that
the networ
Hi, thanks for your answer.
We have a Grafana instance monitoring all those metrics, no one I asked so far
could identify an obvious bottleneck.
However, I have done further experiments to see if we are missing something.
While running the benchmark with our application I've run tools on the
DB
