gifts2017

Опять уперлись в платформу ?, Мрачные раздумья о производительности ...

Опубликовал Доржи Цыденов (support) в раздел Администрирование - Системное

Приветствую всех.
Скажу сразу: букв написал много, потому кому лень до конца читать – просто закрываем ветку.
Значит так. Есть определенная фирма, оказывающая услуги, в которой я тружусь начальником отдела ИТ два года, . Специфика фирмы такова, что корпоративная информационная система должна работать в реальном режиме времени и выдавать информацию 24 часа в сутки 7 дней в неделю
Приветствую всех.

Значит так. Есть определенная фирма, оказывающая услуги, в которой я тружусь начальником отдела ИТ два года, . Специфика фирмы такова, что корпоративная информационная система должна работать в реальном режиме времени и выдавать информацию 24 часа в сутки 7 дней в неделю.

Количество пользователей в фирмы на данный момент порядка 700, раскиданных по почти 30 филиалам нашей необъятной страны. Есть филиалы со 150 пользователями, есть и всего с десятком.
Количество документов в рабочий день порядка 12-15 тысяч. Специфика бизнеса такова, что 3-4 вида документов дают порядка 70-80% объема. Очень объемный справочник контрагентов (порядка полумиллиона).

Силами отдела ИТ в 2005 году была написана собственная разработка на 8ке, т.к. 7ка к тому времени даже на гораздо меньших объемах стала загибаться. Конфигурация не тяжелая, по крайней мере до УПП ей явно далеко.
С 1 января 2006 г конфигурация была успешно запущена и работает по сей день. Сейчас кол-во документов в базе порядка 4,5 миллионов, размер базы порядка 20 Гиг.

Основной проблемой эксплуатации базы всегда был обмен данными (практически нетронутый встроенный УРБД), т.к. , повторюсь, объем данных велик, а оперативность высока (практически в течение часа-двух нужно чтобы данные введенные в филиале, находящемся в одной ветви УРБД видел филиал из другой ветви). При малейших «затыках» с обменом он начинал идти гораздо медленнее требуемого часа-двух, что нарушало бизнес-процессы компании.

Исходя из этого было принято решение о «стягивании» всех пользователей в 2-3 базы, которые будут располагаться на мощном серверном оборудовании. Фирма понесла значительные затраты на покупку и содержание широкополосных каналов И-нет с каждым своим филиалом. Т.к. стоит отъехать от Москвы или Питера на 100 верст, как стоимость устойчивого(!) канала в 1 Мбит/с растет совершенно не пропорционально здравому смыслу.

В результате мы смогли в одной базу нарастить количество пользователей до 270-280, а в другой до 180-185. Но в дальнейшем (видимо из-за роста объемов транзакций (читай – документов), видимо – так как других причин я не вижу) мы были вынуждены откатиться назад и сейчас в этих базах работает соответственно 180-190 и 150-160 человек, при добавлении большего количества пользователей (а 70% из них «колотят» документы) начинаются бешенные транзакции, а если еще и обмен при это начинается, то …

Все попытки как-то оптимизировать базу (как 1С , так и СКЛ) вобщем-то ни к чему не привели. В базе 1С перенесли проведение всех документов на сервер, отказались от автоматической очистки движений документа при проведении, оптимизировали код, запретили пользователям запускать больше 2х сессий, вынесли «крутые» упр.отчеты в отдельную базу на отдельный сервак, вобщем делали наверное все что вычитали по проблеме в И-нете. Движок 1С 8.0.17. На 8.1 честно говоря переходить пока страшновато.

На СКЛ-базе: индексировали, шринковали, убивали лог, ставили базу в Simple, убивали tempdb, переносили лог на отдельный диск, убивали саму базу и выгружали из мастера заново . Никаких радикальных облегчений это не дало.

О железе:

Речь поведу о самой мощной нашей площадке, где «сидят» на данный момент 180-190 пользователей, а было время «сидело» и 280.

- СКЛ-сервер НР Proliant 385 (4 процессора AMD Opteron 2000, 8 Гиг памяти), дисковая коробка HP StorageWorks MSA1000 Smart Array SAN в массиве Raid 0. ОС Windows 2003 (64-bit), SQL 2005. Установка Windows Server 2000 и SQL 2000 дало тока еще большие тормоза.
Дальше на всех серверах стоит по 2 процессора AMD Opteron 2000, 4 гига памяти, ОС Windows Server 2003

- сервер приложений HP Proliant 145;
- восемь терминальных серверов (Citrix MetaFrame Presentation Server 4.0 Enterprise Edition), все пользователи работают только через терминалки;
- сервер, где крутятся обмены HP Proliant 145

Между серваками, ессно, 1Гбит/с.

Словом, стоимость оборудования порядка 100 тысяч долларов Snus1 - 23.04.2007 - 11:02 Тесты показывают, что затыкается в основном дисковая подсистема (не только на этом филиале, в любом другом на любом другом железе тоже).

К чему я все это написал. В планах фирмы рост количества пользователей в течение года до 1000-1200 человек. Мое начальство справедливо (как мне кажется) считает, что 100 тысяч долларов на серверное оборудование на 200 пользователей – это сильно круто.

Исходя из этого совершенно непонятно что делать дальше: при дальнейшем росте кол-ва филиалов и информации обмен просто не будет успевать за потребностями бизнеса. Больше 200 пользователей в одну базу тоже не получается «посадить».

Получается, что мы, сборище далеко не глупых (как я надеюсь) людей, не первый год работающих в ИТ сфере, находимся в некоторой растерянности: оставаться на 1С ? Трогаться на другую платформу ? Какую ?

Где выход ? Еще дальше наращивать железо ? Начальство говорит – все, хватит, денег не дадим.
Писать свой обмен ? С полгода работы пары программистов убью на это. А гарантия что будет быстрее ? Нету. Да и очень удобно, когда все пользователи, что называется «под рукой», а не серверный зоопарк по всей России.

Писать «тонкого» клиента на веб-интерфейсе с занесением данных прямо в СКЛ-базу (тогда на фиг мне 1С ? )? С год работы одного программиста убьем, а гарантия есть что будет быстрее ? Кто-то делал что-то подобное ? Т.е. часть пользователей под 1С, а часть на каком-либо другом интерфейсе с доступом к этой же базе.

Или может мы что-то неправильно делаем ? Может глаз замылился ? Может есть какой-то мега-секрет, какая-то волшебная «птичка», которую мы пропустили ?
Или на самом деле $500 на юзера в серверном оборудовании – это нормально? Может мы многого хотим ?

Особенно меня интересуют ответы людей, имеющий РЕАЛЬНЫЙ (не мифологический, не уровня «от одной бабки слышал», я тоже много чего слышал), именно реальный опыт внедрения, а (самое главное !) длительной (больше года !) эксплуатации каких-либо решений на 8ке на количестве пользователей в одной базе от 200 (минимум 50% активных !) с территориально распределенной структурой при бешеном документообороте, т.е. пользователь должен вводить в день не 1-2 документа, а сотню хотя бы.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. VasilyKushnir (vasilykushnir) 25.04.07 09:46
Чтобы уйти от уровня "не уровня «от одной бабки слышал»" просто посоветую обратить взор на крупные электростанции (для примера в Украине - Днепрогес), особенно те, что обслуживают несколько регионов, где нужна очень быстрая реакция на изменение нагрузки в сети. И сервера там стоят не детские и ПО никому в голову не приходило ставить на платформе 1С.... В твоем случае, ИМХО, 1С немного не та платформа (изначально не ставилась задача максимальной реакции на внешние раздражители - и что 8.0, что 8.1 без разницы - танк не взлетит.).
2. Evgen_5 25.04.07 14:06
Обмен данными можно организовать по-другому. Мы создали регистр - где отмечаем изменные документы (Проц ПриЗаписи() пишет ссылки в регистр). Раз в час обработкой выбираем регистр и по ссылкам выгружаем документы (XML или через СОМ соединямся)- регистр очищаем. У нас объемы не такие как у Вас (база 2 гиг за год). Значительно повысит произодительность ежеднывный перезапуск SQL и 1с-сервера (службы). Еще как вариант терминальный.
3. Drock (d.snissarenko) 02.05.07 15:16
Я немного не уловил, скл сервер работает еще и как сервер терминалов?
Самое печальное в 1с - это то что она не поддерживает SQl репликации.
Откажитесь от Citrix Metaframe - неповоротливое создание, я поставил 2x application server, load balancing на 2 сервера терминалов, можно на сколь угодно сделать, в целом, железо у меня стоит обычное, скл и сервер 1с вынесены на отдельную машину - 4 гига мозгов, дисковая подсистема сата диски 16мб буфером в мирроре, серверы терминалов тоже по 4 гига , везде стоят двухядерные процы, ОС - win2k3 r2 , SQL пока 2005 стандарт, реально заметил снижение нагрузки на железо после снесения метафрейма, в среднем сидит от 40 до 50 юзеров, в планах до 100-150, SQL пока трудится на средней нагрузке в 20-30% ЦП, память ессно по максимуму отъел, все настрйки скл базовые. документов в день около 150-200 мб больше, справочник номенклатуры порядка 25 тысяч, спр контрагентов около 2000, на серверах терминала ограничение на простой 30 минут, не работает человек - нефиг занимать машинное время.
Средний трафик между сервером скл и сервером терминалов от 10-15гб в сутки.
Убейте ctfmon - + 1-5% нагрузки ЦП с юзера.
С дисковой подсистемой все сложнее, харды на 15000к, оч хорошее охлаждение, Raid 5 нужно бы поставить на sql, тоже собираюсь, пока только руки не дойдут, а то смотреть на интенсивность работы хардов прямо жуть.
4. Евгений jhj (Mantis) 28.04.07 14:27
5. Drock (d.snissarenko) 02.05.07 15:23
PS// Или учитывая воможность SQL писать своего клиента для данной БД
6. Александр (garin) 09.05.07 10:53
1с не годится вам. Есть "Галактика", R3 и т.п.
7. DAV (DAV) 16.05.07 06:16
ИМХО не правильно ставите задачу уважаемый, вы пытаетесь решить проблему средствами той платформы, которая не предназначена для решения таких проблем штатными средствами. Да и что греха таить и не штатными. VasilyKushnir правильно отметил - танк не взлетит, посему выход надо искать в другом месте. Для начала необходимо более четко сформулировать задачу. Расписать требования, особенно касаемые бизнес-процессов (время обработки, время реакции, скорость доступа и т.д.). Потом выбирать платформу согласно этих требований. Видел как пытались автоматизировать подобный процесс в Энергосбыте (местном) на 7.7 - жуткое зрелище. Посему советую либо полностью уйти от 1С, либо применить другую технологию используя 1С как интерфейс (Web). В общем и целом чтобы полее полно ответить на заданные вами вопросы, надо иметь несколько больше информации, чем вы описали в статье.
8. Сhe Burashka (CheBurator) 01.08.07 01:55
Считай примерно так: 1000 бакинских на одного пользователя. Вот вам цена решения.
9. Сергей Старых (tormozit) 03.08.07 11:56
Без абзацев читаемость плохая.
10. Доржи Цыденов (support) 03.08.07 12:40
11. Dima (sokir) 02.11.07 12:21
Вообщето 1С сильно хвасталать, что переходе с 7.7 на 8-ку значительно увеличивается производительность её системы (в нете много написано).
Не знаю как по 8-ке, но мы сидим на 7.7 и не собираемся на неё переходить, т.к. после оптимизации кода производительность устраивает (оптово-розничный магазин).
Железо сервака: два Pentium3 450 (не было тогда ещё двухядерников), 1.5 Гб оперативы, винты SCSI по 8 гиг в Raid-5 покупалось в 1999 году (дохрена стоило тогда) :). На нём стоит Win 2000 server Standart, Sql 2000 server Standart. Никаких терминалов не стоит!
Рабочие машины: 8 касс - 366 celeron, 64 mb Win XP SP2 HOME - жестоко конешно. Остальные получше - всё таки отчёты надо побыстрее формировать.
Количесво расходных в день > 1000 в среднем по 11 строк (разумеется при наборе товара показуется остаток по складам в каждой строчке, накладная проводится сразу как набрана с рассчётом всех остатков и т.п.).
Остальные документы (приходы, перемещения и т.д.) - > 100 в день.
При проведении документов никаких окон с транзакциями не выскакивает (кроме случаев когда я перепровожу расходные задним числом. Сразу начинают звонить - а у нас тут какоето окошко вылезло. Т.к. по несколько документов я перепровожу очень редко, то забывают юзера, что такое окно может выскакивать и сильно пугаются. Ну долго считаются остатки у 1С на конкреный момент времени, особенно на конец месяца), т.к. на ТА остатки даже в 1С счичаются почти мнгновенно, в основном время проведения упирается в запись регистров и продовок.
Кароче говоря 10-11 пользователей усиленно набирают доки, а 5 менеджеров усиленно формируют отчёты-простыни да ещё по две 1С-ны запускают (пару - тройку основных отчётов я перевёл на прямые запросы через ADO - сила! по сравнению с 1С).
Когда приняли меня на работу то постоянно доставали из-за транзакций. Слава тебе госпади в семёрке есть оптимизированный под SQl метод ВыгрузитьИтоги, после того как подставил его в модуля проведения проблема с транцакциями исчезла (задним числом могу перепроводить только я, и то по служебке, поэтому это происходит редко как я говорил выше).
Как не гляну на загрузки процов - почти ноль, но иногда некоторій отчёты сильно подгружают (очень редко и на набор доков сильно не влияет). База была до 7 гигов, но я её периодичеки сворачиваю: все старые (более 3 месяцев ) движения по расходам переношу в отдельный документ свёрнуто за день (тоесть независимо сколько раз в день товар продавался, по нему будет одти одно общее движение), т.о. за заданный период в ~ 2.5 уменьшается количество движений по расходам.
Так вот к чему я собственно веду: если на таком галимом сервере на 7.7 нормально всё крутится, то на 8-ке с её производительностью и масштабируемостью (по заверениям фирмы 1С) в стократ должно быть лучше. Хотя конешно для поднятия продаж 8-ки 1С-цы могли приврать в плане скорострельности новой платформы. Да и при увеличении размера базы может дисковая система не выдерживать нагрузки.
Самые общие выходы из ситуации (обрезание базы, сворачивание периодов), вам не помогут, т.к. отчёты как я понял формируются на отдельном серваке. Соответсвенно прямой путь в отладчик и уменьшать - уменьшать - уменьшать - уменьшать - уменьшать время проведения (записи) документов, а может даже и справочников. Это в любом случае надо сделать, т.к. в один момент времени может проводится(записываться), только один документ. Если не сможете этого сделать, то два выхода.
1. Всё таки найти методы как это сделать или найти кто сможет ( я как писал выше нашёл ВыгрузитьИтоги. Хотя в 8-ке вроде всё через запросы тока - тогда оптимизация запроса. Query Analyzer и Profiler вам помогут). Разумеется пользователи нивкоем случае не должны перепроводить документы задним числом (никакие оптимизации при ваших объмах не спасут).
2. Если п.1 не выполним - нафиг 1С (как нипрескорбно).





12. Олег (OLEG4120) 08.11.07 11:22
Не понятно, почему Вам страшно переходить на 8.1...
Даже без плясок с бубном вокруг кода, которые рекомендует 1С производительнось видно не вооружонным глазаом.

Мы перешли и обратно я не когда не соглашусь...
PS мед. Центр 50 пользователей 1500 документов день, 100 000 пациентов...
13. Олег (OLEG4120) 08.11.07 11:24
Кстати Документы поступают из оракловой (основной базы, моя относится к лабораторным исследованиям) обменом, обрабатываются и посылаются обратно.
14. Роман Зиновьев (Широкий) 07.12.07 12:52
На 8.1 есть такая фишка как управляемые блокировки..
Советую попробовать
15. Владимир (hogik) 05.02.08 15:48
Вопрос автору.
Решение найдено?
16. Олег Пономаренко (O-Planet) 12.02.08 21:20
А что мешает отказаться от 1С и использовать системы, предназначенные как раз для таких объемов данных?
17. isn Игнатьев (isn) 28.05.08 07:39
у нас решение по типу вашего реализовано на цитрикс серверах/клиенте, правда клиентов чуть меньше около 650 пользователей. организовано 3 сервера с 1С сервером приложений(32 и 64 битные), 6 серверов с цирикс клиентами, 2 сервера с sql. количество филиалов тоже чуть меньше, но очень большой удаленностью (порядка 5000-7000 км друг от друга. и проблем с произодительностью не наблюдаем. сервера 2-4 процессорные на Intel и IBM. на основной площадке сидят 350 человек. Решение с такими масивами переводят часто на оракл, но это совсем другие решения и стоимость оракла и его поддержки возрастает не соизмеримо. количество документов в день от 3000 до 8000. разделение по шли по пути: базы куда вводят данные и базы которые дают отчеты - производительность резко возрастет. сначала будет пользователям неудобно, потом привыкнут к новому регламенту работы. Я не сказал о дублирующих серварах и тоже их полно. всего в айти сфере 750 компов 48 серверов.
18. Андрей Пастухов (Minotavrik) 30.07.09 14:30
Добрый день!

1) Я думаю вопрос о переходе на другую платформу вообще тут не уместен, для фирмы была разработана программа, которая всех устраивает.

2) Я так понял, что все базы тянут, единственное все утыкается в обмен между этими базами.

3) Теперь про обмен, так вот дорогие товарищи встроенное в 1с 8.1 решение обмена стандартными средствами это полная ж.... говорю полностью обосновано т.к. сам с этим сталкивался.
Работал в одной конторе объем данных хороший, но т.к. обмен был написан нормально все выгружалось и загружалось очень быстро. Я даже все это дело пересадил на пакетный режим. Т.е. загрузка, выгрузка на каждом филиале происходила в регламенте через каждые 5 минут и в центральном узле все это подгружалось, головной офис был отдельной базой с которой шел полный обмен. Центральная база всегда была свободна.

Изменения данных в регистрах сведений в сотни тысяч строк обменивал минут за 30 с 15 филиалами.

После устроился в котору, где обмен настроен стандартными средствами 1с. В итоге за ночь не успевает все обменятся (данных при этом не так много).

Хорошо настроенный, т.е. написанный обмен дает очень много.
19. Андрей Пастухов (Minotavrik) 30.07.09 14:38
Основная проблема в стандартном автообмене это регистрация изменений без разбора. А нужно регистрировать изменения при записи объекта согласно политики миграции документов. Еще много ньюансов, которые можно поправить если выключить стандартную регистрацию.
20. hamsar hamsar (hamsar) 06.12.09 14:56
21. Александр Шишкин (Шёпот теней) 06.12.09 18:54
... мнение от "дедушки" ...

1. свой обмен (выгрузка паралельно с дкументом) ...
2. упростить данные для передачи ...
2.1. переписать документы дающиё большую нагрузку на обмен ...
2.2. упростить структуру данных (конфигурация) ...
2.3. создать паралельные регистры для "нагруженных документов) ...
3. не дано ...

п.с.1. переделывать с запасом ...
п.с.1. переход на другую систему учёта видимо будет ешЁ зАтратнее чем п.1. и п.2. или покупка оборудования ...

... вотТАКОЕмнение ...
22. larissa builova (larisab) 06.12.09 19:05
На дату и автора то смотрели, советчики по переписыванию конфигураций? :D
23. Александр Шишкин (Шёпот теней) 06.12.09 19:10
(22) ... разве это имеет значение ? .. ! ... да пусть хоть 1Апреля ...

... задача интересная и далеко идущая ... на таких вот и бывают прорывы в сознании ...

... тем более можно узнать и результат ... так чем тАмА дело кончилось-то ... ???

... вот ...
24. larissa builova (larisab) 06.12.09 19:16
(23) Судя по твоему ответу в 21 ты последний абзац статьи не читал.
25. Александр Шишкин (Шёпот теней) 06.12.09 19:53
... почему же ... читал ... поэтому и пишу от "дедушки" ...

... порядок цифр не пугает ... пугает переход на 8-ку ... странные у нас программы - прям ка игрушки ... сколько им не дай "железа" всЁ мало ...

... у нас в регионе есть компания которая написала свою программу ... она работает и сейчас ... сейчас её меняют на Р/3 ... и что ? ... да ничего ... программа работает а Р/3 нет ... Р/3 внедряют уже 6 лет человек 100 (програму местную обслуживаеь коллектив в 12 человек) ... вОт ... обЪём данных сопаставим с (0) ...

... где жжж такие задачи найти ... у нас в провинции ... поэтому и считаю что такие задачи, даже вымешленные очень "встряхивают" ... как олимпиады по математике ...

.. вот ...
26. Александр Шишкин (Шёпот теней) 07.12.09 10:26
... так чем тАмА дело кончилось-то ... ???

... ТАКхочетсяУЗНАТЬвот ...
27. Имя Фамилия (a.ivanov) 13.01.10 10:54
Обратитесь в SoftPoint. Там вам помогут. У них есть очень хорошее решение для он-лайн обмена данными
28. dushelov (Душелов) 13.01.10 11:07
(27) Посмотрите на дату публикации.
a.ivanov; +1 Ответить
29. Имя Фамилия (a.ivanov) 13.01.10 14:05
Да я потом только посмотрел. Сначала глянул на дату последнего комментария, думал еще актуально )))