Comments 16
Странно что вы не рассказали про настройку логирования. А это надо делать в первую очередь перед запуском кластера.
Много лет внутри ВМ используем nobarrier, но лучше почитать сначала доводы против.
К сожалению, мы все таки не можем так рисковать. Дело в том, что многие наши клиенты вообще не используют асинхронную реплику для резервирования. И в случае падения базы, можно считать, что целый день очень много людей работали зря. По этой же причине на всякий случай не отключаем и full_page_writes.
Но если есть сервер с асинхронной репликой с такими же характеристиками как и основной (что получается в 2 раза дороже), то я думаю можно для ускорения и nobarrier поставить, и full_page_writes отключить. А если уж совсем рисковать, то вообще вырубить fsync = off.
>Это удобно тем, что потом можно легко при необходимости менять ОС, просто подключая диск с базой данных к другой виртуальной машине.
А так точно можно делать? Просто в своё время я не смог настроить физическую репликацию между Centos 7 и Alt Linux, была ошибка о том, что операционные системы должны быть идентичными. Это наводит на определённые мысли...
Много раз так делал - никаких проблем не возникало. Именно так переключались между CentOS 8 и CentOS 7 для тестирования. С физической репликой не доводилось настраивать между совсем разными ОС, но если честно не понимаю почему должны быть проблемы.
насколько помню, разница в винде и линуксе. Между линуксами не должно быть проблем. Это изза особенностей реализации сетевого стэка, который не захотели пилить под винду.
Кстати, вот как раз недавно как раз возникла проблема. Правда не при переподключении диска, а при переключении на реплику (что в принципе тоже самое) на другой версии ОС (c CentOS 7 на CentOS 8).
Проблема может возникнуть со индексами по строкам, если они содержат специфические символы. Дело в том, что PostgreSQL сравнивает строки используя общие библиотеки из ОС. А в разных ОС могут быть разные реализации сравнения хитрых символов (понятно, что цифры и латинские буквы сравниваются одинаково). В итоге такие индексы становятся невалидными (и самое печальное, что это обнаруживается только через некоторое время). Лечится простой переиндексацией таких индексов. Так что это надо иметь ввиду при переезде между ОС. Планируется, что в следующих версиях PostgreSQL это изменят.
Ни в коем случае не в обиду автору, но статья не понравилась. Новичка очень сильно запутает. Тут автор пытался охватить слишком обширный кусок, но всё это уместить в такую маленькую статью нереально.
Например, установка СУБД рассчитана совсем на новичков. А дальше... Не сказано про pg_settings, откуда можно узнать, можно ли делать просто pg_reload_conf или нужно перезапускать всю СУБД. work_mem -- не написано, что если его будет не хватать, но будет много временных файлов, как это распознать (pgbadger и т.д.) тоже не сказано. shared_buffers -- тоже слабовато описано, вроде как рекомендуется ставить 25%, но если на сервере очень много RAM. maintenance_work_mem -- не написано, почему поставили 2 ГБ. В некоторых случаях это может быть слишком много. Чекпоинты -- ну новичок точно ничего не поймёт. vm.min_free_kbytes -- почему столько, что это вообще такое.
Новичок не поймёт, а более опытный не узнает ничего нового. Лучше просто дать ссылку на pgtune уж тогда.
Цель статьи в том, чтобы показать какие настройки мы устанавливаем для своих приложений. Тем самым я хотел показать, что в настройках PostgreSQL нет ничего сложного. И любой новичок, может установить просто параметры как в статье, глубоко не вникая в них. При этом все будет уже работать достаточно эффективно.
Если нужно почитать более подробно про любые параметры, то они хорошо описаны в официальной документации (или на русском языке в postgres pro).
Коллеги, а не подскажите, где тут теперь хабр?
Каждое подключение к PostgreSQL - это отдельный процесс в ОС. По мере выполнения запросов эти процессы не всегда быстро отдают использованную память обратно операционной системе. Для того чтобы бороться с этим, платформа время от времени закрывает активные подключения и открывает их заново
Довольно странное решение. В сессии кешируются данные, данные могут быть переиспользованы, и это как бы хорошо. Если сессии начинают потреблять много памяти, уменьшаем лимиты памяти на сессии, либо оптимизируем код. Реинициализация сессий приводит к тому, что эффект от кеширования пропадает.
Synchronous_commit также отключаем, так как мы не пишем банковские системы. Если сервер упадет (что бывает крайне редко), то нет принципиальной разницы успело пользователю прийти сообщение об успешном сохранении или нет. Зато все сохранения будут работать чуть-чуть быстрее.
Тут важны детали. Очень странный критерий - банковская система.
А правильный - если при коммите, хотим иметь гарантию, что изменения на диске, то ставим on.
Если гарантия не нужна, можно отключить.
Довольно странное решение. В сессии кешируются данные, данные могут быть переиспользованы, и это как бы хорошо. Если сессии начинают потреблять много памяти, уменьшаем лимиты памяти на сессии, либо оптимизируем код. Реинициализация сессий приводит к тому, что эффект от кеширования пропадает.
А можете уточнить, о каком именно кэше идет речь ? Shared buffers общий для всех процессов. И про какие лимиты памяти на сессии идет речь ? Work_mem - это лимит даже не на запрос, а одну операцию.
Тут важны детали. Очень странный критерий - банковская система.
Да, это не критерий, конечно же. Тут скорее это критично для операций с распределенными транзакциями. Банковская система - это просто один из наиболее распространенных примеров, когда будет очень плохо, если в одной системе деньги списались, а в другой - нет.
Довольно странное решение. В сессии кешируются данные, данные могут быть переиспользованы, и это как бы хорошо. Если сессии начинают потреблять много памяти, уменьшаем лимиты памяти на сессии, либо оптимизируем код. Реинициализация сессий приводит к тому, что эффект от кеширования пропадает.
Проблема в том, что в Postgres похоже есть явная утечка памяти (во всяком случае при работе с временными таблицами и большом количестве разных сложных запросов). То есть долго существующие соединения при такой схеме постепенно подъедают память, пока не сожрут ее полностью. Это очень хорошо на графиках мониторинга видно (выключаешь перестарт соединений, линия потребления начинает постепенно уходить вниз до нуля, после чего здравствуй своп / oom killer и сервер БД ложится). Видимо поэтому существуют мифы, что Postgres не тянет больше 1к одновременных соединений и вообще без пулинга из очень малого количества соединений не может эффективно работать.
Ну и надо сказать, что при выборе соединений на перестарт используется сложная система скоринга (пытающаяся определить "зажравшиеся" соединения) и один из параметров это время жизни соединения, который все же старается не перестартовывать недолго существующие соединения, чтобы эффективно утилизировать использование их кэшей.
Мусорная статья. Конфигурации сервера нет. Какая используется ОС и версии Postgre информации нет. Настройки приведены не понятно для чего
Настройка PostgreSQL под Linux