Подскажите. 1С-ка достаточно долго может "висеть" на некоторых операциях. Например, оприходовании товара на 20-30 тыс. позиций; или переоценке (на большой объем данных), или заполнении регистра ТоварыНаККМ по всему справочнику номенклатуры. При этом как на файловой, так и на SQL-версии. Лезу в диспетчер задач - загрузка ЦП 1с-кой 25%, объем потребляемой памяти - не больше 250 Мб....

Хоть и немного смешной вопрос, но спрашиваю: как можно заставить ее работать быстрее? Например, как заставить ее использовать проц. эффективнее - в смысле чтобы она могла использовать 50, 75% ресурсов компа? Или это в принципе невозможно?

Стадо бежит со скоростью самого медленного бизона. Как правило, это операции ввода-вывода.

Проблему как-то можно решить? Объем свободной оперативы в три раза превышает объем базы?

.. в свое время думал - SQL решит эту проблему. Конечно, работает пошустрее, особенно с учетом того, что SQL стоит на профессиональном серваке за 10.000$. Но прироста скорости в разы не заметил. Самое обидное, что когда 1С-ка подвисает, админ не видит никакой особой нагрузки на сам SQL. Получается, тормозит именно 1С-ка... на 2-ядерном ксеоне и 48 гиг оперативы. Смешно и грустно

Объем свободной оперативы в три раза превышает объем базы.. знак вопроса не нужен, говорю про объем на своем домашнем серваке, который тоже не самый дохлый.

самое простое - пройтись замером производительности по операции.

(2) Чукча не читатель. чукча писатель?
Тормозит не 1С, и даже не SQL, тормозит дисковая подсистема.
Ставьте профессиональный внешний рейд, оптимизированный на запись - разница будет. Пойми ты, что от размера оперативки может зависеть скорость чтения, но на скорость записи это почти не влияет.

а еще можно сделать это wiki:RAM_drive

Я слабо себе представляю приходную накладную на 30 тыс. позиций. Или глобальную переоценку всего на складе.

Может что-то в консерватории не то?

(7) может мы просто работаем не в тех конторах и не с теми масштабами?

какой смешной отчет о наблюдениях :)

(8) Пример таких "масштабных" контор в студию!

(9)а что мне это даст? Вот прямо сейчас заполнял регистр "ТоварыНаККМ" (готовлю тестовую базу для демонстрации нашим управленцам). 25 тыс позиций 1С-ка писала почти 5 минут. По моему, много...

(5). Про дисковую подсистему я уже понял..

Нормальное оприходование, чего вы :). УТ 10.3, магазин строительных материалов, торгующей туевой хучей номенклатуры

(10) нука сообразика "ТоварыНаККМ"

нужно понимать, что конструктор никогда не сможет работать лучше специализированного решения

(11) Хоть пристрелите, но не поверю в приходный документ на 30 тыс. позиций. Максимум 1 раз остатки начальные такого размера могут быть.

я про ввод начальных остатков вообще-то и говорю. Да и про ТоварыНаККМ - операторам проще выгрузить весь справочник в кассу целиком, чем выбирать что надо грузить, что нет

2(14) ну а прикинь как их тяжело перепроводить. если вдруг добавил строчку или удалил.. и так триста раз в день

ладно, спасибо всем.. из комментариев понял, что в общем случае можно (нужно) только терпеть и жрать кактус..

(15) Его ввел 1 раз и все. Это не работа в реальном времени.

А с ККМ - грузите то, что есть в остатках. Зачем весь грузить?

(16) На кой ляд каждый день туда добавлять что-то? Выверили остатки и ввели.
Кроме того все нормальные люди по номенклатурным группам бъют документы. Так проще и работать, и инвентаризацию проводить.

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

(19) 1-2 тыс. - это я могу вполне понять еще.

Кстати, Сисой, за наводку в (5) спасибо. По крайней мере, озвучу нашему начальнику АСУ. Пусть думает

2(5) Вообще, если сервер баз данных нормальный, то влияет. Потому что сначала пишется в кэш....  И только по достижении порога грязности этот кэш экстернализаируется на диск.

все-равно я тормоза 1С-ки не до конца понимаю. В смысле, неужели настолько все неоптимизированно? Взять тот-же регистр ТоварыНаККМ. 25000 позиций создавалось около пяти минут; до заполнения регистр был совершенно пустой. Что мешает внутренним механизмам 1С-ки создать записи в оперативке а потом одним чохом записать на диск?

Говорю еще и потому, что паралельно с 1С-кой у нас используется Sмаркет для продуктовой розницы. Так вот, со слов программиста который ее поддерживает, аналогичные 1С-ке операции записи/проведения документов там происходят в разы быстрее.

(23) Вы хотели, чтобы универсальная система-конструктор умела сама оптимизировать запросы с тем же качеством, которое вручную делает программист под конкретную задачу?

Если умеете так писать - предложите свои услуги Нуралиеву.

(22) В случае 1с на диск пишется сразу, кэш только по чтению.

(25) Нет, но я предполагаю, что по крайней мере код в пределах типовой функционала должен быть оптимизирован :).

Вспомнил кстати, по тому-же S-маркету. Пару месяцев назад мне демонстрировался пример, когда обработкой в S-маркете было сгенерировано и записано на диск 99 тыс. записей за 20 секунд. (вообще-то S-маркет неконфигурируемая система, но там есть хранимые процедуры, через которые можно делать и не такое).

Конечно, в 1С-ке вычислений будет побольше, да и таблица в реальной базе создается не в одно поле, но все-равно - разница в скорости очевидна.

Ладно, это уже просто "мысли вслух"

(26) Типовой функционал является надстройкой над платформой. Платформа построена в том числе под задачу универсальности, чтобы код, который наваял любой быдлокодер нормально "переваривался" платформой, под прикладные объекты строились структуры данных, данные обрабатывались и т.п. Вряд ли тут можно самым оптимальным образом обработать все прикладные задачи. Производительность тут обратная сторона медали универсальности.

Хотите оптимальности - берите SAP, стройте структуру данных и индексы по сути вручную и оперируйте ими оптимальным способом. Цену вопроса Вы знаете? Скорость разработки при таких оптимальных структурах знаете?

(26) Да, и еще спросите сколько времени потратится в S-маркете, если наши обкуренные законодатели вдруг на ходу поменяют правила учета и нужно будет менять эти самые "хранимые процедуры".

Управляемые блокировки и оптимизацию запросов покури, поможет наверняка:

http://kb.1c.ru/articleView.jsp?id=44 (Типичные причины неоптимальной работы запросов и методы оптимизации)
http://kb.1c.ru/articleView.jsp?id=45 (Типичные причины избыточных блокировок и методы оптимизации)
http://kb.1c.ru/articleView.jsp?id=46 (Анализ и устранение взаимоблокировок)
http://kb.1c.ru/articleView.jsp?id=47 (Анализ производительности и оптимизация работающей многопользовательской системы)

(29) ты это писателям типовых предложи, автор про типовые документы в типовых конфах говорит

(30) лучше поправить пару документов, чем купить оборудование на ХХХ тыщ для того же увеличения производительности...

(29) Лучше жуй прежде чем говорить.

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

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

(5) И дисковую систему желательно SSD. Прирост значительный.
Думаю можно проверить и сам код. Может убрать какие-то лишние проверки при проведении документов.

1. вообще если есть документы более 1000 строк - что то в кансерватории нужно менять...
2. замер производительности на таком документе и смотреть, может там накой оператор 99% времени занимет
3. смотреть блокировки типа вот этим http://infostart.ru/public/16681/ или аналогичными

Что-то у вас не в 1С дело. Буквально на днях в файловой версии приходовал остатки с переноса. 25 000 позиций в одном приходном документе, заполняется и проводится в течении  где-то минуты, даже меньше.

(24) Мы хотим чтобы 1с работала быстрее, как минимум в типовой конфе. Нам не нужны новейшие рюшечки на неоптимизированной базе. Сам столкнулся с ситуацией, когда програмисты написали отчет по одному бренду, по словам писали на основании конструктора, так вот запрос каждый раз съедал по 3гб оперативки. И все потому, что запрос сначало сожрал всю инфу, а только потом сделал выборку, и все это с позволения программистов 1С. Потом отчет переписали - он стал съедать по 200кб. Сама структура типовой базы 1с говорит о том, что программисты обслуживают в первую очередь мелкие предприятия. Сама схема скажем подбора номенклатуры, когда оператору нужно видеть сразу и товар и цену и количество, явно неполноценна. Выборку приходится получать сразу из трех источников - справочника номенклатуры, регистра остатков и регистра цен. И в этом явные тормоза - это просчет. Подобный запрос такого рода крайне медленный.

(36) 1. совсем не обязательно
2. +100500
3. это потом

(38) про подбор - ну так сделай правильно... просто цены и количество меняются независимо - вот у них и два источника

(0) Ну и что? Если у тебя 4-е проца то загружен на однопоточной задаче будет только один. Соответсвенно вот и получется 25% загрузки.  Хочешь 100% - переписывай код на многопоточность.

(33) Как это не забавно но при сканировании больших таблиц(DB2) в определенном случае чтение может проходить мимо пула, т.е. с диска.(читаем Дэна Тоу)

(40) Проблема не в том, как мне сделать правильно отчет, а в том, чтобы такая возможность должна работать из коробки. Самый оптимальный подбор в свое время был обеспечен на 7.7 с доработками на основе tsql. Там подбор просто летал. Чего хочется от стандартных механизмов 1с.

(43) Твой подбор на 77 был сделан конкретно под твою задачу. Так и тут сделай так же, получишь оптимальное решение.

(5) Не факт,с чего ты взял что в этом случае узким местом является запись? Вставить 40 тысяч записей на MSSQL дело нескольких секунд. Основные затраты(более 90-а процентов) идут на операции чтения.

(43)дело в том, что для большенства операций подбора цена и остаток вообще нафиг не нужны, по этому и идет оптимизация на 1 таблицу. А то что хочешь ты - это скорее частный случай...

расмотрим различные варианты:

1. Все документы по закупкам (заказ, счет, поступление, ордер) - нафиг ни остатки ни цена

2. Розница - тоже не  нужно (для розницы допустимо продавать в минус)

3. Опт - тут может понадобится


имено по этому в типовых реализована отдельная форма "рабочее место менеджера" и не нужно пытатся воткнуть цену и количество в типовые формы подбора

Все не читал.

Автора ткнули в
1) Регламенты SQL
2) Размер tempDB
3) Борьбу осла со слоном (SQL и сервер 1С физически вместе, SQL неограничен в памяти)
4) Кэш на сетевой/файловой/многопользовательской
5) Антивирус
6) Какой-нибудь RAID5 вместо RAID1+0

2(42) возможно. но (5) говорили что в случае 1С ЗАПИСЬ будет идти мимо буферпула, сразу на диск. а это ложь.

(46) Дело в том, что в большинстве организаций с объемом номенклатуры с остатком более чем 5000 наименований нужны и цена и остаток. Так вот именно подбор номенклатуры - одно из самых узких звеньев в любой оптовой торговле. Отчеты - это уже потом. Вот отчеты то легче всего оптимизировать.

(43) у меня подбор летает, ХЗ что там у тебя

(0) >Лезу в диспетчер задач
В замер производительности 1С-ный надо лезть и выяснять на какую строку уходит больше всего времени.

Если это что-то типа
.Записать()
то упирается в дисковую подсистему.

Хотя 25% загрузка проца при 4 ядрах на файловой версии как бэ намекает на то, что какое-то вычисление крутится в цикле и упирается в проц.

В любом случае отправляться надо туда же.

(45) Я знаю, Мастер. Но спонсоры требуют продавать больше дисков :-)
Конечно, проблему в (0) без исследования не решить.
Почему бы не предложить автору топика напрямую услуги софтпойнта?

(51) Обычно - проблема в слишком большом количестве регистров. 1С - это вообще огромный комок регистров, из-за которых работа с документами имеющими очень много строк становится затруднительной. Всегда можно протестировать - создать пустую базу, добавить справочник номенклатуры, создать документ реализации, заполнить гигантским справочником номенклатуры и провести документ на 50000 наименований. И потом сверить скорость проведения со скоростью в реальной базе.

про глюки\ошибки и пр. в типовых конфах обсуждали помню однажды
OFF: Можно ли признать программу некачественным продуктом (изделием) ?

(46) "2. Розница - тоже не  нужно (для розницы допустимо продавать в минус)"

Скажи это нормальным бухгалтерам - пусть посмеются, когда у них пойдут проблемы в бухгалтерии. Или там убьется перепроведение по партиям.

Телепатирую и экстрасенсирую:
А в конечном счете окажется, что у одного регистра есть поле с типом ЛюбаяСсылка и условие ГДЕ НЕ ЛюбаяСсылка.ПометкаУдаления