Один из наших клиентов, эксплуатирующий PostgreSQL под большой нагрузкой, столкнулся с проблемой, связанной с переполнением счетчика транзакций (xid wraparound), причем выхода из нее штатными средствами не существовало. Мы решили проблему с помощью хирургического вмешательства и выпустили патч, предотвращающий возникновение таких ситуаций в будущем.
В этой заметке мы расскажем, как и почему может произойти проблема и как ее не допустить.
When we think about robots, the first thing that comes to mind are robotic vacuum cleaners. The reason is simple: they are the most "solid" demonstration of success of "consumer" robotics. So making one sounds like a good idea... at first.
But isn't it a bit counter productive - to build something that popular, something we can buy in a store at a commodity (small) price? Should we build something similar, but NOT a vacuum cleaner? Something like... a floor washer, perhaps? Yes, a robotic floor washer.
In this tutorial I am going to build a fully working prototype of a robotic floor washer. By "fully working" I mean that it is going to wash floor, instead of moving dirt around like most robotic "moppers" do. While by "prototype" I mean it is going to be the first step towards production-ready unit, but not a production-ready unit yet. Let me explain.
First of all, it is not going to be THAT solid. You can grab a robotic vacuum cleaner that you got from the store by any part, including wheels and bumper and lift it. It will not fall apart. Ours probably will. The reason is, to make a device "mechanically solid" is a separate task, and if we focus on it, then "robotic" tasks will become more difficult to achieve. So we are going to do what engineers usually do: first they build C3PO without the outside body, wires everywhere and so on. And only then they put a gold-covered outfit on it.
Для многих систем характерен паттерн постоянного накопления данных с течением времени. Причем основная их масса больше никогда не изменяется - то есть они пишутся в режиме append-only.
Это не только различного рода логи и метрики оборудования, но и такие, казалось бы, несвязанные вещи, как переписка между пользователями или комментарии к новостям.
Около года назад я уже писал про модель организации секционирования таких данных и вызываемые этим каскадные изменения в структуре БД. А сегодня на примере нашего сервиса анализа логов PostgreSQL-серверов разберем особенности обслуживания организованных так баз, и как грамотный подход (и немного ночной работы) может сократить затраты на инфраструктуру в разы.
Всем привет! ITSumma на связи! Недавно — 8 февраля мы провели вебинар о мониторинге и обслуживании реляционной базы данных Greenplum.
При всех своих достоинствах у Greenplum есть подводные камни, о которых стоит знать разработчикам и администраторам. Один из таких потенциально опасных моментов — процедура сбора и удаления мусора, её ещё называют вакуумирование, потому что она инициируется командой Vacuum. Работать с вакуумированием нужно деликатно, иначе велик риск надолго нарушить работу всей системы. Как раз о том, как этого избежать, правильно мониторить и очищать таблицы, мы и рассказывали на вебинаре.
Это статья — выжимка нашего мероприятия. Вот что вы из неё узнаете:
С течением жизни приложения в его БД накапливается все больше данных. Десктопное оно, SaaS или даже мобильное - неважно, в современном мире почти каждый что-то хранит "у себя".
Если это какая-то локальная утилита - не страшно, само ее существование у пользователя достаточно ограничено. Но если это что-то вроде нашего СБИС, который накапливает и помогает анализировать операции за все время существования бизнеса, то, по мере его роста, не только операций становится больше, но и понимания, какие именно сводные отчеты помогают в оперативном управлении.
Вот про то, как сделать такие отчеты быстрыми, какие бывают способы их реализации и встречаются "грабли" на этом пути, сегодня и поговорим.
Тема "распухания" таблиц и индексов из-за реализации MVCC - больная для пользователей и администраторов PostgreSQL.
Однажды я уже поднимал ее в статье "DBA: когда пасует VACUUM — чистим таблицу вручную", разобрав на конкретных примерах, насколько драматический эффект для производительности запросов может оказывать невовремя проведенный или бесполезно отработавший из-за конкурентных транзакций VACUUM.
Но, помимо влияния на скорость, есть еще и факт влияния на занятое место. Наверное, вы сильно удивитесь, если таблица с единственной "живой" записью после успешного прохода autovacuum продолжит занимать гигабайты пространства на дорогих SSD.
Сегодня немного поисследуем структуру хранения данных в файлах и копнем pg_catalog - схему с описанием базы PostgreSQL, чтобы понять, как можно определить таблицы, которые явно занимают подозрительно много места.
Postgresql отличается от других СУБД тем, что в ней при операции UPDATE, изменений в существующей строке не происходит, а вместо этого делается копия строки, которая отличается от оригинала значениями колонок, затронутых апдейтом — в оригинале они старые, а в копии — изменённые. Этот подход с одной стороны позволяет избежать блокировок при одновременном выполнении запросов на чтение и запись а с другой стороны порождает необходимость постоянно вычищать старые версии строк, которые уже никто и никогда не прочитает. В связи с этой архитектурной фичей нередко возникает вопрос, что будет, если нужно хранить в БД что-то вроде времени последнего доступа к данным, которые в остальном не меняются. Не отзовётся ли это на производительности? Не приведёт ли к постоянной перестройке индексов?
Если коротко, то да, Copy On Write никуда не денется, но индексы во многих случаях можно будет не перестраивать, благодаря HOT.
Примечание редактора: Любые рекомендации по изменению параметров всегда стоит сравнивать в других докладах
Такой призыв часто возникает, когда в PostgreSQL возникают проблемы, и главным подозреваемым оказывается vacuum (далее по тексту просто "вакуум"). По опыту, многие наступают на эти грабли, и мне с коллегам по Data Egret нередко приходится разгребать последствия, так как потом всё становится ещё хуже. Но если обратить внимание на сам вакуум, то, пожалуй, нет такого человека, который бы использовал Postgres, и при этом ничего не знал про него. Ведь история вакуума начинается относительно давно, и в интернете можно найти массу как старых, так и новых постов про вакуум, объемные дискуссии в списках рассылки. Несмотря на то, что тема вакуума подробно описана в официальной документации к PostgreSQL, новые посты и новые дискуссии будут появляться и дальше. Возможно, поэтому с вакуумом связано очень много мифов, баек, страшилок и заблуждений. Между тем, вакуум является одним из важнейших компонентов PostgreSQL, и его работа напрямую сказывается на производительности. В одном докладе невозможно рассказать про вакуум абсолютно всё, но я бы хотел раскрыть ключевые моменты, связанные с вакуумом, такие как его внутреннее устройство, основные подходы к его настройке, наблюдение за производительностью, мониторинг, и что делать в случае, когда вакуум — главный подозреваемый во всех бедах. Ну и, конечно же, хочется развеять распространенные мифы и заблуждения, связанные с вакуумом.
fillfactor percent full. In this case, vacuum is performed right away without putting off till next time.