Буфферный кеш в PostgreSQL

Очередная серия статей от ребят из postgres. На этот раз о механизме журналирования, он же write-ahead log, он же WAL. Статьи не из лёгких и требуют серьезного погружения.

В первой статье автор рассказывает о такой важной штуке, как буферный кеш. Буферный кеш представляет собой массив буферов, каждый буфер – это место под одну страницу данных. Чтобы работать с данными, процессы читают страницы в кеш, тем самым далее экономя на обращениях к диску. Для поиска страниц в кеше используются хеш-таблицы, но, конечно, со своими нюансиками.

Когда кеш переполняется, что-то нужно вытеснить. Для этого используется алгоритм clock-sweep, который по кругу перебирает все буферы, уменьшает счётчики обращений, учитывает ещё разную хитрую магию и решает кого бы вытеснить.

Чтобы потрогать кеш руками, есть расширение pg_buffercache. С помощью специального запроса можно посмотреть количество страниц, счётчик обращений ним, привязку к процессу. Также можно узнать, какая часть каких таблиц закеширована и насколько активно используются эти данные.

Размер кеша – это, что рекомендуют менять сразу после развёртывания базы. По умолчанию он равен 128 Мб. Нет конкретного значения, которое стоит выбрать для кеша, всё зависит от задачи и лучше выяснять на практике. Автор рекомендует взять для начала 1/4 оперативной памяти. Также стоит учитывать, что postgres использует обычные вызовы операционной системы, поэтому происходит двойное кеширование – кеш СУБД и кеш ОС.

Горячий вопрос: прогрев кеша. В postgres для этого есть расширение pg_prewarm. С помощью него можно сразу прочитать в кеш данные определённых таблиц. Также можно сохранять состояние кеша и восстанавливать после перезагрузки сервера.

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

#skills #database

Нестареющая классика, шпаргалка по SSH

Очень давняя, но информативная статья, которая лежит у меня как шпаргалка, если что-то подзабыл.

Начинается с базы, коротко и по делу. Не нужно авторизовываться по паролю, настраивайте вход по ключу. Ключ генерируется одной командой и может быть закрыт паролем. Разумеется, ключ состоит из двух частей: открытой и закрытой. На сервер ключ можно скопировать ручками или специальной командой. У сервера есть свой ключ, который помещается в known_hosts. Для копирования данных через ssh-сессию есть команда scp. Это база. Теоретические основы были в отдельном посте.

Дальше, как всегда, интереснее:
– с помощью дополнительной утилиты sshfs можно предоставить доступ к удалённой файловой системе. При этом локальные приложения не будут подозревать, что работают с удалённой файловой системой

– можно выполнить команду на удалённом сервере, оставаясь в локальной командной строке. Интересное применение, например, вывести содержимое какого-то файла и с помощью конвейера скормить его локально запущенной программе

– если хотим вызвать удалённую команду, а её вывод поместить в локальный файл, то для этого можно пробросить stdin/out

– чтобы каждый раз не вспоминать ip-адрес, куда подключаешься, или, наоборот, не вспоминать длиннющее имя сервера, то для этого можно в конфиг файле ssh прописать алиасы

– если локальная машина имеет графический x-сервер, а удаленная нет, то можно сделать так, чтобы приложения с сервера рисовались у вас на рабочем столе

– публичные wi-fi совсем небезопасны, а VPN порой просто режут, поэтому есть выход – работа ssh в режиме socks-proxy

– заканчивается статья такими схемами, от которых волосы начинают шевелиться: проброс портов, вложенные туннели, реверс-сокс-прокси и проброс авторизации

Интересный факт, которым меня мучали в институте, и он упоминается в статье: ip-адреса 127.0.0.1 и 127.1 идентичны и нет никакой ошибки. Вот такие пироги.

#skills

#interview

Вопросы для собеседования:

- Примеры последних интересных и скучных задач;
- Какие последние задачи запустили в продуктив;
- Как "выглядит" продуктив: какие инструменты/технологии используются, как это выглядит на практике;
- Есть ли мониторинг качества моделей и их переобучение?
- Есть ли code review или иные способы контроля качества проекта?
- Есть ли A/B тесты, как они реализованы, как используются результаты;
- Есть ли feedback от заказчиков по результатам проектов? Если есть, то в каком виде и как используется?
- Как приходят и ставятся/распределяются задачи?
- Какие обычные сроки у проектов? Есть ли adh-hoc и их доля? Есть ли исследовательские проекты?
- Какая текучка в отделе? Какая структура отдела?
- Какой стиль управления руководства/непосредственного начальника - жесткий контроль, свобода действия или что-то среднее.
- Были ли идеи от заказчиков, которые вы отказались делать? Что это было и почему?
- Какие конкретные задачи (1-2) буду выполнять, если выйду к вам?
- гибкий график? Возможность ходить на встречи/конференции? Переработки?
- Есть ли годовые цели и kpi? В каком виде?
- Планы по развитию отдела и людей?
- как ведется работа над проектами - в одиночку или команды по какому-то принципу?
- где хранятся данные, какое у них качество?
- как ведется разработка - инструменты, версионирование и так далее

#ml #petproject

(1) В этой статье можно отлично разобраться в большинстве оптимизаторов и их параметрах.

Статья с хорошими примерами проектирования сетей с помощью строительных блоков pytorch.

Топ обёрток для pytorch. Нереально классные штуки.

#systemdesign

Блог Alex Xu - https://blog.bytebytego.com/p/algorithms-you-should-know-before
Много интересного по систем дизайну

#video

Клевая подборка видео по теме Multivariate statistics.

В основном, там базовые вещи, но повторить материал (или посмотреть в первый раз, если не знали) это позволяет очень хорошо. Описано все на примерах, рассказывается просто и понятно.