тюнинг postgresql для большого количества оперативной памяти

29

У меня есть два идентичных сервера (с точки зрения аппаратного обеспечения), они оба являются стандартными установками Windows Server 2008 r2, с минимальным количеством установленного программного обеспечения (в основном мой код и необходимые вещи, такие как jvm и т. Д.).

На одном сервере я запускаю sql server 2005, на втором сервере postgresql 9.1. Разница в производительности между этими двумя серверами ошеломляет, это настолько плохо на postgresql, что я сожалею о своей первоначальной речи «давайте использовать postgresql вместо того, чтобы платить за лицензию sql server» моему боссу. Мы говорим о разнице в 30 секунд и 15 минут для одной и той же команды, и это не просто одна команда, это любой запрос или команда, которую я бросаю на нее. Они оба имеют практически одинаковые данные (записи были вставлены в разном порядке), и обе базы данных имеют одинаковую структуру / индексы и т. Д.

Но я надеюсь, что это просто вопрос настройки производительности. Дело в том, что сервер sql в значительной степени использует все 32 гигабайта оперативной памяти на сервере, в то время как postgresl ничего не использует, определенно меньше, чем концерт, хотя на самом деле я не разобрался в деталях.

Как мне заставить postgresql использовать более 20 гигабайт оперативной памяти? Эти серверы были созданы специально для этой базы данных, поэтому, по моему мнению, все оперативные памяти, не используемые базой данных и вспомогательными процессами, теряются.

postgresql memory

— user85116
источник

4

Вы поменяли что-нибудь на первоначальную настройку? Шаг 1: SET effective_cache_size=18G;(настройка по умолчанию очень низкая) Кстати: если предположить, что это 64-битный компьютер (без PTE)

1

Ты действительно не даешь нам достаточно, чтобы сильно помочь. Помимо «Это медленно», мы мало что знаем о вашем наборе данных, о том, как вы к нему обращаетесь, какие типы запросов обычно выполняются медленно, что вы уже сделали, чтобы настроить (и, возможно, неправильно) настроить ваш сервер. Черт возьми, на Linux-машине с большим количеством ядер и каналов памяти вы можете получить хреновую производительность задолго до того, как вы установили postgresql. Вы процессор или IO связаны? Какие нестандартные настройки у вас уже есть? Какие типы запросов медленные?

— Скотт Марлоу

2

Postgres не «использует оперативную память», как вы говорите об этом. Он основывается на кеше страниц файловой системы ОС для большей части своего кэширования, поэтому, когда вы наблюдаете использование оперативной памяти в системе, работающей с postgres, вы обычно видите много ГБ, используемых буферами / кешем ОС, и отдельные процессы бэкэнда postgres, использующие лишь несколько несколько десятков МБ каждый.

— dbenhur

1

Посмотрите эту ссылку: tekadempiere.blogspot.ae/2014/09/… И найдите значения конф, установленные для вашего ресурса, здесь: pgtune.leopard.in.ua

— Sajeev

связанный вопрос, может быть интересен: stackoverflow.com/questions/47311485/…

— mountainclimber

41

Есть много настраиваемых констант, инициализированных через postgres.conf. Самые важные из них:

max_connections: количество одновременных сеансов
work_mem : максимальный объем памяти, который будет использоваться для промежуточных результатов, таких как хеш-таблицы, и для сортировки
shared_buffers объем памяти, выделенный для «закрепленного» буферного пространства.
effective_cache_size объем памяти, предположительно используемый буферами LRU операционной системы.
random_page_cost : оценка относительной стоимости дисков ищет.

max_connectionsне должен быть установлен выше, чем необходимо, соединения стоят ресурсов, даже когда простаивают; в большинстве случаев соединение будет тратить больше времени на ожидание внутри, чем на ожидание снаружи. (за счет параллелизма) Хорошая формула «большого пальца»: «количество шпинделей + количество процессоров + X»

work_memявляется хитрым: это может быть применено к каждому подзапросу, поэтому запрос с 5 HASHJOINSможет стоить 5 * work_mem. И для наихудших сценариев вы также должны подумать о том, что несколько сеансов потребляют эту сумму (опять же, причина оставаться max_connectionsнизкой).

shared_buffersэто (имхо) переоценено. Обычно рекомендуется устанавливать его примерно на 1/4 ... 1/2 от всей доступной "свободной" памяти, но я склонен держать ее на низком уровне и устанавливать effective_cache_sizeна всю доступную "свободную" память.

random_page_costэто стоимость поиска + чтения на диске. Это относительно sequential_disk_cost1. Это значение по умолчанию (4) random_page_costустановлено слишком высоким для современных машин и сетевого хранилища, обычно оно может быть снижено до 2–1. Для дисков SSD вы даже можете установить его на 1,0, поскольку поиск на SSD практически бесплатный.

— wildplasser
источник

Превосходно! Я никогда не видел значимостиффективной_схемы_сайза, всегда дурачил только с помощью общих_буфферов. Это действительно имело огромное значение. Я также запускаю pgtune, и он рекомендует использовать 20 ГБ из 96 для shard_buffers, но 64 ГБ дляffective_cache_size. Благодарность!

1

FWIW, я просмотрел эти и другие параметры, предложенные в документации Postgres, и провел анализ для нашего сервера .

— mlissner

Большое спасибо за ответ. Могу ли я спросить, что рекомендуется work_mem, когда по max_connectionsумолчанию 100, а объем оперативной памяти сервера составляет 32 ГБ (выделенный сервер postgres)? Я знал, что мне нужно настроить это самостоятельно, основываясь на ежедневных запросах. Мне просто интересно, можете ли вы сказать мне значение «один размер подходит для всех» (или начальную точку). 50 МБ слишком большой? Большое спасибо.

— sgon00

Это зависит от типичной одновременной активности на вашем компьютере. 100 сессий, требующих 50M (поверх их 10..20M) каждая может подойти. Или, возможно, нет. Чтобы получить впечатление, следите за vmstat или top. Плюс: это зависит от вашего запроса (и других). Просто посмотрите на планы.

— Wildplasser

@wildplasser большое спасибо за быстрый ответ. Я нашел интересный сайт pgtune.leopard.in.ua . Я думаю, что я буду использовать 40 МБ в качестве отправной точки от его предложения и мелодии, основанной на этом. Приветствия.

— sgon00

20

Подумайте об использовании pgtune, чтобы помочь вам настроить конфигурацию PostgreSQL. Из PgFoundry:

pgtune принимает wimpy по умолчанию postgresql.conf и расширяет сервер базы данных, чтобы быть таким же мощным, как оборудование, на котором он развертывается

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

Имейте в виду, что нет необходимости использовать точные предложения pgtune. Играя с его настройками и наблюдая за полученными изменениями в файле conf, вы получите лучшее представление о конфигурации PostgreSQL и о том, как настроить его вручную.

— Пол Беллора
источник

8

Последнее обновление pgtune было в 2009 году, это 5 лет назад и до сих пор считается. Мне интересно, если он все еще действителен для 9.1-9.2-9.3 серии.

— сорин

9

pgtune теперь доступен онлайн

— Alfabravo

3

Если каждый запрос или команда выполняется медленно, я подозреваю, что:

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

Не могли бы вы сказать нам, сколько времени требуется для выполнения запроса select version()? Если должно быть мгновенным (0,16мс на моей рабочей станции).

— Tometzky
источник

2

Если КАЖДЫЙ запрос намного медленнее, значит что-то не так с сервером или чем-то еще. По моему опыту, каждая база данных имеет несколько вещей, в которых она лучше других, но с точки зрения производительности pgsql легко находится в той же области, что и сервер mssql.

Итак, на какой ОС вы запускаете pgsql? Какое оборудование? Какие настройки вы уже изменили? Насколько большой ваш набор данных? Что является примером плохого запроса и вывода объяснения анализа (Запустите ваш запрос следующим образом:

объяснить, проанализировать, выбрать ... остальную часть запроса здесь ...;

Опубликовать вывод на http://explain.depesz.com/ и разместить ссылку здесь.

— Скотт Марлоу
источник

1

Да, каждый запрос / команда выполняется медленно, и да, «что-то» ужасно неправильно, отсюда и мой вопрос. Проблема в том, что mssql в полной мере использует доступную оперативную память на сервере (настолько интенсивное кэширование), тогда как psql - нет. Я ценю комментарии и советы, но вы, должно быть, пропустили большую часть моего вопроса и саму тему ... Я просто хочу знать, как заставить psql использовать доступного оперативного памяти; в настоящее время пытаются некоторые предложения, перечисленные другими ...

— user85116

1

Использование вашей оперативной памяти не является проблемой. Postgresql полагается на ОС для выполнения большей части кэширования. Таким образом, не нужно использовать всю оперативную память. Опять же, вы пропустили основную часть моей мысли. Вы даете нам очень мало, чтобы помочь вам. Я вожу 5000 TPS postgresql кластеров для жизни. Вы можете принять мой совет или продолжать думать, что знаете, как работает pgsql, и спорить.

— Скотт Марлоу

@ user85116, пожалуйста, слушайте, Скотт, у нас уже есть рабочий процесс с MySQL, который зависит от супер-латентности, поэтому в настоящее время MySQL использует оперативную память 64 ГБ для выполнения быстрых запросов, тогда как этого можно добиться на 2G Postgres только с материализованными представлениями. Кэширование всей базы данных в оперативную память не решит вашу проблему, а только сделает ее менее заметной. Если у вас есть те же проблемы в структуре БД, Postgres не исправит это и не попытается скрыть.

— Кворр