УПП 1.3, ms sql 2008. База 100 гигов. РАУЗ. Расчет себестоимости = 3.5 часа.

Производство круглосуточное. Сейчас оперативный учет производства в той же базе, в которой рассчитывается себестоимость. Простой = 3.5 часа = блокировки.

Варианты - 1. узел РИБ(состав обрезанный) 2. Репиликация SQL ( видимо не вариант, но есть непонятно что http://www.softpoint.ru/products_id28.htm)

Вопрос не в этом.

Вот например SAP R/3. Сколько там таблиц ? (в УПП х. туча регистров - где данные дублируются). Если там только одна таблица ... то как быть с доп. аналитикой. Не видел ни разу САП ... но почему представляется упр. план счетов и все. Сколько в САПе рассчитывается себестоимость, есть ли проблемы с блокировками, возможно ли использовать зеркалирование итп.

Вопрос - а как в других системах решаются вопросы производительности, проблемы с блокировками - когда первичку необходимо заносить круглосуточно.

(0) SAP тоже не видел. Поэтому буду говорить про 1с. :)
Восьмерка - это прожорливый кашалот. Для такого объема данных нужно соотвествующее железо. Серваки озвучь...

(1) Вопрос не про 1с. Это просто прелюдия.
сервер 1с: Xeon E5640 2.67GHz 2.66GHz(2 процессора) 16 ядер / 8 ГБ / 64 разрядная ос
sql: Xeon E5640 2.67GHz 2.66GHz(2 процессора) 16 ядер / 24 ГБ / 64 разрядная ос / RAID-10 на 10 SAS дисках по 450 гигов

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

имхо на мисте кроме "сап г.вно"  ничего внятного ты не услышишь :)

Больной вопрос фирмы 1С - тестировщики.
Помнится, было время, когда на каждый выход ЗУПа появлялась отдельная ветка с обсуждение всех косяков. :)

Скорей всего, 1С не тестит конфы на больших объемах данных.

отсюда http://www.erp-online.ru/phparticles/show_news_one.php?n_id=378

Довольно неожиданно прозвучали жалобы специалистов Волжского трубного завода, входящего в ТМК, на низкую производительность бухгалтерского модуля системы SAP R/3: расчет себестоимости продукции выполняется в нем четыре часа, а формирование месячной оборотно-сальдовой ведомости по материалам — двенадцать.

С большим опозданием в этом проекте приступили к разработке отчетных форм, понадеявшись на то, что в системе есть набор стандартных объектов такого рода. Как оказалось, полностью пригодными для целей предприятия были лишь четырнадцать из них, а всего же требуется 181 вид отчетов. В результате система успешно решает задачи учета, но ее потенциал не в полной мере используется для принятия решений.

Посмотри в моих темах - я тоже поднимал вопрос производительности. Сейчас (уже полгода) база конечно не как у тебя, но уже за 20 Гб перевалила. Так вот расчет себестоимости делаем только в периферийной. Геморроя нет никакого. Бухи довольны, операторы с графиками 24х7х365 тоже не замечают даже. У нас расчет себестоимти с макс кол-вом итераций - 150 занимает около 35 минут.

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

(7) за полгода - обмен стабильно работал ?

вообще ни разу никаких технических проблем не возникло - и обновления и вся инфа. Из тупых проблемы были следующие: у нас отраслевое решение УПП мясокомбинат - так разработчики умудрили не ставить галки на отраслевых документах и они соответственно, были только в базе создания. Т.е. не мигрировали в другую. Вот и все.

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

SAP конечно гов.о то еще, но их это несколько не беспокоит продажи лицензий растут !
http://www.finam.ru/international/newsitem694DE/

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

(10) понятно. У нас тут еще есть распределенка КА. Так вот после последнего обновления релиза ошибка при выгрузке Ошибка SDBL: Ожидается выражение (pos=ХХХ).

Неприятная ошибочка ... риск.

1. HyperV (для серверов 1С - разнести на две виртуальные машины)
2. Настроить Риб
3. Настроить SQL, чтобы регламентная база не отжирала у производственной ресурсы в момент расчетов.

Всё работает прекрасно с аналогичными параметрами. Думаю, ещё на пару лет запас по производительности есть. Единственный момент, с которым возникают сложности - обмен при обновлении конфигурации и при выгрузке документов РСВ. Это подстава, я вам скажу :) - в воскресенье, ночью... бррр...

(0) Кстати... РСВ можно делать и без блокировок... При проведении/расчете "вне транзакции"...

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

(13) +1
с УТ по такой же схеме работаем

(17) Видел я те нетленки... Работает так же, если не хуже, чем типовые, но при этом ее сопровождение - это адЪ и израИль.

В нетленках еще на этапе проектирования возникают методологические ошибки. А для их исправления пишутся и пишутся костыли. Пару лет разработки и нетленка со своими костылями по производительности уже как типовая.

(19) Это если "нетленку" написали на заказ франчевые спецы по принципу "чего изволите-с, всё что угодно за ваши деньги".. А если штатный программист с нормальным опытом, который работал и с типовыми, и знает их слабые и сильные стороны, одновременно зная особенности учета конкретного предприятия - то всё будет ОК.

(0)
отключите Hyper-Threading

обратитесь в софт-поинт
они Вам за дорого сделают конфетку.

(0) Есть еще третий вариант - оптимизировать Расчет себестоимости. У нас в одной из баз работают 20 предприятий, 4 крупных. Так вот, до оптимизации расчет с/с выполнялся 12 часов - на ночь ставили, утром приходили, иногда сервак падал, приходилось запускать заново.
Сейчас после оптимизации Расчет себестоимости по самому крупному предприятию выполняется 30 минут!! Запускаем как в (16), блокировок нет, себестоимость считается параллельно с работой остальных пользователей, даже запускали параллельно 3 расчета - сработало, но стараемся избегать такой ситуации - бухи одной организации перед запуском оповещают по почте другую организацию.

(15) регламентные базы на других серверах 1с и sql.

(16) (23) не знал что есть такой режим. Будем пробовать.

(21) Конфу близкую по функционалу к УПП силами одного программиста?....

Вы ёпнулись или всерьез про это рассказываете?

(25) При чем здесь "близкую к УПП"? Я сказал про решение конкретной задачи конкретного предприятия. Производственный учет и расчет себестоимости. Функционал УПП здесь явно избыточен, и требует завышенных людских и материальных ресурсов.

Для того 1с и создало открытую платформу, кстати..

(23) Что вы имеете ввиду под оптимизацией РСВ ? с 12 часов до 30 минут ...

(27) "если штатный программист с нормальным опытом, который работал и с типовыми, и знает их слабые и сильные стороны, одновременно зная особенности учета конкретного предприятия"
1. Либо он плохой кодер
2. Либо он плохо знает методологию формирования себестоимости (учет на конкретном предприятии)
3. Либо он плохо владеет навыками проектирования КИС
4. Либо он гений - хотя вряд-ли

Написать нетленку для торговли хлебом - это один момент. Ровно как и определить для такого предприятия ФР. А вот для производства молока, например, или того же хлеба (начиная от посева заканчивая реализацией) - решение только пол-года проектировать необходимо. Причём архитектору, проектировщику и методологу. Вместе с заказчиками. Так что пишите нетленки :)

(28) Оптимизация кода РСВ

(21) Дада, конечно... Только завод по выращиванию таких программистов все никак не построят.
Будет ваять этот шедевр говнокода тот самый Вася, который до этого работал во франче. Те моменты из типовых, которые он ниасилил, он придумает заново самым убогим и неочевидным способом. То, что он возьмет из типовой, он по пути поломает, то, что придумает сам, напишет левой пяткой с похмелья так, что через 3 дня уже сам не сможет понять, как это, блин работает и как его поправить...
Говорю же, навидался.

(30) Это понятно ... оптимизация кода опасная штука. Где было самое узкое место ?

(26) Только честно признайся: хоть одну такую конфу видел на предприятии размером крупнее цеха по сбору табуреток из двух досок и трёх гвоздей пятью ПэТэУшниками.
Причем написанную одним прогом и за вменяемое время.

(32) Не стоит этого бояться, если опыт кончено есть. Узкие места легко ищутся с помощью отладчика, например, была строка кода, проверяющая, есть ли в учете распределение по выручке - она выполнялась 20 минут, отключил нафиг, нет у нас распределения по выручке. Запросов несколько не оптимальных было, в общем отладчик в помощь.

(31) ну, по себе других не стоит судить

(0) Офигет! У меня себестоимость на 3 минута рассчитывается.
Сколько нименоваий продукции? Сколько переделов? Или по подразделению?

приколькно

я за вариант с РИБом, в одном из узлов которого считается все

(38)
этот приём - изоляция нагрузки.

(0) (38) Тогда уж лучше обмен через XML, во время обмена по РИБу блокировки всех измененных таблиц будут.

(36) сколько у тебя в месяц записей в регистре сведений "1-е приближение решения СЛУ"?

(41) Расчет себестоимости и закрытие производства кустарная, написанная от балды :) Таких наворотов нету :)

(31) Да я просто варюсь в этом постоянно.
У нас на предприятии (800 рабочих) лет 12 назад пригласили франчей, которые на основе типовой семерочной бухии наваяли нам производственный учет. Через пару лет алгоритмы стали дико тормозить. Когда я стал анализировать код, то слегка офигел - это был индусский код в его худшем варианте, сплошные расчеты бухитогов в цикле, многократное обращение к базе без необходимости, кроме того, абсолютно нечитаемый и неподдерживаемый. Как следствие - куча вылезающих то там то здесь ошибок. Для решения которых приходилось ждать поддержки от этих франчей, а у них еще и программисты менялись каждые полгода. Когда себестоимость рассчитывалась - блокировалась работа всей базы на сутки.. бухгалтерии приходилось работать ночью даже, чтобы отгрузкам не мешать.

Наконец нам это надоело. Обсудили с бухгалтерией, с экономистами весь процесс, и за пару месяцев написали почти полностью новое решение, взяв за основу ту конфигурацию, но переделав всё "производственные" документы и обработки. Оптимизировали по максимуму - прямые запросы, индексированные таблицы, вынос расчетов из модулей проведения и т.д. И с тех пор всё стало ок, бухгалтера уходят домой вовремя, и никто на блокировки не жалуется, себестоимость пары сотен изделий с 10 уровнями передела рассчитывается за считанные минуты. Да, по сравнению с УПП процесс упрощен, однако его вполне хватает.

(0) Что касается SAP: все зависит от того, как настроено.
Могу сказать один пример: расчет себестоимости проходит один раз в месяц, довольно быстро(менее часа). Во всяком случае ни о каких блокировках не может быть и речи, какой бы сложный расчет не производился: все остальные пользователи работают без проблем. При запуске сложных обработок там есть т.н. фоновый режим: обычно все отчеты, обработки, время выполнения которых превышает 15-20 минут, желательно запускать в этом режиме.

(43) Красивая история успеха. Спасибо.

Однако речь в ней идет не о написании нетленки, а об оптимизации имеющегося готового решения.

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

(45) Если в процессе оптимизации полностью переписано 95% кода - это уже не оптимизация, а новая "нетленка" )

(0) я тоже сап не видел, но слышал вот какую вещь: с САПе НИКОГДА не бывает блокировок - у них организована очередь проведения документов (типа стэк), поправьте если не так. но управляемые блокировки круче :)

(0) РИБ выйдет в итоге дороже, чем "борьба" с блокировками.

(36) 3-6 переделов. 400 наименований продукции.

(48) аргументы ?

(46) твоя цитата из (43): "...за пару месяцев написали почти полностью новое решение..."

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

Так что либо речь идёт не об одном программисте, а о целой группе гениев, либо всё-таки не о нетленке и не о 95% переписанного кода.

(50) какие хочешь, их много у меня.

(52) озвучивайте

Содержание двух баз (возможность рассинхронизации).
Потом в эту базу полезут аналитики, так как там "лучше" работать с отчетами.

(54) у меня распределенка КА крутится без рассинхронизации.

(53)
далее надоест перекидывать тоннами данные и будут доработки из серии туда все, обработно только движения по РАУЗ.
Если есть ресурсы, то лучше проанализировать узкое место в расчете и убрать его.

(55) проверял?

(56) что значит надоест ? Это все вообще не аргументы.

(57) ага оборотку сформировал.

(49) походу там кроме производственного учета еще есть разные финтифлюшки с  дохрена регистров :)

(56) Наверное где-то есть "сопля" НачатьТранзакцию() Если Сч = 100 Тогда ЗАфиксироватьТранзакцию()

(60) из чего такие выводы ?

(61) в типовом РСВ ?

(63) в типовом

(62) Например у меня в документе всего пять регистров, кроме конечно регистров бухучета и налогового учета

Если себестоимость в БП 24 часа закрывается это плохо?+) База овер 30 гб

(63) на партнерском форуме периодически пишут, что работало X часов, после изучения стало Y минут.

Если идет блокировка работы пользователей, то нужно смотреть какие регистры изменяются в момент расчета. Если регистры для оперативного учета (что вообщем-то странно), то как вариант отключить текущие итоги (не итоги) по ним на период расчета. Либо убрать такие изменения (они могут быть избыточными).

(50) <- (40) Если оптимизировать не хочешь, перед расчетом создавай копию БД, в ней считай себестоимость. Потом с помощью стандартной обработки Выгрузка/загрузка XML РСВ переносится с движениями в рабочую БД. На другом предприятии (20ч производство, перерыв ночью) РСВ считался 12 часов БУ+НУ (Традиционная схема учета), в регистре Хозрасчетный было порядка 5 млн. проводок - перенос РСВ с движениями занимал 40 минут.

(68) руками так делали. Это все очевидно.

Если очевидно, тогда о чем речь в (0)? простой 3.5 часа?

(70) кто это будет ночью делать ?

сколько времени делался бэкап + копирование ? расчет на том же сервере ? или на другом ?

бэкап средствами SQL - в фоне, про загрузку уже писал, копия на том же железе.

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

(74) вообще если таким путем идти, то лучше купить машинку за 20 тыщ на ssd дисках или вообще серверную мать с 16 слотами по 8 гб забить и устроить рам диск. Там разместить периферию базы и делать все расчеты влет. Обратный обмен более 40 минут, по-моему ни у кого не длится...

(75)
нет пределу совершенства.
можно и c 64 слотами (2 терабайта озу) + time ten.


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

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

а можно экстенсивными - наращивание линейной вычислительной мощности.

- минусы малая линейная масштабируемость.
плюсы - простота, быстрота, надежность.

можно обоими - распараллеливание, изоляция, стекирование .

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

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

(51)"За два месяца производственный учет в одно лицо не написать. Даже относительно простой учет."
Так интерфейсная и методическая часть осталась практически без изменений. Изменились алгоритмы практически полностью, то есть модули.

(2) Вы пишете: sql: Xeon E5640 2.67GHz 2.66GHz(2 процессора) 16 ядер / 24 ГБ / 64 разрядная ос / RAID-10 на 10 SAS дисках по 450 гигов

Смущает объем ОЗУ. Не знаю, какая у Вас материнка, но, скорее всего, она поддерживает минимум 128 ГБ (8 слотов DDR3). По деньгам 8 шт. 16-GB ECC Reg модулей кингстон всего лишь 70-75 т.р., не ахти какие деньги в сравнении с остальным железом. Зато объем ОЗУ станет больше, чем сама база, значит, надобность в частом обращении к массиву отпадет.
В общем, я бы начал с увеличения RAM.

А снятую память с этого сервера, если это возможно, переставить на сервер 1С.
Кстати, может есть смысл увеличить количество рабочих процессов?

Что касается основного вопроса, ИМХО стоит связаться с местными САПерами, они наверняка подробно расскажут, почему эта радость настолько дороже 1С-ки :-)

(51) Тут на прошлой работе за 3 месяца биллинг написали ,А ты производство )))

(79) "За три месяца одному никак не справиться, тут помощник нужен" :)