Кодовой Барабанщик

Так вот, новость про #движ: в пятницу (10 июля) в 19:00 выступаю с #хитпоинт на Dio Birthday Party 🎂🎉🎸
Клуб Цеппелин N5, Слободской переулок д.6 с.4. Вход платный 🤑

#RunIT в этот раз проходит без меня 👟
Зато совсем скоро будет ещё #движ, жди подробностей🎉

Как менялось моё рабочее место в течение дня👆

Последние три дня был в Самаре, приехал по делам.
Поймал себя на интересной мысли: каждый город можно представить как платформу. Если он реализует определённый интерфейс, то становится совместимым с моим образом жизни🥁🧑‍💻

Какие методы должны быть у такого интерфейса?
🔹 RehearsalBase() — должна быть репетиционная база, чтобы можно было подготовиться к выступлению.
🔹 Workspace() — место, где можно спокойно поработать: удобный стол, стабильный интернет (Wi-Fi или хороший мобильный): коворкинг или просто удачный номер в отеле.
🔹 Ну и базовые методы вроде Sleep() и Eat(). Без них тоже никуда.

Если все эти «эндпоинты» реализованы, то для меня город становится совместимым. Я могу жить в нём почти так же, как дома: работать, репетировать, отдыхать, не ломая привычный распорядок.
В прошлом году у меня было такое же ощущение в Батуми🇬🇪 Другой город, другая страна, но все нужные «ручки» оказались на месте. В итоге я продолжал работать в привычном режиме и почти не чувствовал, что нахожусь вдали от дома🏠

Получается, что я не так сильно привязан к конкретному месту. Скорее, я привязан к интерфейсу. Если новый город его реализует, то моя жизнь и работа просто продолжают выполняться без изменений✨

Кажется, #ИИшница постепенно убирает естественные барьеры между работой и отдыхом 🚧

Раньше, если ты идешь обедать, то просто обедаешь, смотришь видосики🟥, кайфуешь. Пока ешь — не пишешь код. Чтобы программировать, нужно сесть за компьютер и сосредоточиться.

Теперь можно есть и одновременно смотреть, как Клавдий😒 пишет код. Иногда что-то ему подсказать, написать пару строк самому, дать следующее задание — и снова вернуться к обеду. Вроде бы отдыхаешь, но одновременно работаешь.

Ещё появилась возможность упралять AI-агентом с телефона. Он выполняет задачи на твоём компьютере, пока ты находишься где угодно: на кухне, в постели, на скамейке в парке. В любой момент можно открыть телефон, дать новую команду, посмотреть результат, что-то поправить.

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

В результате появляется странный эффект😳

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

Не уверен, хорошо это или плохо. Наверняка правильный ответ, как обычно, "зависит". Возможно, мы просто учимся использовать время эффективнее.

Но есть ощущение, что эти «пустые» промежутки были нужны не просто так. Именно в них мозг успевал переключиться, а вместе с этим часто приходили новые идеи и решения⚡️

Похоже, теперь отдых тоже становится навыком, который надо уметь вовремя применить

#ИИшница раздаёт советы

🗄 Оперативное 1: shared_buffers — личный кэш Postgres

В обзорном посте про оперативку постгресса мы насчитали трёх «едоков» памяти. Начнём с первого: shared_buffers. Разберёмся, что это такое и почему он всегда выглядит занятым.

😂 Что это вообще
Как многие знают, Postgres не бегает на диск в каждом запросе. У него есть свой кэш — кусок оперативки, куда он складывает страницы (напомню, что это кусочки по 8 Kb), которые недавно понадобились, чтобы в следующий раз взять их из памяти. Вот этот кэш и есть shared_buffers.

Слово shared («общий») тут ключевое: буферы общие для всех соединений. Один запрос читает страницу с диска и кладет в shared_buffers, а следующий возьмёт её уже из памяти и диск не тронет. (Напомню, что даже на самых мощных SSD разница скорость чтения 10-20 микросекунд, тогда как из оперативки это 50-60 НАНОсекунд, то есть капец как дешево)

📏 Сколько его
Размер задаёт параметр shared_buffers, и фиксируется он при старте сервера. По умолчанию в Postgres это всего 128 MB — наследство времён, когда памяти было мало. На боевом сервере его обычно поднимают примерно до четверти всей оперативки. Текущее значение покажет команда SHOW shared_buffers;

⚙️ Почему он всегда «занят»
Эти 128 MB (или сколько ты выставил) Postgres резервирует под кэш сразу при запуске и держит за собой всё время работы. Поэтому в мониторинге shared_buffers всегда показывает себя занятой памятью. Это не утечка и не повод хвататься за сердце 😰: память заранее отведена под кэш и работает на тебя.

🔬 Что внутри
Что именно сейчас лежит в shared_buffers, показывает расширение pg_buffercache (его надо один раз подключить командой CREATE EXTENSION pg_buffercache).

На прогретой таблице users из миллиона строк (прогретой — значит по ней уже погоняли запросы, и её страницы успели осесть в кэше) у меня вышло так:

🟢 сама таблица заняла 47 MB
🟢 индекс по email — 39 MB
🟢 индекс первичного ключа — 21 MB.

Два индекса вместе съели больше кэша, чем данные! Это частый сюрприз: спрашиваешь «куда ушла память под базу», а ответ нередко оказывается простым — в индексы.

🅰️ Что унести с собой

🟢 shared_buffers — это собственный кэш Postgres в оперативке, общий для всех соединений.
🟢 Его размер фиксируется при старте: по умолчанию 128 MB, на проде обычно около четверти RAM.
🟢 Он всегда выглядит занятым, и это нормально: память заранее отведена под кэш.
🟢 Индексы живут в том же кэше, что и данные, и порой занимают даже больше места.

#бд #postgresql #инженерныештучки #heavywednesday

Рассказать всё 📢 (
от автора "вспомнить всё" и "записать всё")

Как говорил ранее, один из факторов успешного собеседования заключается в умении рассказать о своём опыте и знаниях. Именно рассказать. Вслух!

Помимо освежевания знаний, надо практиковаться в устном ответе на вопросы. Прям вслух проговаривать свой ответ под запись🔴
На первых порах можешь очень сильно удивиться, как много в твоей речи лишних звуков. А ещё во время рассуждений "про себя" мозг работает немного по-другому, и в этом режиме может выдать нужную информацию, а вот "вслух" куда-то вдруг всё пропадает 🤔

Тут можно подмечать свои ошибки во время рассказа или при прослушивании записи, а еще её можно транскрибировать и передать полученный текст, конечно же, нейронке, чтобы получить от неё фидбек по твоему ответу. У ChatGPT 😺 вообще есть режим созвона, в котором прям в реальном времени она может устроить тебе тех-скрининг, но у меня она в этом режиме как будто чаще ошибалась.

Ну а дальше, уже получив желанный оффер, не останавливайся, продолжай практиковаться в пересказе своих знаний и регулярно освежай их: пиши статьи и посты в канальчик, выступай на внутренних митапах и внешних конференциях, ментори кого-нибудь. Поддерживай этот навык тёплым 🔥, он тебе во многом пригодится и после собеседований.
И записывай это всё в достижения, конечно же🧠

#поиск_работы

Очень необычно зайка✨

Я типа в тренде)
#ИИшница

Казалось бы, ещё вчера #занимательныеистории тестировали на хакатоне, а сегодня им уже 6 лет 🥲
Если интересно, исходники 👉здесь👈

Среда - маленькая пятница, так что отдыхаем, мои чуваки

#heavywednesday

Вспомнить всё 🧠

В айтишке для прохождения собеса на высокий грейд надо уметь, помимо прочего, рассказать про множество технических подробностей. В моём случае была сложность в том, что даже если ты их и знаешь, одно дело - рассуждать о решении задачи, глядя через призму этих знаний, другое - словами через рот выдать что-то внятное, структурированное, и понятное. В общем, тяжело, если регулярно в этом не практикуешься. Ещё сложнее, когда что-то изучал, но так редко применяешь это в работе, что эти знания в твоём shared_buffers замещаются более горячими данными (прямо как при чтении данных из БД) 🧠

Как быстро освежить знания?

Мне на помощь в этом случае пришла, конечно же, #ИИшница 🧠
Ты можешь сказать: "Она же галлюцинирует! Она тебе нагенерирует какой-нибудь ерунды, а ты опростоволосишься на собесе, пересказав эту чушь!". Я немедленно отвечу: да, такое возможно, и, как со всяким инструментом, с ней тоже надо уметь обращаться 🔧

Говорят, что генеративные модели обучены на всём интернете. В том числе, получается, на информации из Stack overflow и хабре, безграничных кладезях знаний, наполняемых людьми.
А люди склонны ошибаться.
То есть, когда я читаю статью, я рискую нарваться на неточную или неполную информацию. В этом случае я могу подумать "WTF, что-то тут не сходится" и... остаться наедине с этой мыслью. С нейронкой, в случае сомнений, я могу задать уточняющий вопрос. Ассистент либо признает неточность, либо разложит по полочкам ещё подробнее.
Ещё информацию из статьи или видоса можно неправильно интерпретировать. В случае с ИИ, я могу уточнить, и получить ответ.
В общем, нейросеть может предстать этаким интерактивным учебником, или очень терпеливым экспертом, который ответит на все твои уточняющие вопросы. И который ещё быстро погуглит, если что-то не знает, сопоставит информацию, и выдаст ровно то, что тебя интересует.

🧐Конечно, всё ещё стоит относиться к информации от ИИ (как и любой информации в интернете, к этому посту тоже) с разумной долей скепсиса, и выявить неточности поможет в том числе практический опыт. То есть, важно не просто всё зубрить и принимать на веру, а пытаться спроцеровать (смаппить, по-нашему) свежие знания на былой опыт. Так и полученная информация лучше закрепится, и на собесе сможешь привести пару интересных примеров про конкурентный доступ к файлу на блобе

#поиск_работы

🟪🟪🟪🟪🟪🟪🟪🟪

"Картинка дня"
Чувствуется, что без дополнительных запросов #ИИшница крутится вокруг какой-то одной темы: в прошлый раз за окном тоже был закат над рекой, букет, чашка, и блокнот, но городок был не такой большой

#занимательныеистории пополнились новой историей✨
Напомню: скажи Алисе💜 "Запусти навык занимательные истории", а дальше там понятно))

В прошлых постах мы довольно тщательно разобрали структуру индексов, и нам осталось разобраться, откуда происходит чтение как данных, так и индексов: из диска, или из оперативки, или «зависит»?

📚 Несколько кэшей
Представь, что ищешь нужную книгу: она может быть на твоём рабочем столе — прям под рукой, очень близко; или на полке рядом — на шаг дальше; или вообще в книжном шкафу в другой комнате — туда топать дольше всего. Память под страницы у СУБД устроена такими же уровнями, и за страницей она идёт по ним сверху вниз:

1️⃣ shared_buffers — рабочий стол. Собственный кэш СУБД, она сама им рулит. В Postgres по умолчанию всего 128 MB.
2️⃣ кэш ОС (page cache) — полка рядом. Операционка сама держит в RAM файлы, которые недавно читала; СУБД им не управляет, но пользуется.
3️⃣ диск — шкаф в другой комнате.

Глянула 1️⃣ shared_buffers → нет → 2️⃣ спросила ОС, та смотрит, что есть в RAM → нет → идем на 3️⃣ диск Найденную страницу обычно кладём обратно в shared_buffers, чтобы следующий запрос взял её уже оттуда.

🧩 Данные и индексы — в одном кэше
Тут есть контр-интуитивный момент: и куча с данными (heap — страницы, где лежат сами строки таблицы), и индексы (страницы с элементами дерева) лежат в одном shared_buffers, конкурируя за место. Отдельной «памяти под индексы» нет 🤯

🌳 Почему индекс будто всегда в RAM
Верхушка B-дерева (корень и внутренние узлы) — набор страниц, который дёргает каждый поиск. Из-за частых переходов по дереву верхние уровни почти всегда в кэше, так как с них начинается почти любой поиск, поэтому дочитывать чаще приходится только лист и/или саму страницу кучи.

🔬 Пощупаем (дикпик 1)
EXPLAIN (ANALYZE, BUFFERS): секция BUFFERS показывает, сколько страниц нашли в shared_buffers (hit), а сколько пришлось дочитывать (read).
Холодный поиск по PK на таблице в 1 млн строк, у меня в эксперименте: shared read=4 — три страницы индекса плюс одна кучи, всё мимо кэша.
Повтор: shared hit=4 — всё в shared_buffers диск не трогали, время заметно меньше.
Ищем другой далёкий id: hit=1 read=3 — корень уже в кэше с прошлого раза, поэтому он был переиспользован.

⚠️ Тонкость: read ≠ обязательно диск
«read» здесь значит лишь «не было в shared_buffers». Но страница могла прилететь мгновенно от ОС, а не из диска.
Отсюда неочевидное: два запроса с одинаковым read могут идти с разной скоростью — в одном случае страница пришла с диска, в другом уже лежала в кэше ОС.

🧑‍💻 Как это использовать в работе
1. Первый запрос после рестарта PostgreSQL (или сервера) обычно медленнее: кэш пустой, он наполняется заново. Это так называемый «холодный старт».
2. Index Only Scan (когда всё нужное есть в самом индексе и в кучу за строкой идти не надо) экономит не только чтения, но и кэш: чем меньше heap-страниц тащим в shared_buffers — тем больше места остаётся другим.

Команды из дикпика — в 👉 гисте 👈

Дальше разберём, куда девается оперативка, когда её внезапно «съели» под 99%, и как это диагностировать 👉

🧑‍💻dp 🥁
#бд #postgresql #инженерныештучки #heavywednesday