Как регулярно минусуемый и в комментариях и в карму и в статьи(мои самые любимые причины 😁- личная неприязнь, ничего не понял, придерживаюсь другого мнения), IMHO, позволю себе потратить имеющийся 1 комментарий в сутки:
1) тема кармы и минусов идёт на Хабре , на моей памяти с 2019 года. Ничего не меняется , администрацию текущая ситуация цензуры толпы - устраивает.
2) Какой смысл администрации в том, что авторы публикуются на других ресурсах и трафик просмотров проходит мимо Хабра? Риторический вопрос .
3) минусы влияют только на ограничение свободы слова минусуемому. Никто и никогда не меняет своей точки зрения только потому, что кому-то вообще не известному в интернете , что то не нравится .
5) минусы под статьями вообще никак не влияют на индексирование статей поисковиками и нейросетями - проверено лично 😉
В августе 2023 года , после 2х лет на позиции руководителя направления(направление выстроено с нуля, процессы сформированы и отлажены), после хронического выгорания(раньше я смеялся над этим термином , пока на себе не почувствовал) - я вернулся на позицию эксперта направления .
За прошедшее время - ни разу не пожалел. Столько нового интересного сделано, сколько еще предстоит. Даже, можно сказать больше - уходить надо было раньше , при первых звоночках , не дожидаясь выгорания.
вопрос. Кажеся, призван проверить, случалось ли кандидату разворачивать кластер. Имеет смысл только в том случае, если ему и на новом месте это предстоит.
Только есть один момент - я последний раз разворачивал кластер 6 лет назад. В резюме ясно написано, чем я занимался в течении последних 10 лет. Если бы HR читал резюме- сколько времени удалось бы сохранить. Мне то все равно, одним собеседованием больше, одним меньше , а вот его рабочее время потрачено впустую.
Важно, понимает ли кандидат, что analyze реально выполняет запрос
В ту же тему , в резюме есть ссылки на мой проект и публикации. Но почему то HR не хотят эффективно использовать свое рабочее время.
а зачем вообще нужен swap на сервере субд в наши дни
Потому что как показал эксперимент - настройка swap оказывает влияние на то, что производительность СУБД в данной конкретной конфигурации и данным конкретным сценарием нагрузки с использованием vm.swappiness = 10 выше чем при vm.swappiness = 1. Причина в общем то уже понятна. Статья с подробным анализом будет готова завтра . Но опубликована на другом ресурсе (добавлю ссылку в конце статьи ).
В итоге я остановился на тестировании программного обеспечения.
Есть еще одна область IT в которой возраст не помеха , а жизненный опыт и сопутствующий здравый смысл - только большой плюс - DBA .
Особенно PostgreSQL DBA - на рынке явный дефицит (за прошедшие 7 лет ситуация не изменилась, а скорее усугубилась) , а задачи для джуна отлично подходят для набирания опыта - business as usual : инсталляция, резервное копирования, запросы на обслуживание, инциденты операционной доступности.
В этом смысле взрослый джун часто даже выигрывает: у него уже обычно есть дисциплина, жизненный опыт, ответственность и он понимает, что мгновенного результата не будет.
Не далее как вчера , вопрос "какие базы данных создаются после инсталляции кластера PostgreSQL?" :-) вы серьёзно считаете , что ответ на этот вопрос полезен и имеет смысл ?
Или "что произойдёт при выполнении команды Explain analyze drop database...".
Я честно ответил, что за 20 лет работы с СУБД мне в голову не приходила мысль о принципиальной возможности и необходимости запустить такой explain. И прямо ответил - не знаю, может стоит защита от дурака , а может грохнете базу с такими экспериментами.
Смысл тратить время на такие вопросы ? Хотя с другой стороны , что делать с собеседованиями , я, не знаю. По личному опыту во времена тимлидерства - я вообще не смотрел хард скилы, старался оценить софт скилы, но для этого нужно иметь большой жизненный опыт и хоть какой то психологический бекграунд.
это просто реакция сообщества, на то что ты ведешь себя как спамер
Ну и замечательно - ты сохранишь время , что бы не читать новые публикации по теме оптимизации производительности СУБД PostgreSQL , тем более тебе лично сказать сообществу по теме и нечего, кроме бессмысленных комментариев.
Я - использую время освободившееся от подготовки новых публикаций на Хабре на новые эксперименты и публикации на других ресурсах.
Сообщество - продолжить читать ленту Хабра про ИИ , HRов , менеджеров , психологов и прочих очень актуальных на техническом ресурсе материалов , наверное сообществу это очень интересно. Why not.
Администрация Хабра - передает просмотры и прочтения со своего ресурса, другим.
был один профиль нагрузки . В этой статье эксперимент поставлен для двух разных профилей нагрузки.
почему взяли 15 минут, а не 20 минут.
В связи с политикой Хабра публикуются только выборочные , итоговые результаты экспериментов (1 публикация в неделю). На дзен-канале (ссылка в профиле) масса публикаций по другим значениям checkpoint_timeout. Я не буду приводить ссылку на подборку публикаций , во избежание дальнейшего непрерывного слива кармы по причине "Реклама", если интересно - ссылка на дзен в профиле. На репозиторий инструмента, кстати тоже, если интересно можно все эксперименты проводить и проверять самостоятельно.
В настоящее время эксперименты по checkpoint_timeout - завершены(ну по крайней мере приостановлены). Общая идея понятна, методика отработана, инструмент протестирован, поставленные цели экспериментов - достигнуты. Сейчас проводятся эксперименты по другой теме. Может быть также будет итоговая публикация. Если к тому времени карму не сольют до read-only ;-)
P.S. Ну и разумеется, если уж очень интересно обсуждение темы - лучше в личных сообщениях или в комментариях на дзене. Тут - цензура и отсутствие свободы слова. Впрочем это не бага , это фича Хабра.
1) Инструмент готовит текстовый файл содержащий результаты статистического анализа (корреляции, регрессии , максимальные минимальные значения и т.п. ) и временные ряды метрик производительности СУБД и инфраструктуры
2) текстовые файлы загружаются в нейросеть, главное не превысить ограничение бесплатной версии (128K токенов). Если данных много , придётся анализировать производительность СУБД и инфраструктуры - отдельно.
3) Дальше есть варианты - либо использовать промпты из библиотеки использованных промптов , либо еще проще использовать базовый промпт - "используя входные данные , подготовь промпты для сводного анализа производительности СУБД и инфраструктуры по результатам эксперимента ".
4) Дальше используя уже загруженные данные и промты - дело техники - готовим сводный отчет.
Доступ нейросети никуда давать не нужно, главное - подготовить достаточный набор данных для анализа.
Примеры обработки нейросетью результатов нагрузочного тестирования и инцидентов производительности СУБД, если интересно - на дзен канале(ссылка в профиле) .
Ну а если сильно интересно - пишите в личку. Отвечать на комментарии хоть как-то оперативно - нет возможности, согласно политике Хабра.
LLM сильнее всего там, где для человека слишком много взаимосвязей.
Соглашусь и подтверждаю практическую применимость данного тезиса.
У меня задача сильно проще - есть очень много таблиц и временных рядов , задача найти корреляции и взаимосвязи между данными . Нейросеть , даже в самом простом бесплатном варианте - отлично справляется , дает практически применимый результат и экономит очень много времени на анализ данных.
LLM нормальный и полезный инструмент , если использовать для задач для которых LLM предназначены.
P.S. Например , для прогнозирования нейросети очень плохо приспособлены.
Импорт больших текстовых файлов с временными рядами и возможность анализа данных, кластеризации и выявления корреляций .
И можно будет сравнить с результатами анализа, выполненного другой большой известной нейросетью . Наверное будет интересно . И главное - реальная практическая польза для анализа инцидентов производительности СУБД.
P.S. И пользуясь случаем - просьба сделать вывод результата без псевдографики , в простом текстовом виде. Для дальнейшего протоколирования и анализа в текстовых редакторах.
С академической точки зрения , корректно заявлять не о повышении производительности, а о снижении стоимости выполнения конкретного запроса в условиях единичного изолированного выполнения.
В общем то классика уже - стоимость выполнения отдельного запроса это не производительность СУБД в целом.
Снижение стоимости выполнения запроса не является необходимым и достаточным условием повышения производительности СУБД в целом.
Сценарий когда снижение стоимости запроса не приводит к повышению производительности СУБД в ходе нагрузочного тестирования, а даже наоборот - известны , описаны и опубликованы.
Но в целом , спасибо за информацию и очередную тему для экспериментов 👍🤝.
Предполагается, что вы должны сделать вывод, что на этом ресурсе нет людей, которым интересны ваши статьи, и публиковать их на другом ресурсе.
Немножко перепутана последовательность. Сначала публикации на других ресурсах, потом Хабр для разнообразия и, как было сказано SEO.
Если я буду искать инструменты для измерения производительности PostgreSQL, и Google мне покажет статью на Хабре с рейтингом -3 и с кармой автора -10, я просто ее закрою, и этот инструмент использовать не буду.
Ну и не используйте. Это вообще ни на что не влияет. Я как автор никак не узнаю , что кто то абсолютно неизвестный принципиально не хочет использовать статистический анализ производительности СУБД PostgreSQL на основании рейтинга Хабра 😁
Посмотрел ваш профиль - зачем вам результаты экспериментов и исследований производительности СУБД PostgreSQL? Не используйте , мои статьи не читайте , добавьте меня в черный список.
Нет, вы в корне не правы - автору глубоко плевать и на минусы и на причины тем более .
Результаты и планы экспериментов от реакции и плюсов минусов к публикациям на Хабре, вообще никак не зависят. Цифрам все равно, что про них думаю прохожие .
Ну под автором я про себя конечно, не знаю может быть на Хабре есть авторы реально переживающие за реакцию читателей. Может , кто и ответит .
Возникает закономерный вопрос - а зачем ты тогда на Хабре публикуется, если мнение публики не интересно?
расширение списка причин влияет на авторов а не на минусующих.
Каким образом происходит это влияние по вашему?
Ну вот , чтобы далеко за примерами не ходить - опубликовал я статью , как правило причина первого минуса "Личная неприязнь". И как это должно на меня повлиять ? В очередной раз подтвердить токсичность и хейтерство аудитории Хабра ? А это, что секрет ?
Или причина "не согласен". И что , что не согласен, мне то что с того.
Или вообще огонь , одна самых крутых причин Хабра - "ничего не понял" 😁
Ну вот как эти причины влияют на автора? Ну т.е. на меня . Что , я перестану заниматься интересными мне экспериментами , потому, что кто то непонятный на Хабре ничего не понял или испытывает неприязнь ? 😁
Неужели я обижусь, расстроюсь и с горя от неоценки фиг пойми кем, перестану публиковать результаты исследований и свои мысли ? С какого перепугу ? Просто просмотры публикаций будут не на Хабре а на других ресурсах, и индексироваться будут не страницы Хабра а другие ресурсы .
Вот прям сейчас, с момента слива кармы и ограничения публикации раз в неделю вышло несколько статьей(завтра ещё будет, если будет настроение). Но читатели Хабра их не увидят. В четверг будет итоговая короткая статья и хватит на этом. Статья неделю и достаточно . В ленте Хабра ведь так много интересных статей для практикующих DBA 😎
Ну и кому хуже минусаторы сделали в итоге ?
Итак , ещё раз - как на автора влияют минусы ? Ваше личное мнение .
Я не ездил. Текущая работа образовалась по итогам беседы в Скайпе.
Вообще , вспоминай свой путь - первое единственное тестовое задание и оффлайн собеседование было в далеком 1998 году. И до этого и после просто переписка в почте и беседы в скайпе . Но , повторюсь, я давно не кодер. И повторюсь, софт-скилы IMHO важнее , а их тестовыми задачами не протестить.
Личный опыт во время бывшего тимлидерства - резюме в общем то и не смотрел , просто разговаривал, в скайпе или зуме.
Но, наверное для кодеров свои особенности , я DBA.
По личному опыту участия в проектах по импортозамещению.
Ситуация совершенно стандартная .
Сейчас - так. Исключения настолько редки, что лишь подтверждают правило - "Х*** , х*** и в продакшн".
Я использую нейросеть для следующих задач :
1)анализ результатов экспериментов, проведённых с использованием разработанного мной инструмента
2)генерация короткого предисловия и послесловия
3)генерация иллюстрации(КДПВ) и подписи к иллюстрации
Считается ли такая статья - написанная нейросетью ?
Это риторический вопрос , конечно.
Можно ли, описанные выше задачи выполнить без использования нейросети ? Конечно можно , если есть в запасе достаточно свободного времени .
P.S.
Это да , ЖЖ в этом плане - отличная вещь !
Как регулярно минусуемый и в комментариях и в карму и в статьи(мои самые любимые причины 😁- личная неприязнь, ничего не понял, придерживаюсь другого мнения), IMHO, позволю себе потратить имеющийся 1 комментарий в сутки:
1) тема кармы и минусов идёт на Хабре , на моей памяти с 2019 года. Ничего не меняется , администрацию текущая ситуация цензуры толпы - устраивает.
2) Какой смысл администрации в том, что авторы публикуются на других ресурсах и трафик просмотров проходит мимо Хабра? Риторический вопрос .
3) минусы влияют только на ограничение свободы слова минусуемому. Никто и никогда не меняет своей точки зрения только потому, что кому-то вообще не известному в интернете , что то не нравится .
5) минусы под статьями вообще никак не влияют на индексирование статей поисковиками и нейросетями - проверено лично 😉
Так, что - привет минусаторам 😉
В августе 2023 года , после 2х лет на позиции руководителя направления(направление выстроено с нуля, процессы сформированы и отлажены), после хронического выгорания(раньше я смеялся над этим термином , пока на себе не почувствовал) - я вернулся на позицию эксперта направления .
За прошедшее время - ни разу не пожалел. Столько нового интересного сделано, сколько еще предстоит. Даже, можно сказать больше - уходить надо было раньше , при первых звоночках , не дожидаясь выгорания.
Только есть один момент - я последний раз разворачивал кластер 6 лет назад. В резюме ясно написано, чем я занимался в течении последних 10 лет. Если бы HR читал резюме- сколько времени удалось бы сохранить. Мне то все равно, одним собеседованием больше, одним меньше , а вот его рабочее время потрачено впустую.
В ту же тему , в резюме есть ссылки на мой проект и публикации. Но почему то HR не хотят эффективно использовать свое рабочее время.
Потому что как показал эксперимент - настройка swap оказывает влияние на то, что производительность СУБД в данной конкретной конфигурации и данным конкретным сценарием нагрузки с использованием vm.swappiness = 10 выше чем при vm.swappiness = 1. Причина в общем то уже понятна. Статья с подробным анализом будет готова завтра . Но опубликована на другом ресурсе (добавлю ссылку в конце статьи ).
Есть еще одна область IT в которой возраст не помеха , а жизненный опыт и сопутствующий здравый смысл - только большой плюс - DBA .
Особенно PostgreSQL DBA - на рынке явный дефицит (за прошедшие 7 лет ситуация не изменилась, а скорее усугубилась) , а задачи для джуна отлично подходят для набирания опыта - business as usual : инсталляция, резервное копирования, запросы на обслуживание, инциденты операционной доступности.
В ТОЧКУ ! Именно так !
Не далее как вчера , вопрос "какие базы данных создаются после инсталляции кластера PostgreSQL?" :-) вы серьёзно считаете , что ответ на этот вопрос полезен и имеет смысл ?
Или "что произойдёт при выполнении команды Explain analyze drop database...".
Я честно ответил, что за 20 лет работы с СУБД мне в голову не приходила мысль о принципиальной возможности и необходимости запустить такой explain. И прямо ответил - не знаю, может стоит защита от дурака , а может грохнете базу с такими экспериментами.
Смысл тратить время на такие вопросы ? Хотя с другой стороны , что делать с собеседованиями , я, не знаю. По личному опыту во времена тимлидерства - я вообще не смотрел хард скилы, старался оценить софт скилы, но для этого нужно иметь большой жизненный опыт и хоть какой то психологический бекграунд.
Классика - подписываюсь под каждым словом.
Именно такая мысль пришла еще в прошлом году.
Когда одна идея приходит незнакомым людям - в мысли что-то есть.
Да, были времена когда программирование было наукой , потом инженерной дисциплиной.
Сейчас, ситуация сильно изменилась:
Вы зачем эксклюзивную блокировку используете ?
Это не мы , это фреймворк такой.
Ну и замечательно - ты сохранишь время , что бы не читать новые публикации по теме оптимизации производительности СУБД PostgreSQL , тем более тебе лично сказать сообществу по теме и нечего, кроме бессмысленных комментариев.
Я - использую время освободившееся от подготовки новых публикаций на Хабре на новые эксперименты и публикации на других ресурсах.
Сообщество - продолжить читать ленту Хабра про ИИ , HRов , менеджеров , психологов и прочих очень актуальных на техническом ресурсе материалов , наверное сообществу это очень интересно. Why not.
Администрация Хабра - передает просмотры и прочтения со своего ресурса, другим.
И все довольны . И это хорошо.
в предыдущей статье
Анализ влияния checkpoint_timeout на производительность СУБД PostgreSQL при синтетической нагрузке(Вариант-1) / Хабр
был один профиль нагрузки . В этой статье эксперимент поставлен для двух разных профилей нагрузки.
В связи с политикой Хабра публикуются только выборочные , итоговые результаты экспериментов (1 публикация в неделю). На дзен-канале (ссылка в профиле) масса публикаций по другим значениям checkpoint_timeout. Я не буду приводить ссылку на подборку публикаций , во избежание дальнейшего непрерывного слива кармы по причине "Реклама", если интересно - ссылка на дзен в профиле. На репозиторий инструмента, кстати тоже, если интересно можно все эксперименты проводить и проверять самостоятельно.
В настоящее время эксперименты по checkpoint_timeout - завершены(ну по крайней мере приостановлены). Общая идея понятна, методика отработана, инструмент протестирован, поставленные цели экспериментов - достигнуты. Сейчас проводятся эксперименты по другой теме. Может быть также будет итоговая публикация. Если к тому времени карму не сольют до read-only ;-)
P.S. Ну и разумеется, если уж очень интересно обсуждение темы - лучше в личных сообщениях или в комментариях на дзене. Тут - цензура и отсутствие свободы слова. Впрочем это не бага , это фича Хабра.
Дополнительно по экспериментам с work_mem:
PG_EXPECTO- work_mem: мифы и реальность производительности PostgreSQL
Схема очень простая:
1) Инструмент готовит текстовый файл содержащий результаты статистического анализа (корреляции, регрессии , максимальные минимальные значения и т.п. ) и временные ряды метрик производительности СУБД и инфраструктуры
2) текстовые файлы загружаются в нейросеть, главное не превысить ограничение бесплатной версии (128K токенов). Если данных много , придётся анализировать производительность СУБД и инфраструктуры - отдельно.
3) Дальше есть варианты - либо использовать промпты из библиотеки использованных промптов , либо еще проще использовать базовый промпт - "используя входные данные , подготовь промпты для сводного анализа производительности СУБД и инфраструктуры по результатам эксперимента ".
4) Дальше используя уже загруженные данные и промты - дело техники - готовим сводный отчет.
Доступ нейросети никуда давать не нужно, главное - подготовить достаточный набор данных для анализа.
Примеры обработки нейросетью результатов нагрузочного тестирования и инцидентов производительности СУБД, если интересно - на дзен канале(ссылка в профиле) .
Ну а если сильно интересно - пишите в личку. Отвечать на комментарии хоть как-то оперативно - нет возможности, согласно политике Хабра.
Соглашусь и подтверждаю практическую применимость данного тезиса.
У меня задача сильно проще - есть очень много таблиц и временных рядов , задача найти корреляции и взаимосвязи между данными . Нейросеть , даже в самом простом бесплатном варианте - отлично справляется , дает практически применимый результат и экономит очень много времени на анализ данных.
LLM нормальный и полезный инструмент , если использовать для задач для которых LLM предназначены.
P.S. Например , для прогнозирования нейросети очень плохо приспособлены.
Импорт больших текстовых файлов с временными рядами и возможность анализа данных, кластеризации и выявления корреляций .
И можно будет сравнить с результатами анализа, выполненного другой большой известной нейросетью . Наверное будет интересно . И главное - реальная практическая польза для анализа инцидентов производительности СУБД.
P.S. И пользуясь случаем - просьба сделать вывод результата без псевдографики , в простом текстовом виде. Для дальнейшего протоколирования и анализа в текстовых редакторах.
С академической точки зрения , корректно заявлять не о повышении производительности, а о снижении стоимости выполнения конкретного запроса в условиях единичного изолированного выполнения.
В общем то классика уже - стоимость выполнения отдельного запроса это не производительность СУБД в целом.
Снижение стоимости выполнения запроса не является необходимым и достаточным условием повышения производительности СУБД в целом.
Сценарий когда снижение стоимости запроса не приводит к повышению производительности СУБД в ходе нагрузочного тестирования, а даже наоборот - известны , описаны и опубликованы.
Но в целом , спасибо за информацию и очередную тему для экспериментов 👍🤝.
➕
Немножко перепутана последовательность. Сначала публикации на других ресурсах, потом Хабр для разнообразия и, как было сказано SEO.
Ну и не используйте. Это вообще ни на что не влияет. Я как автор никак не узнаю , что кто то абсолютно неизвестный принципиально не хочет использовать статистический анализ производительности СУБД PostgreSQL на основании рейтинга Хабра 😁
Посмотрел ваш профиль - зачем вам результаты экспериментов и исследований производительности СУБД PostgreSQL? Не используйте , мои статьи не читайте , добавьте меня в черный список.
Мир этого даже не заметит 😎
Нет, вы в корне не правы - автору глубоко плевать и на минусы и на причины тем более .
Результаты и планы экспериментов от реакции и плюсов минусов к публикациям на Хабре, вообще никак не зависят. Цифрам все равно, что про них думаю прохожие .
Ну под автором я про себя конечно, не знаю может быть на Хабре есть авторы реально переживающие за реакцию читателей. Может , кто и ответит .
Возникает закономерный вопрос - а зачем ты тогда на Хабре публикуется, если мнение публики не интересно?
Ответ состоит из 3х букв : SEO.
Каким образом происходит это влияние по вашему?
Ну вот , чтобы далеко за примерами не ходить - опубликовал я статью , как правило причина первого минуса "Личная неприязнь". И как это должно на меня повлиять ? В очередной раз подтвердить токсичность и хейтерство аудитории Хабра ? А это, что секрет ?
Или причина "не согласен". И что , что не согласен, мне то что с того.
Или вообще огонь , одна самых крутых причин Хабра - "ничего не понял" 😁
Ну вот как эти причины влияют на автора? Ну т.е. на меня . Что , я перестану заниматься интересными мне экспериментами , потому, что кто то непонятный на Хабре ничего не понял или испытывает неприязнь ? 😁
Неужели я обижусь, расстроюсь и с горя от неоценки фиг пойми кем, перестану публиковать результаты исследований и свои мысли ? С какого перепугу ? Просто просмотры публикаций будут не на Хабре а на других ресурсах, и индексироваться будут не страницы Хабра а другие ресурсы .
Вот прям сейчас, с момента слива кармы и ограничения публикации раз в неделю вышло несколько статьей(завтра ещё будет, если будет настроение). Но читатели Хабра их не увидят. В четверг будет итоговая короткая статья и хватит на этом. Статья неделю и достаточно . В ленте Хабра ведь так много интересных статей для практикующих DBA 😎
Ну и кому хуже минусаторы сделали в итоге ?
Итак , ещё раз - как на автора влияют минусы ? Ваше личное мнение .
Я не ездил. Текущая работа образовалась по итогам беседы в Скайпе.
Вообще , вспоминай свой путь - первое единственное тестовое задание и оффлайн собеседование было в далеком 1998 году. И до этого и после просто переписка в почте и беседы в скайпе . Но , повторюсь, я давно не кодер. И повторюсь, софт-скилы IMHO важнее , а их тестовыми задачами не протестить.
Личный опыт во время бывшего тимлидерства - резюме в общем то и не смотрел , просто разговаривал, в скайпе или зуме.
Но, наверное для кодеров свои особенности , я DBA.