Ну для начала нужно понимать, что значит этот параметр.
shared_buffers устанавливает размер памяти, которая используется для контроля за клиентами, обслуживание активных операций, и прочего. Но следует знать, что параметры, которые отвечают за буфер базы данных, выделение памяти на сортировку и обслуживание базы задаются отдельно, поэтому shared_buffers не должен потреблять основной кусок памяти на машине.
Каждый процесс на 32 битной машине лимитирован в 4ГБ адресного пространства, где хотя бы 1ГБ (в Линуксе) зарезервирован ядром. Это означает, что не зависимо, сколько на машине памяти, каждый PostgreSQL инстанс сможет обратится максимум к 3ГБ памяти. И эта память включает в себя не только shared_buffers, но всю остальную память (сортировка, обслуживание, различные внутренние кеши, прочее). А учитывая, что shared_buffers рассчитывается как (RAM / 4), то 2-2.5ГБ — «упирание» в потолок, поскольку вы просто дальше будете забирать память от других не менее важных операций.
На 64 битных машинах нет такого лимита (более 1ТБ), но тут уже вступает факт в то, что разработчики указывают, что сам PostgreSQL может не справляется эффективно с обработкой большого (более 8Гб) shared_buffers. Хотя в некоторых случаях было указано, что shared_buffers более 8Гб дает прирост производительности (но только в том случае, если вся база влазит в shared_buffers). Но это не указание к действию, это нужно проверять только практически.
Добрый день. Установка shared_buffers больше 8 ГБ не даёт никакого хорошего эффекта на Linux (тем более что на 32 битных более 2-2.25ГБ тоже ведут к ухудшению). Так что даже тут калькулятор уже Вам помог. Остальные параметры нельзя просто поставить по формуле, поскольку факторы не однозначны (тип SSD дисков, запросы, влазят ли индексы в кеш, и т.д.), и вот такие параметры точно могут принести вред при настройке PostgreSQL.
Как я понял на видео, вы переключаетесь на slave (через триггер файл), делаете изменение на новом мастере (кем стал slave) и начатываете изменения на старый мастер из нового через pg_rewind. И вот в перед запуском старого мастера как slave, я заметил, что вы чистите определенные файлы в (6:03 минута на видео), например backup_label. Этот файл создается при использовании
SELECT pg_start_backup('label')
Но должен сам и чистится через
SELECT pg_stop_backup()
Тоесть pg_rewind не говорит остановить бэкап для мастера (дифф подчитается с wal логов, это ясно). Вопрос: почему так?
P.S. pg_rewind очень напомнил как работает восстановление в wal-e
> В теории даже минорный апдейт билда сервера может сломать возможность восстановить БД.
Минорный точно не сломает. Мажорные апдейты ломали совместимость до 9.3 (но гарантии нет, что опять будут менять). Но минорный на то и минорный, что только баг-фиксы (если что то ломается — например баг в тех же Wal-логах — будет писаться большими буквами в релизе)
Поэтому бекапы, как ни крути, нужны. Большая база бекапится у нас около часа. Практически всё это время проект бездействует. Тут, откровенно говоря, посоветовать ничего не могу. Наоборот, буду рад выслушать, кто и как с ситуацией справляется. Единственная мысль — бить на шарды и бекапить кусками, думая, как при этом сохранить консистентность данных.
Используйте непрерывное резервное копирование. Если делать просто бэкапы — есть огромная возможность просто потерять данные за какое то время (ведь бэкапы делаются раз в N дней/недель). Мы использовали WAL-E и Barman. Обе утилиты отлично справляются. Восстанавливать можно до какого то лога или временной метки (если кто то запустил DELETE/TRUNCATE/DROP на весь кластер). Больше можно почитать тут.
Я на основе Sphero сделал систему нотификации при падении тестов на CI (как замену популярному светофору). Я только использовал Ruby для написания кода. Кстати, 2 версия Sphero — полупрозрачная.
У нас до 100 машин на один Chef Server (у каждого проекта свой сервер, на самом большом проекте уже больше 100, но точное число глянуть не могу — нет доступа). На текущем пока только 24 машины. Не много, но есть и berkshelf, vagrant, chef-zero, fauxhai, chefspec, test-kitchen — развернуть одну ноду на основе кукбуков, ролей и прочего делается на локальной машине (что мы называем development environment) при разработке с покрытием тестами (например меняем ноду роли веб). Далее выкатываем на стейджинг — staging environment (через env и env_run_lists). Если вдруг сломался (риск минимизирован через тесты) — откатываем, чиним, и опять в бой. При успехе раскидывам как нужно по ролям и env, заливаем в мастер ветку и загружаем в сервер. Процес не быстрый, но пока ни одного сбоя (хоть за последнее время все работы сводятся к поддержки кукбуков и софта на нодах «up to date» ).
Если ещё berkshelf использовать, то указание версий в Chef Environments тоже не будет удобным.
Указываем только особо важные кукбуки (или перед тестированием на staging, если просто обновляем вендорные кукбуки).
Локальное окружение и dev — обычно разные вещи.
Вы правы. В моем понимании dev (development environment) — это там, где ведется разработка и первичное тестирование — его машина (ноутбук).
В данном коментарии я написал как вообще делается подход разработки или изменения кухни.
Такая же ситуация и с рецептами: обновил cookbook и везде, где его версия строго не была зафиксирована, он обновится (и что-нибудь сломает).
Укажите версии в env.
Кстати, в вашем же случае отключение chef-client как демон — не спасение! Это просто надежда, что «вот пока я буду разрабатывать/тетсить/исправлять баг» никто не додумается запустить chef-client на проде.
Поэтому сначала это и делается на dev (тоесть локальной машине). Я против тестирования вообще на живую на реальном сервере. На сервер заливается уже готовый результат.
PS. В примере выше через knife ssh запускалась команда tail, а не chef-client. Сам по себе knife ssh не запускает реконфигурацию.
B по логам той команды четко видно, что chef-client демонизирован на проверку каждые 5 минут :) и данная команда через knife ssh запускает (была указана в этом коментарии):
Вот именно: «knife ssh» нужно, чтобы выполнить (как я писал после «knife role edit|load from file» ничего не изменится на нодах) или же ставить chef-client как демон (для тестирования мы эту возможность отключаем). А как я писал, никто не запрещает делать эту команду, ограничивая env для роли :)
Тоесть для dev и test я указал специфичные run_list, остальные будут использовать стандартный.
По поводу атрибутов — это очень гибкая вещь. можно тестовые запихать по неймспейсу env:
attribute_i_want = node[node.chef_environment]
Или просто ложим в env :)
Здесь речь о CI/CD — когда инфраструктурный код движется от дев к проду
Используя систему контроля версий создаете отдельную ветку в chef-repo, дальше тестируете в dev (который находится на вашей машине), используя chef-zero и vagrant, что бы не затрагивать основной сервер. По завершению — мерджим в мастер и заливаем на сервер. Вот так делаем движение от dev to prod.
Никто не мешает вообще и по ssh зайти и ручками что-то поменять, но тогда зачем Chef?
В моем примере все делается через knife, усугубления «руками» или работа без Chef в нем не присутствуют.
Теперь представьте, что вам нужно разделить эти сайты на две роли app_server и blog_server. Ну и как вы собираетесь это тестировать на dev окружении?
Применяю обе роли на ноду в dev окружении.
Можно рискнуть и надеяться, что все будет ОК или перезаписать атрибуты в Chef Environments (сначала на dev, потом на qa и т.д.) и не забыть почистить их после того, как они попадут на продакшн. Не самый лучший вариант.
А зачем чистить атрибуты environment, которые не касаются продакшена (а значит при правильном использовании никогда там не будут видны)? Как раз при тестировании нового функционала закидываете атрибуты в env, тестируете только на нем, и если все ок — выносите в роль.
Chef роли кажутся идеальнами для хранения списка запускаемых рецептов. Однако, этот подход страдает теми же недостатками, что и предыдущий антипаттерн. Если вы добавите или удалите рецепт из списка run_list в роли, то эти изменения применятся ко всем серверам с этой ролью, включая продакшн серверы.
Это никто не заставляет вас делать. Никто вам не помещает сделать:
knife ssh -E dev ‘role:webapp’ ‘sudo chef-client’
Который только затронет dev environment с ролью webapp.
— сбор информации о железе и конфигурациях серверов,
— мониторинг состояния хостов.
Это не входит в список задач Chef. Или хотите сказать, что он уведомляет, если нода не доступна стала, или когда на ноде закончилась память? И мы говорим про Chef, а не Nagios, Cacti или еще что, конфигурируется на нодах через Chef.
А где само тестирование через Test Kitchen? Где bats, minitest? Где вообще тесты?
Из данного лога видно что кукбук sendmail успешно скачался и пакет sendmail был установлен.
Такое можно было сделать и без Test Kitchen на Vagrant и увидеть в логе как отрабатывает chef-client. Тем более проверку установки пакета можно прогнать и через chefspec, и тогда даже Vagrant не потребуется.
В этой статье рассказано как тестировать кукбуки используя подобные инструменты.
Большой парк — понятие не точное. У нас есть проекты, где через Chef Solo разворачивается до 50 машин. И ничего. А есть, где уже из-за 10 машин подняли сервер. Для начала, нужно уяснить что Вам даст Chef Server по сравнению с тем же Solo, и стоит ли он этих усилий (ведь сразу первый минус Chef Server по сравнению с Solo — у Вас появилась точка отказа).
shared_buffers устанавливает размер памяти, которая используется для контроля за клиентами, обслуживание активных операций, и прочего. Но следует знать, что параметры, которые отвечают за буфер базы данных, выделение памяти на сортировку и обслуживание базы задаются отдельно, поэтому shared_buffers не должен потреблять основной кусок памяти на машине.
Каждый процесс на 32 битной машине лимитирован в 4ГБ адресного пространства, где хотя бы 1ГБ (в Линуксе) зарезервирован ядром. Это означает, что не зависимо, сколько на машине памяти, каждый PostgreSQL инстанс сможет обратится максимум к 3ГБ памяти. И эта память включает в себя не только shared_buffers, но всю остальную память (сортировка, обслуживание, различные внутренние кеши, прочее). А учитывая, что shared_buffers рассчитывается как (RAM / 4), то 2-2.5ГБ — «упирание» в потолок, поскольку вы просто дальше будете забирать память от других не менее важных операций.
На 64 битных машинах нет такого лимита (более 1ТБ), но тут уже вступает факт в то, что разработчики указывают, что сам PostgreSQL может не справляется эффективно с обработкой большого (более 8Гб) shared_buffers. Хотя в некоторых случаях было указано, что shared_buffers более 8Гб дает прирост производительности (но только в том случае, если вся база влазит в shared_buffers). Но это не указание к действию, это нужно проверять только практически.
В любой случае тюнинг дело тонкое :)
Как я понял на видео, вы переключаетесь на slave (через триггер файл), делаете изменение на новом мастере (кем стал slave) и начатываете изменения на старый мастер из нового через pg_rewind. И вот в перед запуском старого мастера как slave, я заметил, что вы чистите определенные файлы в (6:03 минута на видео), например backup_label. Этот файл создается при использовании
SELECT pg_start_backup('label')Но должен сам и чистится через
SELECT pg_stop_backup()Тоесть pg_rewind не говорит остановить бэкап для мастера (дифф подчитается с wal логов, это ясно). Вопрос: почему так?
P.S. pg_rewind очень напомнил как работает восстановление в wal-e
Минорный точно не сломает. Мажорные апдейты ломали совместимость до 9.3 (но гарантии нет, что опять будут менять). Но минорный на то и минорный, что только баг-фиксы (если что то ломается — например баг в тех же Wal-логах — будет писаться большими буквами в релизе)
Используйте непрерывное резервное копирование. Если делать просто бэкапы — есть огромная возможность просто потерять данные за какое то время (ведь бэкапы делаются раз в N дней/недель). Мы использовали WAL-E и Barman. Обе утилиты отлично справляются. Восстанавливать можно до какого то лога или временной метки (если кто то запустил DELETE/TRUNCATE/DROP на весь кластер). Больше можно почитать тут.
Указываем только особо важные кукбуки (или перед тестированием на staging, если просто обновляем вендорные кукбуки).
Вы правы. В моем понимании dev (development environment) — это там, где ведется разработка и первичное тестирование — его машина (ноутбук).
Укажите версии в env.
Поэтому сначала это и делается на dev (тоесть локальной машине). Я против тестирования вообще на живую на реальном сервере. На сервер заливается уже готовый результат.
B по логам той команды четко видно, что chef-client демонизирован на проверку каждые 5 минут :) и данная команда через knife ssh запускает (была указана в этом коментарии):
knife ssh -E dev ‘role:webapp’ ‘sudo chef-client'Ну во первых применится — но не будет выполнена (chef-client сам не узнает про изменения). Вариатны решения без усугубления «Все в кукбуку»:
1) ничто не мешает нам создать отдельную роль (с атрибутами и ран листами) и тестировать на ней, а потом перенести в основную
2) никто не запрещал использовать специальные run_list для env:
{ "name": "webserver", "default_attributes": { }, "json_class": "Chef::Role", "env_run_lists": { "test": [ "role[base]", "recipe[apache]", "recipe[apache::copy_test_configs]" ], "dev": [ "role[base]", "recipe[apache]", "recipe[apache::copy_dev_configs]" ] }, "run_list": [ "role[base]", "recipe[apache]" ], "description": "The webserver role", "chef_type": "role", "override_attributes": { } }Тоесть для dev и test я указал специфичные run_list, остальные будут использовать стандартный.
По поводу атрибутов — это очень гибкая вещь. можно тестовые запихать по неймспейсу env:
attribute_i_want = node[node.chef_environment]
Или просто ложим в env :)
Используя систему контроля версий создаете отдельную ветку в chef-repo, дальше тестируете в dev (который находится на вашей машине), используя chef-zero и vagrant, что бы не затрагивать основной сервер. По завершению — мерджим в мастер и заливаем на сервер. Вот так делаем движение от dev to prod.
В моем примере все делается через knife, усугубления «руками» или работа без Chef в нем не присутствуют.
Применяю обе роли на ноду в dev окружении.
А зачем чистить атрибуты environment, которые не касаются продакшена (а значит при правильном использовании никогда там не будут видны)? Как раз при тестировании нового функционала закидываете атрибуты в env, тестируете только на нем, и если все ок — выносите в роль.
Это никто не заставляет вас делать. Никто вам не помещает сделать:
knife ssh -E dev ‘role:webapp’ ‘sudo chef-client’Который только затронет dev environment с ролью webapp.
Это не входит в список задач Chef. Или хотите сказать, что он уведомляет, если нода не доступна стала, или когда на ноде закончилась память? И мы говорим про Chef, а не Nagios, Cacti или еще что, конфигурируется на нодах через Chef.
Такое можно было сделать и без Test Kitchen на Vagrant и увидеть в логе как отрабатывает chef-client. Тем более проверку установки пакета можно прогнать и через chefspec, и тогда даже Vagrant не потребуется.
В этой статье рассказано как тестировать кукбуки используя подобные инструменты.