Я уже написал пару статей. Как бы вижу, за что минусуют. Там есть выборка. Но! Поставить можно что угодно. Вот бы к каждому минусу было требование написать, что именно не понравилось, и там везде было бы "Автор дурак", продублированный несколько десятков раз для преодоления минимума (если он бы был). А еще лучше: сделать так, чтобы было видно, кто поставил минус. Для всех. То же сделать и с плюсами. А лучше вообще убрать к черту эту ерунду, и пусть люди пишут вживую в комментариях или просто пропускают. Тогда все встанет на свои места. А так получается какая-то промокашка вместо реального общения. И, кстати говоря, я согласен с некоторыми минусами на 100%, я действительно ошибался и так мне и надо. Но на остальные оценки "Я не согласен с автором, потому что он дурак" мне наплевать. Ограничение 1 комментарий на 5 минут я еще могу пережить, а вот если полностью заблокируют то я либо заведу новый аккаунт, либо просто сеппукну с этой платформы и буду жить дальше.
Все, понял. Я буду иметь это ввиду. Просто некоторые вещи мне казались очевидными и не требующими доказательств. К примеру, я счел нужным доказать то, что надо использовать именно алгоритм сжатия zstd (само доказательство, кстати, на деле такое себе). Но при этом не стал доказывать кучу других вещей.
Хабр это на 95% соцсеть, как по мне. Скучную и нудную статью читать будут единицы. У меня и так по всем статьям в среднем 5% дочтений. Целью были именно системные администраторы широкого профиля, и, возможно, начинающие разработчики, то есть молодые люди, коим я сам и являюсь до сих пор.
Мои оценочные суждения, эмоции, ругательства и т.п. - да, не очень приятно некоторым такое читать. Но это часть меня. В каждой статье меня ведет куда-то не туда. По натуре я очень вспыльчивый и правдолюбивый. Тем более, что это МОЯ статья, а не дипломная работа и не документация к проекту. Я не ставлю себе цель сколотить имя через интернет, мне это просто не нужно. Я работал со многими ИТшниками, и видел некоторых, которые еще хуже и позволяют себе куда больше, то есть это люди без тормозов вообще. Вроде бы вот есть инженер: несет такую ахинею, хоть в тигель прыгай. А на всех проектах под его руководством полный порядок, и ценят его именно за это. Но у меня этого нет. Я и как личность не очень, и как инженер. Наверное, с годами это уйдет, и я стану нормальным человеком.
За комментарии по делу спасибо. А вот со всем остальным - это вы так видите. Слово "неадекватность" каждый понимает так, как ему выгодно (прямо как: лояльность, подход и т.п.). Вижу дуб, не вижу лес. Все люди разные, у каждого свой опыт. Так что с написанным кто-то согласится, а кто-то нет.
Почитайте другие комментарии. Некоторые люди указывали на конкретные ошибки и недочеты, я их признавал и исправлял. Не с первого раза, но исправлял. А ваше "Все не так и все не то" это пустой звук. Я уже писал статьи до этого, и прекрасно знаю, что конкретики добиться от людей с подобными заявлениями не получится. Но все же сделаю вид, что я воспитанный человек, и попрошу вас указать на конкретные недочеты и с чем конкретно вы не согласны.
Все люди ошибаются. Каждый в чем-то прав и в чем-то не прав. Вы должны это понимать.
Да, не спорю. А как же другие компании? EDB, к примеру? Я разместил много ссылок, и некоторые из них именно от EDB (я действительно думаю, что больший вклад был именно со стороны EDB), а вот от PostgresP*O даже разместил одну книгу. Вы это заметили? А вот документация это просто google translate. А что насчет других разработчиков модулей и сторонних продуктов? К примеру, как тот же WAL-G или PoWA? Почему-то о них никто не вспоминает. А так в целом маркетинговая компания удалась. Так нагадить образованным людям в головы это надо постараться. Если я как-нибудь на работе столкнусь с PostgresP*O, то обязательно сравню их pg_probackup с моим любимым Barman. Даже если результат будет не в пользу последнего - все равно выложу итоги в общий доступ. Да, так делать нельзя, потому что по сути это две разные СУБД. Но все же.
Как только так сразу. Если я найду подобную работу - буду держаться за нее всеми 27 оставшимися зубами. А пока что мне платят и за это тоже. Начну бузить - они просто найдут кто-то еще. Если бы у меня была своя квартира, и мне каждый месяц на карту просто бы так, ни за что приходило хотя бы 30 тыс. деревянных - честно, я бы вообще не работал. А вот как бы реальность, и нужны деньги.
Технических деталей не знаю. Может, там была вообще версия Express. Зря написал про них. Надо себя отучать писать о том, в чем не уверен.
А вот 1Ска это да, главная проблема. Как бы есть готовая сборка на PostgreSQL, которая работает как надо, но все равно люди сидят на MS SQL Server. Не настолько же большая проблема переобучиться и перенести базы (если организация не работает 24/7 и не крупная). Надо с нескольких сторон к вопросу подходить.
С первым согласен. В первой части статьи уже все расписал.
Да, есть жадные мрази. И даже не жадные, а, скорее... не знаю, как объяснить. Просто вот есть точка зрения нас, наемных рабочих, простых людей, а есть точка зрения тех, кто сидит там наверху (их я к людям не отношу). И они прекрасно видят, откуда деньги приходят и куда уходят. Никто не станет в здравом уме держать 10 специалистов по направлению системного администрирования в фирме, где всего 100-150 сотрудников. Максимум - утвердят должность помощника. А это бюджет, а это надо организовать рабочее место. В общем, проблем много.
Мы с вами просто в разных вселенных.
Ну, вы, наверное, можете себе позволить работать 90-100% рабочего времени удаленно, из дома или еще откуда-то. А вот я и большинство, наоборот, - максимум 10%.
Все зависит от нагрузок. Подобрать значение для достижения максимальной производительности крайне сложно. Да в целом для подавляющего большинства это и не требуется (сужу только по своему опыту). Ну, будет 25,3 попугая вместо 25. Не особо критично же. Главное, не оставлять 128MB. Да и про снижение нагрузки на диск не надо забывать, это ведь тоже важно. А учить устройство кеша, и что такое это ваше закрепление буфера, такие сисадмины-универсалы (как я) не будут. Если вы работаете большую часть времени именно с PostgreSQL - то однозначно да, учить надо. Но вот есть я, и есть другие сисадмины-универсалы, которым нужно готовое решение и практика. Когда работаешь с 20 разными технологиями, это очень чувствуется: не надо учить то, что не будешь использовать на практике. Это же вы вроде мне писали, что сисадмин - это тупиковый путь развития, или что-то такое. Может быть, но сисадмины-универсалы тоже ведь нужны. Мы же не в идеальном мире живем, где каждый делает свое дело и хорош именно в этом. Эникейство составляет примерно 3/5 моего рабочего времени, если честно (если не больше), как и у многих других. Надеюсь, мысль донес.
В первом случае речь про нормальных таких клиентов, то есть 300 людей работают одновременно. Сервера для 1С (И для самой платформы, и для СУБД) в 90% организаций являются самыми мощными. 32 GB на 300 юзеров (конкретно для самой СУБД, то есть мы не рассматриваем случай, когда и приложение, и СУБД на одном хосте) недостаточно. Просто недостаточно. Они, может, и подключатся, но вот юзеры работать нормально не смогут. Аналогично и с хранилищем на HDD.
А в чем проблема со вторым? Вот есть пакеты postgresql-15 и postgresql-16, к примеру. Я смигрировал все базы на 16 версию, а зачем мне сервер 15?
Или вы про то, что это очевидные вещи? Для нас с вами - да, а вот для остальных - не могу знать.
Про huge_pages - мы просто получим больше пользы (выгоды, профита, называйте как хотите), чем при использовании HP. Да, зависит от приложения. Да, со временем может измениться. Но пока что имеем, что имеем. Если СУБД используется для приложения, у которого, скажем, 1000 таких жирных клиентов, то да, можно подумать об использовании HP.
Про work_mem. Да, конкретно для 1С я видел много рекомендаций по увеличению этого параметра. Вплоть до нескольких гигабайт (общий объем памяти делят на 32-64, что на самом деле является бредом). Но как бы речь не про 1С, и не про сборку PostgreSQL для 1С. А, увидел, тоже считаете подобные рекомендации странными.
Так что, остановимся на том, что можно увеличить work_mem вплоть до 32MB?
Да, согласен. Но вот есть реалии, и выходим мы из дома в 7-8 утра, и возвращаемся к 7 в лучшем случае, полностью измотанными. И так пять-шесть дней в неделю. Да, надо учится. Но не у каждого есть силы и время.
Про тот же shared_buffers я уже все написал. Там действительно лучше задать 40% (если памяти хватает). Производительность, может, и не вырастет (об этом сказано в документации напрямую), но вот нагрузка на дисковую подсистему снизится точно.
Дело не в том, что они его отключили. дело в том, почему они это сделали. А сделали они это потому, что не смогли подключиться, а менять и открывать порты им либо лень, либо они не знают как. Иными словами, разделение той же 1Ски и СУБД на два разных хоста для них задача выше среднего.
Сам MS SQL Server прекрасен. Но вот ходить под статьей не очень хочется. 95% пиратят его именно для 1С. Остальные пять - либо для WSUS, либо для Solidworks PDM. Возможно, еще для каких-то других сервисов. Но пока что я видел только это.
Так, добавил небольшую историческую справку, которую я уже не помню то ли где-то прочитал, то ли где-то услышал. Согласен, лучше подобную бесполезную информацию не добавлять. Я не работал со старыми версиями, только один раз обновлял с 9.3 до 14.
Вы не обидели. Никакого конфликта не было, потому что с PostgresP*O я не работал. Я не могу оценить вклад, который внесли в open source коммерческие организации. Просто вот есть я, по сути дела конечный пользователь, который смотрит вот только на это. А сервера у меня почти все на Ubuntu, кстати. Если что-то пойдет не так, я просто перейду на Debian.
Про 1Ску надо было уточнять да, потому что умников тоже хватает. Но как бы статья не про 1С. Чем больше изучаю подобные темы - тем больше понимаю, что лучше свое мнение не высказывать, имеем что имеем.
Никакого тонкого тюнинга в статье нет. Просто отправная точка. Если система крупная - там да. Но для большинства главное, чтобы не было проблем (как с тем же отключением автовакуума), а повышение производительности и снижение потребления ресурсов для них так, приятный бонус. Очень многих проблем на самом деле можно избежать, просто изменив пару параметров. Если для той же 1Ски оставить объем общих буферов в 128MB для 50 живых юзеров это уже реальная катастрофа. Про оборудование уже сказал. С облаками не работал.
То есть вы хотите сказать, что если автовакуум захочет пройтись по одной таблице из 1 млн. строк, то одновременно будет задействован только один процесс? Если да, то это очень странно. Хотя, чего странного, у нас ведь блокировки. В общем, исправлю. Производительность на ядро опять выстрелила.
Я уже написал пару статей. Как бы вижу, за что минусуют. Там есть выборка. Но! Поставить можно что угодно. Вот бы к каждому минусу было требование написать, что именно не понравилось, и там везде было бы "Автор дурак", продублированный несколько десятков раз для преодоления минимума (если он бы был). А еще лучше: сделать так, чтобы было видно, кто поставил минус. Для всех. То же сделать и с плюсами. А лучше вообще убрать к черту эту ерунду, и пусть люди пишут вживую в комментариях или просто пропускают. Тогда все встанет на свои места. А так получается какая-то промокашка вместо реального общения. И, кстати говоря, я согласен с некоторыми минусами на 100%, я действительно ошибался и так мне и надо. Но на остальные оценки "Я не согласен с автором, потому что он дурак" мне наплевать. Ограничение 1 комментарий на 5 минут я еще могу пережить, а вот если полностью заблокируют то я либо заведу новый аккаунт, либо просто сеппукну с этой платформы и буду жить дальше.
Все, понял. Я буду иметь это ввиду. Просто некоторые вещи мне казались очевидными и не требующими доказательств. К примеру, я счел нужным доказать то, что надо использовать именно алгоритм сжатия zstd (само доказательство, кстати, на деле такое себе). Но при этом не стал доказывать кучу других вещей.
Хабр это на 95% соцсеть, как по мне. Скучную и нудную статью читать будут единицы. У меня и так по всем статьям в среднем 5% дочтений. Целью были именно системные администраторы широкого профиля, и, возможно, начинающие разработчики, то есть молодые люди, коим я сам и являюсь до сих пор.
Мои оценочные суждения, эмоции, ругательства и т.п. - да, не очень приятно некоторым такое читать. Но это часть меня. В каждой статье меня ведет куда-то не туда. По натуре я очень вспыльчивый и правдолюбивый. Тем более, что это МОЯ статья, а не дипломная работа и не документация к проекту. Я не ставлю себе цель сколотить имя через интернет, мне это просто не нужно. Я работал со многими ИТшниками, и видел некоторых, которые еще хуже и позволяют себе куда больше, то есть это люди без тормозов вообще. Вроде бы вот есть инженер: несет такую ахинею, хоть в тигель прыгай. А на всех проектах под его руководством полный порядок, и ценят его именно за это. Но у меня этого нет. Я и как личность не очень, и как инженер. Наверное, с годами это уйдет, и я стану нормальным человеком.
За комментарии по делу спасибо. А вот со всем остальным - это вы так видите. Слово "неадекватность" каждый понимает так, как ему выгодно (прямо как: лояльность, подход и т.п.). Вижу дуб, не вижу лес. Все люди разные, у каждого свой опыт. Так что с написанным кто-то согласится, а кто-то нет.
Почитайте другие комментарии. Некоторые люди указывали на конкретные ошибки и недочеты, я их признавал и исправлял. Не с первого раза, но исправлял. А ваше "Все не так и все не то" это пустой звук. Я уже писал статьи до этого, и прекрасно знаю, что конкретики добиться от людей с подобными заявлениями не получится. Но все же сделаю вид, что я воспитанный человек, и попрошу вас указать на конкретные недочеты и с чем конкретно вы не согласны.
Все люди ошибаются. Каждый в чем-то прав и в чем-то не прав. Вы должны это понимать.
Да, не спорю. А как же другие компании? EDB, к примеру? Я разместил много ссылок, и некоторые из них именно от EDB (я действительно думаю, что больший вклад был именно со стороны EDB), а вот от PostgresP*O даже разместил одну книгу. Вы это заметили? А вот документация это просто google translate. А что насчет других разработчиков модулей и сторонних продуктов? К примеру, как тот же WAL-G или PoWA? Почему-то о них никто не вспоминает. А так в целом маркетинговая компания удалась. Так нагадить образованным людям в головы это надо постараться. Если я как-нибудь на работе столкнусь с PostgresP*O, то обязательно сравню их pg_probackup с моим любимым Barman. Даже если результат будет не в пользу последнего - все равно выложу итоги в общий доступ. Да, так делать нельзя, потому что по сути это две разные СУБД. Но все же.
Как только так сразу. Если я найду подобную работу - буду держаться за нее всеми 27 оставшимися зубами. А пока что мне платят и за это тоже. Начну бузить - они просто найдут кто-то еще. Если бы у меня была своя квартира, и мне каждый месяц на карту просто бы так, ни за что приходило хотя бы 30 тыс. деревянных - честно, я бы вообще не работал. А вот как бы реальность, и нужны деньги.
Технических деталей не знаю. Может, там была вообще версия Express. Зря написал про них. Надо себя отучать писать о том, в чем не уверен.
А вот 1Ска это да, главная проблема. Как бы есть готовая сборка на PostgreSQL, которая работает как надо, но все равно люди сидят на MS SQL Server. Не настолько же большая проблема переобучиться и перенести базы (если организация не работает 24/7 и не крупная). Надо с нескольких сторон к вопросу подходить.
С первым согласен. В первой части статьи уже все расписал.
Да, есть жадные мрази. И даже не жадные, а, скорее... не знаю, как объяснить. Просто вот есть точка зрения нас, наемных рабочих, простых людей, а есть точка зрения тех, кто сидит там наверху (их я к людям не отношу). И они прекрасно видят, откуда деньги приходят и куда уходят. Никто не станет в здравом уме держать 10 специалистов по направлению системного администрирования в фирме, где всего 100-150 сотрудников. Максимум - утвердят должность помощника. А это бюджет, а это надо организовать рабочее место. В общем, проблем много.
Мы с вами просто в разных вселенных.
Ну, вы, наверное, можете себе позволить работать 90-100% рабочего времени удаленно, из дома или еще откуда-то. А вот я и большинство, наоборот, - максимум 10%.
Все зависит от нагрузок. Подобрать значение для достижения максимальной производительности крайне сложно. Да в целом для подавляющего большинства это и не требуется (сужу только по своему опыту). Ну, будет 25,3 попугая вместо 25. Не особо критично же. Главное, не оставлять 128MB. Да и про снижение нагрузки на диск не надо забывать, это ведь тоже важно. А учить устройство кеша, и что такое это ваше закрепление буфера, такие сисадмины-универсалы (как я) не будут. Если вы работаете большую часть времени именно с PostgreSQL - то однозначно да, учить надо. Но вот есть я, и есть другие сисадмины-универсалы, которым нужно готовое решение и практика. Когда работаешь с 20 разными технологиями, это очень чувствуется: не надо учить то, что не будешь использовать на практике. Это же вы вроде мне писали, что сисадмин - это тупиковый путь развития, или что-то такое. Может быть, но сисадмины-универсалы тоже ведь нужны. Мы же не в идеальном мире живем, где каждый делает свое дело и хорош именно в этом. Эникейство составляет примерно 3/5 моего рабочего времени, если честно (если не больше), как и у многих других. Надеюсь, мысль донес.
Исправил.
В первом случае речь про нормальных таких клиентов, то есть 300 людей работают одновременно. Сервера для 1С (И для самой платформы, и для СУБД) в 90% организаций являются самыми мощными. 32 GB на 300 юзеров (конкретно для самой СУБД, то есть мы не рассматриваем случай, когда и приложение, и СУБД на одном хосте) недостаточно. Просто недостаточно. Они, может, и подключатся, но вот юзеры работать нормально не смогут. Аналогично и с хранилищем на HDD.
А в чем проблема со вторым? Вот есть пакеты postgresql-15 и postgresql-16, к примеру. Я смигрировал все базы на 16 версию, а зачем мне сервер 15?
Или вы про то, что это очевидные вещи? Для нас с вами - да, а вот для остальных - не могу знать.
Про huge_pages - мы просто получим больше пользы (выгоды, профита, называйте как хотите), чем при использовании HP. Да, зависит от приложения. Да, со временем может измениться. Но пока что имеем, что имеем. Если СУБД используется для приложения, у которого, скажем, 1000 таких жирных клиентов, то да, можно подумать об использовании HP.
Про work_mem. Да, конкретно для 1С я видел много рекомендаций по увеличению этого параметра. Вплоть до нескольких гигабайт (общий объем памяти делят на 32-64, что на самом деле является бредом). Но как бы речь не про 1С, и не про сборку PostgreSQL для 1С. А, увидел, тоже считаете подобные рекомендации странными.
Так что, остановимся на том, что можно увеличить work_mem вплоть до 32MB?
Увидел, исправил.
Да, согласен. Но вот есть реалии, и выходим мы из дома в 7-8 утра, и возвращаемся к 7 в лучшем случае, полностью измотанными. И так пять-шесть дней в неделю. Да, надо учится. Но не у каждого есть силы и время.
Про тот же shared_buffers я уже все написал. Там действительно лучше задать 40% (если памяти хватает). Производительность, может, и не вырастет (об этом сказано в документации напрямую), но вот нагрузка на дисковую подсистему снизится точно.
Дело не в том, что они его отключили. дело в том, почему они это сделали. А сделали они это потому, что не смогли подключиться, а менять и открывать порты им либо лень, либо они не знают как. Иными словами, разделение той же 1Ски и СУБД на два разных хоста для них задача выше среднего.
Сам MS SQL Server прекрасен. Но вот ходить под статьей не очень хочется. 95% пиратят его именно для 1С. Остальные пять - либо для WSUS, либо для Solidworks PDM. Возможно, еще для каких-то других сервисов. Но пока что я видел только это.
Специально для самых ранимых читателей убрал. Ладно, признаю, это было некультурно.
Так, добавил небольшую историческую справку, которую я уже не помню то ли где-то прочитал, то ли где-то услышал. Согласен, лучше подобную бесполезную информацию не добавлять. Я не работал со старыми версиями, только один раз обновлял с 9.3 до 14.
За замечание про бэкап конфигов спасибо, учту.
Вы не обидели. Никакого конфликта не было, потому что с PostgresP*O я не работал. Я не могу оценить вклад, который внесли в open source коммерческие организации. Просто вот есть я, по сути дела конечный пользователь, который смотрит вот только на это. А сервера у меня почти все на Ubuntu, кстати. Если что-то пойдет не так, я просто перейду на Debian.
Про 1Ску надо было уточнять да, потому что умников тоже хватает. Но как бы статья не про 1С. Чем больше изучаю подобные темы - тем больше понимаю, что лучше свое мнение не высказывать, имеем что имеем.
Никакого тонкого тюнинга в статье нет. Просто отправная точка. Если система крупная - там да. Но для большинства главное, чтобы не было проблем (как с тем же отключением автовакуума), а повышение производительности и снижение потребления ресурсов для них так, приятный бонус. Очень многих проблем на самом деле можно избежать, просто изменив пару параметров. Если для той же 1Ски оставить объем общих буферов в 128MB для 50 живых юзеров это уже реальная катастрофа. Про оборудование уже сказал. С облаками не работал.
То есть вы хотите сказать, что если автовакуум захочет пройтись по одной таблице из 1 млн. строк, то одновременно будет задействован только один процесс? Если да, то это очень странно. Хотя, чего странного, у нас ведь блокировки. В общем, исправлю. Производительность на ядро опять выстрелила.