PostgreSQL checkpoints are occurring too frequently #800815

Добрый день. Глянул лог постгреса и увидел кучу предупреждений. checkpoints are occurring too frequently. Настройки по чекпоинтам не трогал - они типовые. Не могу толком найти по оптимальным настройкам чекпоинтов для 1с баз. На итс вот так: checkpoint_segments = 32..256   < 9.5 что это значит я не понял

Не, ну ясно, что до версии 9.5 советуют 32-256, но вот как конкретно расчитать

а что вот тут checkpoint_warning ?

а сейчас сколько? поставь больше в 1.5 раза

сейчас 3 по умолчанию.

checkpoint_segments

поставил 32 как советуют минимум, но я не понимаю как рассчитать оптимальное значение

может все таки нужно настроить

checkpoint_timeout

checkpoint_timeout (integer) Maximum time between automatic WAL checkpoints, in seconds. The default is five minutes (5min) т.е. они считают, что 5 минут норм. И влияет это только на время восстановления после сбоя. Если диски справляются ставим побольше, не справляются поменьше. Наверное

на самом деле чекпойнт происходит по достижению либо 1 либо 2 параметра

в смысле параметры checkpoint_segments надо подогнать чтобы чекпойнт случался где то раз в 5 минут или из других соображений. А убрать варнинг можно настроив checkpoint_warning

Можно поставить заведомо большее значении, тогда будет раз в 5 мин

не зря же два параметра, варнинг как то осмысленно должен настраиваться

2 параметра скорее всего ибо так исторически сложилось

врятли, может быть осмысленно для высоких пиковых нагрузок поставить, что при обычной нагрузке чекпойнт по таймауту триггерится, а при пике по сегментам, чтобы не выжрать какие то буферы/память

Ну вообще, при обновлении базы вывалилось: Out of memory for query result. Залез в лог чтоб разобраться что и как, а там только предупреждения по чекпоинтам. Не знаю, оно-нет.

не оно, лучше бы сразу написал ошибку

ну в логе больше нет ничего.

хз куда копать, думал может оно. А из-за чего может вообще так ругаться и не писать в логах?

нашёл, что есть ещё проблема с деградацией индексов на 9.4. А у нас как раз 9.4.

вбиваешь в гугл ошибку, тыкаешь искать только на русском. Еще перевести можно

ну так первым делом так и было. пробовал: - mergejoin = off - настройка work_mem и связанных с этим вещей - увеличение файла подкачки на диске с базами Ничего из этого не сработало. Что ещё не пробовал: - обновить платформу 1с. У нас 8.3.9.2033. Не думаю, что в этом дело - обновить postgresql. У нас 9.4. Возможно и в этом дело, как появится возможность, надо будет попробовать. - купить лицензию на 64-х битный агент сервера 1с - хочу сначала разобраться какой конкретно памяти не хватает прежде, чем отвалить xyz тыщь рублей.

Ну вот сейчас на rphost >2 гигов тратится.

Потому что не надо работать с типовыми настройками! Вот где можно почитать и объясняется что и как:

+ Настройка сервера: #настройка-сервера

кстати на 9.5 этой проблемы нет

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

может и правда обновиться. 9.6 вроде последняя под 1с

Для ленивых: Для увеличения интервала между контрольными точками нужно увеличить количество сегментов журнала транзакций через параметр checkpoint_segments. Данный параметр определяет количество сегментов (каждый по 16 МБ) лога транзакций между контрольными точками. Этот параметр не имеет особого значения для базы данных, предназначенной преимущественно для чтения, но для баз данных со множеством транзакций увеличение этого параметра может оказаться жизненно необходимым. В зависимости от объема данных установите этот параметр в диапазоне от 12 до 256 сегментов и, если в логе появляются предупреждения (warning) о том, что контрольные точки происходят слишком часто, постепенно увеличивайте его. Место, требуемое на диске, вычисляется по формуле (checkpoint_segments * (2 + checkpoint_completion_target) + 1) * 16 МБ, так что убедитесь, что у вас достаточно свободного места. Например, если вы выставите значение 32, вам потребуется больше 1 ГБ дискового пространства. Следует также отметить, что чем больше интервал между контрольными точками, тем дольше будут восстанавливаться данные по журналу транзакций после сбоя. Начиная с версии 9.5 checkpoint_segments был заменен на параметры min_wal_size и max_wal_size. Теперь система может автоматически сама решать сколько checkpoint_segments требуется хранить (вычислять по ранее приведенной формуле от указанного размера). Преимуществом этого является то, что вы можете установить max_wal_size очень большим, но система не будет на самом деле потреблять указанное количество места на жестком диске, если в этом нет никакой необходимости. min_wal_size устанавливает минимальный размер места, который будет использоваться сегментами (можно отключить такую автонастройку, установив для min_wal_size и max_wal_size одинаковое значение).

Ну чо, нашел оптимальное значение?

Последний пост в теме по ссылке. Под клиентом для PostgreSQL понимается сервер приложений 1С. Обнови до СУБД до версии 9.6.3-1.1C, она есть уже даже на users.v8.1c.ru

Не то.

на чекпоинты-то ругаться перестал, но выдаёт: 2017-07-14 01:00:03 AZST STATEMENT:  SELECT tableoid, oid, nspname, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = nspowner) AS rolname, nspacl FROM pg_namespace 2017-07-14 01:00:03 AZST LOG:  Can't find mchar/mvarvarchar types: mchar=0 mvarchar=0 9.6.3 конечно хорошо, но pg_dump 9.6.3 does not dump the schema with this command: The missing 'public' schema was not an issue in 9.6.2.

про Can't find mchar/mvarvarchar types: mchar=0 mvarchar=0 вроде не смертельно - какая-то ошибка 1сного допила, связанная с интдексацией.