Обновить
0
@quitterread⁠-⁠only

Пользователь

Отправить сообщение

Потрошим golang: как устроена память

Время на прочтение18 мин
Охват и читатели58K


Привет, меня зовут Стас Иванкевич, и я работаю в VK Cloud над разработкой облачных сервисов в команде Data Masters. Сервисы, запрошенные клиентами, так или иначе должны развернуться в том виде, в котором клиенты их запросили, в адекватные сроки и без ошибок. Существует множество механизмов, позволяющих этого достичь, и еще больше существует ошибок и проблем, которые мешают в достижении этих целей.

Для любого специалиста, наверное, самой грустной ошибкой будет та, которая рождается из его незнания используемого инструмента. Наверняка практически каждый разработчик со сколь-нибудь большим опытом работы не раз сталкивался с такими проблемами хотя бы раз.

Единственным надежным решением таких проблем является глубокое погружение в теорию и исследования инструмента, которым решаются поставленные проблемы. В нашем случае таким инструментом является язык Go. И как же замечательно, что исследование его внутренностей — совсем легкое дело. В том числе когда дело касается использования памяти.
Читать дальше →

Блокировки в PostgreSQL: 1. Блокировки отношений

Время на прочтение14 мин
Охват и читатели169K
Два предыдущих цикла статей были посвящены изоляции и многоверсионности и журналированию.

В этом цикле мы поговорим о блокировках (locks). Я буду придерживаться этого термина, но в литературе может встретиться и другой: замóк.

Цикл будет состоять из четырех частей:

  1. Блокировки отношений (эта статья);
  2. Блокировки строк;
  3. Блокировки других объектов и предикатные блокировки;
  4. Блокировки в оперативной памяти.

Материал всех статей основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov, но не повторяет их дословно и предназначен для вдумчивого чтения и самостоятельного экспериментирования.
Читайте и другие серии.

Индексы:

  1. Механизм индексирования;
  2. Интерфейс метода доступа, классы и семейства операторов;
  3. Hash;
  4. B-tree;
  5. GiST;
  6. SP-GiST;
  7. GIN;
  8. RUM;
  9. BRIN;
  10. Bloom.

Изоляция и многоверсионность:

  1. Изоляция, как ее понимают стандарт и PostgreSQL;
  2. Слои, файлы, страницы — что творится на физическом уровне;
  3. Версии строк, виртуальные и вложенные транзакции;
  4. Снимки данных и видимость версий строк, горизонт событий;
  5. Внутристраничная очистка и HOT-обновления;
  6. Обычная очистка (vacuum);
  7. Автоматическая очистка (autovacuum);
  8. Переполнение счетчика транзакций и заморозка.

Журналирование:

  1. Буферный кеш;
  2. Журнал предзаписи — как устроен и как используется при восстановлении;
  3. Контрольная точка и фоновая запись — зачем нужны и как настраиваются;
  4. Настройка журнала — уровни и решаемые задачи, надежность и производительность.


Читать дальше →

Блокировки в PostgreSQL: 2. Блокировки строк

Время на прочтение14 мин
Охват и читатели118K
В прошлый раз мы говорили о блокировках на уровне объектов, в частности — о блокировках отношений. Сегодня посмотрим, как в PostgreSQL устроены блокировки строк и как они используются вместе с блокировками объектов, поговорим про очереди ожидания и про тех, кто лезет без очереди.



Блокировки строк


Устройство


Напомню несколько важных выводов из прошлой статьи.

  • Блокировка должна существовать где-то в разделяемой памяти сервера.
  • Чем выше гранулярность блокировок, тем меньше конкуренция (contention) среди одновременно работающих процессов.
  • С другой стороны, чем выше гранулярность, тем больше места в памяти занимают блокировки.

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

Есть разные пути решения этой проблемы. В некоторых СУБД происходит повышение уровня блокировки: если блокировок уровня строк становится слишком много, они заменяются одной более общей блокировкой (например, уровня страницы или всей таблицы).

Как мы увидим позже, в PostgreSQL такой механизм тоже применяется, но только для предикатных блокировок. С блокировками строк дело обстоит иначе.
Читать дальше →

Блокировки в PostgreSQL: 3. Блокировки других объектов

Время на прочтение15 мин
Охват и читатели48K
Мы уже поговорили о некоторых блокировках на уровне объектов (в частности — о блокировках отношений), а также о блокировках на уровне строк, их связи с блокировками объектов и об очереди ожидания, не всегда честной.

Сегодня у нас сборная солянка. Начнем с взаимоблокировок (вообще-то я собирался рассказать о них еще в прошлый раз, но та статья и так получилась неприлично длинной), затем пробежимся по оставшимся блокировкам объектов, и в заключение поговорим про предикатные блокировки.

Взаимоблокировки


При использовании блокировок возможна ситуация взаимоблокировки (или тупика). Она возникает, когда одна транзакция пытается захватить ресурс, уже захваченные другой транзакцией, в то время как другая транзакция пытается захватить ресурс, захваченный первой. Это проиллюстрировано на левом рисунке ниже: сплошные стрелки показывают захваченные ресурсы, пунктирные — попытки захватить уже занятый ресурс.

Визуально взаимоблокировку удобно представлять, построив граф ожиданий. Для этого мы убираем конкретные ресурсы и оставляем только транзакции, отмечая, какая транзакция какую ожидает. Если в графе есть контур (из вершины можно по стрелкам добраться до нее же самой) — это взаимоблокировка.


Читать дальше →

Блокировки в PostgreSQL: 4. Блокировки в памяти

Время на прочтение11 мин
Охват и читатели46K
Напомню, что мы уже поговорили о блокировках отношений, о блокировках на уровне строк, о блокировках других объектов (включая предикатные), и о взаимосвязи разных типов блокировок.

Сегодня я заканчиваю этот цикл статьей про блокировки в оперативной памяти. Мы поговорим о спин-блокировках, легких блокировках и закреплении буфера, а также про средства мониторинга ожиданий и семплирование.


Читать дальше →

Locks in PostgreSQL: 1. Relation-level locks

Время на прочтение13 мин
Охват и читатели24K
The previous two series of articles covered isolation and multiversion concurrency control and logging.

In this series, we will discuss locks.

This series will consist of four articles:

  1. Relation-level locks (this article).
  2. Row-level locks.
  3. Locks on other objects and predicate locks.
  4. Locks in RAM.

The material of all the articles is based on training courses on administration that Pavel pluzanov and I are creating (mostly in Russian, although one course is available in English), but does not repeat them verbatim and is intended for careful reading and self-experimenting.

Many thanks to Elena Indrupskaya for the translation of these articles into English.



General information on locks


PostgreSQL has a wide variety of techniques that serve to lock something (or are at least called so). Therefore, I will first explain in the most general terms why locks are needed at all, what kinds of them are available and how they differ from one another. Then we will figure out what of this variety is used in PostgreSQL and only after that we will start discussing different kinds of locks in detail.
Read more →

Locks in PostgreSQL: 2. Row-level locks

Время на прочтение14 мин
Охват и читатели16K
Last time, we discussed object-level locks and in particular relation-level locks. In this article, we will see how row-level locks are organized in PostgreSQL and how they are used together with object-level locks. We will also talk of wait queues and of those who jumps the queue.



Row-level locks


Organization


Let's recall a few weighty conclusions of the previous article.

  • A lock must be available somewhere in the shared memory of the server.
  • The higher granularity of locks, the lower the contention among concurrent processes.
  • On the other hand, the higher the granularity, the more of the memory is occupied by locks.

There is no doubt that we want a change of one row not block other rows of the same table. But we cannot afford to have its own lock for each row either.

There are different approaches to solving this problem. Some database management systems apply escalation of locks: if the number of row-level locks gets too high, they are replaced with one, more general lock (for example: a page-level or an entire table-level).

As we will see later, PostgreSQL also applies this technique, but only for predicate locks. The situation with row-level locks is different.
Read more →

Locks in PostgreSQL: 3. Other locks

Время на прочтение14 мин
Охват и читатели21K
We've already discussed some object-level locks (specifically, relation-level locks), as well as row-level locks with their connection to object-level locks and also explored wait queues, which are not always fair.

We have a hodgepodge this time. We'll start with deadlocks (actually, I planned to discuss them last time, but that article was excessively long in itself), then briefly review object-level locks left and finally discuss predicate locks.

Deadlocks


When using locks, we can confront a deadlock. It occurs when one transaction tries to acquire a resource that is already in use by another transaction, while the second transaction tries to acquire a resource that is in use by the first. The figure on the left below illustrates this: solid-line arrows indicate acquired resources, while dashed-line arrows show attempts to acquire a resource that is already in use.

To visualize a deadlock, it is convenient to build the wait-for graph. To do this, we remove specific resources, leave only transactions and indicate which transaction waits for which other. If a graph contains a cycle (from a vertex, we can get to itself in a walk along arrows), this is a deadlock.


Read more →

Locks in PostgreSQL: 4. Locks in memory

Время на прочтение10 мин
Охват и читатели18K
To remind you, we've already talked about relation-level locks, row-level locks, locks on other objects (including predicate locks) and interrelationships of different types of locks.

The following discussion of locks in RAM finishes this series of articles. We will consider spinlocks, lightweight locks and buffer pins, as well as events monitoring tools and sampling.


Read more →

Запросы в PostgreSQL: 1. Этапы выполнения

Время на прочтение17 мин
Охват и читатели113K

Привет, Хабр! Начинаю еще один цикл статей об устройстве PostgreSQL, на этот раз о том, как планируются и выполняются запросы.

Предыдущие циклы были посвящены изоляции и многоверсионности, журналированию и блокировкам.

В этом цикле я собираюсь рассмотреть этапы выполнения запросов, статистику, последовательное сканирование, индексное сканирование, соединение вложенным циклом, соединение хешированием, сортировку и соединение слиянием.

Материал перекликается с нашим учебным курсом QPT «Оптимизация запросов», но ограничивается только подробностями внутреннего устройства и не затрагивает оптимизацию как таковую. Кроме того, я ориентируюсь на еще не вышедшую версию PostgreSQL 14. А курс мы тоже скоро обновим (правда, на версию 13; приходится бежать со всех ног, чтобы только оставаться на месте).

Поехали

Postgres в ретроспективе

Время на прочтение37 мин
Охват и читатели13K
Предлагаем вашему вниманию перевод статьи Джозефа Хеллерштейна «Looking Back at Postgres», опубликованной в соответствии с международной лицензией Creative Commons «С указанием авторства» версии 4.0 (CC-BY 4.0). Авторы оставляют за собой право распространять эту работу на личных и корпоративных веб-сайтах с надлежащей ссылкой на источник.

Перевод выполнен Еленой Индрупской. От себя добавлю, что «программист, который отчаянно хотел построить систему с многоверсионностью» — судя по всему, Вадим Михеев, ну а «добровольцев из России», переписавших GiST, мы все хорошо знаем.

Аннотация


Это воспоминание о проекте Postgres, выполняемом в Калифорнийском университете в Беркли и возглавляемом Майком Стоунбрейкером (Mike Stonebraker) с середины 1980-х до середины 1990-х годов. В качестве одного из многих личных и исторических воспоминаний, эта статья была запрошена для книги [Bro19], посвященной награждению Стоунбрейкера премией Тьюринга. Поэтому в центре внимания статьи — руководящая роль Стоунбрейкера и его мысли о дизайне. Но Стоунбрейкер никогда не был программистом и не мешал своей команде разработчиков. Кодовая база Postgres была работой команды блестящих студентов и эпизодически—штатных университетских программистов, которые имели немного больше опыта (и только немного большую зарплату), чем студенты. Мне посчастливилось присоединиться к этой команде в качестве студента в последние годы проекта. Я получил полезный материал для этой статьи от некоторых более старших студентов, занятых в проекте, но любые ошибки или упущения являются моими. Если вы заметили какие-либо из них, пожалуйста, свяжитесь со мной, и я постараюсь их исправить.
Читать дальше →

Чистая архитектура на примере

Уровень сложностиПростой
Время на прочтение27 мин
Охват и читатели107K

Познакомил друга с понятием "Чистая архитектура" и он стал часто спрашивать меня как лучше сделать то или другое. Хотел дать ему к какому-нибудь туториал, но, к удивлению (плохому), не нашел подходящего.

Поэтому выкладываю небольшой обзор:

1.. Что такое чистая архитектура;
2.. Как можно реализовать;
3.. Мои мысли.

Читать далее

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность