PostgreSQL, який скаржиться на спільну пам'ять, але спільну пам'ять, здається, добре

Я виконував якусь інтенсивну схему скидання та створення на сервері PostgreSQL, але зараз скаржиться ..:

WARNING:  out of shared memory
ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.

Але проблема залишається, якщо PostgreSQL буде перезапущений service postgresql restart, я підозрюю, що max_locks_per_transaction нічого не налаштує.

Я трохи відсторонений, оскільки списки усунення несправностей для цієї помилки не працюють для мене.

БІЛЬШЕ ІНФОРМАЦІЇ 1409291350: Деякі деталі відсутні, але я зберігаю основний результат SQL.

postgres=# SELECT version();
PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2,
 64-bit

І:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.1 LTS
Release:        14.04
Codename:       trusty

postgresql schema memory

— 48347
джерело

Версія PostgreSQL від SELECT version()? Цікава проблема ...

— Крейг Рінгер

"Я підозрюю, що max_locks_per_transaction нічого не налаштовує." - е-е, навіщо ви це підозрювали? Чи намагалися ви насправді дотримуватися пропозиції підказки?

— Джош Купершмідт

Чи намагалися ви насправді дотримуватися пропозиції підказки? Я поки що не коментував max_locks_per_transaction = 64 # min 10/etc/postgresql/9.3/main/postgresql.conf.

— 48347

Типовий max_locks_per_transaction - це 64 для початку - коментар до цього рядка фактично не змінив його.

— врожайністьможливості

Добре, ефективне збільшення до 128 вирішило проблему , фактично дозволило операції продовжуватися.

— 48347

Ваш коментар про інтенсивне скидання та створення та повідомлення, яке ви отримали щодо збільшення max_locks_per_transaction, натякають на те, що ви скидаєте та створюєте багато об’єктів в одній транзакції . Кожен з них призводить до блокування, для кожного потрібна невелика кількість спільної пам'яті. Через це max_locks_per_transaction обмежує кількість блокувань, які ви можете утримувати в межах транзакції (щоб запобігти використанню будь-якої однієї транзакції всієї спільної пам'яті).

Ви можете або трохи збільшити цей ліміт (я б рекомендував не встановлювати його довільно великим, або ви зіткнетесь з окремою ситуацією, коли фактично не вистачає загальної спільної пам’яті), або робити краплі і створювати або партіями транзакцій, або як одну краплю / створити за транзакцію.

Редагувати: Мабуть, я помилився з приводу того, як працює max_locks_per_transaction. З документації загальна кількість доступних блокувань становить max_locks_per_transaction * (max_connections + max_prepared_transaction) - будь-яка одна транзакція може містити більше max_locks_per_transaction, якщо кількість блокувань, що утримуються скрізь, менша від цієї загальної величини.

— врожайність
джерело

Мій робочий процес включає (1) скидання схеми X, (2) відміну іншої схеми Y і (3) відновлення X на імені схеми Y. Як я вже говорив, до сьогодні я вже кілька тижнів виконую ці дії, і сьогодні крок (2) провалюється. Крок (2) в основному складається з DROP SCHEMA IF EXISTS public CASCADE; CREATE SCHEMA publicцих пропозицій, які кидають ПОПЕРЕДЖЕННЯ, ПОМИЛКА та ПОРАДА

— 48347

Подвоєння максимальних блокувань від 64 до 128 дозволило продовжити робочий процес. У мене ще немає внутрішніх справ, але, мабуть, вчинення між СРОМИ ДРОПУ та СТВОРЕНОЮ СХЕМИ матиме подібний послаблюючий ефект.

— 48347

Тепер я усвідомлюю, що за багато днів я отримую невелике збільшення схеми, і це питання ідеально відповідає одному з цих невеликих схем . Як загальна стратегія, я відтепер буду більше враховувати підказки.

— 48347