LINUX.ORG.RU
ФорумAdmin

Кое что хотел знать о PostgreSQL, но боялся спросить

 , ,


0

1

Если дать серверу объем ОЗУ превышающий объем баз на диске, будет ли какой то прирост производительности.

У меня сейчас есть возможность попробовать, но для этого нужно ночью просыпаться, а я пока заочно посоветуюсь с экспертами…

Второе утверждение, если ОЗУ превышает объем баз, все закешируется и требования к производительности дисковой подсистемы снизятся, так ли это?

Ну то есть не SSD покупать за 100 тыров, а 128 ГБ ОЗУ, если у меня кластер 100ГБ. И все?

Что скажут знатоки?

В общем навеяно инфой, если не изменяет память от самого @maxcom.

PS. Может ЛОРу это и помогает, а 1С ничего не поможет, но не забегаю вперед

128 ГБ ОЗУ, если у меня кластер 100ГБ. И все

Зависит от того, какие запросы. Может у тебя там на каждый чих временная таблица для сортировки создаётся на 100Гб. Тогда никакой памяти не хватит.

no-such-file ★★★★★ ()

В общем

В общем

объем превышающий...объем

будет ли какой то прирост производительности.

Второе утверждение,

И это далеко не всё.

anonymous ()
Ответ на: комментарий от Shulman

она скорее много их создает но небольших

Дык они и неявно создаются, если запрос по-другому нельзя выполнить. Я к тому, что недостаточно просто сделать память больше чем объём данных, нужно ещё чтобы было где промежуточные результаты хранить, а их может быть дохренилион. Проще всего наверное в натуре проверить, если есть возможность. А так просто гадание получается.

no-such-file ★★★★★ ()

Ну то есть не SSD покупать за 100 тыров, а 128 ГБ ОЗУ, если у меня кластер 100ГБ. И все?

Ну, квантовый компьютер купите что-ли …
Не пожалеете.

Пост ироничен от того, что у вас ни какой конкретики в вопросах нет, соответственно и отвечать нечему.

anonymous ()
Ответ на: комментарий от anonymous2

вот что мой коллега говорит:

Я спрашиваю:

как спрогнозировать рост объема временных таблиц у 1с?

Он отвечает:

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

Думаю с таким поворотом событий можно сразу начинать переиндексировать базу

Shulman ()
Ответ на: комментарий от Shulman

да но на постресе соединения не от количества 1С юзеров а от количества баз, я же не писал про уходить на одноядерность в 2020 году это фантастика!

и да самая быстрая конфигурация для 1С это Microsoft SQL + механизм shared memory. Также сильно зависит как быстро клиент ответит, а там webkit.

anonymous2 ★★★★ ()
Последнее исправление: anonymous2 (всего исправлений: 3)
Ответ на: комментарий от anonymous2

у нас 2 года в проде конфигурация с линуксовыми серверами 1с и постгресом. Может оно и стало медленнее на некоторых задачах, но это ощутимо только по гилеву.

Shulman ()
Последнее исправление: Shulman (всего исправлений: 1)
Ответ на: комментарий от anonymous2

Не всегда. Тест Гилёва на одной и той же виртуалке с MSSQL + shared memory под Win2019 у меня выдал на одного попугая меньше, чем в той же виртуалке PostgreSQL подключеный через сокет под CentOS7. Что MSSQL с дефолтной конфой, что Postgres дефолтный, 12 от 1С. Платформа 8.3.18.

mogwai ★★★★ ()
Последнее исправление: mogwai (всего исправлений: 1)