Pull to refresh
-15
0
Send message

 Но мне Хабр нравится

Это ваш личный выбор.

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

Когда появилось время , и появились новые статьи , хотел получить обратную связь, поговорить с коллегами (я помню именно так и было лет 5-6 назад, именно - разговор с коллегами) , обмен мнениями - получил слив кармы толпой, "личная неприязнь", "низкий технический уровень", "ничего не понял после прочитанного". И Хабр мне перестал нравится.

Потом - бан без предупреждения , просто за высказывание своего мнение. И всё, Хабр мне окончательно не нравится.

Просто как газета почитать. Пару комментариев в день, ничего особенного.

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

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

Где еще я мог бы публично обсудить проблемы Open Source или контейнеризации, например

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

Остаются только телеграм-каналы 

Пробовал. Из тех которые находил - молодежная тусовка какая то , не моё.

В качестве рабочего блокнота для записей результатов экспериментов я использую - Дзен.

Для популяризации и индексации статей - Пикабу.

Так, что судьба Хабра меня мало трогает, вернее вообще не трогает. Захожу почитать, как газету в обеденный перерыв.

Иногда , очень редко, попадается статья в подписанном хабе.

P.S. У меня и на VC есть блог, только там ничего нет. Странная политика по теневому бану , привела к тому, что я там статьи не размещаю. Да и давно уже не заходил.

Хм, есть масса форумов с большим трафиком, соглашусь.

Но мне по работе нужна информация по СУБД.

Раньше был sql.ru но хозяин ресурса оказался с гнилой и площадка умерла.

Форумы(и телеграмм каналы) по СУБД в принципе есть , если поискать, но реально живые и уж тем более полезные для уровня выше юниора, я пока не нашел.

Каналы в телеге это отдельная песня конечно. Может быть кому то подростковый сленг и манеры и в кайф. А я уже старый для общения с подростками на равных и тем более на их языке.

Так, что к сожалению , пока с внешней информацией не очень. Вернее вообще никак.

Я в свое время , пытался спрашивать на форумах.

Там еще тише , чем тут.

Мир изменился . Предположу, те , кто может сказать что то полезное, на форумах не сидят. Или не больно то и хотят делиться знаниями и опытом.

Сообщество вам дало понять, что такие авторы тут не нужны.

Именно так . Редкий случай взаимного консенсуса. Мне тоже такое сообщество - не нужно.

А кому , если вдруг интересна тема - канал Дзен "Postgres DBA" .

Рgpro_pwr — инструмент стратегического мониторинга 

А, что скажете , по поводу встречного

Оперативно-тактический мониторинг производительности

9вообще не понимаю, зачем люди пишут на Хабр.

Давным давно , я регулярно писал технические статьи на хабре . Мне очень был нужен взгляд со стороны и обсуждение идей . Сначала в 2019-20 году было и то и другое. Потом был перерыв в связи с переходом на руководящую должность . После возвращения в инженеры , опять появились идеи которые хотелось обсудить. Опять стал писать, на Хабре.

НО,

Хабр уже стал другим - конструктива ноль - это все неправильно , "личная неприязнь", "низкий технический уровень" , "ничего не понял из прочитанного ". Вплодь до откровенного хамства в комментариях. Карму сливали постоянно. Поэтому терял возможность оперативно отвечать и печатать новые статьи, хотя в топ по итогам прошлого года попал :-)

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

Всё, больше я на Хабре ничего не пишу.

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

Хабр в режиме чтения и редкого комментирования .

Как в известном меме "Всё. Парам парам парам пам".

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

Единственно жалею - надо было сразу уходить , как карму слили . И статьи удалять .

Делать выводы и анализ на основании недостоверных данных - это ваш личный выбор.

Но в целом вопрос стоит- как на высоконагруженных системах научится предугадывать когда настанут критические ситуации?

Мое личное мнение на основе анализа и наблюдений за прошедшие 5 лет - предсказать невозможно.

1) СУБД по сути своей есть стохастическая система

2) СУБД в облачной инфраструктуре(сейчас самый распространенный вариант) - подвержена влиянию массы случайных и непредсказуемых факторов со стороны виртуализации

3)Современные разработчики вообще темой нагрузочного тестирования не заморачиваются, что в очередной раз вылезет со стороны приложения или backend - предсказать невозможно

4)Нагрузка и характер действий конечных пользователей непредсказуем в принципе

в DBA нужна точность, математика и цифры полученные и подтвержденные экспериментально, а не гадания на кофейной гуще.

Да хоть как. Вот эта формула точно к CPU вообще никакого отношения не имеет. Пальцем небо.

Если нужны точные данные для анализа, а не для отчетности юзерам то:

Тип pgpro_stats_rusage 

exec_rusagepgpro_stats_rusage Статистика использования ресурсов при выполнении оператора.

Расширение pgpro_stats.

Может быть еще где-то есть, я использую этот инструмент.

Хотя в последний раз когда смотрел утилизацию CPU и не помню. Потому, что как правило производительность СУБД и утилизация CPU никак не связаны.

Вернее, более строго

  • если производительность не снижается, а CPU растет , то это не инцидент.

  • если производительность снижается , а CPU растет , то это инцидент.

pg_stat_statement и выдаст вам такую ифомрацию. Именно самые тяжелые запросы по CPU

pg_stat_statements не позволяет получить отчет по утилизации CPU. только по total_exec_time .

В настоящее время ведутся работы по теме анализа производительности СУБД.

Идея в следующем :

1) определяем что производительность снизилась

2) анализ причин - определение SQL запроса оказывающего максимальное влияние на деградацию производительности

3) анализ проблемного SQL запроса

4) исправление проблемы .

———

Методика, описанная в статье, начнется на шаге 3 и 4. Так, что , поживём увидим. Может и "можно в партнерстве если есть наработки".

Статья сохранена в закладках.

Мне интересно мнение читателей: насколько это востребовано? 

Востребовано. В рамках работ по теме "черного ящика" для СУБД были некоторые этюды по сохранению истории утилизации RAM процессами postgres. Но дальше эскизных тестов тема не пошла. Пока отложено в долгий ящик.

Однако , на Пикабу есть игнор-лист . Скрыть токсичных комментаторов - 3 клика мышки. На Хабре - никак. Скрыть можно только посты. И только по одному аккаунту. А на Пикабу по тэгу. Например по тэгу 'политика'. Правда на Пикабу, в отличии от Хабра , для любителей политсрачей заведено отдельное сообщество и в общей ленте они не отсвечивают после настройки игнор-листа.

Почему Пикабу никогда не вернёт минусы?⁠⁠

https://pikabu.ru/story/pochemu_pikabu_nikogda_ne_vernyot_minusyi_12328957

  • mean_exec_time — среднее время выполнения запроса;

В данном случае, есть одна серьезная проблема - "среднее арифметическое" неустойчиво к выбросам. А выбросы в продуктивной СУБД и особенно в облаках - это норма.

В результате - возможны аномалии. Например , встретил такое :

https://dzen.ru/a/Z1--cZ4sHEmzLsy5

Поэтому, данный показатель использовать при анализе запросов в продуктивном контуре - рискованно. Можно потратить время на поиск проблемы там где проблемы в общем то и нет.

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

Попробуйте посмотреть здесь https://dzen.ru/kznalp

И здесь были статьи на тему расчета метрики производительности

https://habr.com/p/850106/

12 ...
10

Information

Rating
Does not participate
Registered
Activity