Имя: Пароль:
1C
1С v8
Какая "серверная" архитектура предпочтительней для Клиент-Серверной 1С 8.х
,
0 sanfoto
 
17.10.14
13:57
1. Другое (описываем) 57% (4)
2. 1-ин SGI(1000 ядер) порвет-> 50 серверов 29% (2)
3. 50 Серверов(в сумме 1000 ядер) порвут-> SGI 14% (1)
Всего мнений: 7

Итак Вводные данные:
1) 1С база - допустим стандартная УПП от самой 1С.
2) 1 000 (Одна тысяча) пользователей
3) размер базы 1 Терабайт
------------------------
Варианты по железу и ПО:
1) 50 серверов
- на каждом по 20 ядер CPU... кроме пожалуй под SQL Выделенного (допустим 40 ядер)
- все сервера объедены в "1С кластер"
- OS Windows
- коммуникация 10 или более Гигабит Ethernet
- Везде SSD диски
******----------------------
2) Один SGI сервер 1 000 ядер
- используются те же CPU что и в первом варианте (между блоками быстрый Интер-коннект на NUMA чипах)
- т.к. сервер один то ОДИН "сервер 1С"
- OS Windows
- коммуникация между SQL и "сервер 1С" - без сетевых протоколов - через участок памяти (SharedMemory)
- SSD диски


-------------------------------------------------
--------------Информация для размышления---------
-------------------------------------------------
можете провести простой тест (на любой СТАНДАРТНОЙ конфигурации)

1) берем "Комп1" и такой же абсолютно "Комп2"
- на одном ставим SQL на другом "Сервер 1С"
- обработкой.. проводим несколько тысяч документов Засекаем время.

2) берем "Комп1"(абсолютно такойже как в пункт Один) на нем и SQL и "Сервер 1С" соединены через SharedMemory
- обработкой.. проводим ТЕЖЕ несколько тысяч документов Засекаем время.

3) Сравниваем результаты. (Лично у меня разница около 50%)
11 sanfoto
 
17.10.14
14:06
SGI порвет в клочья -> 50 серверов ИБО между ними будут большие задержки на синхронизацию.

Коммуникацию..
-можно проверить утилитой ipperf - между двумя компами например соединеных Ethernet 1 Gigabit/ Выбираем размер пакета 4 Кб (именно с таким работает MS SQL)/ так вот в результате скорость передачи данных будет равна около 250 Мегабит

- можно проверить утилитой ipperf на ОДНОМ компе))) все увидите... а SharedMemory еще быстрей ИБО ненужно упаковка распаковка в сетевые пакеты.

1-ин SGI(1000 ядер) порвет-> 50 серверов
12 Aleksey
 
17.10.14
14:07
(10) Сдохнут <> умрут
Сдохнут - это значит будут не успевать обрабатывать
13 piter3
 
17.10.14
14:07
(10)если творчески подойти то сдохнут
14 Aleksey
 
17.10.14
14:08
(11) шаред мемерои не панацея. скажем так шаред мемори позволит работать не 100 пользователям, а 101, т.е. там в пределах стат погрешности (по крайне мере на моем серваке было так)
15 vde69
 
17.10.14
14:09
почему автор не расматривает вариант кластера SQL сервера ???

примерно так
30 серверов - кластер 1с
20 серверов - кластер SQL
16 sanfoto
 
17.10.14
14:10
(15)
без разницы пропорции

ИБО между ними будут большие задержки на синхронизацию.

Коммуникацию.. на синхрон транзакций
17 Aleksey
 
17.10.14
14:11
(8) я тестил полку с сас винтами (10 райд) и ССД Самсунг про 840 на 512 гигов

В линейном чтении ССД немного быстрее, но масштабируемость у САС выше,
18 ice777
 
17.10.14
14:12
(7) и правда, зачем 1С при таких возможностях-то.
19 Йохохо
 
17.10.14
14:12
(16) а почему не 10 серверов 1с и 1 скуля?
20 sanfoto
 
17.10.14
14:13
(18) поддержка ПО однако.
21 Aleksey
 
17.10.14
14:13
(16) НЕ согласен. При прочих равных при больших объемах сетевая задержка нивелирует скоростью обработки
22 vde69
 
17.10.14
14:14
(16) не скажи... если в системе наприер 1000 пользователей - то распаралеливание по серверам будет отлично работать... и чем тяжелее запросы тем будет лучше...
23 sanfoto
 
17.10.14
14:16
(22)
рекомендую прочесть https://ru.wikipedia.org/wiki/ORM
чтобы понять что БОЛЬШАЯ часть бизнес логики на "Сервере 1С"
24 sanfoto
 
17.10.14
14:16
(23) а не на SQL
25 Aleksey
 
17.10.14
14:19
(23) С каких пор 1С стала следовать каким то стандартам и поддаваться логики???
26 sanfoto
 
17.10.14
14:24
(25)
читайте матчасть)) https://ru.wikipedia.org/wiki/ORM

все понятно там изложено
27 XMMS
 
17.10.14
14:28
А мне казалось, что 1 сервер на >100 пользователей - это уже весомый риск. Кластеры придуманы не только для распределения нагрузки, но и на случай отказа одного из серверов на любом из уровней - от приложения до железа.
28 Aleksey
 
17.10.14
14:30
(27) Опять таки это если говорить в вне контекста 1С
А вот судя по отзывам кластеры от 1С явно для чего то другого придуманы
29 oleg_km
 
17.10.14
14:33
(27) В 8.2 кластеры решают ТОЛЬКО проблему распределения нагрузки. Вернее, с их помощью можно удлинить интервал падания серверов из-за утечек памяти
30 SSSSS_AAAAA
 
17.10.14
14:36
(0) А под Sql сервером какой сервер подразумевается? MS Sql или какой другой?
31 sanfoto
 
17.10.14
14:42
(28) +
(29) +
от меня + "Кластеры 1С" дают замедление работы.. проведение доков и т.п.
32 sanfoto
 
17.10.14
14:43
(30) в общем случае наибольшая скорость работы 1С на MS SQL

поэтому без разницы какая Реляционная СУБД
33 sanfoto
 
17.10.14
14:45
(30) рекомендую прочесть https://ru.wikipedia.org/wiki/ORM
34 SUA
 
17.10.14
14:49
1 сервер лучше сети, главное делать бэкапы =)
(1)(2)(4)да, 1с уже давно не только для ларьков
хотя для отказоустойчивости - по 2 компа на кластеры скуля и 1с как-то понадежнее
35 SSSSS_AAAAA
 
17.10.14
14:50
(32) Ошибаетесь, разница есть. Кластер MS SQL не умеет параллелить нагрузку и потому всякие разговоры о 20 ms sql серверов для одной базы бесмысленны.
36 piter3
 
17.10.14
14:51
(34)фраза 1с готова как-то не очень.платформа и/или решения?
37 sanfoto
 
17.10.14
14:51
что невижу голования.. кроме НЕОБОСНОВАННОГО))

"pessok
4 - 17.10.14 - 14:03
ни один из вариантов работать не будет, бо 1С
3. Другое (описываем) "
38 ssh2QQ6
 
17.10.14
14:52
(37) все википедию читают, мат часть подкачала
39 sanfoto
 
17.10.14
14:55
(35) Ошибаетесь вы))
даже кластер ORACLE предел масштабируемости ДВА СЕРВЕРА с InfiniBand коэф 0.9.... т.е. уже деградация ...производительности а дальше вниз крутая кривая
https://ru.wikipedia.org/wiki/InfiniBand
40 SUA
 
17.10.14
14:56
(36) УТ11 видел на 1.5К онлайн пользователей, причем по этому показателю база успешно росла
41 SSSSS_AAAAA
 
17.10.14
14:56
(39) И в чем я ошибся?
42 piter3
 
17.10.14
14:57
(40)понял,но больше интересно объемы в Тб.а звери могут пасьянс раскладывать
43 sanfoto
 
17.10.14
15:00
(42)
но больше интересно объемы в Тб.а звери могут пасьянс раскладывать

1)если использовать "Кластеры" - то да

2)а если как и в "SAP NAVISION" использовать ОДИН много много ядерный сервер то нет))
44 Maxus43
 
17.10.14
15:00
насчет количество серверов я хз, но в моём пониманиии примерно так:
1. 1с пофиг сколько у тебя ядер, всё равно использует одно на 1 процесс.
2. через шаред мемори конечно быстрее, не юзается сетевой интерфейс, тут проблема будет в паралельности, блокировках и прочем, на типовой УПП не взлетит впринципе такая нагрузка, хоть в 2 раза лучше железо купи, надо логику переписывать там
45 ice777
 
17.10.14
15:02
(44) насчет ядер на процесс.. дадад.)
46 Maxus43
 
17.10.14
15:02
у софтпойнта такой опыт есть, я хз справились они или нет, там с кластерами скуля что-то мутное делали, свои разработки юзали.
На оракле и 1с знаю проект примерно такой по масштабам, но врятли кто-то даст у них спросить как было сделано, мбо такие вещи делаются дорого специализированными конторами
47 sanfoto
 
17.10.14
15:02
(44)   Maxus43

процес то один и у например SQL сервера, а ПОТОКОВ то МНОГО и они вполне могут быть на разных ядрах.
https://ru.wikipedia.org/wiki/Процесс_(информатика)
48 SUA
 
17.10.14
15:03
(46)Просто дорого. Любой очень крупный франч - центр компетенции.
49 Maxus43
 
17.10.14
15:03
(47) я про процесс 1с, он не юзает различные ядра на разные потоки процесса.
Стандартная картина на серверах: ровно 50% загружен проц - це 1с, к гадалке не ходи
50 Maxus43
 
17.10.14
15:05
(48) я бы например БИТ и близко не подпустил к такому проекту... крупнота не показатель
51 sanfoto
 
17.10.14
15:05
(49)
я кажется понятно написал
ПРОЦЕСС один... но внутри него много потоков как клиентов 1с так и служебных... потоки исполняются ПАРАЛЕЛЬНО
52 piter3
 
17.10.14
15:05
(48)неа 100 раз нет
53 МихаилМ
 
17.10.14
15:06
54 piter3
 
17.10.14
15:06
(51)можно нескромный вопрос?это теория или практика.кроме ссылок на вики
55 sanfoto
 
17.10.14
15:07
(54) практика
56 Maxus43
 
17.10.14
15:07
(51) ты теорию написал, а приложение должно поддерживать работу с несколькими процессорами-ядрами, 1с не поддерживает
57 sanfoto
 
17.10.14
15:08
(56)    Maxus43
вы про ПОТОКИ кода нибудь читали?
58 Maxus43
 
17.10.14
15:09
ЕСЛИ в 1с всего 1 процесс, ты не загрузишь им больше ОДНОГО ядра, это практика, а не теоритические статьи из начальной информатики. Операционка не будет сама распределять, если в программном обеспечении не заложено
59 Maxus43
 
17.10.14
15:10
(57) читал. Нагрузи мне одним процессом 1с больше одного ядра.
60 sanfoto
 
17.10.14
15:11
(59) мы про процесс "сервера 1с" ГОВОРИМ?
61 Maxus43
 
17.10.14
15:14
(60) конечно, но тут без разницы.
процесс rphost (в диспетчере) это и есть процесс сервера 1с, и он работает только с одним ядром
62 sanfoto
 
17.10.14
15:16
(59) Maxus43
"Стандартный нагрузочный тест 1С"
ЛИЧНО проводил тест в Односерверной системе
принудительно ограничивал SQL по ядрам,

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

на сервере где крутился "Сервер 1С" все ядра были загружены под 90%
63 sanfoto
 
17.10.14
15:20
(61)
а 50% была загрузка в ДВУХ-СЕРВЕНОЙ конфигурации
и загрузка сети была всего 20% а это уже забитый канал ПОЛНОСТЬЮ при общении "Сервера 1С" и "MS SQL" ИБО ЛАТЕНТНОСТЬ Etherneta///  т.е. пропускная способность уменьшяется по мере уменьшения пакета

так что 20% ПРЕДЕЛ ПРЕДЕЛОВ
64 oleg_km
 
17.10.14
15:21
(61) Ничего подобного, процесс rphost многопоточный, иначе многопользовательская работа была бы практически невозможна. Это клиентская 1C.exe многопоточная, но программист 1С работает только в одном потоке.
65 sanfoto
 
17.10.14
15:21
(64) +
66 Maxus43
 
17.10.14
15:25
мда. поичтал предыдущие ветки автора, и последние тут посты, бесполезный разговор грядёт на 1000 постов...
(64) тут надо сделать оговорку всё таки. 1с псевдомногопоточная. Каждый сеанс(соединение) может работать только в одном процессе и с одним ядром процессора, другие сеансы в других процессах и с другими ядрами
67 sanfoto
 
17.10.14
15:26
(63)
смотрят СИСАДМИНЫ на загрузку сети 20% и загрузку ядер серверов в 50%
и радуются мы все сделали ресурсов железа хватает.

а Ваша 1С тормозит ибо тупая 1С.. оптимизируйте код!

ТУПО!!!!

на самом деле "Сервер 1С" и "SQL" получается друг друга ждут вот и низкая загрузка CPU))
68 sanfoto
 
17.10.14
15:27
(66)" Каждый сеанс(соединение) может работать только в одном процессе и с одним ядром процессора" глупость
69 Maxus43
 
17.10.14
15:30
дело в таких больших системах не в процессорных мощностях, а в конкуренции юзеров за ресурсы СУБД, блокировках и т.д.
70 Maxus43
 
17.10.14
15:31
(68) давай, просвяти глупых, может в рай попадёшь за благие дела
71 sanfoto
 
17.10.14
15:36
(69)
а вы читали https://ru.wikipedia.org/wiki/ORM

чтобы понять "Сервер 1С" это "Виртуальная ОБЪЕКТНАЯ СУБД"

уперлись рогом в реляционный  SQL  что все дело только в нем))
72 sanfoto
 
17.10.14
15:38
кстати ГДЕ голосование ?

я не учитель... учить надоело однако))

Голосуем!!!
73 sanfoto
 
17.10.14
15:41
(70) Maxus43
внизу и справа веб страничики есть))

Ваш выбор: очистить 1. 50 Серверов(в сумме 1000 ядер) порвут-> SGI
2. 1-ин SGI(1000 ядер) порвет-> 50 серверов
3. Другое (описываем)

Обоснуйте свой выбор!
74 Зеленый пень
 
17.10.14
15:43
Соглашусь с (3).
Если у вас задача проводить последовательно 1000 документов - это одно. Если - параллельная работа юзеров, тест некорректный.

ИМХО, чем меньше сетевых соединений и, соответственно, задержек по передаче данных, тем лучше.
75 Maxus43
 
17.10.14
15:43
(71) чего сказать то хотел? 1с говно?
(72) учи в другом месте,  например в Алтайском государственном техническом университете им.И.И.Ползунова
76 Fragster
 
гуру
17.10.14
15:43
на 1000 юзеров УПП не взлетит без допила, надо ERP брать. ну а так - работать и так и так будет, но на одном 16ядреном серваке в 100 потоков показывает немного лучший результат, чем на двух.

1-ин SGI(1000 ядер) порвет-> 50 серверов
77 sanfoto
 
17.10.14
15:45
(75)
(70) Maxus43
внизу и справа веб страничики есть))

Ваш выбор: очистить 1. 50 Серверов(в сумме 1000 ядер) порвут-> SGI
2. 1-ин SGI(1000 ядер) порвет-> 50 серверов
3. Другое (описываем)

Обоснуйте свой выбор!
78 sanfoto
 
17.10.14
16:04
(76) Fragster

Цитата:
"на одном 16ядреном серваке в 100 потоков показывает немного лучший результат, чем на двух."

по процессорным мощностям я расчитываю примерно так
1)современные CPU держат 8 "высоко нагруженных" потоков на ядро
2)16*8 = 128 потоков

3) вроде хватает на на "100" "высоконагруженных", но надо учитывать, что система кушает, юзер 1с поток+ поток на юзера в SQL
----ИТОГО-----
16 ядерника хватит без резкого падения производительности... скажем так на 60 высоко-нагруженных "1c клиентских потоков"
79 Ник второй
 
17.10.14
16:10
На практике

50 Серверов(в сумме 1000 ядер) порвут-> SGI
80 sanfoto
 
17.10.14
16:13
(79)
маловато обосновано однако)) ну да ладно
81 Fragster
 
гуру
17.10.14
17:04
(78) сделай себе красивые графики с помощью http://infostart.ru/public/173394/ (будешь увеличивать количество потоков или как-то по другому менять алгоритмы, пожалуйста не выгружай результаты в сеть)
82 shuhard_серый
 
17.10.14
17:17
(0) если выделить каждому юзеру по ядру, то очевидное узким местом будет сиквел

и здесь любая альтернативная учетная система, да речь об Аксапте порвёт УПП как тузик грелку



ну нельзя с чудовищной избыточность 1С, пишущей одно и то же в 200 Регистров и на ходу пересчитывающей итоги , всерьёз обсуждать  1000 полноценных ERP пользователей

Другое (описываем)
83 Fragster
 
гуру
17.10.14
17:21
(82) я хз, но на аосы и прочую фигню на сто юзеров дакса ресурсов выделено сильно больше, чем на ту же сотню юзеров 1са... при этом дакс тормозит не меньше, а 1с удобнее сильнее :) как оно отмасштабируется на 1000 юзеров - оно, конечно, хз, но вот 1с-то можно условно-бесконечно "горизонтально" масштабировать с помощью РИБа (конечно, если смириться с некоторой "неопреативностью" из-за разделения по функционалу и/или реквизитам-разделителям регистров (склады или огранизации, например))
84 shuhard_серый
 
17.10.14
17:45
(83) ключевой слово РИБ,
ну не умеет 1С работать с несколькими сиквалами и бысто деградирует под нагрузкой

причина в проведении документов и структуре Рг остатков

пока 1С эту часть архитектуры не изменит ни какие кластеры серверов транзакций не помогут
85 Fragster
 
гуру
17.10.14
17:49
(84) а что такого плохого в проведении? то, что еще парочка таблиц апдейтятся? ну, если совсем тяжело и вы 80-го года доки перепроводите пачками - ну установите вы период рассчитанных итогов на это время и оставьте текущие итоги - будет ровно то же, что в "ынтырпрайзных" даксах по количеству апдейтов, а вот когда вам остатки нужно будет на предыдущий период получить - вот тогда вы табличке итогов скажете спасибо. а при неопреативном проведении даже за пару лет назад (х24 строки апдейтятся) ничего прямо катастрофического нет.
86 Jump
 
17.10.14
17:51
(0)Взлетит.
По принципу - разделяй и властвуй.
Короче серверов побольше, и базу аккуратно делишь между серверами.
87 shuhard_серый
 
17.10.14
19:35
(85) ох мне эти сказочники, ты готов заставить типовой документ(РТиУ под партионкой с оперативным зачетом аванса) в УПП проводиться за 0.1 секунды ?

а записывается он именно за такое время
88 Escander
 
17.10.14
19:55
SGI = Silicon Graphics?

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

1К юзеров... тут наверное базоводом оракл брать... но тут моментов хватает. В общем я-бы Вячеслава Гилёва почитал, у него много чего есть про высоконагруженные решения
89 Fragster
 
гуру
17.10.14
20:17
(88) я видел >500 юзеров на одном сервере 1с + 1 сервере мсскуля (что-то типа 32 ядер там было на каждом). А на оракле может быть опасно из-за ошибок платформы в работе с этим самым ораклом
90 Escander
 
17.10.14
20:37
(89) тут Вячеслав вам в помощь. Моментов там есть, но вроде как всё решаемо. Конечно нужен грамотный ораклоадмин.

Тестировали 1С с разными базоводами... если нужна производительность при >100 юзеров - однозначно оракл.
91 Escander
 
17.10.14
20:37
в смысле не я лично а статью читал
92 Fragster
 
гуру
17.10.14
20:39
(90) пару разработок для Вячеслава делал я, только тсссс ;)
93 Escander
 
17.10.14
20:42
(92) примерно год назад на сходке ораклистов главный от оракла по сибири рассказывал как он ускорил раз в 6 сальдооборотную ведомость на демобазе УПП... есть моменты...
94 Escander
 
17.10.14
20:44
(92) конфы? Так вот значит один из маньяков пишуших конфы где 10% кода попытка - исключение!!!
95 Ник второй
 
17.10.14
20:47
(80) Что тут обосновывать? это было бы сумасшедствие несколько тысяч засовывать на один сервак, в общем 50 серваков (баз) лучше одного
96 Ник второй
 
17.10.14
20:47
(81) А смысл в этой поделке если есть ТесЦентр?
97 Ник второй
 
17.10.14
20:51
(90) Оракл явно проигрывает
98 Ник второй
 
17.10.14
20:52
(93) Вот вот и только в этом случае оракле приблизится к мс скл.
99 Reaper_1c
 
17.10.14
22:32
(0) Ну и нахрена это все, когда:
http://v8.1c.ru/expert/cts/cts-202-010.htm
http://v8.1c.ru/expert/cts/cts-218-001.htm

Другое (описываем)
100 Escander
 
18.10.14
09:21
(97) то-то у последнего сиквела дали возможность ему становиться версионников... то что у оракла всегда было нативно
101 Escander
 
18.10.14
09:25
+ (100) хотя конечно если ты не слышал про управляемые блокировки...
102 kolanych
 
18.10.14
10:41
кластер sql повышает только отказоустойчивость. но не производительность. это надо знать, прежде чем проектировать систему.
103 Маратыч
 
18.10.14
10:59
Во-первых, надо сделать пул терминальных серверов. Как он там называется сейчас - ферма вроде.

Во-вторых, архитектура у тебя непонятная. Я не скажу навскидку, что гамно, но что-то подсказывает...
104 Обработка
 
18.10.14
11:53
Думаю важно не выбор железа а надо писать свое УПП не подойдет.

Другое (описываем)
105 Обработка
 
18.10.14
11:58
**Думаю важно не выбор железа а надо писать свое, УПП не подойдет.
106 systemstopper
 
18.10.14
12:36
(0) условия гипотетические, тест гуано. "Везде SSD диски" - вообще ни о чем, райды какие?
107 sanfoto
 
20.10.14
05:27
радует что большинство таки понимает, что

Кластер <> Скорость работы ,
а лишь повышает отказоустойчивость.

А также есть понимание, что задержки в коммуникации между SQL и "Сервер 1С" - тоже НЕ приводят к "Скорости работы" платформы))
108 sanfoto
 
20.10.14
05:29
(106)
про RAID и SSD -- как это не странно в нем(кроме RAID 0 ) кое-какие характеристики по задержкам ухудшаются по сравнению с Одиночным SSD/
109 sanfoto
 
20.10.14
05:52
про оптимизацию конфигурации под НАПРИМЕР MS SQL:

(0) да можно перенести ПОБОЛЬШЕ логики на SQL путем использования объекта "1С Запрос" .... да можно написать МНОГО ТЫСЯЧА...десятки ТЫСЯЧ строчные запросы
......... вместо пару десятков строк объектного кода....
КСТАТИ "ЗАПИСЬ и Обработка заполнения Объектов" все-равно будет НЕ в ЗАПРОСЕ!!!!!!!!!!!

Суть в том что такое решение становится
1)Очень МЕДЛЕННО в скорости разработки
2)менее гибко
3)зависимо от "первоночального разраба оптимизатора"
4)....... и т.д.
110 sanfoto
 
20.10.14
06:02
т.е.
1) Экономически более оправдано собрать аппаратно-программный комплекс заточенный на поддержку "Объектного подхода",
чем
2)бесконечная "дойная корова" для спецов "Реляционного подхода"....
----------------------------------
Это конечно со стороны "Заказчика"... )))
AdBlock убивает бесплатный контент. 1Сергей