Есть:
1. ms sql 2016.
2. сервер 1С x64.
3. Бухгалтерия 1С КОРП, ред.2
Железо было топ год назад (i9-12900), винт под базу samsung 990 pro.
Размер базы 600 гигов.
Обрезать базу - не вариант. Причин - целая куча.

Есть мысли апгрейдить железо до i9-14900 и винт под базу на pci-e 5.

Что может нас остановить?
Есть ли у кого примеры еще бОльших баз? Просто хочу узнать, можно ли жить дальше или начинать готовиться к эвакуации?

Да, все честно купленное, даже ms sql 2016 standard.
И производительность работы 1С крайне важна.

(0)>3. Бухгалтерия 1С КОРП, ред.2

в курсе, что поддержка БП КОРП ред.2.0 прекращена с 01.04.2024?

(2) В этом, по ряду причин, нет проблемы.

600 Гб много, но не ужас-ужас,
у нас есть клиенты с базами в ТБ, но там правда не один сервер и не на дескотопе

(0)[Есть ли у кого примеры еще бОльших баз? ]
ERP > 900 Гбайт

(0) Картинко отдельно хрони.

(6) даже в мыслях не было картинко хранить в базе.

Самая крупная БД сейчас (КА 1.1) 1,3 Тб

(5) 2 терабайта центральная база, это только данные и 80 распределенных, где каждая распределенная 20-200 Гб
Полет нормальный
Железо стоит профессиональное, любительский i9 не используется

У нас 4тб. Из них 40% - данные маркировки лекарств, никуда от них не избавиться, и дальше будет только больше :(

(7) Ну тогда я не представляю, что в бухгалтерии может занимать 600Гб, разве что незакрытые кривые итоги.
Судя по железу это "динамично и успешно развивающаяся компания" и там не может быть миллион пользователей и миллиард документов.

(0) Не верю в подобный размер базы.
Точно она так разбухла не от прикрепленных файлов?
Даже при 50к документов в месяц на БП3 размер базы за 5 лет был только 2-3 гб dt и примерно 20 гб sql

Откуда у вас 600 гб sql ?
При выгрузке в dt какой размер?

Так-то хоть 20Тб - лишь бы дисков SSD хватало.

(0) Вообще, есть решение - сжатие таблиц в SQL. В 4 раза меньше станет.

(12)Поддерживаю. УТ или там УПП еще можно поверить. Но БП таких больших не бывает.
Что вы там напихали-то?

(10) Вот да, у нас так же чуть меньше половины занимает маркировка, меркурий и прочие EDI - все от Контура.
(12) dt 37 Гб.
(13) Спасибо за то что обнадежили :)
(11) молочка, доки с 2015 года. Около 2 тыс. доков в день по 3-10 строк.

(16) Выносите маркировку наружу из типовой - в итоге все к этому приходят

(17)+ Причем в самой типовой даже ссылки на внешнюю базу хранить не надо.
Наоборот во внешней базе хранить ссылки-уиды (или навигационные ссылки которые из уидов ссылок можно получить и обратно) на объекты типовой базы 1С

(17) каким образом? Мы повязаны с Контуром. И так маркировка сама по себе подтормаживает.

(17) У нас вот своё решение по маркировке: только справочник упаковок на 700млн записей. По нему (и мдлп-шным документам) запросы строятся при прокурорских проверках в стыковке с реализациями. Плюс внешняя база-прослойка для обменов.
upd. ой, не заметил, что это не нам было

(0) лучше построить рейтинг таблиц с сортировкой по размеру. В итоге, может оказаться, что 1) это итоги. Передвинуть дату на границу 01.01.2023 или 01.01.2024 и пересчитать их. Размер может уменьшится на много-много гигабайт. 2) вложенные файлы или письма, тут думать над необходимостью истории или перенести из хранения в базе во внешнее хранение.

(20) Да, когда свое, то очень хорошо. У нас справочник с маркировками 60 млн., я думал что это много и надо бы порезать :)
(21) да, бух.итоги самые большие, за ними очень близко Контуровские таблицы. Но все это важно и нужно. Тут некуда деваться.

(21) +

(22) итоги на старые даты нужны если стоите отчеты по границам итогов (по-недельно, декадно, месяц и т.д.) в старых датах. Делаете это - нужны. Но все равно почитать статьи про итоги которые свернулись в 0, а в базе места занимают много, и пересчитать их в 1С.

Сразу сказу - я не в теме с маркировками, контурскими таблицами и прочая... и я не фанат РИБ, но:
используя механизм обмена между главным и подчинённым узлами, легко реализовать функционал, когда некоторые "важные и нужные"(с) данные могут мигрировать в подчиненный узел и оставаться там, исчезая из главного узла. Так, как в подчиненном узле - полный набор данных, то там и происходит работа с ними. Например, - пометка и удаление данных. А в главном узле - остальная работа, не требующая наличия этих данных. Излишне, имхо, напоминать, что узлы могут находиться в пределах одной сети, а пользователям желательно иметь доступ к базам обеих узлов.

Имхо, используя вышеозвученную схему легко реализовать то, что кажется неразрешимой проблемой. Например: "Обрезать базу - не вариант. Причин - целая куча."(0) А если у Вас будет доступ к двум базам сразу - "обрезанной" и "полной"? В главной - "сокращенный вариант" для текущей работы пользователей, а в подчиненной - всё тоже-самое, но с историей прошлых лет.

(26) Суть у тебя та же что и у меня в (17) - вынос-разделение одной огромной базы на несколько баз поменьше
Как и что выносить отдельный вопрос

Обычно старые данные (дальше пары лет) уже не нужны в актуальной базе совершенно

(25) чисто технически, в терминах РИБ, получается ровно наоборот. главная база - архив, а то место где живут реальные юзвери - узел РИБ с лимитером по дате, который в правилах обмена указывается вручную на 2-3 года вглубь.
но у этого решения есть и побочный эффект - главная база вырастет ещё на 10-20% за счёт таблиц Изменения.
(0) судя по обсуждению 600гб для вашего учёта многовато, и кажется что 1-2 сотни гиг можно скинуть просто на реорганизации внутренних данных, срезов, итогов и прочей платформенной требухи, которую обычные люди в работе не замечают.
потом, лицензию КОРП на сервер и клиентов покупать не хотите? а то можно было бы сегментировать базу и разложить по разным ССД.

(22) Проверьте минимальные и масксимальные границы бух.итогов. Наверняка можно сократить.

(12) 50К документов в месяц - это немного.

(0) У меня база БП2 каз размер 1 Т 118 ГБ
Пользователей от 150 до 250 .
Полет нормальный. Пол года назад переезжали на новый сервак.Intel(R) Xeon(R) Gold 6346 CPU @ 3.10GHz   3.09 GHz (процессоров: 2) ОЗУ = 1,00 ТБ.
64-разрядная операционная система, процессор x64

Прежде всего, коллеги, огромное спасибо за обсуждение!
Очень интересными мне показались идеи по поводу РИБ и версии КОРП платформы.
Но посовещавшись с клиентом, решили все же вот так:
1. Обновляем железо и доживаем с этой базой до 01.01.2025.
2. Переносим все доработки (а их очень много) в БП 3.0, тестим их в тестовой базе.
3. 01.01.2025 заходим остатками и начинаем новую жизнь в пустой новой базе.

А, и 50к доков - это только надводная часть айсберга, это только реализации. Там еще и производство. Молочное. И все это крутится в режиме 24x7. Мне иной раз не дают даже ТиИБ сделать.

(31) а сколько в "гилевских попугаях"?
(32) теоретически, общий объем базы не должен сильно влиять на быстродействие - все равно сервер БД работает только с теми страницами, данные из которых использует. посмотреть, насколько часто он подкачивает актуальные данные из БД - можно по счетчикам производительности (не помню точное название события, но что-то типа "отсутствие требуемой страницы в кэше", и подобным).
Да, кстати, памяти-то на сервере сколько?
Ну и, пардон за мой скептицизм, оперучет 24/7 нужно держать на чем-то более другом. Например, на позапрошлой работе клюшки вполне обеспечивали даунтайм не более часа в месяц (миниимум - достигнутый минимум 15 минут в месяц), при 5000-8000 всех видов доков в сутки.
И да, РИБ для архивной базы - годное решение.

(33) Гилев стоит на сервере. Но при мне не запускали.
надо спросить или запустить. Позже дам ответ.

+ (34)Запустил.
текущий тест 42.74
Резмер строки 512
Макс скорость 1 птоток 134120
Рекомендуемое кол-во пользователей 126
Макс скорость 652 117

(33) памяти 128, на новом сервере будет 192.
Использовать ксеоны не вариант точно. Ибо будет медленно. У другого моего клиента ксеон голд 6244 уже года 2 как стоит с дорогущим серверным рейдом на ссд. Работает медленнее. Значительно медленнее при прочих равных условиях. Если в попугаях Гилева, то примерно раза так в 2.

>>>dt 37 Гб.

от куда там 600 гиг???

DT к базе имеет примерно от 1:5 до 1:10 к SQL базе.

у меня база 200 гиг имет DT в 35 гиг....

(36) >>>Использовать ксеоны не вариант точно.

не говорите глупости...

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

> от куда там 600 гиг???
От сильно разреженных таблиц имени Контура, когда в таблице 100500 безразмерных полей, из которых используется лишь парочка. Ок?

> не говорите глупости...
Всякий инструмент хорош для своих целей. Для целей работы юзеров количеством от 50 однозначно серверная платформа на ксеонах. Тут даже спорить бессмысленно. А для количества пользователей +-20 и необходимости работать не на уровне механического оператора, таки лучше крайний i9. Но мнение лично мое, никому не навязываю.

+(39) в подтверждение моих слов про таблицы Контура - 1 месяц работы в Контур EDI у нас увеличивает размер базы на 10 гигов. Вычислил по соответствующему уменьшению базы при архивации 1 месяца штатными средствами Контура. Чем можно так раздуть базу? Одному Контуру известно ...

(35) ну я почему-то ожидал большего. у нас тестовый на двух старых ксеонах 3.07ГГц на супермикре, без рейда на данных (и почему-то гилевский тест показывает частоту памяти "33") дает 31-33 гилевских попугая.
(36) памяти для 20-30 юзверей вроде более чем достаточно. т.е. тормозов при работе (при регулярном регламенте БД) быть не должно.
А то, что "дорогущий работает медленнее" - так от настроек зависит. Новый сервер (купили б/у для внутренних целей) после сборки вообще дал 0.68. после настройки (тайминги памяти, питание, еще там что-то, в основном по мануалу на ИТС, и на сайте Гилева) - 29.7. Или вот неделю назад коллега из другого города: 28.03.24:"б***ь мне 8 показал", 29.03.24 "поднял производительность до 42 очков... ковырянием биоса, настройками QPI и прочими приблудами....благо сервер повзоляет настройки биоса прям под виндой менять"

(40) ну так возьми базу месячной давности, возьми новую, сравни размер таблиц... Но вообще, контур, конечно, в своей упоротости значительно превзошёл пейсателей типовых...

(41)
> А то, что "дорогущий работает медленнее" - так от настроек зависит.

Нет, с ним все в порядке, админы там грамотные. Работает условно медленно, но медленно почти вне зависимости от нагрузки. На нем одновременно работают 250-300 пользователей 1С. Так что, да, на определенные условия определенное железо. Но у молочников совсем иные запросы - мало юзеров, большая скорость работы.

(43) Всё-таки, что насчет идеи сжатия таблиц в SQL?
Знаю организацию с базой в террабайты, где такое сжатие используют (поэтому база в итоге меньше 1тб)

(44) с размером базы никаких проблем (лежит на 990pro 2Тб), лишь бы не тормозило из-за размера.

>>памяти 128, на новом сервере будет 192
Пока огромные таблицы(с индексами), с которыми ведется наиболее интенсивная работа не будут лежать в памяти СУБД(хоть МSSQL, хоть Postgres, хоть что) никакая работа "веселым галопом не понесется" и сверхSSD с наклейкой Pro особо не помогут. Ориентир - в (31), 1ТБ ОЗУ или около того.
Может, когда-нибудь, Core 18-20го поколений и доведут до этого значения, но база размером около терабайта будет считаться малюсенькой :)

Отдельные большие таблицы можно хранить (MS SQL позволяет) на отдельных дисках

В тесте накатил (путем загрузки, а не сравнения, cf) последний релиз БП 2.0 КОРП. Таким образом, отрезались все Контуровские штучки. База похудела до 200 гигов. Эх, Контур, что же ты творишь ...

(48) они всеми силами заставляют слазить с их интеграционных решений.

Смотря что там в базе? У меня была база под терабайт, в основном место занимали всякие прикрепленные файлы. На производительность это практически не влияло.

(38)На Core-I5 с SSDшкой ещё на PCI-e 3 версии, тест Гилёва выдаёт 102 пункта, это норм или плохо?

Вроде как частота решает, а Ксеоны её не выдают чёт.. Рили медленнее получается же.. Или нет?

(51) медленнее. Но всему свое место. Серверное- это вопрос масштаба (2 процессора, куча мест по ОЗУ, например 24 планки), удаленного управления IPMI (важный фактор), форм-фактора (в стойку 1-2 unit), память с ECC, количество мест под накопители

(52)Пнятна

(51)у тебя файловый тест, а речь идет про скулевый вариант.
ЛУчшие Xeonы в нем судя по статистике дают 60, лучшие десктопные процы 125

(54) 125 на sql это фантастика
Обычно около 80

(55)+ Файловая до 160 попугаев на лучших десктопных процах

(55)+ Причем показатели сильно зависят от сторонней нагрузки и положения ретроградного Меркурия - в смысле антивирус отключать надо!
Вот пример три теста подряд

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