Подобрать значение для достижения максимальной производительности крайне сложно.
И нецелесообразно. Полученный эффект не стоит затраченного времени.
сисадмины-универсалы тоже ведь нужны.
Особенно жадным работодателям. Ага, просто находка.
Надеюсь, мысль донес.
Мысль понятна, зачем вы за это цепляетесь , особенно учитывая текущую ситуацию на рынке труда и легкую возможность работать удаленно. Лично мне не совсем понятно.
По поводу рекомендаций и цифр. Добавлю свои 5 копеек .
Чем дольше, тем больше прихожу к предположению , что эффект тонкого тюнинга конфигурационных настроек СУБД совершенно не стоит потраченного времени и полностью нивелируется побочными эффектами инфраструктуры и приложения .
А с оценкой влияния изменения какого либо параметра на производительностью СУБД в условиях облачной инфраструктуры совсем все печально . Оценить эффект практически невозможно .
Как эта ситуация повлияла на работоспособность СУБД ? У вас бекап и СУБД в одной файловой системе ? Ну , так это ваш личный выбор и ваши личные проблемы .
DBA не предоставляет и не контролирует сервис backup . Это не моя работа , для этого есть команда BAS.
Это было очень давно, во времена работы в банках, и при первой же возможности я ушел из этой области .
Мне трудно представить, как вы всю жизнь работали именно DBA.
Начал программистом на C , C++, Delphi. Потом относительно недолгий период то, что сейчас называют сисадмином . Потом DBA.
Просто личный совет - сисадминство это тупиковый путь эволюции айтишника.
Кстати, что вы думаете о PoWA?
Ничего не думаю. Повторюсь , я DBA у меня другие задачи . Мониторингом я не занимаюсь . Иногда ставлю задачи группе мониторинга по настройке кастомных метрик . Как работает мониторинг и какой инструментарий мне все равно. Пусть каждый занимается своим делом - DB Service , Unix service , Virtualization Service , Storage service , Backup Service , Monitoring Service etc.
Материалов , в отличии от моей молодости - мегатонны. Хороших материалов, фундаментальных , опытных.
И еще раз - я не знаю, кто такие сисадмины . Я DBA и работаю в компании с такими же DBA.
Сисадмины времён 90-х давно канули в историю .
Хотелось бы увидеть от вас развернутое мнение о статье, если не затруднит.
Вам не понравится даже краткое мнение . Да , потраченное время и энергия и нервы . Но , примите как есть - ничего нового , всё это уже было по многу раз в других статьях и источниках.
Время лучше тратить на оригинальные идеи , даже , скажу по себе , если они пока и не принимаются большинством. Новое , если это стоящее и полезное, всё равно пробьется , со временем .
А очередное повторение , завтра все забудут и никто не оценит. А на Хабре еще и карму сольют.
Вы же не ведёте блог какой то компании которая донатит Хабр. Это им можно жевать одно и тоже и двигать свою рекламу .
По этому поводу у меня была долгая и местами нервная дискуссия с главным архитектором, решившим оптимизировать потребление памяти в информационных системах.
С одной стороны , вроде вещи правильные высказываются , с другой непонятные эмоции, с третьей реально галопом по европам.
Как учебное пособие для начинающих - не рекомендовал бы .
С другой стороны , на Хабре в последнее время так мало реально технических статей , что любому проблеску в потоке беллетристики наверное читатели будут рады.
По ободу пишутся номера. Затем старт и остановка.
Псевдогенератор случайных чисел ;-)
Самое необычное использование игры, которое я видел - генерация номеров для "Спортлото"
Почему ? В чем проблема ? hh точка ру по моему 99% вакансий "можно из дома".
Я спасибо ковиду и удаленке, иначе найти DBA в Москве например было практически нереально. А сейчас география специалистов по всей России .
И нецелесообразно. Полученный эффект не стоит затраченного времени.
Особенно жадным работодателям. Ага, просто находка.
Мысль понятна, зачем вы за это цепляетесь , особенно учитывая текущую ситуацию на рынке труда и легкую возможность работать удаленно. Лично мне не совсем понятно.
И с большой вероятностью получить ожидания Buffer pin
И гадать - как же так , shared buffer большой и производительность не растет , а даже наоборот
По поводу рекомендаций и цифр. Добавлю свои 5 копеек .
Чем дольше, тем больше прихожу к предположению , что эффект тонкого тюнинга конфигурационных настроек СУБД совершенно не стоит потраченного времени и полностью нивелируется побочными эффектами инфраструктуры и приложения .
А с оценкой влияния изменения какого либо параметра на производительностью СУБД в условиях облачной инфраструктуры совсем все печально . Оценить эффект практически невозможно .
Как эта ситуация повлияла на работоспособность СУБД ? У вас бекап и СУБД в одной файловой системе ? Ну , так это ваш личный выбор и ваши личные проблемы .
DBA не предоставляет и не контролирует сервис backup . Это не моя работа , для этого есть команда BAS.
Да и мониторить Ram utilisation + Disk utilization . К тому же измение параметра не требует рестарта СУБД.
Хотя лучшее решение - менять на уровне сессии. Но это требует продвинутых разрабов, это сейчас редкость.
Это было очень давно, во времена работы в банках, и при первой же возможности я ушел из этой области .
Начал программистом на C , C++, Delphi. Потом относительно недолгий период то, что сейчас называют сисадмином . Потом DBA.
Просто личный совет - сисадминство это тупиковый путь эволюции айтишника.
Ничего не думаю. Повторюсь , я DBA у меня другие задачи . Мониторингом я не занимаюсь . Иногда ставлю задачи группе мониторинга по настройке кастомных метрик . Как работает мониторинг и какой инструментарий мне все равно. Пусть каждый занимается своим делом - DB Service , Unix service , Virtualization Service , Storage service , Backup Service , Monitoring Service etc.
Учиться , учиться и еще раз - учиться. (С)
Материалов , в отличии от моей молодости - мегатонны. Хороших материалов, фундаментальных , опытных.
И еще раз - я не знаю, кто такие сисадмины . Я DBA и работаю в компании с такими же DBA.
Сисадмины времён 90-х давно канули в историю .
Вам не понравится даже краткое мнение . Да , потраченное время и энергия и нервы . Но , примите как есть - ничего нового , всё это уже было по многу раз в других статьях и источниках.
Время лучше тратить на оригинальные идеи , даже , скажу по себе , если они пока и не принимаются большинством. Новое , если это стоящее и полезное, всё равно пробьется , со временем .
А очередное повторение , завтра все забудут и никто не оценит. А на Хабре еще и карму сольют.
Вы же не ведёте блог какой то компании которая донатит Хабр. Это им можно жевать одно и тоже и двигать свою рекламу .
Нет нет и ещё раз RTFM
Другими словами разработчик может написать такой запрос , что при любом значении данного параметра придёт OOM killer
Ну начнём с того , что аварийные остановки СУБД вызванные недостатком дискового пространства составляют пренебрежительно малую часть от всех причин.
А на производительность СУБД количество свободного места на диске не влияет вообще никак .
Скажу более - мониторинг свободного места в файловой системе это вообще не зона ответственности DBA.
По уровню важности это не на первом месте и даже на не на втором.
Лаг репликации - важнее.
Я не знаю кто это такие "сисадмины". Я всю жизнь работал и продолжаю работать как Data Base Administrator.
Универсал , это значит и там и сям и тут и там , везде по чуть чуть и нигде по настоящему .
Не надо мониторить 100 параметров .
Что надо мониторить DBA описано не один и не два а много раз во многих статьях и докладах.
Мы например мониторим:
Производительность СУБД
Количество активных сессий
Ошибки СУБД
Время отклика
Query per second
Transaction per second
Количество прочитанных блоков в секунду
Количество записанных блоков в секунду
Количество измененных блоков в секунду
[Лаг репликации]
По этому поводу у меня была долгая и местами нервная дискуссия с главным архитектором, решившим оптимизировать потребление памяти в информационных системах.
Странное впечатление от статьи.
С одной стороны , вроде вещи правильные высказываются , с другой непонятные эмоции, с третьей реально галопом по европам.
Как учебное пособие для начинающих - не рекомендовал бы .
С другой стороны , на Хабре в последнее время так мало реально технических статей , что любому проблеску в потоке беллетристики наверное читатели будут рады.
Это чрезвычайно смелое , граничащее с авантюрой , утверждение .
Каждый кто прочитает это, и не уточнит по документации, получит аварийную остановку СУБД по причине OOM Killer.
Это высказывание - ложно.
RTFM
Почему не ALTER SYSTEM SET .... ?
В общем то да , именно про PostgreSQL.
Контраст с отечественными облачными решениями очень заметен(по крайней мере с знакомыми лично мне), прям невооруженным взглядом.
СУБД работает . Облако тоже как бы работает , но со скрипом... Скажем так, мягко и культурно.
Совсем не факт. Вполне вероятно , что серверный процесс ждет освобождения блокировки или IO, например.
Т.е. полезную работу они не выполняют.
Для объективной картины все таки надо уточнить , что с импортозамещением не все так плохо и есть отличные кейсы - СУБД.