Добрый день. Подскажите, у нас на магазине файловая база данных, после обновления на новый релиз стала жутко медленно работать. Тестирование и исправление прироста производительности не дает. Появились 3 варианта: 1. Установить ССД в текущий компьютер, перенести на него базу.
2. Купить 1С мини сервер на 5 компов, сделать СКЛ базу данных и оставить ее на текущем компе.
3. Купить сервер и 1с мини сервер, сделать и перенести СКЛ базу данных на него.
Подскажите, какой из этих вариантов наиболее оптимальный?
Может лучше будет купить ССД и 1С мини сервер и создать и перенести СКЛ базу на ССД? У кого какие практические данные по переходу на ССД и по переходу на клиент-серверный вариант. Что будет работать быстрее?

(0) 1. Конфигурация?
2. Сколько пользователей?
3. С какой на какую обновили?
4. Работает в терминале/по сети?

(1) 1. АСТОР торговый дом
2. 2
3. С 8.2 на 8.3
4. Один напрямую работает, один по терминалу.

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

дык посмотри загрузку диска для начала

(4) посмотрел, в момент вывода на экран печатной формы, например, которая долго считается, идет нагрузка исключительно на жесткий диск. На процессор и ОЗУ никак не отражается. Проблема в том, что база около 9 гб весит и в файловом режиме скоро откажется я так понимаю работать. А переводить на бесплатный СКЛ, мне подсказали, нет смысла, потому что он после того как база вырастает до 10 гб и более становится платным и стоит порядка 100 т.р. Да и не особо он поможет, т.к. пользователей мало, от многопоточности выигрыша соответственно тоже будет мало. По хорошему нужна сверка базы, но это не вариант в нашем случае. Вопрос немного меняется: есть ли необходимость и даст ли это какой-то ощутимый прирост производительности в перемещении базы на компьютер-сервер или же можно ограничиться тем же компьютером, с которого и работают в базе?

(5) А может для начала глянуть что занимает столько места в базе?
Если 8.3 то есть бесплатный postgre

2(5) Ну так переводи на бесплатный ДБ2, там нет ограничения на размер базы.

Раз жесткий диск загружен, то поставьте SSD. Ну и свертку обдумайте.

+(8) и можно еще отчет переписать, который что? в запросе использует большое количество временных таблиц?

(0)Для начала надо бы разобраться почему стало тормозить.
клиент-серверный вариант вряд ли поможет, если тормозит файловый при двух пользователях.

SSD это очень неплохо, и в принципе удивительно, что кто-то еще работает с HDD, но тем не менее тоже не панацея.

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

(3) Очередь диска глянь при тормозах и станет ясно.

(9) Вряд ли запрос сильно поменялся.

(0) Дефрагментировать базу еще попробуйте.

2(12) Ну а почему может бить по диску отчет? Может итоги слетели и они рассчитываются про формировании, вместо того чтобы браться на конец предыдущего месяца?

вообще после смены платформы с изменением третьей цифры версии рекомендуется сделать реструктуризацию (равно как и при изменении режима совместимости)

(14) Третьей или второй?

(15) иногда даже третьей

читайте примечания к релизу

imho - у 1с ограничение одна таблица в файле не более 4ГБ -  таблиц не более 4 - итого база 16ГБ + куча таблиц поменьше
В файловом варианте базы более 4ГБ на 2(1локальный) пользователя по сети - затык по дисковой будет в прокачке данных базы на клиентскую машину
...Или ускорять дисковую или переходить на терминал (до определенного объёма и нагрузки)
Есть клиент на 11.5ГБ база (10 активных пользователей в терминале) - после перехода на ssd больше года молчат (при переходе база была в 9ГБ)
С Fragster согласен - при обновлении платформы/конфы лучше сделать реструктуризацию

2(18) В любой базе таблиц не более 4?

злые языки говорят что в 8.3.8 увеличили размерность таблиц в файловом режиме что должно благотворно отразиться на производительности ИБ в файловом режиме

(20) э... что означает эта фраза? что такое вообще - размерность

(20) Где она логика?

(22) логика видимо в описании изменений 8.3.8

(21) предельный размер и еще чо то они там переделали..

2(24) а...

(21)Реализована возможность изменять размер страницы файла информационной базы (1Cv8.1CD). Размер страницы может быть 4096, 8192, 16384, 32768 и 65536 байт. Информационная база, созданная в версии 8.3.8 и выше, имеет размер страницы 8192 байта и не может быть открыта младшими версиями. Версия 8.3.8 может работать с информационными базами, созданными в предыдущих версиях без нарушения совместимости с предыдущими версиями.

Что касается файловой базы данных 1С:Предприятия, то в ней все данные, относящиеся к одной таблице, собраны в три внутренних файла:
файл записей, в котором находятся все записи таблицы, за исключением полей неограниченной длины
файл индексов
файл значений неограниченной длины
Размер каждого из этих файлов не может превышать 4 гб.
http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=567351)

(14) (18) у нас РИБ, на них не рекомендуют пользоваться тестированием и исправлением, и я пытался у них его сделать, на компьютере 4 гб ОЗУ, выдает "недостаточно памяти". И по поводу расчета итогов, его надо делать только в центральной базе? Или на всех периферийных тоже? Там дело не в одной печатной форме. Там элементарные типовые запросы по 500 секунд выполняются. В постргри есть возможность сделать реструктуризацию?

(28) Выгрузи образы узлов - это будут узлы с нуля,  не придется запускать ТиИ, разверни из них периферийные базы.
Ну как вариант.

(24) страница данных теперь не 4кб а 8-64кб что в теории должно увеличить внутренний обьем файла до 8-64гб. Но на практике руки не дойдут проверить..

(27) а каждый файл состоит из 1й корневой сир. которая содержит 1018 номеров индексных страниц, каждая из которых содержит 1023 номера стр. данных.. Которые теперь от 8кб и выше. Перемножаем и получаем известное ограничение

(28) в РИБ ТиИ не рекомендуется делать из-за про битых ссылок. реструктуризацию и тем более пересчет итогов вполне можно делать.
"В постгри есть возможность сделать реструктуризацию" - в контексте (14) реструктуризация с изменением структуры полей и индексов внутри БД, так что привязка к СУБД тут побоку.
Итоги в каждой базе РИБ считаются отдельно, так что устанавливать период рассчитанных итогов также надо в каждой базе отдельно.