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

1) Ставим "сервер 1С" и "SQL" на одном физическом сервере

т.к. фактически "сервер 1С" = "Объектная СУБД", то
критична скорость обмена между Двумя СУБД
"SQL реляционная СУБД" <--->"Сервер 1С Объектная СУБД"

Не целесообразно разделять эти две СУБД сетью Ethernet Gigabit - предоставляющую в данном случае для обмена максимум 30 Мегабайт/сек
рисунок
http://s51.radikal.ru/i133/1211/40/ee298116320f.jpg
-------------------------------------------
2)Для этих двух СУБД Критична скорость операций Ввода/Вывода с Оперативной памятью, на что непосредственно влияют:
- Частоты ядер CPU -чем больше тем лучше
- реализация контроллера доступа к памяти
- Количество конкурирующих за доступ к Памяти - процессоров/ядер - чем больше тем больше конкуренция и тем хуже ситуация.

Частично решить проблему можно использованием технологии NUMA-узлов (для чего нужна OS и процессоры поддерживающие данную технологию)
рисунок
http://s018.radikal.ru/i528/1211/b7/e87d32cfb458.jpg
------------------------------------------
3)Также критичны операции Ввода/Вывода с Дисковой системой.

На текущий момент можно решить использованием SSD -дисков(или RAID массивов SSD дисков)
Надежность и стабильность работы SSD можно поднять - используя не весь объем диска.

пример(поднятие надежности Десктопного SSD до уровня Серверного SSD):

Если  к примеру, SSD Intel 520 series 120GB, и разметить 81 GB, а остальное пространство оставить не размеченным -
то под over provisioning будет выделено около 32% пространства SSD дополнительно к уже имеющимся скрытым 8%. Итого получаем около 40%
Отличие серверного SSD Intel 710 series от десктопного SSD Intel 320 series как раз и составляет разница в over provisioning: более 40% для Intel 710 и 8% Intel 320.
----------------------------------------
4) В случае использования "Толстого клиента 1С" - необходим отдельный "Терминальный сервер" - также отвечающий Всем вышеописанным пунктам.
----------------------------------------------

Не забываем что "Сервер 1С" - это фактически надстройка = "Объектная СУБ" - над "SQL - реляционной СУБД"
(SQL - хранит плоскую проекцию Многомерных Объектов в нескольких таблицах)
и следовательно "Классические методы" определения узких мест для "Классической клиент-серверной реализации с реляционной СУБД" - здесь мало применимы.

Остается наедятся что разработчики платформы либо разработают Свою "ПОЛНОЦЕННУЮ ОБЪЕКТНУЮ СУБД" - без использования внешних "Реляционных СУБД"
либо
включат поддержку "Внешних Объектных СУБД"
(например "Кэше" http://lusindane.at.tut.by/files/object00.html)

Вы хотите поговорить об этом?;)

)
я обещал через месяц вернуться к этому вопросу))
вот вернулся))

Ставим "сервер 1С" и "SQL" на одном физическом сервере

Емнип, в общем случае рекомендация обратная.

"Классические методы" определения узких мест для "Классической клиент-серверной реализации с реляционной СУБД" - здесь мало применимы.

я вам обосновал?))

(0) Э... Застрял на фразе "Не целесообразно разделять эти две СУБД"... Откуда две СУБД???

(5) Выше "т.к. фактически "сервер 1С" = "Объектная СУБД", " конец цитаты.

Автор, что сказать то хотел? Сервер покупать собрался, или так, просто теоретик?

практик

насчет первого пункта условие
1) если важнее устойчивость, то разносить
2) если важнее производительность на одном
если нужно и то и другое вот тут пусто.
Кстати на тренинге в прошлом году Рупасов упоминал о тенденции писать собственные субд под конкретно свои задачи (гугел), на вопрос что 1с нужно написать свою субд ответил что пока ничего не может сказать, это слишком далекая перспектива.

(9)krbIso
"1) если важнее устойчивость, то разносить"

смысла не имеет на сложных Конфигурациях

т.к. производительность падает в разы, а в некоторых случаях даже в десятки раз.

1 гигабит насегодня смешно.
40 гигабит  сетевой интерфейс за бугром можно купить 500-800
долларов за пару

(11) 40 гигабит - это 40 гигагерц минимум частоты сигнала.
Это хорошая, веселая штука в офис приедет.
Можно посмотреть характеристики?

(10) заказчику виднее что ему нужно, стабильное 24x7 или скорость, говорю же условие.
(11) хоть 100gb, скорость ниже не из за ширины. У нас 10Gb к примеру, рачет себестомости 3 часа (канал свободен,все летает со свистом), а если запускать на одном сервере то 40 минут.

(12)
http://www.ixbt.com/news/hard/index.shtml?15/13/34

(14) Аааа, оптика, чето я сразу недогнал.

(13)  krbIso
Етит налево я кому картику про латентность Ethernet в (0) вставлял?
http://s51.radikal.ru/i133/1211/40/ee298116320f.jpg

у 10 Ethernet Gigabit болезнь наследственная))

Мы по другому пути пошли. Сделали синхронный кластер СУБД который можно масштабировать на много MS SQL серверов. В линейной скорости проигрывает - но зато в масштабировании выигрывает. Ставить можно будет не только на MSSQL ентерпрайс а к примеру на стандарт. Учитывая сколько стоит ентерпрайс 2012 за счет стоимости ПО можно много сэкономить.

(17) МуМу
1)ну дык это ГОРИЗОНТАЛЬНОЕ масштабирование
(нет просадки при увеличении количества пользователей, но нет и большой производительности на Одном пользователе) . ))

а моей конторе нужно ПОЛНОЕ масштабирование (((
(т.е. + большая производительность)
а технологий под такое нет((

(18) Никто не мешает одну из нод совместить с сервером приложением. Затем задачи требующие высокой производительности(например востановление последовательности) выполнять в асинхронном режиме.(при этом остальные ноды будут недоступны пока не донакатятся данные). Т.е. есть возможность управлять этой архитектурой. Но полностью универсальное и эффективное решение теоретически сделать невозможно.

(18) У нас тесты на нужном оборудовании(10GB,40GB, инфинибанд) будут только через месяц. Пока нет доступа к нужному оборудованию. Хотя по инфинибанд провели тесты, предварительно очень неплохо(минимальная просадка по сравнению с локальным размещением). Но есть подозрение на то что серваки были слабоваты. Будем заново проводить.

(20) МуМу
кстати вы писали что драйвер нужно писать для IB под 1с 8.2, а что дравер программной реализации IP поверх IB - не подходит? (минус конечно т.к. грузит CPU, но драйвер таки уже давно существует)

>предварительно очень неплохо(минимальная просадка по
>сравнению с локальным размещением)

И опять таки вы делали тест ЧИСТО SQL, без "Сервера 1С"?

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

(16) ну дык я про это и говорил (11)ому

(23) krbIso
тогды пордон за "наезд" ))

Вот кстати официальное подтверждение Моего мнения))

".... Она напоминает написание приложений объектных БД,
с той лишь разницей, что сохранение данных происходит в таблицах реляционной СУБД...."
http://v8.1c.ru/metod/architecture/

Ну не чушь ли использовать "реляционную СУБД" ?

разрабы платформы как всегда жгут по полной))

(25)
предложите здесь аналог реляционной бд.

(26) МихаилМ
Накой аналог реляционной БД?

нужна Объектная БД

+ к(27)
например "Кэше" поддерживает и ОБЪЕКТНЫЙ и РЕЛЯЦИЛННЫЙ доступ к одним и тем же данным
http://lusindane.at.tut.by/files/object00.html)

реляционный очепятка))

(18) ты какую задачу решить хочешь?

(30) Demiurg
я хочу комплексное решение класса близкого к ERP в единой БД на основе 1с (на данный момент дорабатываем УПП - скоро уже как 2 года будет)) ).

Но если использовать текущую реализацию движка 1с -
НЕ СУЩЕСТВУЕТ аппаратного решения - для реального ПОЛНОГО масштабирования.

1)Либо выбираем скорость (все на одном сервере) - но ограничение по пользователям,

2)Либо опускаем под плинтус производительность разнесением на разные сервера - но увеличиваем количество юзеров.

(25) Я сейчас приведу аргумент, на который, уверен, вам нечего будет ответить.

Если взять типовые конфигурации (которых в эксплуатации подавляющее большинство), то в них бизнес логика размазана между 1С кодом и SQL запросами. Причем запросами часто не тривиальными: многочисленные джойны, группировки, агрегация, TOP N, временные таблицы и т.д. То есть функционал типовых во многом полагается на мощь реляционных СУБД. Почему? Как раз для достижения требуемой производительности. Так что это не "чушь", а осознанный архитектурный выбор.

Объектные БД всего этого не умеют. Зато умеют многое другое. То есть для решения тех же типовых задач (и достижения той же производительности) нужно использовать существенно другие средства. Что означает переписать 50-60% кода типовых. Надеюсь, уже понятно, что это тупиковый путь?

(31)
вот масштабируемое решение
http://www.tiger-optics.ru/products/seamicro/

(32)mistеr
>..то в них бизнес логика размазана между 1С кодом и SQL
>запросами ...
1)Как раз не SQL  запросами - а "1С -объектными запросами"
- в процессе исполнения которых как раз происходит сборка из "плоского" представления запросами SQL -> в "Сервер 1С" - и уже далее непосредственно обработка.

>то означает переписать 50-60% кода типовых
2)не означает (см пункт 1)),
хотя при использовании ООСУБД -  можно и переписать- что сократит код.

Незабываем также что "1С-запросы" - это только ЧТЕНИЕ/ВЫБОРКИ... а никак не INSERT и т.д.

(33)МихаилМ
1)ну во первых Частоты ядер процов если Intel 4 ядра,то 2.4

этого маловато в расчете на 1-ин поток (один поток это Атомарная единица - нельзя его рапараллелить на несколько ядер)

2)пока мало понятно что это Вообще))
- то-ли Сборка Кластеров в одном корпусе
- то-ли Отдельные сервера в Одном корпусе

- а ВОТ если это что-то ти-по NUMAlink (объединение всех процессоров в Единый компьютер - с возможностью установки Одной операционки Видящей все эти процессоры) - тогда да это решение подходит под нашу проблему). - НО боюсь тогда цена вопроса даже не десятки миллионов)))

(32) >Как раз не SQL  запросами - а "1С -объектными запросами"
Эту надстройку я сейчас не беру в расчет. По сути это "синтаксический сахар" - объектная таблица вместо кучи view. А по сути это обычный SQL.

>в "Сервер 1С" - и уже далее непосредственно обработка.
Вы может плохо знакомы с типовыми. Я говорю о том, что обработка происходит как раз в запросе, то есть на SQL сервере.

>хотя при использовании ООСУБД -  можно и переписать- что сократит код.
Теоретически можно, а практически вы себе представляете объем человеко-часов?

mistеr
>"А по сути это обычный SQL."

только по синтаксису похож(что таки обманывает при первоначальном взгляде на код запроса), но реализация обработки такого "1С запроса":

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

2)- запрос выполняется на SQL сервере , а потом ПОСТ обработка результата на "Сервере 1С".

- и говорить что такой запрос обрабатывается ТОЛЬКО на "SQL -сервере" - не верно.

Фактически постоянная Сборка-Расборка объектов из Реляционного вида в Объектный и обратные операции.

(35)
по п 1)
не сргласен, учитывая что процессоров (ядер,и это ядра sandy bridge) по 256 (данные 2011 г).  
а учитывая, что сиамикро куплена амд то возможно и больше в разы (но амд шных)
 
по п 2.

учитвая
"комплексное решение класса близкого к ERP в единой БД"
,
- универсальность - враг призводительносьти и всегда дорого.
и стремтся к деградации те распаду на специальные решения.

например oltp+ бд рабочих групп + olap  

миф - что поддержка единой бд проще чем несколько специализированных.


цены в России на продукцию сиамикро не знаю. но в штатах в 2011 от 50 000, что
в разы дешевле аналогов хп,айбим,сан.

mistеr (36)
специально для вас что такое ORM ))
wiki:ORM
"Сервер 1С" -как раз такая Объектная ORM надстройка над реляционными СУБД

(38) МихаилМ
>миф - что поддержка единой бд проще чем несколько
>специализированных.

У меня противоположное мнение,

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

(33) МихаилМ
>вот масштабируемое решение
>http://www.tiger-optics.ru/products/seamicro/

не взлетит наверное в случае с "SQL"<--->"Сервер 1С" )).

это всего лишь ОТДЕЛЬНЫЕ Десятки серверов в одном корпусе....(каждый со своей OS - что добавляет Задержки)

>связанные Freedom Supercompute Fabric, которая связывает эти
>компактные, энергоэффективные системные платы между собой,
>обеспечивая

>рекордную пропускную способность в 1,28 терабит в секунду.

Вот интересно чего пропускную способность? Суммарный трафик при обмене БОЛЬШИМИ ПАКЕТАМИ инфы между серверами?

т.к. из описания я понял что там Ethernet - то полная хрень будет при обмене малыми пакетами

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

(39) Я в курсе что такое ORM и я согласен, что ORM в 1С имеется. Я о другом говорю, о бизнес логике. Рельную работу выполнятет СУБД, а не ORM.

(41)
читайте на сайте производителя.

(42) mistеr
>Реальную работу выполняет СУБД, а не ORM
)) улыбнуло

это ваше "Политическое убеждение" или в случае с "Сервером 1С" - подтверждено на практике?

Я могу привести один из примеров ПРАКТИКИ))
1)Мы брали сервер с двумя NUMA-узлами - определяли - "MS-SQL" на один NUMA-узел, а "Сервер 1с" на другой NUMA

2)Запускали в базе 1с УПП - проведение док "Расчет себестоимости"

3) так вот картина была следующая когда идет нагрузка на NUMA0 - то практически нет нагрузки на NUMA1 - и наоборот.

-при этом поочередно нагрузка менялась местами примерно кажды 5-8 минут

- при этом на NUMA - где был "Сервер 1С" - нагрузка была в момент активности процентов на 10-15 больше

>Реальную работу выполняет СУБД, а не ORM
в случае с "Сервером 1С" - таки дума в корне не верно))

реальность такова что в НАШЕМ случае взаимодействуют ДВЕ СУБД

"Реляционная СУБД" <---->"Объектная СУБД"

и бизнес логика как раз в "Объектной СУБД", а "Реляционная СУБД" - используется как Хранилище информации

(43)МихаилМ

Базовая конфигурация SM15000 с 64 процессорами Opteron, с базовой оперативной памятью, восемью дисками и шестнадцатью каналами Gigabit Ethernet

без корпуса стоит $139000. ~ 44 миллиона руб. нда...
http://www.servernews.ru/tags/SeaMicro

(44) >Запускали в базе 1с УПП - проведение док "Расчет себестоимости"
Да, РС имеет специфику. Там действительно расчетов много.

>так вот картина была следующая когда идет нагрузка на NUMA0 - то практически нет нагрузки на NUMA1 - и наоборот.
Это обычное дело, и не только с 1С. Подготовка данных, расчеты, запись, новая порция данных и спова по кругу.

Если у вас задачи похожи на РС, вам NUMA архитектура получается не выгодна - ресурсы будут простаивать.

(46)

ошиблись в 10 раз.  $139000 ~ 4,4 миллиона руб

да)) 4.4

(47) mistеr
это был частный случай с РС в УПП))

пример 2.
1)Запускаем групповое проведение документов Реализация.
2)Эту операцию запускаем одновременно на нескольких компах.

-И видим что на NUMA-где "Сервер 1С" - стабильно все ядра загружены под завязку все время))
- а NUMA где SQL - в это время загрузка незначительна

ИМХО это свидетельствует, что обработка блокировок тоже происходит в основном на "Сервере 1с", а не только обработка бизнес логики ))

(50) Как то у вас все сбивчиво в логике обоснований. Раз уж столько времени потратили, привели бы цифры и условия проведенных экспериментов. В конце концов дали бы терминальный доступ к серверам -  наши люди провели ряд тестов и оформили. Я к примеру выложить смогу результаты исследований не раньше нового года.(ждем соответсвующее оборудование)

(51) МуМу
>В конце концов дали бы терминальный доступ к серверам -  наши
>люди провели ряд тестов и оформили.

из вне - точно не будет доступа))
у нас VPN доступ, даже прогерам Холдинга, дают - только если минимум год в конторе проработал(и то решение долго ходит по инстанциям).

ЦИФРЫ - есть в моей публикации на Инфостарте - не все конечно и раскиданы по комментариям к теме.

Можно конечно собрать все в кучу - долго однако собирать если подробно описывать)). Это уже подобно дипломной работе объем будет.

Сама суть есть в (0).

Тогда опять покритикую(0).
1) Здесь необходимо указать количество обращений к СУБД. Я видел качественно написанные самописки которые обладают относительно небольшим количеством обращений к СУБД. Соответсвенно для таких конфигураций этот пункт не имеет смысла. Если принебречь временем отклика сети при малом количестве обращений к СУБД то выделенный сервер СУБД это всегда надежней. Да и дешевле получится для высоконагруженных систем.Опять таки не хватает примера спецификаций, стоимости серверов и лицензий.
2) Это утверждение сложно опровергнуть, чем больше частота ЦПУ, памяти тем лучше для ИТ-ов. Вопрос насколько это нужно бизнесу? Для этого опять необходимо смотреть сравнение спецификаций и их стоимость. Насчет вреда конкурирующих за доступ к памяти процессоров -  спорное утверждение. Уверен что ваши тесты не заточены под РЕАЛЬНУЮ по нагрузке и спектру многопоточность. Для линейных,массовых обработок это утверждение отчасти верно.
3)Опять таки, дисковая система действительно важна. Есть разные подходы. Только что то я мало знаю продакшн систем работающих на SSD. Точнее у всех знакомых DBA работающих в крупных компаниях ни у кого эта технология не используется. Да, ее рассматривают как вариант но только с совокупностью системы синхронного резервирования. А это совсем не простая задача. Я могу сказать что в банковской деятельности к примеру это точно не взлетит. Да и в любом другом бизнесе где нужно гарантировать 100% сохранности транзакций. Хотя для большинства торговых и финансовых систем подобный подход применить можно , гарантирую при этом высокую надежность систем резервирования(хотя бы не синхронной, например логшиппинг,бэкапы)
4)А вот для терминала надежность дейтсвительно не так важна, если их несколько серверов. Здесь можно применять SSD.А вот насчет утверждения "соответствующий всем вышеописанным пунктам" - неверное утверждение. Специфика обращения к памяти терминальных серверов принципиально отличается от специфики обращений MSSQL.

+(53). Дополнение к пункту(3) SSD можно использовать для tempdb , при этом понимая что на надежность сохранения данных это не влияет но может повлиять на простои. То есть потенциально нужно иметь диски на замену. С точки зрения производительности 1С конечно дает эффект их использования для tempdb. Так как большой процент работы с дисками завязан на использования временных таблиц.

>> т.к. фактически "сервер 1С" = "Объектная СУБД"
дальше можно не читать

(55) Федя Тяпкин
>дальше можно не читать

чуть больше чем "полностью Деревянным" - конечно дальше можно не читать))

(53) МуМу
я не спорю ЕСТЬ самописки ... и проче и прочее..

Но более менее Сложные конфигурации - ведудут себя именно так как я описывал.

>Если принебречь временем отклика сети при малом количестве
>обращений к СУБД то выделенный сервер СУБД это всегда
>надежней

1)а вот не надо  ПРЕНЕБРЕГАТЬ..,

2)
- а в случае малых обращений к СУБД  - это вообще что тупо СПРАВОЧНАЯ конфа - с минимумом бизнес-логики?(я сам писал подобные),
- можно вообще ВСЮ бизнес-логику на "чистом SQL" писать, но нафига тогда нам 1С (притом что очень сложно такое писать и поддерживать)?

3) а если хотите повышение надежности КЛАСТЕРЕЗУЙТЕ приложения  например средствами OS))

(57)"Кластеризуйте средствами OS" - Вы сами себе протеворечите!
Средствами ОС можно делать кластер с единым(с одним общим) дисковым хранилищем. Надежность такого кластера будет равна надежности самого слабого звена. В данном случае SSD дисков.  Что бы повысить надежность нужна уже другая кластеризация(межсерверная) а это не всегда тривиальная задача.

>Средствами ОС можно делать кластер с единым(с одним общим)
>дисковым хранилищем
да, это так

>Надежность такого кластера будет равна надежности самого
>слабого звена. В данном случае SSD дисков
нет,
1)это не так в том случае если вы сравниваете СЕРВЕРНЫЕ SSD c СЕРВЕРНЫМИ механическими дисками.

2)Никто не мешает использовать например зеркальные массивы из нескольких "Внешних Дисковых массивов"(внутри каждого тоже RAID)
- такое решение гораздо проще и НАДЕЖНЕЕ - чем организация  "уже другой кластеризации(межсерверной)- ... не всегда тривиальной задачи."

(59) По первому пункту. Я исхожу из простых фактов что пока это на больших системах никто не использует. Если вы решились - хорошо расскажете через полгода;)
По второму - вы знаете досканально как работают рейд масивы и за счет чего  вообще возможно ускорение на дисковых масивах?Для чего нужны дисковые контроллеры? Если да то ваш совет про использование нескольких дисковых масивов различных по скорости явно не в тему.

(60) А вообще очень много теоретических выкладок не подтвержденных практикой. При этом в теории есть тоже пробелы. Задумайтесь - почему в дисковых масивах и рейдах всегда один и те же диски с одной и той же скоростью? Этому есть простое объяснение.

где я советовал "про использование нескольких дисковых масивов различных по скорости" ?

моя в шоке))

"про ускорение работы в случае RAID массивов" :

- отметём сразу RAID0 - такое на сервер БД  таки не надо))

- в случае других типов RAID -всегда есть Штраф на запись, и в зависимости от типа еще меняется Штраф на чтение

например RAID10 (4 шт дисков) - Штраф на запись =2 => Скорость операций(IOPS) = 4/2 = 2 * IOPS единичного диска

(62)Где советовали? - (59)"Никто не мешает использовать например зеркальные массивы из нескольких "Внешних Дисковых массивов"(внутри каждого тоже RAID)
- такое решение гораздо проще и НАДЕЖНЕЕ " Была такая фраза в разрезе обсуждения надежности SSD.
Как извините ее трактовать?

+(63) Вы пишите умные термины и т.п. Я готов объяснить просто на пальцах руки. На дисках уже давным давно не удается повысить скорость оборота и соответсвенно скорость обращения к информации. Поэтому давным давно уже для ускорения используется параллелизм. Когда писаться и читаться информация может параллельно с разных физических носителей. В кеше контроллера может происходить предварительная обработка за счет чего происходит существенное ускорение. Но принципы транзакционной целостности остаются теми же самимы. Если вы каким то боком ставите в рейд SSD диск то вы автоматом понижаете надежность системы. Если вы ставите его в райд зеркалку - вы понижаете производительность. Отсюда вывод, SSD можно использовать только для логических устройств в которых не страшно потерять информацию. Самый лучший пример это использование для tempdb в MSSQL. Другой пример - я дома на нем держу только операционку. Полетит - и фиг с ним, образ востановлю. Зато - быстро грузит.

(64) используем SSD на очень крупном проекте. давно. все довольны. что мы делаем не так.

заодно спрошу что делает не так EMC  в кларионе? :)

(65) Значит это первый большой проект о котором я услышал что он работает на SSD. Правда теперь ньюансы. Как я уже писал использовать SSD для tempdb не только можно но и нужно.(что бы не было больших простоев нужно иметь запасные). Каким образом вы его там используете? Используете ли его для хранения базы данных либо хранения транзакшион лога? Для клиента критична потеря нескольких транзакций?(бывают которым не особо важно). Сколько по времени он уже работает на продакшн системе?

(0)это много умных букав обоснование сервака за лям баксов и оправдание неспособности настроить его одновременно?

+(67)Можно название(спецификацию) модели назвать?

(69) на таких масштабах любые технические подробности могут позволить вычислить продажу у вендора, поэтому - нет )
могу сказать, что мы говорим об интерпрайз SSD с большим 100 000 $ ценнике
в продакшане достаточно давно, лежит основная база на SSD в том числе, данные зеркалируются и бэкапятся с высокой частотой

(31) твоя проблема в том, что ты хочешь автоматизировать вселенную в одной информационной базе,
опыт показывает, что разные люди выполняют РАЗНУЮ работу, даже если она с виду похожа, заставлять базу на 100 000 сотрудников в одной базе делать работу субд по каждому сотруднику применительно к упп - это заставлять делать систему работу с противоречивыми требованиями к железу, блокировкам и т.п.

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

Уважаемые  что-то Мы скатились к обсуждению частных случаев))

1)УПП в мем подразделении - это проблема моего ИТ-отдела и не будем ее больше упоминать наверное))
------------------------------------------------
2)тема же про то как Собрать Наиболее ПРОИЗВОДИТЕЛЬНЫЙ сервер - ВООБЩЕ под платформу 1с 8.х (клиент-серверный режим)
-------------------------------------------------
3)Думаю все согласны что описание в (0) - позволит собрать НАИБОЛЕЕ ПРОИЗВОДИТЕЛЬНУЮ систему на основе 1с 8.х (клиент-серверный режим)?
----------------------------------------------------
4)Обеспечение НАДЕЖНОСТИ - это уже следующий вопрос, и наверное нужна таки отдельная тема.

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

(73) Сферический сервер в вакууме? Имхо, когда говорится про производительный сервер, то нужно смотреть конкретику фирмы - какая конфигурация, какие основные действия. + выносить в отдельную тему надежность, имхо, недальновидно. Т.к. часто ставится вопрос компромисса между производительностью, надежностью и ценой.

Хорошо нужна конкретика -Вот такой вскоре купим сервер))

1)IBM X3650M4 -сервер

2) 2 Х Intel Xeon E5-2643
( 3.30 GHz (TB разгон до 3.5), 2x8.00 GT/s Intel® QPI)

3) RAID1 - 2 SAS диска (+3-й диск установлен как резервный)
(используется под OS)

4) RAID10 - 4 SSD (+5-й  диск установлен как резервный)
( под базы, под каталоги временных файлов, файл подкачки)

5) 8 x 8 Гб ECC DDR3 (64 Гб - с задействованными 8 каналами доступа)
--------------------------------------------------
в дальнейшем планируется
Второй такой-же для кластеризации на уровне OS
+
Внешняя дисковая полка есно.

+ к (76)
-для части сотрудников работающих в "Толстых клиентах" и для Терминалов Сбора Данных используется отдельный "Терминальный сервер"

-"Тонкие клиенты" - запускаются локально на рабочих станциях (в основном это Моноблоки с сенсорным дисплеем)

(76). Мы пошли по другому пути. Для масштабирования используем межсерверную кластеризацию. Для линейного ускорения используем набор технологий оптимизации.В том числе параллельные вычисления. В этом месяце выпустим бесплатно ПК для 1С8.х позволяющий реализовывать полноценный параллелизм при разработке.

Разумеется на железо тоже обращаем внимание. Просто бывают случаи когда одним железом ничего не решишь. Если ваша ИТ система будет успешно развиваться - вспомните мои слова через года 2,3.

(78)  МуМу
есно одним железом  ВСЕ - проблемы не решить))
но про возможности рапараллеливания Вы уже знаете мое мнение...

НО напомню еще раз ))
1) не все можно рапараллелить - "Девять одновременно забеременевших женщин - не родят Одного ребенка через месяц"

2)если параллелить путем кластерных решений - т.е. отдельные Процессы на Отдельных физических серверах - то теряется скорость из за накладных расходов на синхронизацию и задержек в коммуникационной среде

+ к (80)
Потому ничего лучше технологий типо "интерконнекта NUMAlink" - на сегодняшний день нет однако))

Ого у Вас как жарко)))
(80)
1. Если бы в новых процессорах количество ядер уменьшалось, то параллельные вычисления (далее ПВ) не надо было и рассматривать. А раз в процессорах обратное..., то и все длительные линейные операции надо по возможности приспосабливать к ПВ. Основная сложность ИМХО этой адаптации - в переписывании логики и нехватка простых средств в языках (в том числе 1С).
2. "то теряется скорость из за накладных расходов на синхронизацию и задержек в коммуникационной среде" - вот и ответ на возможность использования ПВ. Надо посчитать эту потерю и сравнить с длительностью самой операции. Рассчитать предполагаемую выгоду от этих работ.

(80) Разумеется согласен, что не все можно параллелить))

(64) "Отсюда вывод, SSD можно использовать только для логических устройств в которых не страшно потерять информацию" - шьёрт побери, на каком основании?

"1982 год — американская компания Cray представила полупроводниковый накопитель на RAM-памяти для своих суперкомпьютеров Cray-1 со скоростью 100 МБит/с и Cray X-MP со скоростью 320 МБит/с, объемом 8, 16 или 32 миллиона 64 разрядных слов"
wiki:Твердотельный_накопитель

Цитата много букв)) - "деревянным" не читать))

Но суть в том что нет эффективных математических методов для  ЭФФЕКТИВНОГО РАСПАРАЛЛЕЛИВАНИЯ задач экономико-математического характера.


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

>Для задач линейного программирования,.....
>... был разработан «симплекс-метод», который до последнего
>времени не имел никакой альтернативы по эффективности в
>применении для решения реальных задач. Но ситуация сейчас
>ситуация изменилась - про это написано уже немало статей,
>опубликовано множество выступлений на конференциях. Проблема
>с «симплекс-методом» это широко известный факт, который
>никем не оспаривается.

>Суть в том, что «симплекс-метод» имеет жёсткий предел
>масштабируемости. Скажем, если говорить о кластерной
>системе, то его масштабируемость заканчивается на уровне
>порядка 8 узлов-потоков. Сверх этого уровня начинается
>деградация, увеличение времени необходимого для просчёта,
>снижение эффективности работы алгоритма. То есть, падение
>производительности наблюдается самое непосредственное.

>Учёными было проделано множество попыток как-то
>модифицировать «симплес-метод», но в итоге, был сделан
>вывод, что «симплекс» в своей глубокой математической основе
>плохо масштабируется и никакая адаптация этого алгоритма на
>системы с массовым параллелизмом, то есть на системы с
>тысячами узлов, попросту невозможна.

>Ни у кого к сегодняшнему дню это не получилось, и думаю, уже
>не получится.

(79)МуМу
вы про "Softpoint Data Cluster – программный кластер MS SQL Server 2012 для 1С 8.2 " - все время как бы упоминаете? ))
http://www.softpoint.ru/products_id15.htm  

ну начнем про НАДЕЖНОСТЬ
1) Вылетел "Balance Cluster Sevice" - похоже все кирдык
2)Вылетел "Management Sevice" - - похоже все кирдык
---------------------
про Скорость
1) да теоритически возможно Ускорение на Чтение при отсутствии блокировок
2)Запись .... тут похоже будет просадка нехилая... синхронизации БД и прочее
-------------------------------

А теперь рассмотрим другую реализацию
1)Берем сервер с несколькими Сетевыми карточками
2)Настраиваем в MS SQL - несколько инстанций - настраиваем каждую на свой ПОРТ и с привязкой Каждой к Отдельным сетевым адаптерам(Это возможно на практике).
3) в ИДЕАЛЕ - на другом сервере (тоже несколько Сетевых карт) должно быть приложение Которое может распределять работу с SQL по нескольким портам и соответственно по нескольким Сетевым картам

//////////////////////////////////////////////////////////
Вот реализация пункта 3) для 1С 8.2 - вот это интересно.

А текущая реализация "Softpoint Data Cluster" - мне лично не интересно))

+ к (86) - притом Сетевые карты должны быть с низкой латентностью - т.е. должны обеспечивать "Большую пропускную способность - даже на малых пакетах" (среди текущих решений на основе Ethernet - что-то мне подсказывает такого нету)

(76) для временных файлов raid10 наверное перебор...
А про кластеризацию на уровне ОС можно подробнее? ОС какая (возможно, пропустил где-то)? Какая цель -- масштабирование или надежность?

(88) zlnk
>для временных файлов raid10 наверное перебор.
да там просто Корзинка на 8 дисков - куда еще темпы кидать, как не на оставшиеся 4 SSD? ))

>А про кластеризацию на уровне ОС можно подробнее? ОС какая
>(возможно, пропустил где-то)?

OS Windows 2008 R2

>Какая цель -- масштабирование
>или надежность?
Кластерными решениями нормально масштабировать 1с 8.2 не получается. (Потеря производительности при разнесении на разные серверы - я Нормальным Масштабированием НЕ СЧИТАЮ)

Следовательно моя цель надежность))

(86) А вы какую надежность имеете в виду?
Если на одном из узлов системы проблемы, то в любой схеме кердык. Другое дело, чтов нашем решении БД два экземпляра (при количестве серверов 2). Учитывая, что не нарушается транзакционная целостность - вот и обеспечивается надежность.


По поводу просадки записи - вы опять используете слова типа "похоже будет", вы ее замеряли - реально на операции изменения данных приходится до 5% нагрузки (измеряли для 1С).

По поводу вашего предложения - не увидел кто синхронизирует экземпляры БД (или вам это и не надо)))? Вы описали один из подходов, причем нашу схему решения с серверами БД вы закинули на один сервер с множеством сетевых плат. Что пытаетесь добиться при этом не понятно!!!

+ К предыдущим топикам: любые рейды и SSD диски всегда имеют, пусть и небольшую вероятность поломки. Если есть несколько экземпляров серверов (разнесенных в пространстве, то, я думаю, не у кого нет сомнения в том, что это схеме безопаснее. При всем том, что можно те же рейды и диски поставить на сервера.  

Вы точно понимаете чем отличается надежность, отказоустойчивость и распределение нагрузки?

+(90) Схему распределения нагрузки MS SQL через сетевые интерфейсы я видел у Гладченко (очень напоминает схему, приведенную автором). softNumа кажется называется, но там совсем другие цели ставились.

(91) gallam
>по поводу вашего предложения - не увидел кто синхронизирует
>экземпляры БД (или вам это и не надо)))?

1)я предлагаю "ОДНА ЕДИНАЯ БД" на внешней дисковой полке
2)"Виндовый Отказоустойчивый кластер" - при падении Одного физического сервера - приложения переезжают на другой

3)Схему распределения нагрузки одного MS SQL через сетевые интерфейсы - как применить к 1с 8.2 - не знаю))
+ еще остается проблема Низкой пропускной способности Etherneta с маленькими пакетами

+ к (92)
для "Клиентов 1с 8.2" - в том числе "толстых" проблема Ethernet -не критична по моим исследованиям))
критична между "SQL"<--->"Сервер 1С"

(92) Тогда вы говорите об отказоустойчивости, если БД одна. Проблемы надежности все равно остаются. Виндовый кластер встраиваете в наше решение - перед балансировщиком, и решается сразу 2 задачи. Отказоустойчивость и надежность. Учитывая, что для Always on вин кластер необходим, то можно:
две ноды настроить на одну БД (общую) в режиме фейловер, а остальные - по Always ON на других серверах.

По поводу связи SQL - Сервер 1С, нам удалось при использовании межсерверного взаимодействия достичь отставания от локального режима работы на 30% (учитывается только сетевое взаимодействие), если без нашего решения (стандартный Ethernet 1Гб), то отставание в 3-4 раза.

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

(94) gallam
Ваши слова "из отказоустойчивости НЕ СЛЕДУЕТ надежность"
- МОЯ В ШОКЕ...вместе со всем нашим ИТ отделом))

> достичь отставания от локального режима работы на 30%
> (учитывается только сетевое взаимодействие)

что это? ))
Давайте уже без воды.. смущает приписка в скобках))
и смущает оперирование то % то разами))

переведу уж сам Скорости по Вашей цитате
- локальный режим 100%

- ваш режим 70% - весьма неплохо
(НО ПРИ УСЛОВИИ ЕСЛИ конечно локальный режим вы запускали в Shared Memory или хотя-бы named pipe)

-стандартное разнесение по Ethernet 1Гб - от 33% до 25%

Приведите более конкретную инфу.

1)"Локальный режим" - вы имеете ввиду "SQL"+"Сервер 1с" - на одном сервере?

тогда=> 2)На сколько % - реально отстает скорость работы Одного пользователя от локального режима БЕЗ протокола TCP?

(95) Долго описывать... лучше мы статью выпустим по замерам и в ней будут цифры (что касается потерь при сетевом взаимодействии).
По поводу отказоустойчивости и надежности, можно долго рассказывать - "если много удивления", welcome на наш следующий семинар для обсуждения.
А то прочитал эту тему заново и не увидел большого смысла говорить об одном и том же бесконечно.

p.S> Сложно что-то доказывать, если человек глубоко убежден в своей единственно правильной точке зрения (это относится и ко мне)))). Но как правильное и эффективное решение - обсуждение очно, когда есть время рассказать, показать, объяснить...
Удачи

(96) gallam
оки
согласен "катаем вату"))

завершаем обсуждение.
и вам также Удачи.