Re: Same query taking less time in low configuration machine

Поиск
Список
Период
Сортировка
От Vishwa Kalyankar
Тема Re: Same query taking less time in low configuration machine
Дата
Msg-id CAFWaVn1WH8+Prz0dsUQYVC=YNXEOofhkHKq-tGx0NUmxL8=oaw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Same query taking less time in low configuration machine  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-performance
Hi Justin,

    I am pasting once again the output of low end server , explain result and shared_buffer size of high end machine.

-bash-4.2$ psql -p 5422
psql (12.3)
Type "help" for help.

postgres=# \c IPDS_KSEB;
You are now connected to database "IPDS_KSEB" as user "postgres".
IPDS_KSEB=# set track_io_timing TO on;
SET
IPDS_KSEB=# explain (analyze,buffers, settings) select * from kseb_geometry_trace_with_barrier_partition(5,'kottarakara_version',437,'htline',2) ;
                                                                       QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------
 Function Scan on kseb_geometry_trace_with_barrier_partition  (cost=0.25..10.25 rows=1000 width=169) (actual time=22762.767..22762.800 rows=389 loops=1)
   Buffers: shared hit=775445 read=2371
   I/O Timings: read=1061.060
 Settings: search_path = '"$user", public, topology'
 Planning Time: 0.091 ms
 Execution Time: 22781.896 ms
(6 rows)

#------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------

# - Memory -

shared_buffers = 10GB                   # min 128kB
                                        # (change requires restart)
#huge_pages = try                       # on, off, or try
                                        # (change requires restart)
#temp_buffers = 8MB                     # min 800kB
#max_prepared_transactions = 0          # zero disables the feature
                                        # (change requires restart)
# Caution: it is not advisable to set max_prepared_transactions nonzero unless
# you actively intend to use prepared transactions.
work_mem = 10MB                         # min 64kB
maintenance_work_mem = 2GB              # min 1MB
#autovacuum_work_mem = -1               # min 1MB, or -1 to use maintenance_work_mem
#max_stack_depth = 2MB                  # min 100kB
#shared_memory_type = mmap              # the default is the first option
                                        # supported by the operating system:
                                        #   mmap
                                        #   sysv
                                        #   windows
                                        # (change requires restart)
dynamic_shared_memory_type = posix      # the default is the first option
                                        # supported by the operating system:
                                        #   posix



On Thu, Jul 16, 2020 at 10:33 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
On Thu, Jul 16, 2020 at 09:13:45PM +0530, Vishwa Kalyankar wrote:
> I have two machines - one with 8GB RAM & 4core CPU and the other with 64GB
> Ram & 24 core CPU.  Both machines have the same DB (Postgres 12 + Postgis

It looks like they're returning different number of rows, so definitely not the
same DB.

Also, they're performing about the same now...

It looks like you didn't set shared_buffers, even for a machine with 64GB RAM.
I think it's unusual to keep the default.

On Thu, Jul 16, 2020 at 10:21:35PM +0530, Vishwa Kalyankar wrote:
> Both the db's configurations are not same, I have tuned the db in both
> machines according to https://pgtune.leopard.in.ua/#/

It looks like your low-end machine has no settings at all ?
Did you forget to restart the server or use SET instead of ALTER SYSTEM SET ?

> IPDS_KSEB=# set track_io_timing TO on;
> IPDS_KSEB=# explain (analyze,buffers, settings) select * from kseb_geometry_trace_with_barrier_partition(5,'kottarakara_version',437,'htline',2);
>
>  Function Scan on kseb_geometry_trace_with_barrier_partition
>  (cost=0.25..10.25 rows=1000 width=169) (actual time=24708.020..24708.048 rows=254 loops=1)
>    Buffers: shared hit=254235 read=1484
>    I/O Timings: read=827.509
>  Settings: effective_cache_size = '30GB', effective_io_concurrency = '2', max_parallel_workers = '24', max_parallel_workers_per_gather = '4', search_path = '"$user", public, topology', work_mem = '10MB'
>  Planning Time: 0.064 ms
>  Execution Time: 24772.587 ms
>
> Low End Machine
> IPDS_KSEB=# explain (analyze,buffers, settings) select * from kseb_geometry_trace_with_barrier_partition(5,'kottarakara_version',437,'htline',2) ;
>  Function Scan on kseb_geometry_trace_with_barrier_partition  (cost=0.25..10.25 rows=1000 width=169) (actual time=21870.311..21870.344 rows=389 loops=1)
>    Buffers: shared hit=774945
>  Settings: search_path = '"$user", public, topology'
>  Planning Time: 0.089 ms
>  Execution Time: 21870.406 ms

В списке pgsql-performance по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Same query taking less time in low configuration machine
Следующее
От: Julian Wolf
Дата:
Сообщение: Too few rows expected by Planner on partitioned tables