Итак Вводные данные:
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%)

SGI порвет в клочья -> 50 серверов ИБО между ними будут большие задержки на синхронизацию.

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

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

(10) Сдохнут <> умрут
Сдохнут - это значит будут не успевать обрабатывать

(10)если творчески подойти то сдохнут

(11) шаред мемерои не панацея. скажем так шаред мемори позволит работать не 100 пользователям, а 101, т.е. там в пределах стат погрешности (по крайне мере на моем серваке было так)

почему автор не расматривает вариант кластера SQL сервера ???

примерно так
30 серверов - кластер 1с
20 серверов - кластер SQL

(15)
без разницы пропорции

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

Коммуникацию.. на синхрон транзакций

(8) я тестил полку с сас винтами (10 райд) и ССД Самсунг про 840 на 512 гигов

В линейном чтении ССД немного быстрее, но масштабируемость у САС выше,

(7) и правда, зачем 1С при таких возможностях-то.

(16) а почему не 10 серверов 1с и 1 скуля?

(18) поддержка ПО однако.

(16) НЕ согласен. При прочих равных при больших объемах сетевая задержка нивелирует скоростью обработки

(16) не скажи... если в системе наприер 1000 пользователей - то распаралеливание по серверам будет отлично работать... и чем тяжелее запросы тем будет лучше...

(22)
рекомендую прочесть https://ru.wikipedia.org/wiki/ORM
чтобы понять что БОЛЬШАЯ часть бизнес логики на "Сервере 1С"

(23) а не на SQL

(23) С каких пор 1С стала следовать каким то стандартам и поддаваться логики???

(25)
читайте матчасть)) https://ru.wikipedia.org/wiki/ORM

все понятно там изложено

А мне казалось, что 1 сервер на >100 пользователей - это уже весомый риск. Кластеры придуманы не только для распределения нагрузки, но и на случай отказа одного из серверов на любом из уровней - от приложения до железа.

(27) Опять таки это если говорить в вне контекста 1С
А вот судя по отзывам кластеры от 1С явно для чего то другого придуманы

(27) В 8.2 кластеры решают ТОЛЬКО проблему распределения нагрузки. Вернее, с их помощью можно удлинить интервал падания серверов из-за утечек памяти

(0) А под Sql сервером какой сервер подразумевается? MS Sql или какой другой?

(28) +
(29) +
от меня + "Кластеры 1С" дают замедление работы.. проведение доков и т.п.

(30) в общем случае наибольшая скорость работы 1С на MS SQL

поэтому без разницы какая Реляционная СУБД

(30) рекомендую прочесть https://ru.wikipedia.org/wiki/ORM

1 сервер лучше сети, главное делать бэкапы =)
(1)(2)(4)да, 1с уже давно не только для ларьков
хотя для отказоустойчивости - по 2 компа на кластеры скуля и 1с как-то понадежнее

(32) Ошибаетесь, разница есть. Кластер MS SQL не умеет параллелить нагрузку и потому всякие разговоры о 20 ms sql серверов для одной базы бесмысленны.

(34)фраза 1с готова как-то не очень.платформа и/или решения?

что невижу голования.. кроме НЕОБОСНОВАННОГО))

"pessok
4 - 17.10.14 - 14:03
ни один из вариантов работать не будет, бо 1С
3. Другое (описываем) "

(37) все википедию читают, мат часть подкачала

(35) Ошибаетесь вы))
даже кластер ORACLE предел масштабируемости ДВА СЕРВЕРА с InfiniBand коэф 0.9.... т.е. уже деградация ...производительности а дальше вниз крутая кривая
https://ru.wikipedia.org/wiki/InfiniBand

(36) УТ11 видел на 1.5К онлайн пользователей, причем по этому показателю база успешно росла

(39) И в чем я ошибся?

(40)понял,но больше интересно объемы в Тб.а звери могут пасьянс раскладывать

(42)
но больше интересно объемы в Тб.а звери могут пасьянс раскладывать

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

2)а если как и в "SAP NAVISION" использовать ОДИН много много ядерный сервер то нет))

насчет количество серверов я хз, но в моём пониманиии примерно так:
1. 1с пофиг сколько у тебя ядер, всё равно использует одно на 1 процесс.
2. через шаред мемори конечно быстрее, не юзается сетевой интерфейс, тут проблема будет в паралельности, блокировках и прочем, на типовой УПП не взлетит впринципе такая нагрузка, хоть в 2 раза лучше железо купи, надо логику переписывать там

(44) насчет ядер на процесс.. дадад.)

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

(44)   Maxus43

процес то один и у например SQL сервера, а ПОТОКОВ то МНОГО и они вполне могут быть на разных ядрах.
https://ru.wikipedia.org/wiki/Процесс_(информатика)

(46)Просто дорого. Любой очень крупный франч - центр компетенции.

(47) я про процесс 1с, он не юзает различные ядра на разные потоки процесса.
Стандартная картина на серверах: ровно 50% загружен проц - це 1с, к гадалке не ходи

(48) я бы например БИТ и близко не подпустил к такому проекту... крупнота не показатель

(49)
я кажется понятно написал
ПРОЦЕСС один... но внутри него много потоков как клиентов 1с так и служебных... потоки исполняются ПАРАЛЕЛЬНО

(48)неа 100 раз нет

закройте ветку
автор уже 2 раз на аналгичные темы по 900 постов
надрывался

v8: Полное масштабирование 1С 8.х (клиент-серверный вариант) - кому удалось, идеи? )  
v8: 1с 8.х от чего зависит скорость  и Миф о многопроцессорных/многоядерных серверах

(51)можно нескромный вопрос?это теория или практика.кроме ссылок на вики

(54) практика

(51) ты теорию написал, а приложение должно поддерживать работу с несколькими процессорами-ядрами, 1с не поддерживает

(56)    Maxus43
вы про ПОТОКИ кода нибудь читали?

ЕСЛИ в 1с всего 1 процесс, ты не загрузишь им больше ОДНОГО ядра, это практика, а не теоритические статьи из начальной информатики. Операционка не будет сама распределять, если в программном обеспечении не заложено

(57) читал. Нагрузи мне одним процессом 1с больше одного ядра.

(59) мы про процесс "сервера 1с" ГОВОРИМ?

(60) конечно, но тут без разницы.
процесс rphost (в диспетчере) это и есть процесс сервера 1с, и он работает только с одним ядром

(59) Maxus43
"Стандартный нагрузочный тест 1С"
ЛИЧНО проводил тест в Односерверной системе
принудительно ограничивал SQL по ядрам,

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

на сервере где крутился "Сервер 1С" все ядра были загружены под 90%

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

так что 20% ПРЕДЕЛ ПРЕДЕЛОВ

(61) Ничего подобного, процесс rphost многопоточный, иначе многопользовательская работа была бы практически невозможна. Это клиентская 1C.exe многопоточная, но программист 1С работает только в одном потоке.

(64) +

мда. поичтал предыдущие ветки автора, и последние тут посты, бесполезный разговор грядёт на 1000 постов...
(64) тут надо сделать оговорку всё таки. 1с псевдомногопоточная. Каждый сеанс(соединение) может работать только в одном процессе и с одним ядром процессора, другие сеансы в других процессах и с другими ядрами

(63)
смотрят СИСАДМИНЫ на загрузку сети 20% и загрузку ядер серверов в 50%
и радуются мы все сделали ресурсов железа хватает.

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

ТУПО!!!!

на самом деле "Сервер 1С" и "SQL" получается друг друга ждут вот и низкая загрузка CPU))

(66)" Каждый сеанс(соединение) может работать только в одном процессе и с одним ядром процессора" глупость

дело в таких больших системах не в процессорных мощностях, а в конкуренции юзеров за ресурсы СУБД, блокировках и т.д.

(68) давай, просвяти глупых, может в рай попадёшь за благие дела

(69)
а вы читали https://ru.wikipedia.org/wiki/ORM

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

уперлись рогом в реляционный  SQL  что все дело только в нем))

кстати ГДЕ голосование ?

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

Голосуем!!!

(70) Maxus43
внизу и справа веб страничики есть))

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

Обоснуйте свой выбор!

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

ИМХО, чем меньше сетевых соединений и, соответственно, задержек по передаче данных, тем лучше.

(71) чего сказать то хотел? 1с говно?
(72) учи в другом месте,  например в Алтайском государственном техническом университете им.И.И.Ползунова

на 1000 юзеров УПП не взлетит без допила, надо ERP брать. ну а так - работать и так и так будет, но на одном 16ядреном серваке в 100 потоков показывает немного лучший результат, чем на двух.

(75)
(70) Maxus43
внизу и справа веб страничики есть))

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

Обоснуйте свой выбор!

(76) Fragster

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

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

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

На практике

(79)
маловато обосновано однако)) ну да ладно

(78) сделай себе красивые графики с помощью http://infostart.ru/public/173394/ (будешь увеличивать количество потоков или как-то по другому менять алгоритмы, пожалуйста не выгружай результаты в сеть)

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

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



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

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

(83) ключевой слово РИБ,
ну не умеет 1С работать с несколькими сиквалами и бысто деградирует под нагрузкой

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

пока 1С эту часть архитектуры не изменит ни какие кластеры серверов транзакций не помогут

(84) а что такого плохого в проведении? то, что еще парочка таблиц апдейтятся? ну, если совсем тяжело и вы 80-го года доки перепроводите пачками - ну установите вы период рассчитанных итогов на это время и оставьте текущие итоги - будет ровно то же, что в "ынтырпрайзных" даксах по количеству апдейтов, а вот когда вам остатки нужно будет на предыдущий период получить - вот тогда вы табличке итогов скажете спасибо. а при неопреативном проведении даже за пару лет назад (х24 строки апдейтятся) ничего прямо катастрофического нет.

(0)Взлетит.
По принципу - разделяй и властвуй.
Короче серверов побольше, и базу аккуратно делишь между серверами.

(85) ох мне эти сказочники, ты готов заставить типовой документ(РТиУ под партионкой с оперативным зачетом аванса) в УПП проводиться за 0.1 секунды ?

а записывается он именно за такое время

SGI = Silicon Graphics?

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

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

(88) я видел >500 юзеров на одном сервере 1с + 1 сервере мсскуля (что-то типа 32 ядер там было на каждом). А на оракле может быть опасно из-за ошибок платформы в работе с этим самым ораклом

(89) тут Вячеслав вам в помощь. Моментов там есть, но вроде как всё решаемо. Конечно нужен грамотный ораклоадмин.

Тестировали 1С с разными базоводами... если нужна производительность при >100 юзеров - однозначно оракл.

в смысле не я лично а статью читал

(90) пару разработок для Вячеслава делал я, только тсссс ;)

(92) примерно год назад на сходке ораклистов главный от оракла по сибири рассказывал как он ускорил раз в 6 сальдооборотную ведомость на демобазе УПП... есть моменты...

(92) конфы? Так вот значит один из маньяков пишуших конфы где 10% кода попытка - исключение!!!

(80) Что тут обосновывать? это было бы сумасшедствие несколько тысяч засовывать на один сервак, в общем 50 серваков (баз) лучше одного

(81) А смысл в этой поделке если есть ТесЦентр?

(90) Оракл явно проигрывает

(93) Вот вот и только в этом случае оракле приблизится к мс скл.

(0) Ну и нахрена это все, когда:
http://v8.1c.ru/expert/cts/cts-202-010.htm
http://v8.1c.ru/expert/cts/cts-218-001.htm

(97) то-то у последнего сиквела дали возможность ему становиться версионников... то что у оракла всегда было нативно

+ (100) хотя конечно если ты не слышал про управляемые блокировки...

кластер sql повышает только отказоустойчивость. но не производительность. это надо знать, прежде чем проектировать систему.

Во-первых, надо сделать пул терминальных серверов. Как он там называется сейчас - ферма вроде.

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

Думаю важно не выбор железа а надо писать свое УПП не подойдет.

**Думаю важно не выбор железа а надо писать свое, УПП не подойдет.

(0) условия гипотетические, тест гуано. "Везде SSD диски" - вообще ни о чем, райды какие?

радует что большинство таки понимает, что

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

А также есть понимание, что задержки в коммуникации между SQL и "Сервер 1С" - тоже НЕ приводят к "Скорости работы" платформы))

(106)
про RAID и SSD -- как это не странно в нем(кроме RAID 0 ) кое-какие характеристики по задержкам ухудшаются по сравнению с Одиночным SSD/

про оптимизацию конфигурации под НАПРИМЕР MS SQL:

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

Суть в том что такое решение становится
1)Очень МЕДЛЕННО в скорости разработки
2)менее гибко
3)зависимо от "первоночального разраба оптимизатора"
4)....... и т.д.

т.е.
1) Экономически более оправдано собрать аппаратно-программный комплекс заточенный на поддержку "Объектного подхода",
чем
2)бесконечная "дойная корова" для спецов "Реляционного подхода"....
----------------------------------
Это конечно со стороны "Заказчика"... )))