|
Вопрос производительности 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
|
Телепатирую и экстрасенсирую:
А в конечном счете окажется, что у одного регистра есть поле с типом ЛюбаяСсылка и условие ГДЕ НЕ ЛюбаяСсылка.ПометкаУдаления |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |