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

Хоть и немного смешной вопрос, но спрашиваю: как можно заставить ее работать быстрее? Например, как заставить ее использовать проц. эффективнее - в смысле чтобы она могла использовать 50, 75% ресурсов компа? Или это в принципе невозможно?
1 1C-band
 
06.08.12
18:31
Стадо бежит со скоростью самого медленного бизона. Как правило, это операции ввода-вывода.
2 suvolod
 
06.08.12
18:35
Проблему как-то можно решить? Объем свободной оперативы в три раза превышает объем базы?

.. в свое время думал - SQL решит эту проблему. Конечно, работает пошустрее, особенно с учетом того, что SQL стоит на профессиональном серваке за 10.000$. Но прироста скорости в разы не заметил. Самое обидное, что когда 1С-ка подвисает, админ не видит никакой особой нагрузки на сам SQL. Получается, тормозит именно 1С-ка... на 2-ядерном ксеоне и 48 гиг оперативы. Смешно и грустно
3 suvolod
 
06.08.12
18:36
Объем свободной оперативы в три раза превышает объем базы.. знак вопроса не нужен, говорю про объем на своем домашнем серваке, который тоже не самый дохлый.
4 Нуф-Нуф
 
06.08.12
18:38
самое простое - пройтись замером производительности по операции.
5 Сисой
 
06.08.12
18:39
(2) Чукча не читатель. чукча писатель?
Тормозит не 1С, и даже не SQL, тормозит дисковая подсистема.
Ставьте профессиональный внешний рейд, оптимизированный на запись - разница будет. Пойми ты, что от размера оперативки может зависеть скорость чтения, но на скорость записи это почти не влияет.
6 Нуф-Нуф
 
06.08.12
18:40
а еще можно сделать это wiki:RAM_drive
7 Джинн
 
06.08.12
18:42
Я слабо себе представляю приходную накладную на 30 тыс. позиций. Или глобальную переоценку всего на складе.

Может что-то в консерватории не то?
8 Нуф-Нуф
 
06.08.12
18:43
(7) может мы просто работаем не в тех конторах и не с теми масштабами?
9 Agent ООЗ
 
06.08.12
18:43
какой смешной отчет о наблюдениях :)
10 Джинн
 
06.08.12
18:44
(8) Пример таких "масштабных" контор в студию!
11 suvolod
 
06.08.12
18:45
(9)а что мне это даст? Вот прямо сейчас заполнял регистр "ТоварыНаККМ" (готовлю тестовую базу для демонстрации нашим управленцам). 25 тыс позиций 1С-ка писала почти 5 минут. По моему, много...

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

Нормальное оприходование, чего вы :). УТ 10.3, магазин строительных материалов, торгующей туевой хучей номенклатуры
12 Agent ООЗ
 
06.08.12
18:45
(10) нука сообразика "ТоварыНаККМ"
13 Agent ООЗ
 
06.08.12
18:47
нужно понимать, что конструктор никогда не сможет работать лучше специализированного решения
14 Джинн
 
06.08.12
18:47
(11) Хоть пристрелите, но не поверю в приходный документ на 30 тыс. позиций. Максимум 1 раз остатки начальные такого размера могут быть.
15 suvolod
 
06.08.12
18:49
я про ввод начальных остатков вообще-то и говорю. Да и про ТоварыНаККМ - операторам проще выгрузить весь справочник в кассу целиком, чем выбирать что надо грузить, что нет
16 Живой Ископаемый
 
06.08.12
18:49
2(14) ну а прикинь как их тяжело перепроводить. если вдруг добавил строчку или удалил.. и так триста раз в день
17 suvolod
 
06.08.12
18:51
ладно, спасибо всем.. из комментариев понял, что в общем случае можно (нужно) только терпеть и жрать кактус..
18 Джинн
 
06.08.12
18:52
(15) Его ввел 1 раз и все. Это не работа в реальном времени.

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

(16) На кой ляд каждый день туда добавлять что-то? Выверили остатки и ввели.
Кроме того все нормальные люди по номенклатурным группам бъют документы. Так проще и работать, и инвентаризацию проводить.
19 suvolod
 
06.08.12
18:57
на самом деле ситуации проведения/перепроведения большого объема данных встречаются очень часто. Пусть не на 30000 позиций, но на 1-2 тыс - чуть ли не каждый день. Речь идет о закрытии кассовой смены по большому магазину, плюс хитрой схемы, когда чеки отбиваются от одной фирмы, а товар числиться на другой. В конце дня, кроме отчета на эту тысячу позиций, приходиться делать документы продажи/поступления (по собственным фирмам).
20 Джинн
 
06.08.12
18:58
(19) 1-2 тыс. - это я могу вполне понять еще.
21 suvolod
 
06.08.12
18:59
Кстати, Сисой, за наводку в (5) спасибо. По крайней мере, озвучу нашему начальнику АСУ. Пусть думает
22 Живой Ископаемый
 
06.08.12
19:02
2(5) Вообще, если сервер баз данных нормальный, то влияет. Потому что сначала пишется в кэш....  И только по достижении порога грязности этот кэш экстернализаируется на диск.
23 suvolod
 
06.08.12
19:07
все-равно я тормоза 1С-ки не до конца понимаю. В смысле, неужели настолько все неоптимизированно? Взять тот-же регистр ТоварыНаККМ. 25000 позиций создавалось около пяти минут; до заполнения регистр был совершенно пустой. Что мешает внутренним механизмам 1С-ки создать записи в оперативке а потом одним чохом записать на диск?

Говорю еще и потому, что паралельно с 1С-кой у нас используется Sмаркет для продуктовой розницы. Так вот, со слов программиста который ее поддерживает, аналогичные 1С-ке операции записи/проведения документов там происходят в разы быстрее.
24 Джинн
 
06.08.12
19:11
(23) Вы хотели, чтобы универсальная система-конструктор умела сама оптимизировать запросы с тем же качеством, которое вручную делает программист под конкретную задачу?

Если умеете так писать - предложите свои услуги Нуралиеву.
25 lepesha
 
06.08.12
19:17
(22) В случае 1с на диск пишется сразу, кэш только по чтению.
26 suvolod
 
06.08.12
19:31
(25) Нет, но я предполагаю, что по крайней мере код в пределах типовой функционала должен быть оптимизирован :).

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

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

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

Хотите оптимальности - берите SAP, стройте структуру данных и индексы по сути вручную и оперируйте ими оптимальным способом. Цену вопроса Вы знаете? Скорость разработки при таких оптимальных структурах знаете?
28 Джинн
 
06.08.12
19:49
(26) Да, и еще спросите сколько времени потратится в S-маркете, если наши обкуренные законодатели вдруг на ходу поменяют правила учета и нужно будет менять эти самые "хранимые процедуры".
29 Inform
 
06.08.12
19:53
Управляемые блокировки и оптимизацию запросов покури, поможет наверняка:

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 (Анализ производительности и оптимизация работающей многопользовательской системы)
30 milan
 
06.08.12
19:55
(29) ты это писателям типовых предложи, автор про типовые документы в типовых конфах говорит
31 Inform
 
06.08.12
19:58
(30) лучше поправить пару документов, чем купить оборудование на ХХХ тыщ для того же увеличения производительности...
32 NcSteel
 
06.08.12
20:02
(29) Лучше жуй прежде чем говорить.
33 Живой Ископаемый
 
06.08.12
20:35
2(25) наглая, не прикрытая ложь. в случае ДБ2 ничто мимо буфер пула не пройдет.
34 Fragster
 
гуру
06.08.12
20:37
что, замер производительности уже был?
35 spleen
 
07.08.12
09:05
(5) И дисковую систему желательно SSD. Прирост значительный.
Думаю можно проверить и сам код. Может убрать какие-то лишние проверки при проведении документов.
36 vde69
 
07.08.12
09:14
1. вообще если есть документы более 1000 строк - что то в кансерватории нужно менять...
2. замер производительности на таком документе и смотреть, может там накой оператор 99% времени занимет
3. смотреть блокировки типа вот этим http://infostart.ru/public/16681/ или аналогичными
37 DEVIce
 
07.08.12
09:21
Что-то у вас не в 1С дело. Буквально на днях в файловой версии приходовал остатки с переноса. 25 000 позиций в одном приходном документе, заполняется и проводится в течении  где-то минуты, даже меньше.
38 dmrjan
 
07.08.12
09:51
(24) Мы хотим чтобы 1с работала быстрее, как минимум в типовой конфе. Нам не нужны новейшие рюшечки на неоптимизированной базе. Сам столкнулся с ситуацией, когда програмисты написали отчет по одному бренду, по словам писали на основании конструктора, так вот запрос каждый раз съедал по 3гб оперативки. И все потому, что запрос сначало сожрал всю инфу, а только потом сделал выборку, и все это с позволения программистов 1С. Потом отчет переписали - он стал съедать по 200кб. Сама структура типовой базы 1с говорит о том, что программисты обслуживают в первую очередь мелкие предприятия. Сама схема скажем подбора номенклатуры, когда оператору нужно видеть сразу и товар и цену и количество, явно неполноценна. Выборку приходится получать сразу из трех источников - справочника номенклатуры, регистра остатков и регистра цен. И в этом явные тормоза - это просчет. Подобный запрос такого рода крайне медленный.
39 Fragster
 
гуру
07.08.12
10:09
(36) 1. совсем не обязательно
2. +100500
3. это потом
40 Fragster
 
гуру
07.08.12
10:10
(38) про подбор - ну так сделай правильно... просто цены и количество меняются независимо - вот у них и два источника
41 МуМу
 
07.08.12
10:11
(0) Ну и что? Если у тебя 4-е проца то загружен на однопоточной задаче будет только один. Соответсвенно вот и получется 25% загрузки.  Хочешь 100% - переписывай код на многопоточность.
42 МуМу
 
07.08.12
10:14
(33) Как это не забавно но при сканировании больших таблиц(DB2) в определенном случае чтение может проходить мимо пула, т.е. с диска.(читаем Дэна Тоу)
43 dmrjan
 
07.08.12
10:21
(40) Проблема не в том, как мне сделать правильно отчет, а в том, чтобы такая возможность должна работать из коробки. Самый оптимальный подбор в свое время был обеспечен на 7.7 с доработками на основе tsql. Там подбор просто летал. Чего хочется от стандартных механизмов 1с.
44 ДенисЧ
 
07.08.12
10:23
(43) Твой подбор на 77 был сделан конкретно под твою задачу. Так и тут сделай так же, получишь оптимальное решение.
45 МуМу
 
07.08.12
10:26
(5) Не факт,с чего ты взял что в этом случае узким местом является запись? Вставить 40 тысяч записей на MSSQL дело нескольких секунд. Основные затраты(более 90-а процентов) идут на операции чтения.
46 vde69
 
07.08.12
10:27
(43)дело в том, что для большенства операций подбора цена и остаток вообще нафиг не нужны, по этому и идет оптимизация на 1 таблицу. А то что хочешь ты - это скорее частный случай...

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

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

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

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


имено по этому в типовых реализована отдельная форма "рабочее место менеджера" и не нужно пытатся воткнуть цену и количество в типовые формы подбора
47 H A D G E H O G s
 
07.08.12
10:30
Все не читал.

Автора ткнули в
1) Регламенты SQL
2) Размер tempDB
3) Борьбу осла со слоном (SQL и сервер 1С физически вместе, SQL неограничен в памяти)
4) Кэш на сетевой/файловой/многопользовательской
5) Антивирус
6) Какой-нибудь RAID5 вместо RAID1+0
48 Живой Ископаемый
 
07.08.12
10:31
2(42) возможно. но (5) говорили что в случае 1С ЗАПИСЬ будет идти мимо буферпула, сразу на диск. а это ложь.
49 dmrjan
 
07.08.12
10:43
(46) Дело в том, что в большинстве организаций с объемом номенклатуры с остатком более чем 5000 наименований нужны и цена и остаток. Так вот именно подбор номенклатуры - одно из самых узких звеньев в любой оптовой торговле. Отчеты - это уже потом. Вот отчеты то легче всего оптимизировать.
50 Fragster
 
гуру
07.08.12
10:48
(43) у меня подбор летает, ХЗ что там у тебя
51 jk3
 
07.08.12
10:51
(0) >Лезу в диспетчер задач
В замер производительности 1С-ный надо лезть и выяснять на какую строку уходит больше всего времени.

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

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

В любом случае отправляться надо туда же.
52 Сисой
 
07.08.12
11:33
(45) Я знаю, Мастер. Но спонсоры требуют продавать больше дисков :-)
Конечно, проблему в (0) без исследования не решить.
Почему бы не предложить автору топика напрямую услуги софтпойнта?
53 dmrjan
 
07.08.12
11:36
(51) Обычно - проблема в слишком большом количестве регистров. 1С - это вообще огромный комок регистров, из-за которых работа с документами имеющими очень много строк становится затруднительной. Всегда можно протестировать - создать пустую базу, добавить справочник номенклатуры, создать документ реализации, заполнить гигантским справочником номенклатуры и провести документ на 50000 наименований. И потом сверить скорость проведения со скоростью в реальной базе.
54 Rovan
 
гуру
07.08.12
11:39
про глюки\ошибки и пр. в типовых конфах обсуждали помню однажды
OFF: Можно ли признать программу некачественным продуктом (изделием) ?
55 dmrjan
 
07.08.12
11:40
(46) "2. Розница - тоже не  нужно (для розницы допустимо продавать в минус)"

Скажи это нормальным бухгалтерам - пусть посмеются, когда у них пойдут проблемы в бухгалтерии. Или там убьется перепроведение по партиям.
56 Ksandr
 
07.08.12
11:49
Телепатирую и экстрасенсирую:
А в конечном счете окажется, что у одного регистра есть поле с типом ЛюбаяСсылка и условие ГДЕ НЕ ЛюбаяСсылка.ПометкаУдаления
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа. Фредерик Брукс-младший