Не буду описывать предысторию и проведенные тесты..
посмотреть можно тут http://infostart.ru/public/147259/
*******************************************
Выводы:
1)Производительность 1с 8.х больше всего:
- зависит от Частоты Ядра процессора
- зависит от скорости работы CPU-RAM
(кстати к MS-SQL - это тоже относится)

2) чем больше процессоров тем хуже производительность 1С -
- падает скорость работы CPU-RAM
(Два процессора связанные 2-мя QPI -предел аппаратной конфигурации)

3)Чем больше ядер в процессоре - тем ниже Частота ВСЕХ ядер и хуже производительность 1с.
***************************************
В итоге для Клиент-Серверного варианта:

1) Толстые клиенты 1C на "Терминальном сервере" - с Наибольшей скоростью Запись/Чтение оперативки + Наибольшая частота Ггц Ядер процессора

2) Тонкие клиенты 1C - уже нет особой разницы где... но желательно настроить через "HTTP://".

3) "SQL сервер" +"Сервер 1с предприятия" (в режиме Shared Memory) - на одной тачке с Наибольшей скоростью Запись/Чтение оперативки + Наибольшая частота Ггц Ядер процессора
*************************************************
Остался ОДИН невыясненный вопрос:
если ДВА одинаковых СЕРВЕРА соединить "СЕТЬЮ Infiniband"(имеющую сверх низкую латентность) и на ОДНОМ-SQL, а на ДРУГОМ(сервер 1С)  - не будет ли ПАДЕНИЯ производительности в сравнении ОДИН сервер(SQL+сервер 1).

У кого есть техническая возможность проверить..протестируйте пожалуйста!

это прорыв

Слава Гелев уже описывал это все.
К чему потуги??? Звезды понадобились, могу поделится

если ДВА одинаковых СЕРВЕРА соединить "СЕТЬЮ Infiniband"(имеющую сверх низкую латентность) и на ОДНОМ-SQL, а на ДРУГОМ(сервер 1С)  - не будет ли ПАДЕНИЯ производительности в сравнении ОДИН сервер(SQL+сервер 1).

У кого есть техническая возможность проверить..протестируйте пожалуйста!

какие звезды))

больше капс лока!

и где это все он описывал?

я только видел как он одним клиентам предлохил сверх-многопроцессорный сервак за 500 тыщ буржуйских для 1000 юзверей 1с
... который будет ЖУТКО ТОРМОЗИТЬ)))))))

(6) смешно.

как раз не смешно((

2) чем больше процессоров тем хуже производительность 1С -
- падает скорость работы CPU-RAM
(Два процессора связанные 2-мя QPI -предел аппаратной конфигурации)

короче доказывать ничего не буду...
читайте ссылку на Инфостарте.

я жду ответа
про сеть Infiniband (хотябы 40 Гбит) между двумя одинаковыми компами: на одном SQL, на другом Сервер 1с.

а в чем суть то?..

(6) он тормозит или БУДЕт тормозить (по твоему мнению)? добавляй ИМХО
как бы Гилев - заслуженный авторитет и вряд ли его решение ни на что не опирается
а на что опирается твое суждение? на догадки и тесты сферических коней в вакууме?
не бывает универсальной оптимизации: оптимизация - это всегда подстройка под конкретные условия

(8) и да, соглашусь с (6): смешно

* не с (6) а с (7)

(11) вот и я оп томже.
Я хоть и профан, однако Славины вещи по возможности читаю, что бы вот такие вот ТС мне лапшу не вешали на уши

сервер то как раз умеет многопоточность

как раз его тест и послужил основой))
тест от Гилева (конфигурация TPС_1C_GILV_A)

(15) Не умеет

(17) умеет

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

(18) Чем докажешь?

Так я в магаз, поппкорн брать? (колла у мну есть)?

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

(18) Т.е. пользователь А выполняет задачу по проведению документа. И сервер может эту задачу распаралелить?

Или максимум что он может раскидать на разные ядра 2 задачи, одну от пользователя А и вторую от пользователя Б?

(17) ты наверно не правильно понимаешь многпоточность. Это не когда проведение в несколько потоков. Нет это не про это

(19) об том и речь: "сервер то как раз умеет многопоточность" - перечитай еще раз

(11) "заслуженный авторитет" - звучит

не Путаем - Один процесс и несколько потоков самого процесса

(24)Многопото?чность — свойство платформы (например, операционной системы, виртуальной машины и т. д.) или приложения, состоящее в том, что процесс, порождённый в операционной системе, может состоять из нескольких потоков, выполняющихся «параллельно(с) wiki:%CC%ED%EE%E3%EE%EF%EE%F2%EE%F7%ED%EE%F1%F2%FC


У него псевдо потоки

распаралеливать поток - это пять

(28) что есть псевдопотоки???

(26) :-)

1С ниразу не многопоточная система. В 8.2 её сделали псевдо, но один фиг операция проведения юзает один поток

Q: ВОПРОС: Рабочй процесс 1С:Предприятие 8.1 является однопоточным приложением или многопоточным? Т.е. может ли загрузить много ядер при одном подключенном пользователе? При нескольких? А рабочий процесс 1С:Предприятие 8.2? Спасибо.
A: 1Сv8.exe и rphost.exe в версии 8.1 отъедали 1 ядро. По сколько в 8.1 соединение клиента находится жестко привязанным к рабочему процессу, то можно условно считать, что обработка клиентов 1С выполняется в рамках одного ядра. Исключение составляет СУБД, которая использует ядра не зависимо, как работает сервера 1С.

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

платформа 8.2 не реализует всех возмжностей многопоточной системы, но она существенно лучше использует возможности железа по сравнению с 8.1, в том числе и в плане параллельности.

(с) http://www.gilev.ru/1c/app/

та суть не в этом))
а то что Многопроцессорные системы - Обман.

Читайте Криса Касперски в конце концов)).

Что "серверу 1с" , что SQL - важней всего
Частота ядра + Скорость работы с Оперативкой

(33) И что тебе не понятно здесь?

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

Базван, и мне попкорну))

(36) От того что каждый сеанс может (!) (но не обязан) запускаться на отдельном ядре процессора не означает что сервер 1С многопоточная система

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

ага
и нет фундаментальной проблемы паралельной обработки

т.е.
"Девять беременных женщин - дадут Одного ребенка через месяц"

(39) И давно научились 1С в GPU запускать?

(37) Не вопрос. НО только кушать придется за тебя:)))))

про "супер крутую видео карту" чушь полная)).
под CUDA ещебы 1с затачивали угу

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

(41) мопед не мой

Я конечно профан, но на старом ноуте, Тосиба с процом Дотон с 3 метрами кеша 2 уровня 1С шушршала офигительно.

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

частота ядер а какая? ))

(43) а вот и мопед http://ithappens.ru/story/6407

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

(47) Нет, это псевдомногопоточность, или как сказал Гилев "не реализует всех возмжностей многопоточной системы"

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

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

(50) в обсуждениях есть в конце
TRITON и BIOSMART

(1) Это порыв. У вас буква лишняя.

(50)
TRITON и BIOSMART (однопроцессорные частота 3.3)
так вот они рвут Многопроцессорные и многоядерные с более низкой частотой ядер

TRITON и BIOSMART (Itel i3 по 4-ре ядра 3.3 Ггц)

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

(0) Специалист?

Или Капитан Очевидность пожаловал к нам в гости!

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

Короче
я жду ответа (может у кого есть возможность проверить)

про сеть Infiniband (хотябы 40 Гбит) между двумя одинаковыми компами: на одном SQL, на другом Сервер 1с.

Дадут ли производительность такую же как все на Одном(SQL+Сервер 1с).

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

(60)
"Все остальное воспринимаю как флуд... "

Мне их что, банить всех O_O?

(49) Бред какой-то

(61) проще забанить тс за пеар своей статьи на ис

ладно
"Имеющий глаза да прочтет, + еще имеющий мозг да поймет".

))

 H A D G E H O G s  лучше забаньте меня.
что мне подсказывает тема утопает во флуде и уже утонула.

я согласен баньте Меня, всеравно галимый флуд

ммм, интрига!
Нет уж, мучайся!

(65) ну так уйди красиво - запости анекдот про сузуки

ок, щща запостим))

Молчи ж, кума; и ты, как я, грешна,
А всякого словами разобидишь;
В чужой nuздe соломинку ты видишь,
А у себя не видишь и бревна!

(67) В статье есть годное - гипертрейдинг надо отключать!

(68) Машу каслом не испортишь.

(69) очень спорное утверждение.

(71) Пусть сервер 1С сам разбирается, че ему там распараллеливать.

(71) Ты вот эту фантастику почитал?
http://ithappens.ru/story/6407

Не юзает же 1С CUDU? И SQL вроде тоже?
Там скорее всего терминальник был.

конечно скорей всего RDP и глюк со встроенной видюхой

(73) терминалке видик вообще не нужен

(75) Что формирует изображение?

(76) видик на компе откуда подключаешься

(75) не все так гладко,
я раньше думал что и звуковая карта не нужна на сервере
чтобы нормально звук через RDP воспроизводить.
как выяснилось нужна - был проект для 1С 7.7 через RDP и нужен был звук.

(78) звук нужен а видик нет.

(73) Нет, мне такая фантастика не интересна. Я просто знаю как работает гипертрейдинг.

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

(0) по поводу производительности и эффективности 1С: поскольку разные люди из одних и тех же фактов умудряются делать взаимоисключающие/противоположные выводы (и чего только мне не приписывают), поэтому в нашей линейке http://www.gilev.ru/services/online запланирован выход "мегатеста", ориентировочно декабрь 2012-начало января 2013 года (сразу после выхода сервисов "статистика ошибок" и "блокировки"), что то сможем показать на инфостарт евент...
сейчас могу сказать, что тест будет отражать и полосу пропускания, и критичные объемы, и узкие места в железе, прошу немного потерпеть, так как наряду с новыми сервисами развиваем уже вышедшие

(0) Я ещё помню мультик про скорняка и шапочки из одной шкурки, но Intel надо развиваться и ей плевать на базы данных не поддерживающие многопоточность, а 1С всё надеется на прорыв в облачках и ей попараллельно уже давно на всё остальное.

(83) Типа Толстый клиент - нежилец?

(84) По ходу и тонкий то-же, надежда на web-клиента :) Сервеп 1С походу был признан неразвиваевым.

эт чо - раз, и мы уже на облаках??

(6) предлагаешь сервер на 1000 пользователей на одном процессоре делать? :)

(85) Кем признан?

(87) предлагаю уволить 90% дармоедов )))

(87) люди путают производительность и параллельность, для многих 1Сков это одно и тоже

Блин, жалко в Питер не попадаю.
Буду ждать 2 питерский, там вы все попадетесь

(21) Кола ... Стареешь, генерал.

Только полные утырки сравнивают последнюю версию коре-архитектуры с ксеонами семилетней давности, забывая еще и о том, что за эти годы контроллеры памяти из северного моста переползли на кристалл процессора, кэши полностью поменяли алгоритмы да и шина стала совсем другой. Оба сервера на ксеонах из исследьвания сейчас на распродажах лизингового барахла стоят около 600-700 долларов за комплек.
Исследование бессмысленно и бесполезно

та екарный бабай помешались все на параллельности.
не все можно распраллелить и есть пределы.

Фундаментальные проблемы многопроцессорных систем
http://www.insidepro.com/kk/330/330r.shtml

так в кратком изложении...
1)если Процесс А, зависит от результата процесса Б ....
2)ну "не родят Девять беременных женщин - Одного ребенка через месяц"

Касается любого ПО.

(92) есть такое

(22)А сколько в архитектуре алгоритмов 1С логических конструкций, которые могут выполнятся параллельно ??

Ну разобрать хотя бы на основе проведения расходной накладной :)

(0)Есть доля правды в твоих словах. Одинес лудше всего будет работать на адном ядре с максимально возможной частотой и самым болшим кешем.
Для на всякий случий - ИМХО.

А всем остальным, кто будет ратовать за многозадачность или многопоточность или многопроцессорность или !!! про распараллеливание процессов или потоков простой вопрос.

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

Я бы с удовольствием послушал грамотных людей.
(Тока братва без обид :))) Звучит так, как быдто я тут всех ламерами обозвал. Это не так.)
Но пример бы очень хотелось увидеть.

Пошол курить ссылки по Глеву и мегапроцессорному серверу ...
Может таки я неправ.

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

(97):DDD Нафига тогда блокировки СКЛ ??

>любая одновременная работа двух и более пользователей

Не параллелится а кешируется в собственных темпах.
А запись результатов ?

(95) ЖАлко воскресенье. А то в колу и каняка плехнуть можно :))

Щас меня клювать начнут интереснее буит ...

(98) Я не понимаю о чем ты. Например два пользователя одновременно запускают отчет.
О какой записи результатов ты говоришь?

не знаю что там ваши тесты показывают, но то что видел я навело меня на мысль:

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


соответственно в итоге сервак на коредвадуо с кучей мегагерц и  SSD работает быстрее чем какоинйть на ксеонах где мегагерц меньше и SAS стоит..

(это конечно сугубое имхо да и на пользователях порядка 20-30)

либо 100 пользователей одновременно просматривают справочник.

(100)Нифига ты увлекся, сотку пропалил :))
Ну я говорю про запись результатов работы.

Ну да, чето я погорячился ... Чтение и построение да. Пример.

Интересно (без подеба), как Одинеска будет распределять нагрузку по процессорам при множественном выполнениии отчетов именно одновременном многими пользователями ?

Передавать тупо задачи другому процу по мере загрузки одного ?

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

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

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

(104) Если бы 1С работала только на проведении, и при проведении была полная блокировка - то конечно одного процессора достаточно. Но естественно в 1С никто так не работает.

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

(107)Да, но самые затыки как раз и являются результатом проведения ...

Но вот подумалось про чтание справочника. Мы тупо крутим справочник, очень большой.
Ну предположим даже, что бы уже весь справочник имеем в памяти (ну там в таблице), так вот вопрос - будет одинеска бить таблицу на блоки (ну как чтение файлов) при чтении и потом при построении будет блоки соствлять ?

Или таки будет осуществлять последовательную выборку и строить ?

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

(109) про:Ну предположим даже, что бы уже весь справочник имеем в памяти (ну там в таблице), так вот вопрос - будет одинеска бить таблицу на блоки (ну как чтение файлов) при чтении и потом при построении будет блоки составлять ?

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

(111)Я не могу ни верить ни не верить ... Я сам плутаю в поисках истины :)

(111) мы сейчас про sql или сервер 1С?

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

(79) Оказывается нужна видюха на терминалке. Там что-то GDI связано. Писал обработку с динамической загрузкой картинок номенклатуры (табличная верстка) на обычных формах. Загружалось порядка 800 фоток. При перелистывании страниц прокруткой начинались визуальные глюки с прорисовкой. Переход на 8.2 не решил вопроса. Помогла установка нормальной видеокарты в терминальный сервер. Вот так вот.

(115) Терминальный сервер использует свою аппаратную видюху только при включенном римоут эфэкс.

Дам один "хинт", если использовать наш бесплатный сервис https://skynet.gilev.ru/hardware - мониторинга загруженности серверов и посмотреть на счетчик SQLServer:General Statistics / Processes Blocked, то по нему очень легко сделать оценку степени ухудшения параллельности работы без всяких заумных теорий и глубоких знаний: 0 - хорошо, и чем больше ненулевые значения тем хуже, при сотнях начинаются дикие тормоза - сотни тысяч - колапс практически любой системы, мы "зашили" условный  порог 8 штук, так что даже думать не надо, сервис сам скажет хорошо или плохо...

(114)Все точно.
Исходя из этого можно сделать вывод, что ожидания в очереди на исполнение или чтение БД нас не интересуют, так как этот то участок распаралелить точно нельзя :)

Тогда следует, что нас интересуют участки между ожиданиями. И нас интересует момент, когда при достижении максимальной нагрузки на один процессор или ядро, система отдает кусок исполняемого процесса (задачи) на другой(другое).

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

Вот будет так или нет ?

(116) Никак нет, сэр! Сервер 2003 без новых фишек RDP.
У меня самого никаких объяснений этому нет. Спецы говорили что про GDI. Но факт, установка видеокарты в терминальный сервер решила проблему прорисовки изображений на обычной форме 1С 8.

(118) <i>Исходя из этого можно сделать вывод, что ожидания в очереди на исполнение или чтение БД нас не интересуют, так как этот то участок распаралелить точно нельзя </i> - вот это очень спорно - надо делать "сбалансированную архитектуру хранения данных" и "сбалансированное железо", не должно быть явно узких горлышковых мест, в том числе по процам или другим ресурсам.
Вот поэтому сначала мы опубликуем сервисы для классических задач, а потом замахнемся за на те, кто еще даже не пытался решить.  В том числе выше озвученный тест. Не так много времени до декабря, так что потерпите )

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

твоя стратегия переложить на другое ядро ничто по сровнению с тем если делать много не нужной работы - рано или поздно в этом случаи все ресурсы быстро закончатся и перекладывать будет некому (впрочем "переложить на других" это главная причина большинства бед в России)

(95) Господин полковник, вас понизили? Куда звезды делись?

(122) Пропил

Языку 1С не хватает директив на подобие функционального программирования, когда конструкция языка позволяет распаралелить вычислительные процессы.

Например N! можно алгоритмизировать так:
F(N) = N * F(N-1). Процесс однопоточный.


а можно и так: определим F(N, K) = N*(N-1)*...*(N-К+1)  =  N!/(N-K)!
тогда такой алгоритм полностью загрузит все ядра:

(для четного)    F(N, 2K)   = F(N, K) * F(N-K, K)
(для нечетного)  F(N, 2К+1) = F(N, K) * F(N-K, K+1)

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

(122)Какой полковник, боец ? Он даже щас - минимум енерал-летенант :)

(118) В случае одного пользователя с существующим языком параллелится только SQL. В сервере 1С нечего параллелить.

А вот когда пользователей несколько можно параллелить и сервер.

(124) В нормальных языках - нормальные средства распараллеливания. Другое дело что нет смысла параллелить в 1С. Ибо это многопользовательская система. Тут и так куча потоков.

Распараллеливание важно в системах, где ведутся сложные расчёты, которые занимают много процессорного времени и памяти. При этом, не все задачи можно эффективно распараллелить.
Основные операции 1С выполняет с данными на сервере, причём к большей части данных требуется или монопольный доступ или последовательное изменение. Конечно, разные пользователи могут писать в разные части базы, но в одно и то же место может писать только один. Создание нескольких рабочих потоков для одного пользователя приведёт к возрастанию числа блокировок, что может сказаться отрицательно на скорости работы всей системы, хотя, при определённом старании можно бы было проводить документ с одновременной записью во все регистры, а не в каждый по отдельности.
P.S. в некоторых случаях, при работе с базой данных оказываться, что когда с ней работает только один процесс, то он выполняет операции быстро и без блокировок, а все остальные только готовят для него данные.

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

(130) Простите, великий, ваше сияние слепит. Можно сделать поменьше?

(131) это вопрос восприятие написанного, регулятор яркости у тебя в голове :)

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

(133) да, мы так и делали, правда через шедулер винды

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

(135) такое тоже воспроизводили?.. если я не ошибаюс то УФ по сути уже это и есть, нет?

(130)1С-кам, которые не понимают преимуществ асинхронности фоновых заданий, в руки вообще ничего нельзя давать. :)

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

(114) "это кстати одна из причин, почему 1С последнее время рекомендует 1 процесс"

А можно ссылочку на общедоступный источник?

Странная ветка.
Параллельность в 1С и сейчас работает замечательно. Два юзера запускают отчет - два одновременных запроса к СУБД.
Сервер 1С всего лишь отправляет запросы к СУБД. Его роль сильно переоценивают.
В результате всё упирается:
1) В кривые алгоритмы программистов конфигураций
2) В скорость работы СУБД

Если и говорить о железе и влиянии на производительность, то думать надо в первую очередь о СУБД, а не о "сервере 1С".

(128) А как бороться с многочасовыми закрытиями месяца и с восстановлением последовательности? Маштабируемость - это хорошо, но нужно также сокращать время транзакции. Через несколько лет 128-ми ядерные и более процессоры будут в порядке вещей на десктопных бухгалтерских компах, и без технологий распаралеливаная 1С будет в глубокой жпо

Вон (83) -сказал, что будет и я ему почему то верю.

Вполне возможно, что не будет у 1С клиента ни многоядерного (многопотокового), ни 64-х разрядного. Ни толстого ни тонкого. Делайте все на сервере, господа!

(139) Ну как бы слабо серверу 1С при проведении реализации отправить паралельно сразу несколько запросов к СУБД по разным несвязанными участкам учета: партии БУ, Партии НУ, взаиморасчеты, НДС?

(139)ptiz "Сервер 1С всего лишь отправляет запросы к СУБД"

ага ага.. если бы все было так НАКОЙ он нужен?))

(141) (83) вот чего понять не могу, так почему "параллельность железа" ассоциируют с количеством ядер процессора, как будто это узкое место.
Наша практика показывает, что гораздо чаще узким местом являет ся недостаточное количество тех же дисков. Очень на 40ядерный сервак покупается всего 16-20 дисков, хотя если кто помнит, еще в лохматые 90е фирма  IBM опубликовала исследования, где опуская подробности на одно ядро нужен минимум 1 диск и еще 1 диск в зеркало ему (и это минимум). Другими словами 40ядерную железку нужен 80 дисковый массив.
Уж молчу что узким местом могут быть и другие компоненты. Так что сводить все к тому что просто 1С не очень юзает ядра - очень соблазнительная, но совершенная неправильная позиция ИМХО конечно...

(140) Скорее всего у пользователей будут тонкие клиенты, а приложения будут исполняться в облаке на виртуальных серверах. Облако локальное или глобальное. imho ))

(101) соглашусь с Алексеем: скорость сервера 1с (да и клиента) очень сильно зависит от скорости дисковой подсистемы

Господа, тыкните носом, что лучше:
2 физ процессора = 4 "логических" или как том они называются

сколько рабочих процессов вешать на машину?
-1
-2
-4
...?

(148) 32-бит сервер - по кол-ву физядер, 64 - 1 и один резевный

Есть где прочитать про это?

(0) На многоядерных ксеонах есть вполне конкретная спецификация - и программи интелловская, смысл там простой - 2 ксеона - у каждого из 3 каналов памяти забито по 1 пластине памяти , макс возм память 48Гб (условно). Скорость обмена проца с озу - 96Гб\сек, у КАЖДОГО проца со своим банком памяти. Хотите поставить в сервер 96Гб оперативы - проблем нет, но скорость обмена уменьшается в 2 раза.

(150) Я таки в ЖКК и на сайте 1С про это читал. Это стандартные рекомендации. 64 бит - не ограничен пока теми 2,7- 3,7 Гб на процесс. А на распараллеливание в рпхост тратится время.

(0) А любители кричать "а у вас 1С медленно работает, а у меня дома на стареньком буке - летает" - да не проблема, подключите к буку 200 сессий 1С, придется правда с быстрой шаредмемори на тсп-ип поменять протокол и тд

(0) И нормальные люди обычно в сервер ECC память ставят, а она медленнее чем "текущая" для домашнего сегмента

(150) не парься, в 8.3 настраивать уже количество рабочих процессов вручную нельзя, только параметры "стратегически" учитывающие взаимовлияние баз и отказоустойчиваость, ну и весь партнерский форум утыкан подобными ветками, где то видел на ИТС

(150) Лучше парся - если ты по своей профессии работаешь, никто не придет и не сделает счастья забесплатно.

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

(157) Эт точно, сам советую подобное..

OFF: А вы играете в "Бомбермена"? »    / Игры

(157) "рефакторинг" - а ты смешной:

Кто знает, что за файлы лежат в
C:\Program Files\1cv82\srvinfo\reg_2041\ГУИД_БАЗЫ\1Cv8FTxt\
вида changes20120407000000.log
в них инфа вида

R260:81e4000423dedd1c11df2b3de56ab8a8
R260:81e4000423dedd1c11df2b3de56ab8a9

R260:81e4000423dedd1c11df2b3de56ab8aa

(158) (159) И в чем суть сообщений?

В том что я не считаю вас ни "опытных эдынысникав и одминов", и прошу не подмазыватся к моему мнению и ответам.

(161) Да на Ваше мнение мне плевать вообще, и "подмазываться" к Вам я не собираюсь. (157) был ответ на (150) и ничто иное.

* на (156)

(163) Если (157) на (156) - читай книжку по логике, или букварь по русскому языку

>>> Лучше парся - если ты по своей профессии работаешь, никто не придет и не сделает счастья забесплатно.
<<< Согласен.

Так Вам яснее?

Димасик, ты не способен самостоятельно прочитать ЖКК, тебе подсказали, потом ты из себя гуру корчишь, по темам - так вообще звиздец. Чего ты хочешь? Задал в (150) вопрос, тебе в (152) ответили. В (157) - это уже твои мечты, о "большем заработке и т.д." Я в (152) - ответил очевидное и убогое, доступное всем, ты первый раз об этих параметрах 1С сервера услышал?

(165) Автор темы - так вообще - дроччер-теоретик, но я ему грубого слова не сказал, а ты мозги ипешь.

(0) Дроччер - тоже обосную, когда он на ИнфиниБанд цену узнает и куда ее в связку 1С - SQL server засунетю. И видел ли он  Инфинибанд стойку для начала. Ну дурак он, на руси спокон веков, нет обид на дураков

(0) Ну в принципе это и понятно.

+(169) Сосбно с чего процы при работе с базой - узкое место.

(170) Вроде как дисковая подсистема была?

(171) Ну я там вопрос в конце не  поставил.

(101) Так и есть и что главное это уже давно истина и на 77 и на 8 и т.д. Ничего нового. и вполне себе совпадает с теоретическими представлениями.

(173) Получилось что в (0) очередной тролль, так и есть.

какая хрень разница, как работает 1С..
чай, не Айртоны, на вираже не разобъемся..

Новую тему создавать не буду.

Вопрос, есть задача поднять БД из семейства УПП на 30-40 пользователей. Принято решение о разнесении сервера приложений и сервера БД (MS SQL) на разные машины. Лучше использовать две разные железяки, или можно обойтись средствами виртуализации типа hyper-V, т.е. на одной железяке запустит два виртуальных сервера?

По поводу процессоров для сервера. Прочитав тему, я так понял, что смысла в многоядерных процах нет. Какой проц из семейства е-2600 порекомендовали для сервера приложений (он же терминальный) под УППырище на 40 пользователей. Ну и рекомендации по оперативке.

(176) т.е. в первом вопросе ты готов использовать виртуализацию для серверов СУБД и сервера 1С, а во втором говоришь, что многоядерный проц тебе не нужен?

а ничо, что как раз разные виртуальные сервера будут "сидеть" в параллельных процессах, каждый из которых соответственно получит в свою виртуальную собственность ядра процессоров?

По моим выводам из этих и других подобных обсуждений, Многоядерный проц внутри отдельно взятой еденичной машины (может быть и виртуальной машины) не имеет смысла если:
1) используется MS SQL
2) используется сервер приложений 1С

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

(177) многоядерность имелась в виду в ситуации, когда сервер 1с вынесен на отдельную железяку, а не на виртуальном сервере

(178) да это я понял :)
имхо, железячная изоляция между серверами надежней, чем заморачиваться с виртуализацией - результат предсказуем и легко тестируется. А на виртуальных серверах скорость передачи данных выше (теоритически) между ними, но я на практике такими не пользовался и достоверно утверждать не могу.

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

179+ А если еще и представить себе ситуацию, что на сервере 1С окажется не одна только база, а несколько параллельно существующих баз, то и тем более будет интерес в многоядерном процессоре (боевая база, отчетно-справочная, тестово-песочная)

(180) угу, пожалуй, верно

Кстати вот накидал запросик....
проверять какой протокол юзает сервер 1с
запускать можно например в Энтерпрайз менеджере SQL
(печалька но Shared Memory -не увидел -вплоть до 1с 8.2.17)

select program_name,net_transport
from sys.dm_exec_sessions as t1
left join sys.dm_exec_connections AS t2 ON t1.session_id=t2.session_id
where not t1.program_name is null

(180) - а для других баз/тестовых отдельный комп лучше.
Хотя лицензия опять таки на сервер 1С нужна будет))

(180)
и нет интереса в тормозном многоядерном/многопроцовом как раз))
Смысл? смотреть что нет загрузки на процах - а работа в базах всеравно тормозит?

(168)   SWD
давно ветку не читал, но увидел ваш пустой треп..
1)какой нафиг я теоретик? для "мозговитых как вы" (именно в кавычках) - тесты есть практическая проверка теории.
2)ИнфиниБанд - можно купить комплект 2 сетевухи(40 Гбит) + кабель медный = за 21 тыс.руб. -два компа можно соединить.

а вы по моему мнению  "пустой мудозвон" ))
ИМХО ни чем практическим, ваши слова не подтверждены - в отличии от моих тестов!

(184) ну я весьма предвзято отношусь к продуктам от мелкософта

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

но неужели MS SQL настолько ужасен, что все сеансы для _разных_ баз обкручивает в одном процессе?!

(186) Что в этом ужасного: сервер работает в одном процессе, на с использованием многих потоков? И ведь в отличие от сервера 1С РАБОТАЕТ

(185) Купить можно только как вы их между собой подружите?Приведите пожалуйста ссылку на конкретное решение(дабы не быть пустозвоном) с помощью кторого можно связать между собой к примеру сервер приложения и MSSQL?

А вообщем то в этой ветке столько заблуждений что даже как то их коментировать не хочется.

для МуМу
в (185)я всего лишь ответил для SWD
на в ответ на его утверждения:

1)что я теоретик)) (про зависимость 1с(файловый и клиент-серверный вариант) от частоты CPU и от скорости CPU-RAM -проверил тестами...и не только я)

2) он утверждал что запредельная цена ИнфиниБанд - 21 тыс. не так и запредельно.

3)"мудозвоном" - его назвал, не стерпел...как он меня всяко парафинил)) и притом звенел он пусто))

Про ИнфиниБанд - я спросил в (0) - есть ли возможность у кого проверить

(190) Мы сейчас как раз занимаемся интеграцией ИнфиниБанд. Так вот - она не стоит 21 т.р. а к тому же просто так еще и не взлетит.(сейчас например оледб драйвера перписываем скульные). Мне тоже было бы интересно у кого она в России работает в связке 1С MSSQL без дополнительных решений по интеграции?(помоему у нас первых решение появится)

(191)+ Купить две карточки и кабель недостаточно для того что бы решение заработало. К тому же мне интересно где вы нашли для двух карточек цену 21 т.р.?(нет, ну реально может мы не там покупали)

(192)
)) б/у если честно... комплект предлагал один чел на сайте

(192) Почему недостаточно? Еще во времена семерки работало без колдовства. Вполне может быть, что можно оптимизировать софт под возможности железа, но все взлетает прямо из коробки.

(186) Херово.
Вон, даже в sql express, работающем на одном ядре - 37 потоков. И ничего.
И даже в 1С-ке клиентской части дофига потоков, просто главный из них - один.

(186) Рекомендую поменять специальность, пойти работать там, менеджером каким...

Вот (186) - яркий пример пациента, описанного в (44) посте в ветке
Одинэсников обижают

(респект таким пацанам, которые пишут подобные посты)

(195) об чем тогда вообще этот топик?

(0) Что касается этих утверждений то они отчасти корректны но только в контексте работы 1С по одной регламентной задаче, да и то в том случае если она не распараллеливается. В контексте 1С мне кажется важнее говорить о масштабируемости, в этом случае большинство утверждений не верно. Если поставить SQL сервер и сервер приложений на один сервак то время отклика(по шине данных) будет минимально. Если ресурсов этого сервера хватает на них обоих то это является оптимальной схемой. К тому же это проверялось.Особенно это актуально для тех систем в которых много серверных вызовов(скл запросов) в единицу времени(например в конфигурациях инталева). С другой стороны иметь на одном серваке сервер СУБД и сервер приложений это тоже повышенные риски. Им может нехватить обоим ресурсов, сложнее администрировать, утечки сервера приложений могут приводить к резкой деградации системы и т.п. Короче, вывод о конфигурации  нельзя делать вообщем. Необходим хотя бы первичный анализ системы.

(194) Вы тестировали этот коробочный продукт? Вы замеряли время отклика системы? Зачем он нужен если он работает с характеристиками как обычная сетевая карта? Скиньте мне пожалуйста конкретную ссылку, тогда диалог будет конструктивным.

(197) это я один всю х...ю в этой ветке напостил?

(198) Тема про то, что у автора есть Infini band

(200) Конкретику? бугага

(200) Вооот. В (199) - яркий пример конкретики. ага, ага.
Шмузер, скинь ка товарищу конкретики, образец в (199) у тебя есть.

сколько клиентов тестировалась нагрузка?

(203) ах вот оно в чем все дело :-0

а как ты узнал про 37 потоков на экспресс?

(206) Диспетчер задач, меню Вид->Выбрать столбцы, галочку "Счетчик потоков"

(205)
изначально на одного чтобы понять СУТЬ))

далее "Стандартный нагрузочный тест 1С" - он уже выявил зависимость количества пользователей в клиент-серверном варианте от Объема оперативки - на сервере 1с + SQL
(тупо добавляли планки и количество юзверов по тесту становилось больше))

(205) притом без падения коэф. производительности))

фи... я как тона тестовом сервере базу полностью в оперативку загнал... вот это была скорость.... раз в 5 выше ваших извратов

(210) В нормально спроектированной и оптимизированной системе скулю хватает памяти не более 5% от объема БД. Утверждение о том что загнав БД в память можно решить все проблемы - не верное. Например один запрос с неоптимальным огромным хеш объединением может отнять всю оперативку.

(207) спс

хмм (211) где можно почитать про это, я то я несколько не уверен в этом.

sql.ru(поискать на тему системы кеширования данных в mssql) , или Дэн Тоу (sql для профессионалов).

Смысл в том что основной объем обращений в правильно спроектированной БД  идет к небольшой части данных. Эта небольшая часть данных и будет находится постоянно в оперативке. Чем меньше будет ее вытеснение тем меньше будут провалы в производительности. Как данные попадают в оперативку и как они вытесняются почитайте по ссылкам(214).

(200) Тестировали и сравнивали. Вы расстроились из-за того, что не вы первые догадались использовать кластерное железо для 1с? Не переживайте, у нас эти решения году этак в 2003 уже использовались. Был хороший бюджет проекта и мы тогда пытались отмасштабировать систему по максимуму одними железками. Интерконнект не требует волшебного тюнинга для того, чтобы работать на порядки быстрее "обычной сетевухи".

+(211)Предположим  у вас есть 10-ть таблиц общим объемом 10ГБ. А оперативки допустим на 32. Можно написать пару таких запросов что 32 ГБ оперативки не хватит.

(216) А можно ссылку на решение, оборудование?

(216) Да, ничего мы не расстроились. Я работал с подобными технологиями от HP в тех же самых волосатых годах. Только стоили они как готовое решение совсем не дешево.
Еще раз прошу у вас, скиньте ссылку?

(219) Ссылку на то, что было тогда или на то, что есть сейчас?

И, кстати, у НР в тех волосатых годах подобных решений, кроме блейд систем, и не было.

(220) И то и другое пожалуйста.

(216) Все сказанное вами интересно, просьба скинуть оборудование, которое по технологии infiniband организует взаимодействие между сервером БД и приложения 1С. В любые времена)))

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

но в случае с 1с, у нас получается размер базы = размер съеданой памяти. Так?

(224) Для 1С-их оптимизированных , оперативных БД этот показатель равен приблизительно 20-30 %.

(222) Ага, я вам все на блюдечке того, а вы потом много денег заработаете :) На корпоративном рынке про успешные конфигурации оборудования рассказывают только продавцы железа :)

(225) А вот про эту оптимизацию где почитать?

(226) Странно , интеграторы российские об этом ничего не знают. А работаем мы только с корпоративными клиентами и поверьте за 400-а проектов увидели много различного железа. Я реально готов вам заплатить денег если вы мне скажете готовое решение.  В противном случае у меня есть основания не доверять недавно зарегеистрированному участнику.

(226) мда
А товарищ HADGEHOGs чего молчит, где конкретика?)))

(229) Какую конкретику вам надо?

(227) Я уже писал - начните с Дена Тоу.

(230) оборудование, софт и прочее. Информация открыта для нее. А то блабла бла получается)))

(232) Тыщу раз уже писал.

(233) Блаблабла действительно тыщу раз писал, а конкретику: решение для 1С по Infiniband не разу, и софт?)). А у нас есть прототип решения в офисе и 1С 8.2. реально работает по этой технологии.

(234) Ниче не понял.
Про инфинибэнд услышал первый раз в жизни в этой ветке.

SWD, прошу вас не выражаться.

(236) Инфинибанд - высокопроизводительная магистраль связи, размером - стойка для 42 юнитов, минимум. Используется магистральными провайдерами, теми, у кого денег хватило.

фото - на хабре и в интернете - полно их

(239)Смотрим определение в википедии.
Infiniband — высокоскоростная коммутируемая последовательная шина, применяющаяся как для внутренних (внутрисистемных), так и для межсистемных соединений.
Ключевое слово межсистемных. Активно как и технология PCI Express используется для кластерных решений.

а что разве tcp over Infiniband не работает?

или RDMA драйвер пишите?

+(241)Основное назначение Infiniband — межсерверные соединения, в том числе и для организации RDMA (Remote Direct Memory Access).

(241) мда, очередной раз Му-Му, сказал муму. Муму- мы вроде спорили уже с тобой по этому поводу - виккипедия, шмикипедия? Ограничения у шины PCIex - ведь - есть, и вполне конкретные?

говорят sql 12 умеет rdma, а 8.2.17 умеет нэйтив клиент и SQL 12.
Разве этого не достаточно?

(244) Раскрылся клиент - шина ширше доступа к памяти ?

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

(248) где ваш сайт, статистика, подтверждение что ваш драйвер работает без ошибок?

(245) Очень конструктивно. Сразу хочу сказать что спорить в таком тоне и с такими аргументами не привык?
(238) Мое мнение если SWD в таком тоне и с такой аргументацией будет спорить дальше его нужно забанить.

(247) Основное практическое применение на данный момент это уменьшение времени отклика между двумя серверами. До Remote Direct Memory Access пока руки не дошли.

(250) А я и хочу видеть конструктив, а не двух виртуальных клонов с тремя темами в тематическом сайте.

(246) "8.2.17 умеет нэйтив клиент" - таки пока никто не тестил

таки (251) Муму и (248) gallam - реально клоны и не скрывается даже

(253) ну таки и драйвер самописный нужно будет тестить ого-го

Интересно у кого нибудь кроме SWD сложилось мнение что я в этой ведке что нибудь утверждал неконструктивно, переходил на личности? Я готов ответить за каждое слово сказанное в ветке!

(254) Приходи в офис я тебе докажу свою невиртуальность;) Покажу работающее решение!(хотя с некоторыми ограничениями)
Насчет используемой технологии инфинибенд с 1С , пока что никто так ссылку и не предоставил.

(228) Вот видите, вы даже деньги предлагаете за решение и информацию о своем программно-аппаратном комплексе не делаете достоянием общественности, а от других ожидаете иного :)

(257) "Приходи-покажу". Скриншоты сильно секретные?

+(257)Аргументы что вот у нас "где-то" работает но я вам не покажу потому что это секрет -  не принимаются! Я например если чего то не хочу рассказывать - реально молчу. Если же о чем то говорю - могу показать!

(258) Я вам готов за эту информацию заплатить! Повторяю уже второй раз. У нас есть реальные клиенты которым это нужно.

(260) Понятно. Покажешь правленную тобой статью в википедии? Сколково и вечный двигатель.

(258) А помоему - это нездоровье. Готов заплатить за информацию о собственной разработке.

(259) С твоим изначальным недовольством и скепсисом, что тебе скажут скриншоты?
Есть стенд на котором мы проводим исследования и тесты. Готов показать что дает эта технология на конкретных нагрузочных тестах.

(261) У меня сложилось такое впечатление.
Про неконструктивность.
Еще со времен кривого типа в конфе 1С и 3.4 гигов памяти.
Клещами из тебя вытаскивал - так и не вытащил.

Может тут сорвешь покровы - как удалось зафигачить в конфу несуществующий тип?

мда

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

(263) Вот и меня это смущает

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

(269) Что насчет (265).
Расскажи подробнее.
Какой реквизит, в каком объекте, как удалось найти, какой запрос формировался на SQL

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

Почему утекала память (предположительно хоть).

(272) Это предлагаю вличку.Дабы не забивать текущую ветку. Отвечу на все вопросы. Но в измененной статье это все есть.

(273) Слава яйцам
http://softpoint.ru/info_id146.html

Счаст затестим.

Господа Шмузер и SWD, готов вам перечислить каждому по 500 usd если вы найдете готовое на инфинибанд решение которое подойдет для 1С 8.2 MSSQL.Только нужно будет проверить что оно реально работает.(Я думаю потенциальный интегратор не будет против что бы мы перед покупкой провели тест.) Только вот я сомневаюсь, потому как анализ рынка уже проводился. А судя по вашей аргументации будет очередной раз неконструктивная критика.

http://www.forum.mista.ru/users.php?action=show&id=44103 покинул нас.

(277) Спасибо, я думаю от этого форум только выиграет.

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

Кстати, о ценах - там уже давно все демократично, кроме свичей.
http://www.ebay.com/sch/i.html?LH_ItemCondition=3&_sacat=0&_from=R40&_nkw=Mellanox&rt=nc&LH_BIN=1

(280) Кроме плат и свичей, требуется адаптация для замены взаимодействия: сервер приложения 1С и сервер СУБД. Сервер приложения взаимодействует с БД через OLEDB Provider, далее более низкий уровень сокеты, далее TCP. Какой уровень сетевого взаимодействия ваше решение заменяет?  У 1С нет провайдера для infiniband?

(280) Именно в адаптации основная сложность...

Карточки они недорого стоят. Проблема с адаптацией. Я попросил коллегу по этому поводу более подробно написать здесь. Если вдруг уже разработано ПО под них с помощью которого эту карту легко поставить и заставить скуль(или на уровне сокетов) обращаться с сервером приложения 1С(под windows) мне 500 баксов будет не жалко:)

многобукв читать лень, киньте номера дельных сообщений, плиз

(281) TCP?

(285) Это вопрос или ответ?

(281)Сервер приложения взаимодействует с БД через OLEDB Provider
А как же нэйтив клиент?

(280) Карта здесь вторична, скиньте ссылку на карту плюс ПО. Желательно что бы в описании была информация о том что поддерживается взаимодействие с MSSQL(то есть реализован протокол-оболочка).

И вообще, это IB уже морально устарел - его Эзернэт уделал нафик.
Не продавайте несвежие решения :)

(289)Я дал еще раз задание что бы проверили на совместимость с MSSQL(windows). Потому как как только брались за исследования - тоже многие декларируют что все поддерживает а потом оказывается что вроде работает но например только под линукс и т.п. а под виндой на уровне сокетов но крайне неоптимально.
А насчет эзернет уделал? Я бы так не сказал. Нам например важно минимальное время отклика. Какое оно у эзернета?

(290) Очень хорошее - http://www.cisco.com/web/RU/news/releases/txt/2012/100112e.html

(0)Америку открыл?
и так ясно что если проц один фиг 3,2 ггерц то не важно сколько их если быдлокод не распараллелить, т.е. ума если не хвататет

(273) Нефига не растет

Бида

Поменял я этот ДокументОснование на неизвестное поле,
Кстати, что это за типзначения в терминах 1С вы туда залупили?

И не растет.
Не при обновлении списка заказов, не при открытии

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

Ах тыж еп твою...
Не тот документ я открывал :-)

Пацаны, не делайте так.
rphost.exe сожрал всю память и завесил сервер напрочь.
Счаст его еле еле прибил и все приблуды вылезают потихоньку из свопа.
На момент прибития памяти было свободно 95% (то есть сервер 1С оставил остальным только 5%).

SQL сервер в шоке.

(298) у тебя скуль с 1сом на одном? гыгы

(299) Че гыгыгы?

У нас все крайне экономно.

(301) вот чтобы такой фигни не было

трехсотку запорол

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

(302) Чтоб такого не было - надо ставить x32. Спокойно бы вывалился и не пугал SQL

(305) у меня были загрузки/выгрузки/отчеты, кот орые физически только на х64 сервере выполнится могли, даже /3гб не помогал

Господа, для однопользовательского/файлового режима а если я отключу 3 ядра из 4х у кореи5, разгоню до 5.5 Гигагерц, операции удаления, обработки/записи нескольких тысяч элементов справочников, документов будут происходить быстрее, чем в однопользовательском/клиент-серверном режиме с 4мя  ядрами?
Уже хочется поставть в рабочий комп 32/64 гига, содать рамдрайв, положить туда базу/темп винды, чтобы такая обработка происходила быстрее. Мне для 1го пользователя это дешевле чем Infinity Band. SSD диск и так стоит... но не то...

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

(307) Сначало подумал, что пишет 18-летний представитель поколения покемонов.

пишу на 1с с 8ми лет ))

(307) kauksi
В вашем случае:
лучше оставить ДВА ядра - и разогнать.
ИМХО OS -тоже хочет кушать.

Да разгон поможет в Вашем случае -больше - чем SSD.

PS:
Клиент 1с - один фиг будет Одно ядро грузить.

(299) Fragster

действительно что за ГЫГЫ)) "(298) у тебя скуль с 1сом на одном? гыгы"

приведите пожалуйста подробную конфигурацию оборудования
(+сетевой интерфейс)
которая бы не уступала "скуль с 1сом на одном? гыгы".

(311) сетевой интерфейс - 2 гигабитных объединенных. "задержки" на передачу данных сильно приувеличены - я ни разу не видел нагрузку именно между ними больше 30-40%. а вот в проц на сервере 1с и в проц/диски на скуле не раз видел. а гыгы - как раз из-за того, что если сервер 1, то 1с любящий проц и текущий по памяти конфликтуют все-таки из-за этих ресурсов частенько со скулем, также любящим проц и памяти много.даже если 64 ядра будет - одновременных юзеров может быть больше.

(312) Fragster
да не в ОБЩЕМ трафике дело,
а именно в латентности(задержках).

Поясняю:
Допустим у нас сеть 2 Гбит - с высокой латентностью,
то разберем случаи:

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

2)надо общаться "Сервер 1С"<--->"SQL" - при этом будет очень много мелких пакетов -
- здесь в ВЫСКОКО-ЛАТЕНТНОЙ сети мы никогда не увидим ВЫСОКОЙ-загрузки сети.

+ к (313)
для Fragster

пункт 2) - грубый пример/аналог - чтение или запись на Механическом жестком диске большого количества мелких файлов

(313) +1

(314) А при каком отклике тестировали взаимодействие между сервером БД и сервером приложения? Было нагрузочное тестирование по сравнению с обычным Ethernet?

(313) А что не так при высокой латентности?

Че там, запрос выполниться на 10 миллисекунд позже?

Что такое МелкийПакет, чем он отличается от КрупногоПакета?

(314) Время отклика сетки соизмеримо со временем выполнения запроса? Это вообще как?

(316)
один из примеров приведу:

брал Два-абсолютно одинаковых компа.
Варианты запуска тестов:

1)Комп1(SQL(pipe named)+сервер 1c) -45 попугаев.

2)Комп1(SQL)<-- 1 Гбит Ethernet--> Комп2(сервер 1С) - 16.5 попугаев

(320) Время отклика конечно. Время запроса - тоже конечно. Они могут быть соизмеримы, то есть близки по значению. И когда запрос выполняется быстрее времени отклика (это тоже возможно), то влияет на скорость не столько длительность запроса, сколько отклик и пропускная способность (она как раз редко бывает узким местом).

(321) А все тесты в однопользовательском режиме?

(323)
нет не все, далее использовался "Стандартный нагрузочный от 1с" -- но увы и ах уже и так было понятно про КОЭФ.Быстродействия ))

(324) А почему этим занимался, была практическая задача какая-то?

(325)
мое подразделение расширяется, задумались о новых серверах))

я пока остановился на 2-у процессорной системе
Intel Xeon E5-2643 (3.3 Ггц если без TB) QPI 2х8 GTs

т.е. Два процессора будут Связаны - Двумя шинами QPI с сумарной скоростью 32 Гб/сек в Одну сторону.

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

(327)
немного пошучу))

я конечно всего лишь программист( не только 1С),
но книги по сетевым технологиям в туалете почитываю))

ps:
Книги действительно есть - один разок даже СисАдмин проспорил по инфе из них - больше он со мной спорить на что либо отказывался (спор был не просто на интерес) ))

(313) <1мс времени реакции, о чем ты с латентностью тут? у нас не сверхбыстрый трейдинг...

(329)+ тут провели исследование - время путешествия пакета через пол планеты (15мс) меньше, чем "пинг" от команды на изменение кадра до реального его изменения на мониторе (около 30мс) из-за задержек в видеокарте, в мониторе

(0) вырубайте гипертрейдинг, для ms sql он вреден

(324) "стандартный нагрузочный" фигня полная. у меня он на рабочем компе выдает 45 попугаев, а на сервере - 15. но документы проводятся и запросы выполняются на сервере быстрее.

(331) это распространенное заблуждение

то, что "загрузка процессора" от одного потока 50% становится - это неверно показывает диспетчер задач...

(334) вернее эти 50% такие же как100% без гипертрейдинга. а вот в 2 потока суммарная производительность будет 100% без и 130-140% с гипертредингом

(332) - (335) обоснуйте?
http://technet.microsoft.com/ru-ru/magazine/2007.10.sqlcpu.aspx

(336) это было 5 лет назад. и даже там написано:
"Только в очень редких случаях приложения с высокой загрузкой процессора в SQL Server могут эффективно использовать гиперпоточность. Перед реализацией изменений в рабочих системах необходимо всегда проверять приложения в SQL Server с включенной и выключенной гиперпоточностью."
у меня при использовании HT стало полегче (стало 16 "ядер" вместо 8) на 70+ активных 150+ всего одновременно

_всегда проверять приложения_

вдогонку http://www.astera.ru/news/?id=30890
(337) а какая версия скуля используется? наверно ms sql 2012? или все таки ms sql 2005

(337) 2008

(333) Это не заблуждение, это частный случай. Для SQL 2005 гипертрединг стоит выключить, для SQL 2008-2012 стоит провести тестирование под своей нагрузкой, чтобы решить - выключать или не выключать.
И, да - Майкрософт очень осторожно советует держать MAXDOP при гипертрединге равным числу физических процессоров. Т.е., фактически не использовать его :)

(338) там проблема - кэш цпу физически один на два виртуальных проца - в этом корень проблемы

(339) Все же 7 лет прошло, Интел произвела на свет уже несколько версий гипертрединга и процессорных кэшей.

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

(344) Мне кажется, что я ни где не призывал надеяться. Я считаю, что гипертрединг скорее нет, чем да, но всегда стоит проверять.

Автор, мы в свое время проводили туеву хучу тестов и измерений про производительность. Это серьезный вопрос. А раз так уверен в своих утверждениях, то посади десяток сумасшедших пользователей на комп, где сможешь менять по одному кусочку платформы. Сначала проц с большой частотой и минимум ядер. Потом поменяй его на меньшую частоту и много ядер и создай несколько процессов 1С. Потом попробуй изменять скорость памяти, без изменения размеров. Потом размер памяти без изменения скорости. Потом поиграй со скоростью винта. Только не забывай про пороговые размеры памяти и частоту проца, которые озвучены уже мульён раз.
После этих замеров отделяй 1С сервер от сервера СУБД физически и заново мерь все. Потом увеличивай кол-во пользователей на сколько сможешь, лучше больше сотни и проводи все эти замеры, только изменяй размер кластера 1С.
Вот серьезно, давно бы уже измерил это все. Главное бери крайние точки, что бы выводы более точные были

(346)
еще раз повторюсь

я пока остановился на 2-ух процессорной системе
Intel Xeon E5-2643 (3.3 Ггц если без TB) QPI 2х8 GTs

т.е. Два процессора будут Связаны - Двумя шинами QPI с сумарной скоростью 32 Гб/сек в Одну сторону.

а АБСОЛЮТНО согласен что Десктопы - для дестопных задач.

(346)

а еще тестил на своем компе (клиент-серверный режим)
(у меня можно отключать Ядра - повышая тем самым Ггц)
так вот

1)2-а ядра (3.1 Ггц) -72 попугая

2) 4 ядра (2.8 Ггц) - 62 попугая

(346)
да вообще все было проверено что вы описываете.

А про скорость памяти Открою вам секрет..
только тссс... никому))
НИ ОДИН современный проц Itel не прокачает даже средненькую DDR3 на полную, разве только I7- сильно разогнаный!!

(349) А можно подробнее?

(348)->(332)

а вообще понятно, что 3.1 > 2.8, причем результаты просто пропорциональны получаются. Попугаетест реально однопоточный.

(352)+ а сервер 1с, как и скуль-сервер реально работают во много потоков

(291) Приведу пример из маркетинговой статьи Mellanox
http://www.pcweek.ru/themes/detail.php?ID=136554
- Низкие задержки
Задержки переключения port-to-port — 230 ns при скорости 40GbE
Задержка RDMA приложений — менее 1,3 µs
Задержка socket-based-приложений — 4 µs

Обратите внимание на то что socket-based-приложений время отклика уже целых 4 микросекунды. Также что конечной целью является не ускоренная закачка файлов а ускорение работы с сервера приложения с сервером MSSQL. Я к тому что маркетинг маркетингом но нужно все проверять самому. Согласен что за последние 2-а года наших исследований и разработки на инфинибанд технологии шагнули несколько вперед. Поэтому я инициировал новые исследования. Проведем тесты на 10,40 GB езернет, также проверим последние решения инфинибанд.
При этом тесты будут на рабочей системе. Потому как синтетические тесты ни о чем не говорят. Мы например повелись в свое время на маркетинг и купили карточки dolphin(типа технология суперсокет) а потом оказалось что все это используется для линукса а для винды нужна серьезная разработка. Вообщем в любом случае если окажется что текущие инфинибэенд решения без адаптации реально ускоряют по сравнению с тем что мы сделали то с меня 500 баксов. Также как впрочем если решение на базе 10ГБ езернет окажется быстрее чем текущее наше.

(353) Fragster
хорошо повторю еще раз что далее проводились "многопоточные тесты"

НО - если сервер показывает ОЧЕНЬ НИЗКИЕ результаты в ОДНОПОТОЧНОМ тесте - неужели вы надеетесь на чудо в многопоточном? ))

(355) он с практически одинаковой скоростью работает (если брать основной шаблон работы пользователей) что на 10 пользователях, что на 50, что на 150, очень долго пилилось, чтобы убрать влияние блокировок. а то, что однопоточная скорость мала - да и черт с ней, основные документы проводятся < секунды и хорошо

а то, что там 0,5мс или 5мс на отправку запроса скулю идет - да вообще накакать

(357) Вы очень сильно ошибаетесь, недооценивая влияние латентности интерфейса передачи данных между приложением и сервером бд.

(357)
"а то, что там 0,5мс или 5мс на отправку запроса скулю идет - да вообще накакать" - еще соглашусь если ОДИН запрос.

НО профайлером SQL смотрели обмен "Сервер 1с"+"SQL" ? ))

(359) Сотни запросов.
СОТНИ!!!
Но не тысячи :-)
Так что эта латентности монопенисуальна.

(358) Чтобы Fragster ошибался? Да не бывало такого.

(361)
хе мне честно пофигу Кто там для Вас авторитет))
я все привык проверять на практике!

"СОТНИ!!!" - за какой период времени?

готов поспорить что:
1)"SQL+сервер 1с" - запросов за одно и тоже время будет
БОЛЬШЕ
чем
2)Комп1"SQL"<---сеть 2 Гбит-->Комп2"cthdth 1c"

(362)
Комп2"cthdth 1c" = Комп2"сервер 1c"

(362) Конечно больше.

(360) У нас есть клиенты с специфическими системами в которых тысячи запросов в секунду. Оптимизация в таких случаях помогает достаточно слабо. А вот если уменьшить время отклика по сервера приложений с сервером СУБД - эффект получается просто замечательный.  То есть данная задача очень важна хоть и для узкого круга компаний.

(364)
Ну и.... какой напрашивается вывод? ))

(365) Сервер 1С не захлебывается?

я, конечно, не технике не понимаю, но кэш проца тоже на что-то влияет?
Был у меня Целерон 2ГГц с 2М кэша 2 или 3 уровня, так он давал фору двухголовым Интелам с мЕньшим кэшем.

(366) Вывод напрашивается такой, что сервер SQL + сервер 1С на нескольких компах - гораздо более масштабируемое решение, с меньшей нагрузкой на диск.

+(368) с той же частотой, но с кэшем 512Кб на каждой голове.

(369) Кластер?

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

(369)
понятно с меньше нагрузкой на диск))
ИМХО - в принципе не может загрузить

+(373)
т.к. запросов меньше может обработать

(373) Посмотри как чехвостит сервер 1С тмп файлы (от имени процесса System).

(366) Не понимаю о чем спор. Локальная связка в определенных случаях конечно же лучше. Но в определенных значительно хуже. Все зависит от ситуации. Хотя в однопоточном нераспараллеленом варианте она конечно же лучше. Вопрос нассколько? Зависит от количества обращений к СУБД в единицу времени.

Под tempDB и временные файлы я бы выделил RAM диск, лучше конечно аппаратный.

Читал, что SQL пищет/читает TempDB только когда ОЗУ нехватает - а вот фиг - постоянно пишет/читает.

Как и сервер 1С - поэтому RAM диск.

(377)
вот... ну и... зачем нам разделять? ))

(376) ответь на (367)

(367)Нет не захлебывается, да и сеть вроде не загружена. Такое впечатление что все не загружено а система тормозит. Это как раз прямое следствие длительного времени отклика СУБД. Это связано и с транспортом на физическом уровне и на уровне обработки сокетов и на уровне обработки SDBL. На SDBL мы влиять не можем а вото на все остальное возможно. Та наработку которую мы сделали позволила сократить линейное время операций на 40% хотя битва на уровне оптимизации шла за 5-10 процентов.

+(382) Хотя это специфический случай. В правильных системах в которых идут сотни обращений в секунду улучшение за счет уменьшения латентности будет не более процента. Разумеется в таких случаях боротся за это не стоит.

я понимаю стереотипы трудно ломать ребята))
думаю все согласны:

1) с разделением SQL и сервера 1с по сети
из за задержек МАКСИМЛЬНОЕ количесво запросов между ними уменьшается.

2)как следствие из пункта 1) - уменьшается нагрузка на диски
- т.к. в принципе МЕНЬШЕ операций успевает совершится.  

3)получаем низкую скорость работы 1с

в чем тут масштабирование?

+(384)
ИМХО ну станет больше пользователей...
ну и ....? что увеличится МАКСИМАЛЬНОЕ количество запросов? ))

(367) прямо сейчас у меня было 12 тыс. запросов к субд, полет нормальный, цпу загружен при этом на 25%

(384) Это у тебя пока один пользователь - все утыкается в задержки передачи запросов, а вот будет толпа юзверей - все уткнется в сервер 1С или в блокировки.

(387)
о как произойдет чудо
и запросы перестанут выстраиваться в очередь
ПРОРВУТ задержки ... и оБМЕН между 1с<--SQL увеличится в разы?

чем медленней обмен-- тем дольше операция тем дольше блокировка

ломайте стереотипы, смотрите глубже))

(388) Медленно вдумайся в процесс.

SQL быстрее обработает запрос, сервер 1С быстрее подготовит запрос, если их процессы не будут прерывать друг дураг. windows - не многозадачная ОС, она выдает каждому процессу квант времени выполнения, а потом отключает его и выполняет следующий процесс.

(388) Возможно, что речь идет о том, что при достижении определенного количества запросов в секунду ты задидосишь сервер 1С и поможет тебе только кластер серверов 1С.

(393)
имеете ввиду связь: "N клиентов 1с" <---> "сервер 1с" ?

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

(395) Угу. Скажи это операционке.
Операционка не заберет управление, если только идет ввод/вывод.

уровень драйверов(0)... это другое))

Хотя.. MS SQL. MS все же. он такой, необычный. Он даже с диском по особому работает.

(397) Что другое?

400

(385) если запросы вида select 1 т.е. когда время выполнения запроса сравнимо с временем передачи, и время собственно передачи сравнимо с временем "латенстности". в случае с 1с это не так.

(394) Риски размещения сервера СУБД и сервера приложения на одном серваке.
1) Нехватка оперативки,(в первую очередь утечки сервера приложений).Возможны неэффективные вымещения из кеша данных. В любом случае необходимо ее ограничивать и разделять.
2) Высокая нагрузка на дисковую подсистему(один из наиболее высоких рисков).
3) Высокая нагрузка на ЦПУ. (сервер приложений иногда умеет полностью отхватить ресурсы на казалось бы безобидных операциях)
4) Станет узким местом шина(тут конечно вопрос, у меня есть сомнения)?

ну ладно я смотрю вы свято верите АВТОРИТЕТАМ? ))

если так, то Крис Касперски - для Вас Авторитет?
если да то дам ссылку на его статью про кванты.

(303) для   H A D G E H O G s

тфу ты
(403) для  H A D G E H O G s

(405) :-)

Давай ссылку

можно я (361) распечатаю и в рамочку повешу?

(402)
да такое было "в первую очередь утечки сервера приложений"
победили установкой нового релиза

(402) Дааааа, безобидные...
Вчера воспроизвел твою ошибку из статьи.

Сервер ушел в даун, еле забил приложение 1С сервера.

Сожрал 95% памяти, вытеснил всех в своп., ms sql в шоке сжался, отдав всю оперативку, потом вылезал потихоньку в ОЗУ, окошки тормозили, отрисовываясь слайдами.
Весело.

У нас некоторым клиентам 32 ядра для SQL не хватает в момент пиковых загрузок. Соответсвенно размещая на этом же сервере сервер приложений - немного(зависит от ситуации) увеличится линейная скорость и серьезно уменьшится масштабируемость системы.

(409) Запустите в вашем тесте не одну обработку а сразу 10 -ть(что бы нагружали сервак и что бы не висели на блокировках, например тяжелые отчеты) и сравните разницу. А то спор слепого с глухим получается.

(411) "32 ядра для SQL не хватает в момент пиковых загрузок"

вопрос к вам на SQL стоит запрет параллелить слишком долгие запросы на другие ядра?
просто кхм... как бы был замечен косячок у MS SQL с этим делом))

+ к (413)
реально видел как ОДИН запрос грузил все ядра.
Получилась ситуация "лебедь,рак и щука... )))"

Отключил это дело и все стало гуд))

(413) Уверяю, эти настройки(maxdop=1) как и многие другие стоят. А также проводились работы по оптимизации.

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

(402) МуМу

1)+2) Высокая нагрузка на дисковую подсистему(один из наиболее высоких рисков).  

- согласен но только если не хватает оперативки. Как вы и описали хавается Своп и т.п.

-у нас победили сменой релиза движка 1с + переписан код.

3) Высокая нагрузка на ЦПУ.

- у нас было замечено при бесконечном цикле на Упр.Приложении - баг.платформы - но удалось победить программно))

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

(417) я могу написать код, который сожрет сколько угодно оперативки

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

это может любой))
пример:
делаем процедуру &НаСервере

создаем ТаблицуЗначений
делаем бесконечный цикл
добавляем строчки в ТЗ... ))

(418) МуМу
".К примеру массовое изменение данных все равно приведет к нагрузке на систему..." - да но зачем нам такое?
Востановление последовательности? - если да, то есть таки РАУЗ))

(420) Здесь имеется ввиду что в больших БД с большим функционалом получается много тяжелых SQL запросов которые обладают большим количеством reads(в трассе), которые отъедают большое количество ресурсов как ЦПУ так и дисковой подсистемы.Это происходит независимо от наличия оперативной памяти.(разумеется определенный разумный объем важен.)

(421) Вы смотрите на ситуацию слишком узко сквозь призму вашей системы. Я исхожу из опыта большого количества проектов с различными системами. Предлагаю вам провести указанные мной ранее тесты.  И провести замер времени выполнения операций в одном и другом случае. Мы подобные тесты уже проводили. Также рекомендую почитать тесты tpc.org(у нас на сайте есть в переводе) , не зря же тесты на 200 страниц расписываются.

(420) есть способ намного быстрее, см v8: Нехватки памяти, алкогольные декларации и все-все-все. напирмер

(424)
ну это тоже самое что в ТЗ1 добавляем строки содержащие ТЗ2 ))

таблица таблиц так сказать))

(426) прочитай там пост №42.

Я решил завести ветку на sql.ru обсудить вопрос о преимуществах и недостатках существующих современных  технологий типа езернет 10,40 GB,инфинибанд и т.п. в контексте работы с MSSQL. Отдельно как только дадут необходимое оборудование проведем тесты. Статей маркетинговых много а вот конкретных  успешных примеров(по крайней мере в россси) практически нет.

вот просили ссылку
про Кванты WINDOWS
"На самом верхнем уровне абстракций ядром принято называть совокупность компонентов операционной системы, работающих на привилегированном кольце нулевого уровня"

это объяснение, когда я писал что у драйверов уровень=0(нулевой)

http://www.insidepro.com/kk/030/030r.shtml

Windows NT поддерживает два типа квантов - длинные и короткие. Независимо от своего типа, кванты могут быть как фиксированной, так и переменной длины (кванты переменной длины еще называют динамическими). Величина кванта выражается в условных единицах, официально называемых quantum units. Три квантовых единицы обычно равны одному тику таймера..

(428)МуМу
правильно статей практически нет))
поэтому я и запостил тему...
надеясь - может у кого есть возможность ))
протестить "инфинибанд и т.п. в контексте работы с MSSQL"

(407) для  H A D G E H O G s

вот просили ссылку (429)

(430) Мы тестили - работает хорошо(для вырожденных случаев). Но пришлось много времени писать ПО. Не исключаю что пока мы его писали появились уже готовые коробочные решения.(сейчас будем проверять) Область применения на тот момент времени была в основном под линукс.

(432) МуМу

вот вот интересует именно под Windows.

Будем ждать ваших результатов!!

у меня клиент арендовал сервер в германии 25000р первый взнос и 10000р в месяц. Толи на 8 толи на 12 процов. Вобщем все стало летать просто "неподетцки". Раз в 5 быстрее чем предыдущий сервак за 200тыр на двух зионах.

(434)  KazanKokos
"Толи на 8 толи на 12 процов" - наверное ядер таки? ))

(434) Цесаревич Мандриан :)))

(428) sql.ru может оказаться бесполезным, лучше на майкрософтовском технете написать.

(434) KazanKokos
"Раз в 5 быстрее чем предыдущий сервак за 200тыр на двух зионах."

Зион - Зиону рознь!

конкретную модель в студию..
все раскладем по полочкам))

" чем больше процессоров тем хуже производительность 1С"

Что, реально удалось запустить толстую конфу под серьезной нагрузкой на SQL 8-процессорнике и 4-процессорнике?

(439) alex1974

давайте сначала определим термины))
1)Сокет - физический отдельный процессор - миросхема.
2)ядро - кол. процессоров в сокете, в настоящее время их несколько в одном Сокете))

"Что, реально удалось запустить толстую конфу под серьезной нагрузкой на SQL 8-процессорнике и 4-процессорнике?"

ваш вопрос про 8-Сокетный и 4-Сокетный? или про ядра?

(439)  alex1974
" чем больше процессоров тем хуже производительность 1С"

поясняю:
это про Сокеты))

(439)  alex1974

НО чем больше Ядер в Одном Сокете - тем ниже их Частота.
ИМХО - это физика)) тепловыделение и все такое))

(435) Ну я открывал свойства моего компьютера и там перечислялись процы. Я особо в этом не разбираюсь. Вот ведь налетели. Коршуны. По своим ощущениям я еще быстрее компа(не то что сервера) не видел.

(440)(442)
Ребята, процессор - одно физическое устройство, ядро - физический и/или логический элемент унутре процессора. (еще есть определение процессора от тёти-бухгалтерши, но его рассматривать не будем)

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

"чем больше Ядер в Одном Сокете - тем ниже их Частота" - ну, это у кого денег мало ;)

(444)  alex197
"...тем ниже их Частота" - ну, это у кого денег мало ;)"

Видимо фирма интел начала бомжевать))) от нехватки денег ))

в их 10 ядерных процах ядра по 2 ГГц
http://ark.intel.com/ru/products/53577/Intel-Xeon-Processor-E7-8867L--30M-Cache-2_13-GHz-6_40-GTs-Intel-QPI

(444)  alex197

я пока остановился на 2-у процессорной системе
Intel Xeon E5-2643 (3.3 Ггц если без TB) QPI 2х8 GTs

т.е. Два процессора будут Связаны - Двумя шинами QPI с сумарной скоростью 32 Гб/сек в Одну сторону.

(445)
Стоит дождаться следующего семейства - там с новой технологией  (что там после 32 нм?) частоту поднимут для топовых моделей.

(446)
По процессорам тормозов счетчики не показывают - сейчас уперлись в память и дисковую подсистему (конкурентные запись/чтение) Видимо, следующим 2-процессорный апгрейдом будет ящик с кучей слотов под оперативку

(447)alex1974

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

можно конечно сервак и в ВАННУЮ с МАСЛОМ ухнуть))
но не думаю что Интелл будет выпускать процы с расчетом на это))

(447)
".....По процессорам тормозов счетчики не показывают..."

ну я видел сервера и по 64 ядра суммарно (8 сокетов) (но естественно с низкими частотами)

Описываю ситуацию
-загруженности на процессорах почти нет
-1С - тормозит...

Почему тормозит?)) смотрите сообщение(0)
ИМХО
1)низкая частота CPU и
2)низкая скорость CPU-RAM (таки 8 сокетов...большие задержки)
"-загруженности на процессорах почти нет" - это следствие из пункта 2)
***************************************************
а если еще и Оперативки нехватает - то задержки еще увеличиваются(таки свопится все) - естественно процы будут отдыхать))

вообще жду тестов сетевых подключений InfiniBand (в ней очень низкие задержки)от пользователя  МуМу - обещалси протестить насчет MS SQL. ))

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

а пока разделять
"SQL" <--- Ethernet 1 Gbit--> "сервер 1С" - смысла не вижу))

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

(452) alex1974

Короче говоря - я имею ввиду надо мерить не Загрузку процов
а следующее :

1)Очереди(макс,миним,средн) - чем меньше тем лучше
2)Задержки(макс,миним,средн) - чем меньше тем лучше

вот например
http://www.sql.ru/articles/mssql/02111903performancecounters.shtml

НО если SQL и сервер 1с разделены сетью с высокой латентностью)))

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

Для упорядочивания знаний рекомендую почитать на тему NUMA технологий. Из переведенного самое лучшее - доклад Саши Гладченко.

(454)МуМу
ссылочку можете подкинуть?

(453) что ты уперся? если дожидаться выполнения каждого запроса вида select 1 перед посыланием следующего, то задержки сети будут влиять сильно. если выполнения время запросов больше "задержки сети" на порядки - то на них можно забить. если не дожидаться выполнения запроса (например для асинхронного клиента или когда много клиентов), то суммарное время запросов будет "суммарное время выполнения запросов" + "задержка на посылку ОДНОГО запроса" + "задержка на отправку ОДНОГО ответа"

то тоже можно забить

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

(455) Вот его блог http://msmvps.com/blogs/gladchenko/default.aspx Товарищ действительно пишет нормально, не гилевская школота.

(458) Fragster
хорошо рассмотрим случай под ваше мнение))
-берем Два абсолютно Одинаковых компа.
-попугаи - это = общее Время / 5 000 созданных и проведенных документов

1)разделили Комп1"SQL" и  Комп2"Сервер 1С" на разные компы сеть 1 Gbit Ethernet - получили 16.5 попугаев

2)теперь берем все на Комп1"SQL + Сервер 1С" - 45 попугаев.

Ваше мнение? ))

(460) дисковая какая есть или планируется? ее характеристики?

(460) ты код "попугаеметра" смотрел? он с роду "select 1". и выполняется он в одном потоке и дожидается каждый раз времени выполнения того самого "select 1". Я именно об этом и писал в (456)

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

(460) Повторите эксперимент для варианта, когда эти 5000 доков проводятся на 10 компах.
(462) Это синтетика штоле?

правда в типовом попугаеметре блокировки достанут

(463) попугаеметр? да, конечно...

(462)   Fragster

вы уходите от ответа

вопрос конкретный почему 45 все на одном, и 16.5 при разделении по сети SQL и Сервер 1с?

(466) все объяснено в (456). потому что время выполнения запросов сопоставимо с временем передачи и каждый раз мы дожидаемся выполнения запроса.

Есть упертые парни в русских селениях.

(463) И скорее всего 10 сеансов пользователей не помогут.
Для проверки надо сделать следующий эксперимент: реализуйте клиент скл с простым запросом SELECT 1, далее запустите много раз в цикле с замерами на одном с сервером СУБД компе и на разных. Разница (я уверен в пользу совмещенного с сервером клиента) будет означать разницу между SharedMemory и Sockets. А когда запустить большое количество клиентских программ, то теоретически клиентские приложения могут конкурировать за ресурсы с СУБД ... другие законы. Долго объяснять. А с (468) согласен полностью))

(446) рассматривать нагрузку на ЦПУ без связи с дисковой подсистемой достаточно бессмысленно, если дисковая слабая вам будет достаточно и однопроцессорной системы

к примеру у меня стоит двухпроцессорная система с цпу http://ark.intel.com/products/52577/Intel-Xeon-Processor-X5675-12M-Cache-3_06-GHz-6_40-GTs-Intel-QPI

при этом цпу очень редко загружаются на 100% хотя очень мощная дисковая, конкретная нагрузка недавно - http://www.picamatic.com/show/2012/10/25/12/46/8753235_1360x728.jpg

(467) Fragster
итак по порядку
1)рассматриваем пока ОДНОПОТОЧНЫЙ тест.
2)рассматриваем не  "select 1" , а создание и проведение документов 1с.

т.е. иными словами ваш ответ "Если SQL+1C на Одном компе мы получаем низкие задержки связи SQL<-->Сервер 1С", так? ))

(gallam) меня не интересует написание своего клиента для работы с SQL,
меня интересует только быстродействие "SQL"<-->Сервер 1С"

Мне все это напоминает анекдот: Оторвал таракану все лапки,сказал "беги!" - не бежит.Вывод:без лапок таракан не слышит ???

(471) однопоточный тест клиент-серверной архитектуры не имеет смысла по определению

(474)
все разберем по порядку..

я не говорил что Ограничимся Однопоточным тестом.

"однопоточный тест клиент-серверной архитектуры не имеет смысла по определению"

хорошо перейдем к простым аналогиям
рассматриваем первый кирпичик здания))
Или вы утверждает что Кирпичное здание СРАЗУ САМО СОБЕРЕТСЯ и исчезнут кирпичи, и появится вдруг МОНОЛИТ? ))

через пару месяцев сделаю многопоточный тест, хорош флудить :)

(475) тебе говорят: если отправить 1 запрос селект 1, то время условно будет 1(задержка сети на передачу запроса) + 1(время выполнения запроса) + 1(задержка на время передачи ответа) у.е.
если отправлять х запросов и дожидаясь выполнения предыдущего перед посыланием следующего - то общее время будет х*(1+1+1). если же не дожидаться, то 1+х*1+1

(476) ждем!

(478)Fragster
вы отвечаете вопросом на вопрос.
вам задан конкретный вопрос.

"Если SQL+1C на Одном компе мы получаем низкие задержки связи SQL<-->Сервер 1С" ?

напишите что-то одно либо "Да" либо "Нет"

(479) да. а если разбежаться и об стену, то будет больно. но этот ответ абсолютно бесполезен.

(480) Fragster
понятно...
задавать Вам вопросы Абсолютно бесполезно.. Ибо ответа не будет никогда))

(481) софистика вместо реальности - вот это бесполезно. твои 2 * 3,3 ггц сольют твоим же 4 * 2,8 ггц в многопоточном тесте.

(482) не все так просто, это если гигагерцы перемножать, то теста для этого делать не надо, много зависит от размера данных в тесте

(483) ну, даже если упрется не в проц (как однопоточный текущий), а в io, все равно многопоточных попугаев будет больше

(481) Мы уже проводили подобные тесты. Основные за и против я уже указывал. Какое то впечатление дежавю.:)
В первую очередь ложится дисковая подсистема, затем ЦПУ.Также нужно понимать что это два приложения с большим количеством потоков интенсивно общающихся между собой.Потенциально узким местом может стать шина - но это нужно проверять(пока что гипотеза). Плюс сложности администрирования - нужно выделять квоты на память на ЦПУ.Желательно по дискам разделять(для СУБД отдельно, для сервера приложения и операционки отдельно). Если этого не делать появляются дополнительные риски.

Если это не является узким местом то конечно за одни и те же деньги более оптимальным выбором является один мощный сервак на котором будет крутится

+(485) Дополнение. На котором будут крутится сервер СУБД и сервер приложения. Между прочим когда хотят проверить эффект от технологий типа инфинибанд и других подобных - в первую очередь предлагается провести простейшие синтетические тесты переместив СУБД и сервер приложения на один сервак.(при этом смотреть на основные счетчики, что бы не возникло других узких мест )

(485) у меня другое мнение, но спорить не буду, может я ошибаюсь, тест покажет

(485) МуМу
"Также нужно понимать что это два приложения с большим количеством потоков интенсивно общающихся между собой"

вот именно! "..с большим количеством..." + "...интенсивно общающихся.."

+

(487) Demiurg,
кстати на Инфостарте я задал вопрос - ответ будет? ))

дай ссылку где задал

ок минутка

http://forum.infostart.ru/forum24/topic68077/message779722/#message779722

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

До питерской конференции думаю успеем тесты провести. Инфинибанд точно, своременный езернет 10,40 ГБ - если оборудование(cisco и mellanox) успеем раздобыть.

(493 )там не про обучение было.. там ирония))
ну не работает Shared Memory ни у кого кроме вас.

(494)МуМу
будем ждать ваших тестов сетевого оборудования.

Кстати и про Дисковую систему я с вами Абсолютно согласен.
И никогда не утверждал обратного))

Например: как вы описывали есть случаи и в моей практике - модификации/удаления/добавления большого количества записей. И в таких случаях ложится именно дисковая система первой))

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

Поэтому я сторонник SSD дисков + при работе на таких дисках меньше нагрузка на CPU.

Вот пример демонстрирующий  разницу между массивом RAID 0 и накопителем SSD - с точки зрения загруженности ЦП, средней очереди диска и количества транзакций БД.
http://ru.intel.com/business/community/index.php?automodule=blog&blogid=143&showentry=3067

Что за утка про видеокарту? я прочитал и не понял.

+ к (496)
"большого количества записей..." разговор идет о миллионах строк в БД.

(497)AlexNecro
про видюху - реально утка))
не работает ни ms sql ни 1С на CUDA)))

Вашу энергию да б в мирных ядерных целях.

(500) H A D G E H O G s
дык давно просил меня забанить))

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

496) Вариант базу на рамдрайв ен предлагать. Ибо серверные Ксеоны http://ark.intel.com/products/64587 вроде как сотни гигабайт умеют вращать одним процом?
а 32 можно и в десктоп задешево засунуть?

(502) kauksi
уточните вы предлагает базу на рамдрайв?

c RAM-диском в оперативке... не все так гладко.
1)тырит Оперативку у других процессов
2)тырит i/o по CPU-RAM - у других процессов.
3)нет надежности

Даже проверяли частный случай
(не рам-диск но пункт 2)-присутствует) - программный RAID механических дисков. Так вот из-за пункта 2) скорость работы 1С падала.

(502)  kauksi
или вы bмели ввиду рамдрайв = SSD? ))

(495) Я думаю вот этот тред всё объяснит :)
v8: Интересно а серверная часть 1С V8.1 может работать с Shared Memory SQL 2005

Обратите внимание на даты :)

(506) babys

обратил)) все осталось также и по сей день))

1c "работает" по Sharaed Memory у единственного человека в стране))

хотя если честно
то теоретически (не проверял на практике):
Named Pipe =(почти) Shared Memory - если клиент и MS SQL на одной тачке

503) SSD и так есть. могу купить еще и сделать RAID1 или 10 из них. Могу купить много оперативки и выделить под базу/темп винды. Благо размер базы позволяет пока что.
Интересует максимальная производительность 1С в файловом однопользовательском режиме для перепроведения документов (восстановления последовательности), изменения больших обьемов данных (обработка справочников, регистров сведений). Я так понимаю что для теста Гилева все таки частота проца/памяти играет большую роль чем скорость дисковой подсистемы. Поменяю мать, разгоню проц 3570K , о результатах отпишусь.

(509)kauksi
для вашего случая такой тест уже проводили(разгоняли I5 и I7).

Разгон проца дает впечатляющий результат.
+ немалую роль играет где находится контроллер памяти.
т.е. в самом процессоре или на материнке.

(507) https://lh6.googleusercontent.com/-XkFyxHyQi6s/UIxp5uXyglI/AAAAAAAACpw/S3I0ZYbceEc/s447/Снимок35.jpg

(501) я тебе говорю, что ты теплое с мягким сравниваешь, а ты мне "тролль! тролль!". эх...

(511)  Demiurg
1v83 --- мне кажется таки 1с 8.3, а не 8.2 так? ))

(511) Уже жевали сто раз
v8: Сервер приложений и MSSQL на одном физическом сервере

(512) Fragster
А я тебе говорю "при разнесении SQL и Сервера 1С - на разные компы соединенные Ethernet 1Gbit" -
мы получаем ИЗНАЧАЛЬНО НИЖЕ ПЛИНТУСНУЮ производительность на каждого пользователя и тащимся от того что нет допустим сильного падения на 100 пользователях)).

Ну это ппц.. выше описанные мной примеры 45 vs 16.5 попугаев

"что влияет на скорости ЗАПИСИ и ЧТЕНИЯ в RAM. Что и есть основа быстродействия 1с 8.х."

А поясните нубику - это следствие мягкой типизации языка 1с, и возникающего из-за этого неэкономного использования оперативной памяти?

(515) зачем вообще тестировать однопользовательский режим, если будет 100+ пользователей?

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

(518) скорость дает расширение узкого http://sasja.shap.homedns.org/Uzkoe.jpeg

места

(515) эти попугаи не показывают реальную производительность. они только проц на полную грузят.

(521)+ для того, чтобы проверить - делаешь копию и запускаешь восстановление последовательности. вот тут будет реальный тест.

(516) Стрим
>"что влияет на скорости ЗАПИСИ и ЧТЕНИЯ в RAM. Что и есть
>основа быстродействия 1с 8.х."

>А поясните нубику - это следствие мягкой типизации языка 1с, и
>возникающего из-за этого неэкономного использования
>оперативной памяти?

Это следствие того что язык 1С работает не с табличками и сторками БД, а он работает с ОБЪЕКТАМИ - данные которых содержатся в многочисленных Таблицах и строках БД.
Ну грубо говоря как-то так))

+
на самом деле - Прокрутка и Изменения Объектов в RAM -  ничего плохого в этом нет))

Почитайте например про великий и могучий SAP
использует как они называют:
"инновационную технологию IN MEMORY" - конечно там завернуто все покруче чем у нас в 1С.... не буду описывать подробно,
но основной смысл думаю понятен? ))

очень интересно. сам заметил что на в клиент серверном варианте у меня раньше на двух ядерном проце работало намного шустрее с 4мя гбами оперативки чем сейчас на 6 ядерном проце с 8 гб оперативки

всю тему пока не осилил, но тоже попинаю автора:
А размер баз на которых производилось тестирование какой?
----
Может там тупо вся база в оперативку SQL сервера помещается

(526) ))) попинать это у нас завсегда))
сначало принято у нас бить...а потом разбираться))

БД максимально до 60 Гигабайт
тестов было много от Гилевского до "Стандартного нагрузочного 1С" и до тестов на Реальной Базе УПП

притом На серверах(рабочих) RAM=32 Гб + базы от 1с 7.7 и другие 1с 8.2.

(527) т.е. восстановление последовательности в УПП на одной и той же базе в случае, когда сервер 1с и SQL на одной физической машине, было в 3 раза быстрее (16 vs 45 баллов)?

(528)  Fragster

у нас нет необходимости "восстановление последовательности.."
в полном смысле)) ИМХО РАУЗ( Расширенная Аналитика Учета Затрат),
Но близко по смыслу есть "Расчет себестоимости" - делающий миллионы записей в регистрах.

45 попугаев -это сервер для программистов(собран из десктопа RAM = 3 ГБ) (Реальный же сервер(RAM = 32 ГБ) 20 попугаев)

да есть второй абсолютно такой-же конфигурации.
Да при разделении на разные SQL и Сервер 1с "Расчет себестоимости" - проходил значительно медленней

Я не знаю, что и где вы там меряете... Но на моей базе всё упирается в скорость обмена с дисками...

(530)ДенисЧ
Размер БД и количество RAM сервера в студию))

" на моей базе всё упирается в скорость обмена с дисками..."
откуда вывод? очереди к дискам? своп файл случайно не юзается по полной? ))

(531) база - 70Г, рамы - 32ГБ, скуль и сервер 1с - на одной железке. Скуль ограничен 20ГБ.

вывод - да, именно из очередей и просмотра счётчиков в перфмоне.

(532)
сначало уточню.. потом про очереди скину ссылку))
своп файл случайно не юзается по полной? ))

ладно еще раз про Очереди скину ссылку

http://ru.intel.com/business/community/index.php?automodule=blog&blogid=143&showentry=3067
смотрим картинки
1) "Результаты для RAID 0"
2)"Результаты для SSD"

и что мы видим ? видим что на SSD большие очереди но SQL-транзакций в 6 раз больше успевает за тоже время.

так что Очереди не всегда не показатель просадки на дисках))

(533) если верить счётчикам - нет. Есть явная зависимость нагрузки дисков (разных физически) от вида выполняемого процесса (я некоторые таблицы базы вынес на отдельные диски)

тфу))
так что Очереди не всегда - показатель просадки на дисках))

(534) У меня не SDD, a SAS

смотрим картинки
1) "Результаты для RAID 0" -sas ))

Я просто вижу, в какой момент идёт просадка скорости... А именно - при записи в регистры...

(540)ДенисЧ
ну в вашем случае все в комплексе))
работа c sas Дисками грузит проц + грузят проц(SQL + сервер 1С)

короче не хватает IOPs-ов)) как с Оперативкой так и с дисками.

Надеюсь написал понятно))

(541) Вот я и говорю, что диски просаживают...

(542) да
но просаживают они не только I/O на шпинделях  + еще и I/O CPU -RAM.... а там дальше эффект домино в цикле))

Вот как раз цпу в эти моменты почти не нагружен, по тем же счётчикам...

они погоду показывают.

1)пример
можно написать приложение которое будет отдавать квант на миллисекунды раньше его истечения...
так вот реально загрузить проц на 99% - при этом загрузка по мнению диспетчера будет никакой

2)пример
если 1с серверу и SQL не хватает I/O CPU-RAM....

А вообще можете конфу вашего сервера поподробней скинуть,если не секрет конечно?

конфа... Точно не помню, но зионы интеловские Е5620 2.4, 32ГБ памяти, два рейд-контроллера, один наплатный, второй вставной...

вот Ваш "Xeon Е5620 (4 x 2.4 Ггц)" Westmere-EP
частоты Ядер не велики, скорости работы с памятью тоже не велики))

тему почему с быстродействием 1с поднял..

выбираем сервер Новый))
пока остановился на:
(предположительно Одно-юнитовый IBM(правда пока поставщик завысил цены в  ТРИ раза - трем эту тему с ним)
2-ух процессорной системе Intel Xeon E5-2643 (2х4=8 ядер, по 3.3 Ггц если без TB) QPI 2х8 GTs
т.е. Два процессора будут Связаны - Двумя шинами QPI с сумарной скоростью 32 Гб/сек в Одну сторону.
+ убеждаю сисадмина таки взять SDD.

+(547) оЧепятка )) SDD = SSD

(494) МуМу
у вас как там хотя-бы двигается дело с тестом Infiniband и др. современных скоростных сетей насчет MS SQL?

Интересно, кто нибудь может запустить тест Гилева на AMD FX-8350 (Vishera). Все таки 4Ггц. Интересно было бы посмотреть на попугаи в сравнении с Интелом на такой же частоте. Вроде как уже есть в продаже...

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

+(551) Ускорение я писал про инфинибанд. А езернет я имею ввиду 1 GB. 10,40 GB пока не було возможности сравнить.

Всё не осилил, потому-что скучно. 550 постов обсуждать, что чем быстрее процессор и оперативка, тем быстрее выполняется однопоточное приложение в однопользовательском режиме.

+(551) В протоколе шаред мемори в вырожденном случае разница составляет 7 %. На реальных системах разница будет доли процентов.

(551)МуМу
1)"через нетпайпс" - это что такое уточните?

2)"В протоколе шаред мемори в вырожденном случае разница составляет 7 %." - разница с чем и какая разница прирост или падение? ))
3) замеры чисто SQL или в связке с сервером 1с?

Посоветуйте сервачок на 10 пользователей терминал + 8.2 + SQL

(sanfoto) Кстати в свое время делали перевод интересной статьи по pwd. К сожалению потрогать на стенде это чудо не дали.
Вот ссылка http://softpoint.ru/article_id409.htm  
Что интересного - оказывается в некоторых моментах узким местом может стать шина.:) Только на досупных нам серверах это явление к сожалению наблюдать не удается.

(555)Что касается шаред мемори - проверяли на локально, запускали не 1С(для 1С нужно драйвер подменять, да и то 8.2. не факт что заупстится). Смысл теста - интенсивная, многопоточная  генерация запросов с различным размером пакетов(как на отправку так и на получение). Разница составила не более 7-и процентов в прирост с шаред мемори. В силу этого дальнейшие тесты прекратили. На тестах с 1С будет разница еще меньше, так как будет значительно больше соотношение времени выполнения на SQL и отправки-получения приложением.  Впрочем про это подробнее позже напишем.

не дает мне сына переписку вести))
завтра продолжим

(556) тебе сюда:
http://3nity.ru/viewforum.php?f=40&start=0

(559) И зачем мне туда? Мне и здесь неплохо:)

Кстати провели тест на так сказать "Вырожденном" случае:
(тестовый сервер для программистов)

1)нехватка оперативки (RAM всего 2 Гб)
2)объем БД 66 Гб
2)SQL + Сервер 1с - на одном компе
3)софтварный RAID - зеркало
4)Запись/Удаление/Чтение огромного количества строк БД(проведение/депроведение "Расчет себестоимости" + Отчет собирающий данные с огромного количества записей регистров(за год). - инициировано одним пользователем.

***************************************
Результаты:
1)Да диски просели напрочь.... Очереди пик до 600
2)но еще больше нагрузка была на работе с Оперативной памятью (например обмен страниц в секундах, Pages/sec пик до 9000)
3)при этом счетчики загрузки CPU - в среднем 35%
4)работа других пользователей была весьма затруднена)) большой отклик на любой операции
5)естественно активно использовался своп
**************************

К чему я клоню - а к тому что СИЛЬНО недооценивают работу с оперативной памятью. т.к. обычно заостряют внимание на загрузке: CPU,сети и дисковой системы.

(557) МуМу
касательно ваших тестов проверяли Вы хотя-бы "обмен страниц в секундах, Pages/sec" на на сервере где находится SQL?
Если да, то интересны результаты))

http://support.microsoft.com/kb/139609

"Заголовок такой: PerfMon: High Number of Pages/Sec Not Necessarily Low Memory

Перевожу на русский: Высокое значение Pages/Sec НЕ ОБЯЗАТЕЛЬНО говорит о малом кол-ве памяти. "

Это означает, что какое-то ПО интенсивно юзало память. Например переложило один мегабайта ОЗУ с одного адреса в другой адрес раз эдак 9000. Зачем? Ну например сортировку данных выполняло.

(563) это не про (561). там вообще эксперимент уныл.

и все там уперлось в диски

(565) Fragster
да в диски)) но и работа с памятью была на пределе
эксперимент как я писал с "Вырожденым случаем"

сегодня поставим следующий
1)оперативки (RAM всего 4 Гб)
2)объем БД 66 Гб
2)SQL + Сервер 1с - на одном компе
3)софтварный RAID0 (4 шт SSD)
-tempBD
-базы данных  
-файл подкачки

4)Запись/Удаление/Чтение огромного количества строк БД(проведение/депроведение "Расчет себестоимости" + Отчет собирающий данные с огромного количества записей регистров(за год). - инициировано будет одним пользователем.

+к (561) кстати забыл указать SQL Transaction/s пик до 400

+ к (566)
поправка(больше ГБ) - "1)оперативки (RAM всего 6 Гб)"

вопрос в тему:
сейчас удаляю документы реализаций (тупо Объект.Удалить()), параллельно решил запустить удаление сч/фактур, при этом общая загрузка проца так и осталась 25% (25-28)
Почему так? Думал, что по-больше загрузка должна быть.
PS загруженность диска (SSD: система и база в одном) минимальная

(569)John83
процы какие?
в (0) - все описано)) частоты CPU и скорость CPU-RAM - таки))

+ режим 1с клиент-серверный?

(570) проц i5 4х-ядерный
забыл сказать, база файловая

(566)
результаты теста в сравнении спредыдущим.
1)Очереди к дискам пики выросли 600 до 900
2)загрузка CPU примерно таже
2)обмен страниц/сек пики выросли с 9 000 до 29 000
4)работа других пользователей все гуд как буд-то и нет нагрузки -система работает без задержек.
5) время Депроведения/Проведения(Расчет себестоимости) - уменьшилось почти в 4 раза
6)SQL Transaction/s пик до 600, притом среднее количество поднялось с 20 до 40
*************************************
обратите внимание на пункт 2) и сравните с пункт 5)

(572) John83 -у меня такой дестоп))

для файлового варианта - для вашего случая
1)т.к. -1с грузит всеравно одно ядро
- отключаем в BIOS 2-а лишних)) (останется два)
-Включаем TurboBoost
наблюдаем прирост производительности))

(566) поставь туда 16 гигов оперативы и проверяй.
ну и будет ли проверка 4 гига на одном сервере vs 2 сервера по 2 гига?

6

sanfoto

568 - 31.10.12 - 09:39
+ к (566)
поправка(больше ГБ) - "1)оперативки (RAM всего 6 Гб)"

(572) в 2-х 1сках запустил?

(578 ) Fragster
ой точно упустил из виду что две проги))
тогда нет смысла отключать ядра

(573) Посмотри в первую очередь на счетчик SQL page life expentacy - это для SQL самый показательный счетчик для работы с памятью.(время жизни страницы). Он показывает как вытесняется быстро память. Будет меньше 500 или будут резкие пики падения - значит не все хорошо.
Но в любом случае твои выводы неверные. Да - если памяти не хватает это действительно не гуд и диск становится сразу же узким местом. Но даже если памяти поставить по максимуму(уж на памяти точно не стоит экономить) все равно диск при такой конфигурации остается потенциально узким местом номер один.

...........
2)обмен страниц/сек пики выросли с 9 000 до 29 000
.............
5) время Депроведения/Проведения(Расчет себестоимости) - уменьшилось почти в 4 раза

------------------------
математика
29 000/9 = 3.22 - и примерно на столько-же увеличилась скорость проведения))

(581) дык в кэш потому что заколбасило

(580) МуМу
"Но в любом случае твои выводы неверные."
весьма расплывчиво какие именно выводы вообще все?))
давайте по порядку:
*******************************************
Выводы:
1)Производительность 1с 8.х больше всего:
- зависит от Частоты Ядра процессора
- зависит от скорости работы CPU-RAM
(кстати к MS-SQL - это тоже относится)

2) чем больше процессоров тем хуже производительность 1С -
- падает скорость работы CPU-RAM
(Два процессора связанные 2-мя QPI -предел аппаратной конфигурации)

3)Чем больше ядер в процессоре - тем ниже Частота ВСЕХ ядер и хуже производительность 1с.
***************************************
добавлю пункт
4)проблему с дисковой системой снимаем SSD

(583) так неверные же

......и говорят ему земля "есть плоская" ,
а ты НЕВЕРНЫЙ утверждаешь что она "круглая" .... )))
вот как то так

(sanfoto)Я конкретно про то что мало уделяем внимания оперативной памяти. Это очень вырожденный случай(можно вообще ограничить память на 500 мБ и посмотреть), к тому же все равно узким местом становится диск. Памяти можно добавить сколько угодно но потом все равно диск станет узким местом.