Слишком долго перепроводятся документы по сравнению с Бух7.7 (более чем в 6 раз!).
Кроме того стандартная обработка перепроведения делает текущий сеанс "неотвечающим".
Пока не замечано что запущенная обработка перепроведения влияет на нормальную работу пользователей.

база файловая?

(1) Как будто на скуле будет быстрее :)

(0) Это 8-ка и УФ, так что да, как минимум в 3 раза мощнее железо нужно

сейчас PostgreSQL,
MsSQL немного быстрее

(0) продолжайте наблюдения

что хотите от мистян то?

идей :)

(6) это к Гилеву :)

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

(7)не заслужил доверия Гилев

(6) Переходите на 7-ку

(7) Как показывает практика, даже он в типовой ничего толком не сделает


(8) А не взлетит в принципи, из-за особенности типовой к универсальности. Это или вообще все нафиг переписать в хлам (тогда зачем вам БП, если вы в итоги свою нетленку родите) или железом догонять

(9) че вдруг то ??
вы его статьи то читали ?

РЛС поди включен ещё?
Всё типовое почти некрасиво работает, написать своё для конкретного случая

(11) читал, попугаи мерял, ничего интересного

(8) напиши... из БСП можно дёрнуть механизмы фоновых, в отчетах используются

(12) РЛС, версионирование, даже последовательности - все выключено

(0) а железо то же?
Такое ощущение, что сервак слабоват.
Там столь большой разницы быть не должно.
Или есть незакрытые регистры НДС.
На хорошем железе и ms sql все летает.

Итоги можно отключить на период перепроведения, проводить пачки доков в транзакции и т.д. и т.п.

(15) работаете в RDP ?

(0) Это абсолютно нормально. Привыкайте.

(17) какие и как

Да постгря у него с дефолтными настройками

(17) а откуда программу будет итоги брать, если они отключены?

(6) требуй повышения ЗП (типа, компенсировать расходы на такси)

Максимум что можно сделать, это написать свой алгоритм расчета без итогов (т.е. хранить итоги в ТЗ) и заполнять из обработки движения по рассчитанному алгоритму

Но как бы ты ни изгалялся, проблема в том что основное время - это не расчет итогов - а запись, а тут уже ускорить нереально

(20) ну какие движения делают документы - по тем регистрам и отключать временно.
(22) на время массового перепроведения отключать, потом включать.
При включении обратно итоги будут пересчитаны, что тоже потребует времени.
Для начала перепроведение документов в транзакции попробуй, в пачке штук по 500 доков. Разницу можно почуствовать уже будет, без плясок с итогами

(21) админ рулил настройки, я могу посмотреть что он накрутил можешь посоветовать на что обратить внимание

(25) 77 например вообще не дает проводить параллельно документы, 8,2 это работает и такое ощущение что блокировок вообще нет

весь бред не читал и читать без ТТХ серверов и сетки не буду

(0) Смотри счетчики производительности.

Постгри - это смешно. А еще печальнее - 8.

Сервак нормальный купите с Рэйд 10 и процом приемлимым.

Сервер приложений 1С он же сервер СУБД HP Proliant DL 380 P 8 поколения, проц 2*6ядер E5 2620 HT-off, ОЗУ 48 ГБ (28)

(31) С дисками что?

(31) (32) Хранилище фибер HP P2000 G3 RAID 10

Ну бестолку обсуждать железо, бестолку! Время проведения документов в Бух 7.7 и БП 8 отличается практически на порядок - это данность, ничего вы с этим не сделаете.
Работайте так, чтобы свести перепроведения к минимуму.

(34) ню ню

(33) Настораживает то, что это хранилище.
Как там с быстродействием ? каким каналом к сервакам подключены?
Кто еще туда пишет?

(29) По факту бесполезно потому что что делает 1С понять не возможно. При этом по счетчикам будет все по нулям

(35) Речь не о нетленки с двумя документами и тремя регистрами

(37) +

На ССД и локальном компике протестируй для начала - потом сможешь о производительности думать.

(34) на файловой!
Если брать ms sql,  то 8- ка даже быстрее иногда. И уж если медленнее, то уж точно не в 6 раз.

(36) ошибок хранилище не показывает

Если локально все тип-топ, то потом уже вариант вы бухами друг другу мешаетесь и на блокировках висите.

К восьмерке все уже так привыкли, что забыли, как в 7.7 документы проводились за доли секунды, а не по нескольку секунд.

ставь ссд лучше рейдом и обязательно архивацию системы

и да, постгри в _опку

(46) да чего это с посгре не так, вон всеми любимый Гилев хвалит посгре

у него она показывает чудеса производительности

(0) тебе в (18) вопрос задали - работаешь через терминал, или напрямую тонким клиентом подключаешься

(42) А должно? Может у тебя канал узкий до хранилища. Т.е. ошибок как таковых нет, просто скорость обмена небольшая.

(37) потому что у тебя формы в терминале тормозят, в то время как код уже давно выполнился

+(51) нормально всё счетчики показывают

(49) а че будет большая разница.... через терминал

(47) Prosgrasql хорошая база данных, а как он прикручен в 1С отдельный вопрос...

(50) оптика если что.

(52) подскажи какие счетчики критичны могут быть в моем случае, все посмотрю

(54) перешли на скуль, все стало в разы быстрее, у нас бгу 104 учреждения в одной базе.

(47) Потому что оптимизация типовых при написании и отладке выполняется на ms sql. Для 1С это СУБД № 1.

> сейчас PostgreSQL
Выкинь бяку, поставь на пробу MS SQL Express

>сейчас PostgreSQL

чего ж вы хотите :)

(51) а если перепроведение запускать через COM - намного быстрее будет ?

(60) >чего ж вы хотите
не платить за MS SQL - это политика руководства - экономить на софте где можно и сэкономленные деньги пускать на железо

(53) а чё поиск уже отменили? искать не пробовал - в каждой первой такой теме на мисте написано не используйте УФ через терминал

(56) и счетчики тебе не помогут (верее мало помогут) - если по ним будет показываться "по счетчикам будет все по нулям" как у Алексея в (37) а тормоза при этом будут

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