По моему вы все перепутали относительно чекпоинтов…
1. checkpointer process фиксирует в датфайлах на диске только то что содержится в WAL журнале. Измененные страницы пишет bgwriter — отдельный процесс. Если он медленно работает (при дефолтных настройках) то за него грязные страницы будут скидывать бэкенды (обратите внимание на pg_stat_bgwriter.buffers_backend).
2. checkpoint_timeout это не то что вы написали, а время между выполнением двух чекпоинтов. если с момента выполнения последнего чекпоинта прошло время указанное в checkpoint_timeout, то запустится новый чекпоинт.
3. >> непрерывно монотонно
неправда, если он сделал свое дело, то он будет курить в сторонке (пока не наступит checkpoint_timeout или не запишется число сегментов указанное в checkpoint_segments). еще раз повторюсь, dirty pages сбрасываются bgwriter'ом и в крайнем случе бэкендами
4. >> Если в shared_buffers все страницы изменены, то воркерам придётся подождать
не будут они ждать, они сами начнут скидывать страницы на диск. а dba следует тюнить bgwriter_lru_multiplier
вобщем во втором абзаце у вас полное непонимание вопроса, как бы обидно это незвучало.
p.s. такие длинные коменты очень сложно читать, если вы хотите подискутировать напишите мне скайп.
backup_label.old остается от запуска pg после копирования pg_basebackup'ом (внутри у него так и написано LABEL: pg_basebackup base backup). А вот новый backup_label создается pg_rewind'ом (BACKUP METHOD: rewound with pg_rewind) и только потом при запуске postgres'а он переименовывается в backup_label.old. Увы, не умею читать сорцы но вполне подразумеваю что там какой-то отличный от pg_start/stop_backup механизм копирования.
Вообще у них там еще много работы, на прошлой неделе постил им тикет типа «перемотка не работает если после файловера в новом мастере удалить базу». И второй пример, на прошлой недели при сборке требовался один набор зависимостей, а на этой неделе к зависимостям уже добавились еще три пакета (devel пакеты для openssl, libxslt, pam). Так что можно не удивляться всяким странностям.
вот как раз потихоньку колупаю perf, мне нравится, пока нашел для него применение в целях определения тех мест в которых проводит свое время процесс (и сколько времени проводит).
про DISCARD ALL. Не скажу точно где (толи pgsql-hackers, толи pgsql-performance), но проскакивало что DISCARD ALL добавляет вполне ощутимый оверхед. Померять руки не дотянулись, но тем дядькам я вобщем доверяю. Да и вроде как время кривых orm прошло уже)))
да, zabbix очень гибок в плане добавления кастомных вещей, я как-то года два назад запилил простецкий мониторинг дырявых пакетов для redhat систем (на гитхабе).
Да, довольно легко. Но тем не менее, зависит от того что внутри базы. Простой пример двухдневной давности, провел обновление с 8.4 на 9.3 с pg_upgrade. Обновление прошло гладко, а все потому что там не было ничего кастомного (специфические контрибы, репликации в виде slony/londiste, системы очередей типа pgqd). Вот, поэтому перед обновлением нужно обратить внимание на такие вещи и где-нибудь в сторонке развернуть бэкап и проиграть сценарий обновления.
оставлю и я свои 5 копеек… бэкапы начиная с 9.1 можно делать через pg_basebackup это в разы удобнее чем pg_start/stop_backup+rsync. Очень и очень удобная вещь, к примеру выше есть коментарий, так вот есть такой ключ как -c fast и чекпоинт будет делаться asap, независимо от того что выставлено в checkpoint_timeout и checkpoint_completion_target. А в 9.4 уже есть коммит который реализует тротлинг… так что rsync будет не нужен)).
Спасибо за статью.
Сколько времени у вас проработала эта связка пгпулов, случались ли нештатные ситуации (вылет ноды из пула, отвал по простой проверке), если да, то как часто. И главный вопрос, какова нагрузка (кол-во запросов в сутки будет достаточно)?
У меня был не очень хороший опыт с пгпулом, и меня мягко говоря он разочаровал, поэтому интересно как у других.
Большое спасибо автору и коментаторам за интересную статью и содержательные коменты!
Есть пара вопросов:
Первый вопрос к EuroElessar, в одном из коментариев вы написали «Мы считаем sha512 от имени файла, получаем соответствующий записи ключ», а как быть в случае, когда нужно хранить много файлов с одинаковыми именами?
Второй вопрос, вот существует приложение которое работает с Elliptics, оно обращается к кластеру по какому-то ip-адресу, который принадлежит какой-либо ноде (предполагаю), и тут нода падает и ip-адрес становится недоступным. Соответственно приложение теряет кластер из виду. Как устраняется такая ситуация? Разъясните этот момент (хотя предполагаю что запущено несоклько прокси и у «приложения» есть список адресов кластера).
Может кому пригодится, написал Gentoo ebuild'ы для phantom и yandex-tank.
Установка и работа проверена с Python2.7.
Качество написания ebuild'ов, возможно оставляет желать лучшего)))
Присоединяюсь к вопросу.
Еще бывает интересно насколько изменилась (и изменилиась ли вообще) производительность/отзывчивость сервиса при обновлении ядра, системных пакетов, зависимостей и т.п.
еще добавлю чего сам знаю
F — операция объединена со смежной операцией в очереди; (front merge бывает в очень специфичных workloads, — объединяет запросы в начале очереди, deadline elevator позволяет отключать такое слияние)
M — операция объединена со смежной операцией в очереди; (back merge встречается гораздо чаще — объединение запросов в конце очереди)
1. checkpointer process фиксирует в датфайлах на диске только то что содержится в WAL журнале. Измененные страницы пишет bgwriter — отдельный процесс. Если он медленно работает (при дефолтных настройках) то за него грязные страницы будут скидывать бэкенды (обратите внимание на pg_stat_bgwriter.buffers_backend).
2. checkpoint_timeout это не то что вы написали, а время между выполнением двух чекпоинтов. если с момента выполнения последнего чекпоинта прошло время указанное в checkpoint_timeout, то запустится новый чекпоинт.
3. >> непрерывно монотонно
неправда, если он сделал свое дело, то он будет курить в сторонке (пока не наступит checkpoint_timeout или не запишется число сегментов указанное в checkpoint_segments). еще раз повторюсь, dirty pages сбрасываются bgwriter'ом и в крайнем случе бэкендами
4. >> Если в shared_buffers все страницы изменены, то воркерам придётся подождать
не будут они ждать, они сами начнут скидывать страницы на диск. а dba следует тюнить bgwriter_lru_multiplier
вобщем во втором абзаце у вас полное непонимание вопроса, как бы обидно это незвучало.
p.s. такие длинные коменты очень сложно читать, если вы хотите подискутировать напишите мне скайп.
Вообще у них там еще много работы, на прошлой неделе постил им тикет типа «перемотка не работает если после файловера в новом мастере удалить базу». И второй пример, на прошлой недели при сборке требовался один набор зависимостей, а на этой неделе к зависимостям уже добавились еще три пакета (devel пакеты для openssl, libxslt, pam). Так что можно не удивляться всяким странностям.
Сколько времени у вас проработала эта связка пгпулов, случались ли нештатные ситуации (вылет ноды из пула, отвал по простой проверке), если да, то как часто. И главный вопрос, какова нагрузка (кол-во запросов в сутки будет достаточно)?
У меня был не очень хороший опыт с пгпулом, и меня мягко говоря он разочаровал, поэтому интересно как у других.
Есть пара вопросов:
Первый вопрос к EuroElessar, в одном из коментариев вы написали «Мы считаем sha512 от имени файла, получаем соответствующий записи ключ», а как быть в случае, когда нужно хранить много файлов с одинаковыми именами?
Второй вопрос, вот существует приложение которое работает с Elliptics, оно обращается к кластеру по какому-то ip-адресу, который принадлежит какой-либо ноде (предполагаю), и тут нода падает и ip-адрес становится недоступным. Соответственно приложение теряет кластер из виду. Как устраняется такая ситуация? Разъясните этот момент (хотя предполагаю что запущено несоклько прокси и у «приложения» есть список адресов кластера).
Установка и работа проверена с Python2.7.
Качество написания ebuild'ов, возможно оставляет желать лучшего)))
Еще бывает интересно насколько изменилась (и изменилиась ли вообще) производительность/отзывчивость сервиса при обновлении ядра, системных пакетов, зависимостей и т.п.
F — операция объединена со смежной операцией в очереди; (front merge бывает в очень специфичных workloads, — объединяет запросы в начале очереди, deadline elevator позволяет отключать такое слияние)
M — операция объединена со смежной операцией в очереди; (back merge встречается гораздо чаще — объединение запросов в конце очереди)
Имею ввиду в вашей компании.