ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Постгре начинает тормозить на запросе при пороговом значении limit
31 сообщений из 31, показаны все 2 страниц
  все  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679433
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Коллеги, доброе утро.
По Постгре опыт не сильно большой. Базовые настройки менял, запросы оптимизировал.
Но вот наткнулись на такой ньюанс.
СУБД на Windows.

Есть линейный запрос:
Код: sql
1.
Select * from Table limit X



Ставим вместо х 10.000, запрос работает 10с.
20.000 - 20с.
и т.д., все вроде бы линейно.
Но по достижению какого-то порогового значения, допустим, 60.000, запрос выполняется ну там 1.5 минуты.
После этого запрос на 10.000 начинает работать дольше, 18с.

Через какое-то время все запросы снова выполняются за стандартное время.
Не очень понятно, что происходит. Может я не до конца понимаю, как работает буфер данных в Постгре...

Проверяли все это на продакшн сервере на виртуалке, на тестовом сервере на другой виртуалке, и даже на локальном физическом сервере.
На 2х виртуалках с разными ресурсами(32 на тестовом и 57 на продакшн гб) по памяти наблюдали данный эффект. На локальном физическом сервере такого эффекта не наблюдали, но там данных было всего 41.000.

Памяти вроде достаточно. На тестовом в Shared_buffers указано 6гб, на продакшн поднимали с 6 до 12, никакого эффекта не достигнули.
Или дело может быть в виртуалках? При тестировании всех и все отключали. На тестовом так точно никого не нет
---
Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с)
...
Рейтинг: 0 / 0
26.07.2018, 10:08
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679461
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mefman
Участник
MegabyteПо Постгре опыт не сильно большой. Базовые настройки менял, запросы оптимизировал.

Это такой замкадский диалект?
типа поребрика, шавермы итд?
СУБД называется PostgreSQL, допустимо называть Постгрес, на не как не что-то другое
...
Рейтинг: 0 / 0
26.07.2018, 10:40
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679474
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
mefmanMegabyteПо Постгре опыт не сильно большой. Базовые настройки менял, запросы оптимизировал.

СУБД называется PostgreSQL, допустимо называть Постгрес, на не как не что-то другое
Принято. :)
...
Рейтинг: 0 / 0
26.07.2018, 11:01
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679487
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkij
Участник
Megabyte,

смотрите для начала explain (analyze, buffers) при включенном в конфиге track_io_timing.
...
Рейтинг: 0 / 0
26.07.2018, 11:24
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679489
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Megabyte,

Приведите `EXPLAIN (analyze, buffers)` для запросов с интересующими значениями X, будет проще показать.

Однако, использовать столь большие значения для LIMIT да ещё и без ORDER BY — сильный анти-паттерн.
Какую задачу пытаетесь решить?
...
Рейтинг: 0 / 0
26.07.2018, 11:24
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679531
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
vyegorovMegabyte,

Однако, использовать столь большие значения для LIMIT да ещё и без ORDER BY — сильный анти-паттерн.
Какую задачу пытаетесь решить?
Как таковой задачи нет. Просто клиент на больших объемах заметил такую вот особенность.
В первую очередь для себя хочу разобраться, почему такое поведение.

EXPLAIN (analyze, buffers), да, гляну.
...
Рейтинг: 0 / 0
26.07.2018, 12:11
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679645
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
X = 10.000: время выполнения, 1с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..7184.38 rows=10000 width=2061) (actual time=0.041..294.720 rows=10000 loops=1)"
"  Buffers: shared read=5174"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.039..291.570 rows=10000 loops=1)"
"        Buffers: shared read=5174"
"Planning time: 93.881 ms"
"Execution time: 296.397 ms"



X = 20.000: 3с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..14368.76 rows=20000 width=2061) (actual time=0.010..862.423 rows=20000 loops=1)"
"  Buffers: shared hit=6 read=14243"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.009..855.537 rows=20000 loops=1)"
"        Buffers: shared hit=6 read=14243"
"Planning time: 0.335 ms"
"Execution time: 865.630 ms"



X = 40.000: 6с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..28737.52 rows=40000 width=2061) (actual time=0.009..324.086 rows=40000 loops=1)"
"  Buffers: shared hit=14 read=5633"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.007..313.061 rows=40000 loops=1)"
"        Buffers: shared hit=14 read=5633"
"Planning time: 0.334 ms"
"Execution time: 329.299 ms"



X = 60.000: 9с
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..43106.28 rows=60000 width=2061) (actual time=0.009..459.498 rows=60000 loops=1)"
"  Buffers: shared hit=15 read=7761"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.007..443.212 rows=60000 loops=1)"
"        Buffers: shared hit=15 read=7761"
"Planning time: 0.313 ms"
"Execution time: 467.411 ms"



X = 100.000: 58с, 2й раз 60с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..71843.81 rows=100000 width=2061) (actual time=0.010..3109.619 rows=100000 loops=1)"
"  Buffers: shared hit=3 read=51196"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.009..3078.248 rows=100000 loops=1)"
"        Buffers: shared hit=3 read=51196"
"Planning time: 0.307 ms"
"Execution time: 3124.537 ms"



X = 100.000: 2й раз 60с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.00..71843.81 rows=100000 width=2061) (actual time=0.009..4814.963 rows=100000 loops=1)"
"  Buffers: shared hit=1 read=79115"
"  ->  Seq Scan on skulskul2  (cost=0.00..1090096.14 rows=1517314 width=2061) (actual time=0.008..4781.128 rows=100000 loops=1)"
"        Buffers: shared hit=1 read=79115"
"Planning time: 0.337 ms"
"Execution time: 4832.361 ms"



Я так понимаю, что в следующих итерациях PostgreSQL меньше данных читает из буфера.
Почему?

Сделал запрос с явной сортировкой:
Код: sql
1.
select * from skulskul2 order by skul_no limit 100000


Выполнился за 30с, 2й раз за 25с.
Код: sql
1.
2.
3.
4.
5.
6.
"Limit  (cost=0.43..237660.77 rows=100000 width=2061) (actual time=0.019..275.851 rows=100000 loops=1)"
"  Buffers: shared hit=100685"
"  ->  Index Scan using pk_skulskul2 on skulskul2  (cost=0.43..3606054.11 rows=1517314 width=2061) (actual time=0.017..248.251 rows=100000 loops=1)"
"        Buffers: shared hit=100685"
"Planning time: 0.344 ms"
"Execution time: 288.582 ms"


Прикольно, PostgreSQL заюзал Primary Key и сделал индекс скан вместо сканирования таблицы...
...
Рейтинг: 0 / 0
26.07.2018, 14:31
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679749
Ы2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ы2
Участник
Megabyte, чем вы свои секунды измеряете? В последнем примере, где вы пишите 60 с, база уверена, что сделала все за 4,8 с.
Если вы смотрите время выполнения в PgAdmin, то он показывает не время выполнения запроса, а суммарное время, потребное в т.ч. на передачу данных и, возможно, отображение.
...
Рейтинг: 0 / 0
26.07.2018, 16:32
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679789
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Ы2Megabyte, чем вы свои секунды измеряете? В последнем примере, где вы пишите 60 с, база уверена, что сделала все за 4,8 с.
Если вы смотрите время выполнения в PgAdmin, то он показывает не время выполнения запроса, а суммарное время, потребное в т.ч. на передачу данных и, возможно, отображение.
Я написал фактическое время, да, когда, собственно, выполнил сам запрос.
А Execution time в explain разве показывает реальное время, а не предполагаемое?
Т.к. запрос с explain - это уже был следующий запрос.

p.s. Т.е., получается, PostgreSQL значительную часть времени может тратить на передачу и отображение, а не выполнение запроса?
...
Рейтинг: 0 / 0
26.07.2018, 17:38
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679793
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
MegabyteТ.е., получается, PostgreSQL значительную часть времени может тратить на передачу и отображение, а не выполнение запроса?

НЕ PostgreSQL, а то приложение, которым Вы данные извлекаете.
IMHO & AFAIK
...
Рейтинг: 0 / 0
26.07.2018, 17:42
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679795
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Megabytep.s. Т.е., получается, PGAdmin значительную часть времени может тратить на передачу и отображение, а не выполнение запроса?
поправил
...
Рейтинг: 0 / 0
26.07.2018, 17:45
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679869
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkij
Участник
MegabyteА Execution time в explain разве показывает реальное время, а не предполагаемое?
explain analyze - именно реальное выполнение запроса. И actual time в каждом узле - реальное измеренное время выполнения этого узла плана от первой до последней строки результата.
Но без учёта передачи ответа по сети, да. Т.к. ответ никуда не передаётся.
И даже Planning time - это не планируемое время, а реальное время затраченное планировщиком запроса на составление и выбор плана выполнения.

При включенном track_io_timing в explain (analyze,buffers) будет ещё измерение времени чтения всех блоков, которые не нашли в shared buffers. Которое тоже может сильно скакать, тем более в вашем случае где судя по explain ничего в shared buffers не было и чуть менее чем всё просили читать операционную систему.
...
Рейтинг: 0 / 0
26.07.2018, 20:35
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679891
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Спасибо.

К слову о реальной задаче.
Есть запрос, без каких либо условий фильтрации. Просто join нескольких таблиц среднего размера(100-300 тысяч записей).
Базовая(первая таблица выборки) таблица, как раз та, по которой возник вопрос насчет Select * from Table limit X.

В MS SQL этот запрос отрабатывает в районе 10с, что в студии, что в приложении.

В PostgreSQL запрос в студии и в приложении работает 70с.
Execution time в explain (analyse, buffers) показывает 15-16с.
Получается, что 55-56с тратится, что в приложении, что в PgAdmin на передачу данных и отображение..?

Это возможно как-то ускорить? Или что на это влияет?

Со слов клиента, раньше этот запрос в приложении работал за 30с(проверить нет возможности), Кол-во данных не менялось.
...
Рейтинг: 0 / 0
26.07.2018, 21:20
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679902
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
MegabyteСпасибо.

К слову о реальной задаче.
Есть запрос, без каких либо условий фильтрации. Просто join нескольких таблиц среднего размера(100-300 тысяч записей).
Базовая(первая таблица выборки) таблица, как раз та, по которой возник вопрос насчет Select * from Table limit X.

В MS SQL этот запрос отрабатывает в районе 10с, что в студии, что в приложении.

В PostgreSQL запрос в студии и в приложении работает 70с.
Execution time в explain (analyse, buffers) показывает 15-16с.
Получается, что 55-56с тратится, что в приложении, что в PgAdmin на передачу данных и отображение..?

Это возможно как-то ускорить? Или что на это влияет?

Со слов клиента, раньше этот запрос в приложении работал за 30с(проверить нет возможности), Кол-во данных не менялось.

Для начала - обновится до 10.4 и включить параллельное выполнение запросов на многих ядрах.
Дальше в psql делать
1)explain (analyze, costs, buffers, timing) запроса общего

2)\timing on
\o somefile
запрос;
чтобы посмотреть на сколько времени запрос выполняется в реальности и главное какой обьем данных он отдает

3)если с временем на приложении сильно не совпадает - смотреть на то какая вообще скорость сети и за какое время этот БОЛЬШОЙ ответ через нее пролезает (вряд ли у вас 10GBit кругом чтобы не думать об этом почти)

4)если сети хватает - лечить приложение.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
26.07.2018, 21:38
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679910
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Спасибо, буду копать.
...
Рейтинг: 0 / 0
26.07.2018, 21:50
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679911
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Maxim BogukДальше в psql делать
1)explain (analyze, costs, buffers, timing) запроса общего

C таким explain получилось уже 52с.
...
Рейтинг: 0 / 0
26.07.2018, 22:05
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679931
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
MegabyteMaxim BogukДальше в psql делать
1)explain (analyze, costs, buffers, timing) запроса общего

C таким explain получилось уже 52с.
Со 2,3го раза уже 18,20с. Но сам запрос все равно в районе 70с.
Что-то я не улавливаю причины...
...
Рейтинг: 0 / 0
26.07.2018, 22:46
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39679945
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Megabyte,

Вы абсолютно не туда смотрите.
Время исполнения запроса базой гораздо меньше и явно видно в выводе `EXPLAIN`.

То, что вы замеряете — пропускная способность сети + поведенческие особенности вашего клиентского приложения.
С этим помочь в рамках форума не выйдет.
...
Рейтинг: 0 / 0
27.07.2018, 00:18
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39680043
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
Maxim Boguk2)\timing on
\o somefile
запрос;
чтобы посмотреть на сколько времени запрос выполняется в реальности и главное какой обьем данных он отдает

3)если с временем на приложении сильно не совпадает - смотреть на то какая вообще скорость сети и за какое время этот БОЛЬШОЙ ответ через нее пролезает (вряд ли у вас 10GBit кругом чтобы не думать об этом почти)

Недавно наткнулся, вроде в тему.
psql может много времени тратить на форматирование результата. Возможно и pgAdmin грешит этим, не проверял.

 
Несложные замеры в psql показывают, что выгрузка данных в файл командой SELECT выполняется существенно дольше, чем командой COPY .. TO.

В таблице tickets демонстрационной базы данных около 3 миллионов строк.
Попробуем выгрузить данные столбца contact_data в файл.
Сначала командой SELECT, а затем командой COPY .. TO.

Интересует время выгрузки, поэтому включим \timing.
Дополнительно замерим время между двумя вызовами функции clock_timestamp: до и после выгрузки.

Скрипт timing.sql:
--
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
\echo Run SELECT
select clock_timestamp() as d\gset
\timing on
\o contacts.txt
select contact_data from tickets;
\o
\timing off
select clock_timestamp() - :'d'::timestamptz as real_time;

\echo Run COPY .. TO
select clock_timestamp() as d\gset
\timing on
\o copy_contacts.txt
\copy (select contact_data from tickets) to stdout;
\o
\timing off
select clock_timestamp() - :'d'::timestamptz as real_time;


--

Запускаем:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
demo=# \i timing.sql
Run SELECT
Timing is on.
Time: 2125,645 ms (00:02,126)
Timing is off.
    real_time
-----------------
 00:00:09.856476
(1 row)

Run COPY .. TO
Timing is on.
Time: 2416,298 ms (00:02,416)
Timing is off.
    real_time
-----------------
 00:00:02.634909
(1 row)



Обращает на себя внимание.
1. Реальное время выполнения, полученное разницей вызовов clock_timestamp первой выгрузки (~10 сек), значительно больше чем показал \timing (~2 сек). Т.е. к показаниям \timing нужно относиться аккуратно.
2. Вторая выгрузка (COPY .. TO) заняла ~2,6 сек, что почти в 4 раза быстрее чем первая выгрузка.

Однако причина вовсе не в особенностях выполнения команд SELECT и COPY .. TO.
Столь существенная разница объясняется тем, что psql по умолчанию форматирует результаты запросов. В частности выравнивает ширину столбцов. Стоит только отключить выравнивание, как время обоих запросов становится похожим:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
demo=# \pset format unaligned
Output format is unaligned.
demo=# \i timing.sql
Run SELECT
Timing is on.
Time: 2156,758 ms (00:02,157)
Timing is off.
real_time
00:00:02.817774
(1 row)
Run COPY .. TO
Timing is on.
Time: 2422,347 ms (00:02,422)
Timing is off.
real_time
00:00:02.602836
(1 row)

...
Рейтинг: 0 / 0
27.07.2018, 10:42
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39680251
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
vyegorovТо, что вы замеряете — пропускная способность сети + поведенческие особенности вашего клиентского приложения.

Но MS SQL этому не подвержен. Не выгрузку оттуда сеть и приложение не влияет почему-то.
...
Рейтинг: 0 / 0
27.07.2018, 15:29
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39680292
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
MegabytevyegorovТо, что вы замеряете — пропускная способность сети + поведенческие особенности вашего клиентского приложения.

Но MS SQL этому не подвержен. Не выгрузку оттуда сеть и приложение не влияет почему-то.

Это уже вам тут не помогут. С таким вопросом.
Разбирайтесь сами. Непрофильный вопрос.
Профилируйте/смотрите что где тормозит и тд.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
27.07.2018, 16:15
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39680311
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Maxim BogukMegabyteпропущено...

Но MS SQL этому не подвержен. Не выгрузку оттуда сеть и приложение не влияет почему-то.

Это уже вам тут не помогут. С таким вопросом.
Разбирайтесь сами. Непрофильный вопрос.
Профилируйте/смотрите что где тормозит и тд.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
Да это не вопрос был. Скорее рассуждение на тему влияния сети и приложения на длительность запроса...
...
Рейтинг: 0 / 0
27.07.2018, 16:29
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39680326
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
MegabyteДа это не вопрос был. Скорее рассуждение на тему влияния сети и приложения на длительность запроса...

Так протоколы то разные.
Кстати о протоколах у вас там в ответе двоичных данных (LO/bytea) нет случайно больших?
Попробуйте изменить bytea_output на hex если еще не (если у вас есть в ответе bytea большие).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
27.07.2018, 16:47
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39680419
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Maxim BogukMegabyteДа это не вопрос был. Скорее рассуждение на тему влияния сети и приложения на длительность запроса...

Так протоколы то разные.
Кстати о протоколах у вас там в ответе двоичных данных (LO/bytea) нет случайно больших?
Попробуйте изменить bytea_output на hex если еще не (если у вас есть в ответе bytea большие).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
Посмотрю, спасибо.
...
Рейтинг: 0 / 0
27.07.2018, 21:31
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39682842
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Коллеги, подскажите, а в Explain в:
Код: sql
1.
Buffers: shared hit=8357288 read=6165444 dirtied=44820 written=5590


Что означают последние 2 блока: dirtied, written? Что обозначают hit, read, я в курсе.
Поиском что-то не нашел ничего путного...
...
Рейтинг: 0 / 0
02.08.2018, 22:18
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39682847
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
А, правильно ли я понимаю, что dirtied - это чтение "мертвых" страниц, не удаленных vacuum?
...
Рейтинг: 0 / 0
02.08.2018, 22:25
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39682854
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
MegabyteКоллеги, подскажите, а в Explain в:
Код: sql
1.
Buffers: shared hit=8357288 read=6165444 dirtied=44820 written=5590


Что означают последние 2 блока: dirtied, written? Что обозначают hit, read, я в курсе.
В Postgres-e информация о видимости записей хранится в заголовках самих записей. И также есть commit log, в котором хранится состояние транзакций. Если происходит rollback транзакции которая, к примеру, поменяла много записей, то просто меняется статус транзакции в commit log-е — rollback быстрый, но с “отложенной” работой.

Первый же запрос, который потом обращается к таким записям видит, что
1. транзакция откачена
2. у записей не выставлены биты видимости (эти биты нужны для скорости, чтобы все следующие запросы не лезли в commit log)
И он, проверив статус транзакции в commit log-е, меняет биты видимости в заголовке записи. Т.е. даже если это SELECT, он меняет данные. Изменения происходят в кэше (shared_buffers), изменённые блоки помечаются как грязные (dirty), т.е. требуют синхронизации с диском.

Если запросу нужно прочитать данные в кэш — а в Postgres-е всё взаимодействие происходит через кэш (в отличии от, скажем, ORACLE) — и в кэше нет свободного места, то происходит вытеснение самой “ненужной” страницы. Если при этом страница грязная, то её сначала надо сохранить на диск, т.е. даже SELECT может неожиданно начать писать (write) данные на диск.

Одно с другим не связано, т.е. могут быть только dirtied блоки при исполнении запроса, без written.
...
Рейтинг: 0 / 0
02.08.2018, 22:38
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39683320
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Благодарю.
...
Рейтинг: 0 / 0
04.08.2018, 14:52
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39683948
Andy_OLAP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andy_OLAP
Участник
vyegorov а в Postgres-е всё взаимодействие происходит через кэш (в отличии от, скажем, ORACLE)
Дополню коллегу для автора темы.

Под обсуждением перевода яндекс почты с оракла на постгрескл в комментариях звучит неприкрытая боль.
"Под нашей нагрузкой postgres по I/O проигрывал в 4 раза. И как показал PGCon 2016, разработчики postgres'а в курсе всех проблем.
Например, нельзя отдать без малого всю память под разделяемый кэш, потому что алгоритм вытеснения буфера очень паршивый. Приходится активно использовать page cache, которым сложно управлять + двойное кэширование. Или нет нормального асинхронного I/O, потому что поддерживается 100500 платформ, во многих из которых этого и близко нет".

Плюс еще одна хорошая статья для автора темы от 2013-го года, старая, но краткая, Postgres. Как устроено кеширование.
...
Рейтинг: 0 / 0
06.08.2018, 19:59
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39683949
Andy_OLAP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andy_OLAP
Участник
Megabyte,

Вот тут еще отличное обсуждение, как наличие реплик заставляет делать автовакуум агрессивнее .

Это не сейчас Вам, но на будущее.
...
Рейтинг: 0 / 0
06.08.2018, 20:00
| Ответить | Цитировать | Написать  
Постгре начинает тормозить на запросе при пороговом значении limit
    #39683991
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
2Andy_OLAP: Спасибо.
...
Рейтинг: 0 / 0
06.08.2018, 22:37
| Ответить | Цитировать | Написать  
31 сообщений из 31, показаны все 2 страниц
  все  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Постгре начинает тормозить на запросе при пороговом значении limit
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=53&tid=1995641]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 41ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 291ms
total:  426ms
созд. / загр.: 426ms
x
x
Закрыть


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