Медленные вставки в postgresql

1: посмотри какие именно запросы в этот момент идут к БД

Вот сейчас сервер после внезапной перезагрузки странно себя ведет. Сначала долго висел процесс recovery, теперь insert срабатывает сразу, а все insert, update и commit висят минут 5.

1. Выполняется один insert и один update вроде (точнее смогу позже сказать).

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

Индексы на внешние ключи есть?

и запросы покажи

Индексы на внешние ключи есть?

Поищу. Я не в курсе, создает ли их джанга.

Да, так немного быстрее работает. А на manytomany индексы тоже нужны?

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

Покажи лучше запросы.

А постгрес нормально настроен? shared_buffers и все такое?

Настолько, насколько стандартное ядро позволяет.

Запросы именно для постгреса показать не могу, он у меня только на живом сервере стоит, где дебаг-панель не врубишь. Могу показать запросы для скулайта, но насколько это поможет...

Ну shared_buffers сколько?

24M

в /etc/sysctl.conf добавь - kernel.shmmax=17179869184 kernel.shmall=4194304

sysctl kernel.shmmax=17179869184 sysctl kernel.shmall=4194304

и поставь в shared_buffers нормальное значение, для начала можно 1/4 оперативки.

Это очень сильно ускорит работу постгреса.

Сделал sysctl -w и эти значения. Все равно не стартует. Это точно должно работать на впс с openvz?

Если мне не изменяет склероз - у меня на openvz работало, но это было очень давно.

Проверь на всякий случай установились ли эти значения -

sysctl kernel.shmmax
sysctl kernel.shmall

И ошибка из-за которой постгрес не стартует покажи на всякий случай.

Значения установились.

2013-11-04 21:06:48 EET FATAL:  could not create shared memory segment: No space left on device
2013-11-04 21:06:48 EET DETAIL:  Failed system call was shmget(key=5432001, size=61071360, 03600).
2013-11-04 21:06:48 EET HINT:  This error does *not* mean that you have run out of disk space.  It occurs either if all available shared memory IDs have been taken, in which case you need to raise the SHMMNI parameter in your kernel, or because the system's overall limit for shared memory has been reached.  If you cannot increase the shared memory limit, reduce PostgreSQL's shared memory request (currently 61071360 bytes), perhaps by reducing shared_buffers or max_connections.
        The PostgreSQL documentation contains more information about shared memory configuration.

Попробуй поставь kernel.shmmni = 4096

Я туда уже поставил 4194304, ничего не изменилось.

Ну тогда я не знаю, видимо у openvz не поменять эти значения изнутри.

Проверь что приложение выключает синхронный коммит (должно быть что то вроде «SET synchronous_commit TO OFF»)

И хорошо бы обновить pg до 9.3, там больше не нужно плясок с sysctl

Разве это не уменьшает сохранность данных?

Не могу, у меня убунта 12.04, а обновлять ее на живом сервере боюсь. Уже не раз убунта ломалась после обновлений, не рискну.

Он просто будет завершать insert, не дожидаясь пока данные запишутся на диск(это десятки-сотни миллисекунд экономии на каждом запросе).

Без синхронного коммита действительно могут потеряться записываемые данные при внезапном отключении (за время записи, те самые десятки-сотни миллисекунд). Но скорее всего, для web-приложения это не критично, оно просто не успеет за это время собрать страницу и передать клиенту.

А что увидит пользователь в ответе (где должны отображаться записанные данные), если они еще пишутся на диск?

Ответ будет такой же в любом случае. Разница будет только если пользователь отправил запрос со вставкой/обновлением данных в БД. С синхронным коммитом приложение будет ждать, пока данные реально запишутся на диск. Если в это время произойдёт сбой(аппаратный или системный), то транзакция не запишется. С выключенным синхронным коммитом вставка будет происходить так же, только приложение сразу после вставки пойдёт дальше заниматься своими делами. Оно уже может отправить ответ клиенту, и он уже думает что данные записались, хотя при сбое транзакция откатится.

Тут ничего нельзя поделать, либо честно ждать пока данные запишутся (сотни миллисекунд на каждый коммит), либо немного схитрить и говорить что записано, в то время пока пишется.

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

Можно так примерно сравнить скорость в консольном клиенте(psql):

disarmer=> create table test(a integer);
disarmer=> \timing
disarmer=> insert into test (a) values(1);
INSERT 0 1
Время: 241,777 мс
disarmer=> SET synchronous_commit TO OFF;
SET
Время: 0,347 мс
disarmer=> insert into test (a) values(2);
INSERT 0 1
Время: 0,869 мс

Ясно, спасибо. Так и сделал.

SHOW PROCESSLIST же...

Это либо нехватка параметра kernel.shmall, либо уже занятая shared memory.

с какого полотка выставлять эти цифры: kernel.shmmax= - максимальное количество байт, доступное под shared memory. Например выставить его в количество доступной оперативной памяти компьютера, чтобы больше туда не лазить. kernel.shmall= - количество страниц, доступное под shared memory.

определяешь размер страницы, getconf PAGE_SIZE в дефолтных ядрах линукса это 4096 байт. и делишь устанавлиаемый kernel.shmmax на размер страницы.

также память может быть не освобождена, например после краха. посмотреть: man ipcs -m, если нет процессов, жующих её - man ipcrm.