PostgreSQL - если я запусту несколько запросов одновременно, при каких обстоятельствах я вижу ускорение? При каких обстоятельствах я бы увидел замедление?


10

Я смиренно отношусь к вам как к человеку, который НЕ является администратором баз данных, и я уверен, что мой вопрос чреват концептуальными недостатками и «зависит от» наземных мин. Я также уверен, что все, кто решит ответить, захотят гораздо большего в плане специфики, чем я могу предоставить в настоящее время.

Тем не менее, мне любопытно о следующем сценарии в целом:

  • Скажи, что у меня есть два нетривиальных запроса.
  • Запрос в среднем занимает 2 минуты.
  • Запрос 2 требует в среднем 5 минут.

Если я запускаю их последовательно, один за другим, я ожидаю, что в среднем потребуется 7 минут. Это разумно?

Более того, что делать, если я запускаю два запроса одновременно? Два отдельных соединения одновременно.

  • При каких условиях я ожидаю увидеть ускорение? (Общее время <7 минут)
  • При каких условиях я ожидаю увидеть замедление? (Общее время> 7 минут)

Теперь, если бы у меня было 1000 нетривиальных запросов, выполняемых одновременно, у меня есть догадка, что это приведет к общему замедлению. В таком случае, где может быть узкое место? Процессор? БАРАН? Приводы?

Опять же, я знаю, что, вероятно, невозможно точно ответить на вопрос, не зная специфики (которой у меня нет). Я ищу некоторые общие рекомендации, о которых нужно подумать, задавая следующие вопросы:

  • При каких обстоятельствах одновременные запросы приводят к общему ускорению?
  • При каких обстоятельствах одновременные запросы приводят к общему замедлению?

Ответы:


14

Если я запускаю их последовательно, один за другим, я ожидаю, что в среднем потребуется 7 минут. Это разумно?

Если они используют несвязанные наборы данных, тогда да.

Если они совместно используют набор данных, и кэш-память холодна для первого запроса, а запрос в основном связан с вводом-выводом, то второй может завершиться за несколько секунд. Вы должны учитывать эффекты кэширования при анализе производительности и времени запроса.

Более того, что делать, если я запускаю два запроса одновременно? Два отдельных соединения одновременно.

"Это зависит".

Если бы они оба использовали последовательное сканирование одной и той же таблицы, то в PostgreSQL это было бы огромным выигрышем в производительности благодаря его поддержке синхронизированного последовательного сканирования.

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

Если они независимы и касаются разных данных, они могут конкурировать за пропускную способность ввода / вывода, и в этом случае они могут занимать столько же времени, сколько и последовательная работа. Если подсистема ввода / вывода выигрывает от параллелизма (более высокая пропускная способность сети с большим количеством клиентов), тогда общее время может быть меньше. Если подсистема ввода / вывода плохо справляется с параллелизмом, то это может занять больше времени, чем последовательный запуск. Или же они могут вообще не быть связаны с вводом / выводом, и в этом случае, если для каждого из них есть свободный ЦП, они вполне могут работать так, как если бы другой вообще не работал.

Это во многом зависит от конфигурации оборудования и системы, набора данных и самих запросов.

Теперь, если бы у меня было 1000 нетривиальных запросов, выполняемых одновременно, у меня есть догадка, что это приведет к общему замедлению. В таком случае, где может быть узкое место? Процессор? БАРАН? Приводы?

Да, это очень вероятно замедлит ситуацию по ряду причин.

  • Собственные издержки PostgreSQL на межпроцессную координацию, управление транзакциями и блокировками, управление буфером и т. Д. Это может быть довольно дорого, и PostgreSQL на самом деле не рассчитан на большое количество клиентов - он работает лучше, если вы ставите в очередь работу .

  • Конкурс на рабочую память, кеш и т. Д.

  • Расходы на планирование ОС, поскольку они манипулируют 1000 конкурирующими процессами, требующими временных интервалов. В наши дни довольно незначительно, современные ОС имеют быстрые планировщики.

  • I / O Thrashing. Большинство систем ввода-вывода имеют максимальное количество клиентов. Иногда это 1, то есть лучше всего с одним клиентом, но часто выше. Иногда производительность снова падает выше порога. Иногда это просто достигает плато.


Это именно то объяснение, которое я искал. Понятно, лаконично, информативно. Спасибо!
Аарон Джонсон

Привет @Craig Ringer, Что делать, если я буду выполнять 1000 запросов одновременно в одной таблице (200 миллионов строк). Сможет ли Postgres справиться с ними? Помогает ли синхронизированное последовательное сканирование?
Рахул Гаутам

@RahulGautam Новый вопрос с деталями, пожалуйста, со ссылкой на этот вопрос.
Крейг Рингер

@CraigRinger добавил. Пожалуйста, проверьте dba.stackexchange.com/questions/188649/…
Рахул Гаутам

@RahulGautam Ваша ссылка мертва. Интересно, не могли бы вы предоставить обновленную информацию о том, что произошло? Это очень интересная тема.
Зеруно
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.