powered by simpleCommunicator - 2.0.40     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Непостоянное время выполнения запроса - всегда разное
40 сообщений из 40, показаны все 2 страниц
Непостоянное время выполнения запроса - всегда разное
    #40088217
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть несложный запрос с группировкой данных

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select 
		rq.endpoint_id,
		rq.is_provider_response,
		rq.namespace
		--count(*) as rq_count,
		--count(*) filter (where rq.is_response_exists) as res_count
	from requests rq
	where --(rq.reccreated >= _dateFrom AND rq.reccreated < _dateTo)
			(rq.reccreated >= '2021-05-01' AND rq.reccreated < '2021-06-01')
		AND (rq.is_provider_response = false)
	group by rq.endpoint_id, rq.is_provider_response, rq.namespace;



Я хочу получить стабильное время работы данный выборки, но не получается. Каждый раз когда я меняю диапазон дат (например хочу другой месяц) запрос выполняется очень медленно - например это время сравнимо с 3-4 минутами. Если не менять даты и запускать запрос несколько раз с одними и теми же датами, то время выполнения измеряется секундами.

Я новичёк в PG - мне не понятно почему так происходит.

План выполнения запроса прилагаю
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088218
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron
Есть несложный запрос с группировкой данных

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select 
		rq.endpoint_id,
		rq.is_provider_response,
		rq.namespace
		--count(*) as rq_count,
		--count(*) filter (where rq.is_response_exists) as res_count
	from requests rq
	where --(rq.reccreated >= _dateFrom AND rq.reccreated < _dateTo)
			(rq.reccreated >= '2021-05-01' AND rq.reccreated < '2021-06-01')
		AND (rq.is_provider_response = false)
	group by rq.endpoint_id, rq.is_provider_response, rq.namespace;



Я хочу получить стабильное время работы данный выборки, но не получается. Каждый раз когда я меняю диапазон дат (например хочу другой месяц) запрос выполняется очень медленно - например это время сравнимо с 3-4 минутами. Если не менять даты и запускать запрос несколько раз с одними и теми же датами, то время выполнения измеряется секундами.

Я новичёк в PG - мне не понятно почему так происходит.

План выполнения запроса прилагаю

Код: sql
1.
explain(analyze,buffers,timing)


и не в виде скриншотов, а консольный вывод пжлста
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088219
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Используемый в плане индекс ix_requests_reccreated создан по полю reccreated
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088221
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mefman
и не в виде скриншотов, а консольный вывод пжлста


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
QUERY PLAN
Group  (cost=696378.15..696467.75 rows=2240 width=69) (actual time=7571.077..7571.148 rows=106 loops=1)
  Group Key: endpoint_id, is_provider_response, namespace
  Buffers: shared hit=2268904 read=140449 written=1
  ->  Sort  (cost=696378.15..696400.55 rows=8960 width=69) (actual time=7571.076..7571.095 rows=440 loops=1)
        Sort Key: endpoint_id, is_provider_response, namespace
        Sort Method: quicksort  Memory: 86kB
        Buffers: shared hit=2268904 read=140449 written=1
        ->  Gather  (cost=694871.56..695789.96 rows=8960 width=69) (actual time=7570.435..7682.402 rows=440 loops=1)
              Workers Planned: 4
              Workers Launched: 4
              Buffers: shared hit=2268904 read=140449 written=1
              ->  Partial HashAggregate  (cost=693871.56..693893.96 rows=2240 width=69) (actual time=7565.460..7565.491 rows=88 loops=5)
                    Group Key: endpoint_id, is_provider_response, namespace
                    Buffers: shared hit=2268904 read=140449 written=1
                    ->  Parallel Index Scan using ix_requests_reccreated on rsmev___requests rq  (cost=0.43..689137.14 rows=631256 width=69) (actual time=0.077..7436.615 rows=521397 loops=5)
                          Index Cond: ((reccreated >= '2021-05-01 00:00:00'::timestamp without time zone) AND (reccreated < '2021-05-20 00:00:00'::timestamp without time zone))
                          Filter: (NOT is_provider_response)
                          Rows Removed by Filter: 9441
                          Buffers: shared hit=2268904 read=140449 written=1
Planning time: 0.174 ms
Execution time: 7683.077 ms
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088234
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Поменял даты на месяц пораньше - запустил опять, результат ждал десяток минут... ((

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
QUERY PLAN
Group  (cost=450162.82..450252.42 rows=2240 width=69) (actual time=132516.481..132516.557 rows=122 loops=1)
  Group Key: endpoint_id, is_provider_response, namespace
  Buffers: shared hit=1325536 read=306916 dirtied=1 written=16
  ->  Sort  (cost=450162.82..450185.22 rows=8960 width=69) (actual time=132516.479..132516.500 rows=470 loops=1)
        Sort Key: endpoint_id, is_provider_response, namespace
        Sort Method: quicksort  Memory: 91kB
        Buffers: shared hit=1325536 read=306916 dirtied=1 written=16
        ->  Gather  (cost=448656.23..449574.63 rows=8960 width=69) (actual time=132515.795..132578.981 rows=470 loops=1)
              Workers Planned: 4
              Workers Launched: 4
              Buffers: shared hit=1325536 read=306916 dirtied=1 written=16
              ->  Partial HashAggregate  (cost=447656.23..447678.63 rows=2240 width=69) (actual time=132264.791..132264.820 rows=94 loops=5)
                    Group Key: endpoint_id, is_provider_response, namespace
                    Buffers: shared hit=1325536 read=306916 dirtied=1 written=16
                    ->  Parallel Index Scan using ix_requests_reccreated on rsmev___requests rq  (cost=0.43..444660.44 rows=399439 width=69) (actual time=106.856..132155.959 rows=308630 loops=5)
                          Index Cond: ((reccreated >= '2021-04-01 00:00:00'::timestamp without time zone) AND (reccreated < '2021-05-01 00:00:00'::timestamp without time zone))
                          Filter: (NOT is_provider_response)
                          Rows Removed by Filter: 22535
                          Buffers: shared hit=1325536 read=306916 dirtied=1 written=16
Planning time: 0.139 ms
Execution time: 132579.696 ms
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088235
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
balykovdron

Planning time: 0.139 ms
Execution time: 132579.696 ms


Я вижу, что сильно отличается время плана и факта, но что дальше делать и куда копать - не предположу.


Табличка высоконагруженная и работа с ней реальными пользователями не останавливается ни на секунду. Что можете предложить в данной ситуации?
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088251
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron

Табличка высоконагруженная

автовакуум настраивали?
и вообще настройки в БД меняли какие-либо?
или все по-дефолту?
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088258
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mefman
balykovdron

Табличка высоконагруженная

автовакуум настраивали?
и вообще настройки в БД меняли какие-либо?
или все по-дефолту?

ЛОЛ. и зачем вам group если вы закомментировали каунты?
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088269
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Видимо у Вас очень "дорогое" чтение с диска

Я так понимаю, это время после нескольких запусков, т.е. у Вас прогрелся кэш и читать с диска надо меньше
Код: sql
1.
2.
3.
4.
(actual time=0.077..7436.615 rows=521397 loops=5)

Rows Removed by Filter: 9441
Buffers: shared hit=2268904 read=140449 written=1




А это первый запуск после смены периода, холодный кэш, приходиться читать больше
Код: sql
1.
2.
3.
4.
(actual time=106.856..132155.959 rows=308630 loops=5)

Rows Removed by Filter: 22535
Buffers: shared hit=1325536 read=306916 dirtied=1 written=16
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088270
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mefman

ЛОЛ. и зачем вам group если вы закомментировали каунты?


Т.к. я разбираюсь с этим запросом - решил методо исключения его упрощать, поэтому закомментировано.

Админ сервака, говорит, что автовакуум настроен. А вот на сколько он эффективен? Как можно глянуть?

И скорее всего большинство настроек сервера настроены по-умолчанию.
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088272
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Кстати, сколько у Вас ОЗУ и shared_buffers ?
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088279
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Guzya
Кстати, сколько у Вас ОЗУ и shared_buffers ?


ОЗУ 24Гб, shared_buffers = 4GB
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088281
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mefman

автовакуум настраивали?


автовакуум настроен также по-умолчанию - админ его просто включил и всё, ничего не настраивая...

А как можно проверить - он ввобще что-то делает? На сколько он эффективен?
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088282
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Guzya
Видимо у Вас очень "дорогое" чтение с диска


Похоже на то - а что теперь дальше с этим делать? Как "удешевлять"? :-)
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088284
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
balykovdron,

Удешевлять, наверное, только заменой дисков.

По поводу запроса, возможно Вам стоит посмотреть в сторону создания материализованного представления с рефрешем (например раз в день).
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088289
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron
mefman

автовакуум настраивали?


автовакуум настроен также по-умолчанию - админ его просто включил и всё, ничего не настраивая...

А как можно проверить - он ввобще что-то делает? На сколько он эффективен?

сделать запрос в БД на соответствующие параметры.
Код: sql
1.
show xxx
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088326
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А вот вообще ахтунг - этот же запрос на другом сервере, этаже таблица, с такимже индексом показывает совершенно другой план запроса! Это как вообще?!

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
QUERY PLAN
HashAggregate  (cost=161256.62..161273.56 rows=1694 width=63) (actual time=713.668..713.762 rows=88 loops=1)
  Group Key: endpoint_id, is_provider_response, namespace
  Buffers: shared hit=192889
  ->  Index Scan using ix_requests_reccreated on rsmev___requests rq  (cost=0.43..159721.99 rows=204618 width=63) (actual time=0.016..414.557 rows=202476 loops=1)
        Index Cond: ((reccreated >= '2021-07-01 00:00:00'::timestamp without time zone) AND (reccreated < '2021-08-01 00:00:00'::timestamp without time zone))
        Filter: (NOT is_provider_response)
        Rows Removed by Filter: 5875
        Buffers: shared hit=192889
Planning time: 0.344 ms
Execution time: 713.984 ms



Этот план больше похож на то, чего ждут от запроса, и вопрос, а почему на другом сервере он не такой? И как исправить ситуацию там?
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088330
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron
этаже таблица, с такимже индексом

balykovdron
Buffers: shared hit=192889

против
balykovdron
Buffers: shared hit=2268904 read=140449

Всего-то на порядок больше данных, почему бы и работать не на порядок дольше? Фигня какая, действительно.
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088334
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mefman

show xxx
[/src]


namesettingunitautovacuumonNULLautovacuum_analyze_scale_factor0.1NULLautovacuum_analyze_threshold50NULLautovacuum_freeze_max_age200000000NULLautovacuum_max_workers3NULLautovacuum_multixact_freeze_max_age400000000NULLautovacuum_naptime60sautovacuum_vacuum_cost_delay20msautovacuum_vacuum_cost_limit-1NULLautovacuum_vacuum_scale_factor0.2NULLautovacuum_vacuum_threshold50NULLautovacuum_work_mem-1kBlog_autovacuum_min_duration-1ms
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088408
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron,

Довольно высокое отношение кол-ва прочитанных страниц к извлеченным строкам на проблемном (4.5 к 1)
Попробуйте отключить параллелизацию (set max_parallel_workers to 0, set max_parallel_workers_per_gather to 0) и еще раз выполнить запрос.
Если отношение останется таким же высоким то возможная проблема в блоатинге индекса.
Так же проверьте долгие транзакции на основном сервере (и всех репликах особенно если включен hot_standby_feedback).
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088414
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gav21
balykovdron,

Довольно высокое отношение кол-ва прочитанных страниц к извлеченным строкам на проблемном (4.5 к 1)
Попробуйте отключить параллелизацию (set max_parallel_workers to 0, set max_parallel_workers_per_gather to 0) и еще раз выполнить запрос.
Если отношение останется таким же высоким то возможная проблема в блоатинге индекса.
Так же проверьте долгие транзакции на основном сервере (и всех репликах особенно если включен hot_standby_feedback).

max_parallel_workers отключать не рекомендую, вот а max_parallel_workers_per_gather - да
ну и автовакуум таки не "оттюнен", следовательно возможен блоат и тухлая статистика.
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088484
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
gav21

Если отношение останется таким же высоким то возможная проблема в блоатинге индекса.


А как лечится блоатинг индекса? Если пересозданием, то я так делал - примеры запросов уже после пересоздания индекса
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088500
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Отключил один параметр: set max_parallel_workers_per_gather to 0

Теперь результат запроса на плохом сервере изменился - пропал узел Gather и план запроса стал похожим на план со здорового сервака

Но скорость по-прежнему плохая. Вот план запроса

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
QUERY PLAN
HashAggregate  (cost=482866.38..482888.78 rows=2240 width=85) (actual time=412207.833..412207.870 rows=122 loops=1)
  Group Key: endpoint_id, is_provider_response, namespace
  Buffers: shared hit=1562534 read=69856
  ->  Index Scan using ix_requests_reccreated on rsmev___requests rq  (cost=0.43..462662.28 rows=1616328 width=70) (actual time=0.109..411606.093 rows=1543152 loops=1)
        Index Cond: ((reccreated >= '2021-04-01 00:00:00'::timestamp without time zone) AND (reccreated < '2021-05-01 00:00:00'::timestamp without time zone))
        Filter: (NOT is_provider_response)
        Rows Removed by Filter: 112677
        Buffers: shared hit=1562534 read=69856

Planning time: 0.135 ms
Execution time: 412207.956 ms
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088508
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron,

включите track_io_timing в конфиге
чтобы понимать сколько времени на работу с диском уходит.



--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088509
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
думаю вам скорее всего нужно вместе со своим админом смотреть.
очень сложно лечить по телефону...
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088510
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
тензор- таблица сильно разрежена, рекомендуется произвести очистку с помощью VACUUM [FULL]
- возможно, чтение идет "с середины" индекса
- вероятно, сервер перегружен (CPU/RAM/HDD), или возникли блокировки
посмотрите тут
может что найдете для себя.
но лучше идти к админу и решать вопрос совместно с ним.
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088518
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron,

Скорее всего проблема в перегруженной дисковой системе.
Покажите на всякий случай описание индекса: ix_requests_reccreated
Так же полезно было бы знать на каких ожиданиях проводит запрос в процессе выполнения: колонки pg_stat_activity.wait_event_type, pg_stat_activity.wait_event
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088550
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mefman

посмотрите тут
может что найдете для себя.


Спасибо большое за инструмент!

mefman

таблица сильно разрежена


А вот как оценить этот факт? Я раньше с MS SQL работал - там из инструментов администрирования можно было сразу видеть % разряженнго пространства. Как это сделать в PG? Простым гугленьем - не найду. Нахожу только, что сделайте вакуум фул. И не находится, "а что даст вакуум фул для конкретной таблицы? Сколько там сейчас свободного места?"
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088561
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
gav21

Покажите на всякий случай описание индекса: ix_requests_reccreated


Код: sql
1.
2.
3.
CREATE INDEX ix_requests_reccreated
    ON public.rsmev___requests USING btree
    (reccreated ASC NULLS LAST)




gav21

на каких ожиданиях проводит запрос в процессе выполнения: колонки pg_stat_activity.wait_event_type, pg_stat_activity.wait_event


wait_event_typewait_eventbackend_startxact_startquery_startstate_changebackend_xminIODataFileRead2021-08-04 09:06:11.017858+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.018347+00159454958LWLockbuffer_io2021-08-04 09:06:11.01808+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.018547+00159454958IODataFileRead2021-08-04 09:06:11.018268+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.018736+00159454958IODataFileRead2021-08-04 09:06:11.018561+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.019042+00159454958IODataFileRead2021-08-04 09:01:43.032007+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.015373+00159454958
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088570
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron,

Вакум скорее всего никак кардинально не изменит картины.
Поищите потенциальных потребителей-конкурентов, которые возможно параллельно нагружают ввод-вывод так, что у вас пропускная способность падает до 1-2 Мб в сек (read=69856 Execution time: 412207.956 ms) (тут на всякий случай нужно подтверждение, что бОльшая часть времени действительно была потрачено на операции IO - включите параметр track_io_timing как рекомендовал Максим)

ожидание LWLock/buffer_io - говорит о том, что процесс пытается прочитать страницу с диска, которая уже читается другим процессом.
Вы случай не пытаетесь одновременно в параллель выполнять эти запросы от разных процессов?
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088573
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron
mefman

посмотрите тут
может что найдете для себя.


Спасибо большое за инструмент!

mefman

таблица сильно разрежена


А вот как оценить этот факт? Я раньше с MS SQL работал - там из инструментов администрирования можно было сразу видеть % разряженнго пространства. Как это сделать в PG? Простым гугленьем - не найду. Нахожу только, что сделайте вакуум фул. И не находится, "а что даст вакуум фул для конкретной таблицы? Сколько там сейчас свободного места?"

по поводу разрежённости таблицы - это лишь предположение тензора.
по поводу вакуум(фулл) - лучше общаться с вашим ДБА.
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088579
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron
gav21

Покажите на всякий случай описание индекса: ix_requests_reccreated


Код: sql
1.
2.
3.
CREATE INDEX ix_requests_reccreated
    ON public.rsmev___requests USING btree
    (reccreated ASC NULLS LAST)




gav21

на каких ожиданиях проводит запрос в процессе выполнения: колонки pg_stat_activity.wait_event_type, pg_stat_activity.wait_event


wait_event_typewait_eventbackend_startxact_startquery_startstate_changebackend_xminIODataFileRead2021-08-04 09:06:11.017858+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.018347+00159454958LWLockbuffer_io2021-08-04 09:06:11.01808+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.018547+00159454958IODataFileRead2021-08-04 09:06:11.018268+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.018736+00159454958IODataFileRead2021-08-04 09:06:11.018561+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.019042+00159454958IODataFileRead2021-08-04 09:01:43.032007+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.01537+002021-08-04 09:06:11.015373+00159454958



А у вас на этом сервере есть графики утилизации дисковой систему, r/w IOPS, r/w latency?
Если нет - начните с нормального мониторинга.
У вас всё по скорости в диски упирается.
Лечить или искать кто так диски жестоко нагружает и лечить или ставить дисковую систему быстрее.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088580
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Для поиска "bloat"

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
SELECT
    current_database(), schemaname, tablename, 
    ROUND((CASE WHEN otta=0 THEN 0.0 ELSE sml.relpages::float/otta END)::numeric,1) AS tbloat,
    CASE WHEN relpages < otta THEN 0 ELSE bs*(sml.relpages-otta)::BIGINT END AS wastedbytes,
    iname, 
    ROUND((CASE WHEN iotta=0 OR ipages=0 THEN 0.0 ELSE ipages::float/iotta END)::numeric,1) AS ibloat,
    CASE WHEN ipages < iotta THEN 0 ELSE bs*(ipages-iotta) END AS wastedibytes
  FROM (
    SELECT
      schemaname, tablename, cc.reltuples, cc.relpages, bs,
      CEIL((cc.reltuples*((datahdr+ma-
        (CASE WHEN datahdr%ma=0 THEN ma ELSE datahdr%ma END))+nullhdr2+4))/(bs-20::float)) AS otta,
      COALESCE(c2.relname,'?') AS iname, COALESCE(c2.reltuples,0) AS ituples, COALESCE(c2.relpages,0) AS ipages,
      COALESCE(CEIL((c2.reltuples*(datahdr-12))/(bs-20::float)),0) AS iotta 
    FROM (
      SELECT
        ma,bs,schemaname,tablename,
        (datawidth+(hdr+ma-(case when hdr%ma=0 THEN ma ELSE hdr%ma END)))::numeric AS datahdr,
        (maxfracsum*(nullhdr+ma-(case when nullhdr%ma=0 THEN ma ELSE nullhdr%ma END))) AS nullhdr2
      FROM (
        SELECT
          schemaname, tablename, hdr, ma, bs,
          SUM((1-null_frac)*avg_width) AS datawidth,
          MAX(null_frac) AS maxfracsum,
          hdr+(
            SELECT 1+count(*)/8
            FROM pg_stats s2
            WHERE null_frac<>0 AND s2.schemaname = s.schemaname AND s2.tablename = s.tablename
          ) AS nullhdr
        FROM pg_stats s, (
          SELECT
            (SELECT current_setting('block_size')::numeric) AS bs,
            CASE WHEN substring(v,12,3) IN ('8.0','8.1','8.2') THEN 27 ELSE 23 END AS hdr,
            CASE WHEN v ~ 'mingw32' THEN 8 ELSE 4 END AS ma
          FROM (SELECT version() AS v) AS foo
        ) AS constants
        GROUP BY 1,2,3,4,5
      ) AS foo
    ) AS rs
    JOIN pg_class cc ON cc.relname = rs.tablename
    JOIN pg_namespace nn ON cc.relnamespace = nn.oid AND nn.nspname = rs.schemaname AND nn.nspname <> 'information_schema' AND nn.nspname <> 'pg_catalog'
    LEFT JOIN pg_index i ON indrelid = cc.oid
    LEFT JOIN pg_class c2 ON c2.oid = i.indexrelid
  ) AS sml
ORDER BY wastedbytes DESC;
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088586
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Guzya,

Оно такого насчитать может что не рады будете.
Единственный рабочий метод анализа bloat это pgstattuple расширение.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088616
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Boguk
Guzya,

Оно такого насчитать может что не рады будете.
Единственный рабочий метод анализа bloat это pgstattuple расширение.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru


Это если прям точно-точно надо, при этом надо поставить расширение и при подсчете проверяются все страницы таблицы(полный проход).
А этот скрипт делает прикидочную оценку, после которого уже можно переходить к более точным и более "тяжелым" подсчетам.
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088646
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk

А у вас на этом сервере есть графики утилизации дисковой систему, r/w IOPS, r/w latency?
Если нет - начните с нормального мониторинга.
У вас всё по скорости в диски упирается.
Лечить или искать кто так диски жестоко нагружает и лечить или ставить дисковую систему быстрее.

Короче, ТСу прямая дорога к его ОПСам.
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088654
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Boguk

А у вас на этом сервере есть графики утилизации дисковой систему, r/w IOPS, r/w latency?
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088659
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron
Maxim Boguk

А у вас на этом сервере есть графики утилизации дисковой систему, r/w IOPS, r/w latency?


Блин не тот файл приложил ((

это пять!
"у вас jpg" :D
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088691
balykovdron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
gav21

это пять!


Вы бы лучше IOPсы откоментили ))
...
Рейтинг: 0 / 0
Непостоянное время выполнения запроса - всегда разное
    #40088706
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
balykovdron
gav21

это пять!


Вы бы лучше IOPсы откоментили ))

цифры не впечатляют и малополезны.
Полезней будет latency / service time дисков - может у вас с СХД проблемы и высокие задержки на дисках.
...
Рейтинг: 0 / 0
40 сообщений из 40, показаны все 2 страниц
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Непостоянное время выполнения запроса - всегда разное
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]