Блог

Все,

Я использую CentOS 6.0 с Postgresql 8.4 и, похоже, не могу понять, как предотвратить такую большую замену диска. У меня 12 гигабайт оперативной памяти и 4 процессора, и я делаю несколько простых обновлений (по 1 таблице за раз). На минуту я подумал, что вставки, выполняемые параллельно из неправильного скрипта, вызывали большое использование памяти, но когда я увидел, что простое обновление тоже вызывает это, я в основном бросил полотенце и решил обратиться за помощью.

Я вставил файл conf сюда. http://pastebin.com/e0jdBu0J

Вы можете видеть, что я установил буферы относительно низкими, а количество подключений высоким. Служба БД не запустится, если я установлю общие буферы размером более 64 мегабайт. У кого-нибудь есть идея, что может быть причиной этого для меня?

Спасибо, Адам

Если вы переходите на swap, увеличение shared_buffers усугубит проблему; вы будете забирать оперативную память у части, которая заканчивается, и заменять, вместо этого выделяя память для кэширования базы данных. Стоит исправить SHMMAX и т. Д. Только по общему принципу и для последующей настройки, но это не поможет с этой проблемой.

Угадывать, как определить источник, поглощающий вашу память, — это ошибка. Гораздо лучше просмотреть данные из «top -c» и ps, чтобы определить, какие процессы используют большую их часть. Действительно плохой запрос может потреблять намного больше памяти, чем следовало бы. Если вы видите, что использование памяти увеличивается для процесса PostgreSQL, выполняющего что-либо, проверьте идентификатор процесса на соответствие информации в pg_stat_tables, чтобы увидеть, что он делает.

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

Есть две проблемы с вашими настройками PostgreSQL, которые могут быть связаны. Базы данных на самом деле работают не очень хорошо, если у вас намного больше активных подключений, чем ядер на сервере; наилучшая производительность обычно составляет 2-3 активных клиента на ядро. И всевозможные вещи идут не так, как надо, когда у вас более нескольких сотен подключений. Существует некоторое поведение connections ^ 2, которое становится уродливым с точки зрения производительности, и также есть некоторые проблемы с памятью. Если вам действительно нужно 1250 подключений, вы должны использовать средство объединения подключений, такое как pgBouncer или pgpool-II.

И effective_io_concurrency = 1000 слишком высока для любого оборудования на планете. Полезные значения для этого в небольшом кратном количестве дисков, которые у вас есть на сервере. Я понятия не имею, что происходит с использованием памяти, когда вы устанавливаете ее на таком высоком уровне, но она не очень хорошо тестировалась в этом диапазоне. Обычные настройки больше похожи на 1 к 25. Параметры, описанные при настройке вашего сервера PostgreSQL, гораздо важнее, чем это; значение параллелизма влияет только на один конкретный тип сканирования таблицы.

Centos 6, похоже, имеет очень консервативный shmmax по умолчанию, устанавливающий ваши общие буферы в соответствии с рекомендациями postgres tuning resources

смотрите объяснение и как установить.

Для эксперимента вы можете (как root) использовать sysctl -w kernel.shmmax = n, где n — значение, которое сообщение об ошибке запуска, которое postgres пытается выделить при запуске. Когда вы определите значение, которое хотите использовать постоянно, установите его в /etc/sysctl.conf