Вспоминаю о графане и бегу смотреть метрики (Рисунок 3) 🚘

На графике отображена динамика использования памяти кучи в Java-приложении, он содержит данные о used memory, commited memory и max memory.

🌺used memory - это объем памяти, который в данный момент используется работающим Java-приложением. Включает в себя все объекты, которые были созданы и еще не были удалены сборщиком мусора.
🌺 max memory - это максимальный размер памяти кучи, который может быть использован JVM. Этот лимит устанавливается при старте JVM и может быть задан через параметр. Он определяет верхнюю границу того, сколько памяти кучи может быть выделено из операционной системы.
🌺 commited memory - это объем памяти, который в данный момент времени выделен JVM из операционной системы и гарантированно доступен для использования Java-приложением.

Committed vs Max Memory: Committed Memory – это объем памяти, уже выделенный и гарантированный JVM, тогда как Max Memory указывает на максимально возможный размер памяти кучи, который может быть выделен. Committed Memory может увеличиваться в пределах заданного лимита Max Memory.

🔭 Что можно сказать, анализируя график:

1. Период до 18:00 - Используемая память держится на стабильном уровне - 1,5 гб (на скриншоте, к сожалению, этого периода не видно).
2. 18:00 - Начало нагрузки - Объем используемой памяти резко возрастает, что характерно для ситуации, когда на приложение поступает нагрузка в виде входящих запросов.
3. До 19:00 - Обработка запросов - Используемая память достигает пика и затем стабилизируется, что может говорить о том, что приложение успешно справилось с нагрузкой.
4. Спустя время после нагрузки - Используемая память падает с 2.79 ГБ до 954 МБ, что свидетельствует о том, что объекты, занимающие память, были убраны сборщиком мусора (Garbage Collector, GC). Это стандартное поведение, когда GC выполняет очистку памяти от недостижимых объектов.
5. Committed Memory остается высоким - JVM не возвращает память операционной системе, даже если часть памяти не используется.

Почему JVM не отдает память?

JVM, как правило, не сокращает Committed Memory сразу после того, как объем используемой памяти уменьшается

Это связано с несколькими причинами:

1. Производительность: Частое выделение и освобождение памяти может отрицательно сказаться на производительности системы из-за дополнительной нагрузки на управление памятью.
2. Оптимизация GC: JVM может решить сохранить Committed Memory на более высоком уровне, чтобы сборщик мусора работал более эффективно, особенно если предполагается, что будущая нагрузка потребует схожего объема памяти.
3. Настройки JVM: Параметры запуска JVM и настройки сборщика мусора могут определять, как быстро и когда память будет возвращаться операционной системе. Например, настройки `XX:MinHeapFreeRatio` ито можно сказать, аналимогут контролировать долю свободной памяти в куче и тем самым влиять на Committed Memory.

🎀Чтобы JVM более активно освобождала память, можно настроить соответствующие параметры запуска или использовать другие сборщики мусора с другими стратегиями управления памятью. Однако, это может иметь побочные эффекты, например, увеличение частоты выполнения сборки мусора, что может повлиять на задержки в работе приложения.

Итог исследования: с сервисом все в порядке, нагрузку держит и с Out Of Memory не упадет в соответствии с нефункциональными требованиями 🍪

Расскажи, как ты бы решал подобную проблему? 💗

😡САМЫЙ НЕНУЖНЫЙ ИНДЕКС В POSTGRESQL😡

И речь про хеш-индекс - об этом индексе часто говорят, как об абсолютно бесполезном.

На хрен эти хеш-индексы, когда есть B-tree, которые подходят в 90% случаях и при этом всегда выполняют запросы быстрее!

Давайте разберемся, действительно ли всегда хеш-индексы будут проигрывать своим коллегам и какие вообще есть основания называть этот индекс АБОЛЮТНО БЕСПОЛЕЗНЫМ?!🤬😤

Как устроен хеш-индекс

Хеш-индекс - использует принцип хеш-таблицы для поиска данных, где ключом является значение индексируемого поля. Это значение преобразуется в хеш-код с помощью хеш-функции, а в качестве значения хеш-таблицы выступает указатель на строку данных в таблице.

Как происходит процесс добавления индекса по полю

1. Преобразуем значение поля в хеш-код с помощью хеш-функции.
2. Определяем, в какой бакет поместить запись с помощью побитовой операции или остатка от деления на кол-во бакетов.
3. Добавляем запись в соответствующий бакет, а точнее, в страницу бакета. Каждый бакет это отдельная страница, в которой может храниться множество записей из-за коллизий хеш-кодов.
4. Если коллизии приводят к полному заполнению страницы бакета, выделяется новая страница для дополнительных записей (связанная страница).

Как осуществляется поиск с помощью хеш-индекса

1. СУБД считает хеш-код искомого значения поля.
2. Используя этот хеш-код, СУБД определяет бакет, в котором должен находиться указатель на данные.
3. СУБД перебирает записи в бакете (и в связанных страницах, если есть), чтобы найти точное совпадение искомого значения поля.
4. Найдя запись в бакете, СУБД извлекает указатель на данные в таблице.

Для каких задач подходит

Хеш-индексы подходят для выполнения запросов SELECT и UPDATE с точным совпадением, так как способны обеспечивать доступ к данным за константное время O(1) в идеальных условиях.

Пример: Таблица для хранения финансовых транзакций.

CREATE TABLE financial_transactions (
id serial PRIMARY KEY,
transaction_id UUID NOT NULL,
user_id INTEGER NOT NULL,
amount DECIMAL(10, 2) NOT NULL,
transaction_date TIMESTAMP NOT NULL DEFAULT current_timestamp,
status TEXT NOT NULL
);

CREATE INDEX financial_transactions_transaction_id_hash_ix ON financial_transactions USING hash(transaction_id);

SELECT * FROM financial_transactions WHERE transaction_id = 'уникальный-uuid-транзакции';

Этот запрос хеш-индекс выполнит намного быстрее, чем B-tree, и займет намного меньше места на диске в идеальном случае.
То есть, если будет минимальное количество коллизий и равномерное распределение transaction_id, все будет чики-пуки 😂

НО

❌Если бакеты переполнятся из-за большого количества коллизий, время доступа увеличится до O(N).
❌Если будет много записей с одинаковым transaction_id, это также приведет к коллизиям и увеличит время доступа.
❌Или если просто наша таблица обрабатывает большие объемы данных, просядет производительность из-за частого рехеширования.

В общем полный пипяу🫡

Какие есть еще ограничения у хеш-индексов

1. Поддерживают только оператор =. Нет поддержки операций диапазона (<, >, BETWEEN), текстовый поиск.
2. Не поддерживают упорядочивание: поскольку хеш-функция преобразует значение в псевдослучайное число, хеш-индексы не могут использоваться для получения упорядоченного результата.
3. Можно строить только по одному столбцу и нет функционала проверки на уникальность значений.

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

В процессоре одно ядро - сколько потоков запускать?🫡

На одном из собеседований мне задали этот вопрос, и он поставил меня в тупик. 😳

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

Тогда запускаем количество потоков равное количеству ядер! 🏀

Это утверждение тоже неверно. Чтобы понять, сколько потоков запускать, нужно определить, какие операции будут выполнять потоки.

🌟 Если операции в потоках асинхронные и не требуют ожидания или блокировки, то, оптимально будет создать столько потоков, сколько доступно ядер процессора. Так как большей параллельности добиться не получится.
🌟 Однако если есть синхронные операции, требующие ожидания: обращение к диску, сетевые запросы, обращение к базам данных. В таких случаях потоки могут большую часть времени простаивать, ожидая завершения ввода/вывода. В этой ситуации использование большего количества потоков, чем количество ядер процессора, становится выгодным. Пока один или несколько потоков ожидают завершения операций, другие потоки могут продолжать выполнение, таким образом, повышая общую пропускную способность и эффективность системы.

Пост для тех, кто считает, что получение высшего образования это не трата времени впустую
(мама, папа для вас короче)❤️

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

У меня опускаются руки от того, насколько сильно преподавателям безразлично реализованное мною решение - об используемых технологиях они ничего не знают. Все внимание сосредоточено на корректности формулировок и оформлении презентации/отчета.

Это скриншот с замечаниями по моей работе, клянусь вам, если бы ее читал человек, который разбирается в программировании и архитектуре, он бы точно мою работу слил НЕ за неправильное оформление.

Я не понимаю расстановку приоритетов - почему столько времени и внимания уделяется форме, а не содержанию?

🍓WILDBERRIES - Разбор собеса

Как и обещала, в видео разобрала задачи, которые давали на собесе в WB.

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

И я это обязательно учту ❤️

full видео тут

🔔Открываю набор на консультации и менторство

Менторить я начала в декабре, однако спустя 2 месяца приостановила набор новых учеников, так как начала усиленно заниматься развитием своих навыков.

Сейчас я готова опять проводить занятия и помогать людям достигать своих целей.
Мои ученики получили офферы на 230к и 260к чистыми, вкатившись с 0.

Формат работы:

0. Встреча знакомство
Я расскажу о себе, отвечу на вопросы. А ты поделишься своим запросом.

1. Консультация
Если тебе нужен разовый созвон и нет потребности в менторинге, то этот формат тебе подойдет.

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

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

4.Менторство с постоплатой
Ты будешь обучаться под мои наблюдением. Цель зависит только от твоих запросов: войти в айти, повысить грейд до мидла/сеньера, прокачать знания в бэкенде.

Оплата менторства после получения оффера, предоплата — 0 рублей. Деньги я беру только после трудоустройства, а именно первую зарплату.
При такой оплате, в моих интересах за минимальное время добиться максимальных результатов.

Прочитать подробности | Записаться на встречу знакомство