Не буду описывать предысторию и проведенные тесты..
посмотреть можно тут 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).

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

Интересно, кто нибудь может запустить тест Гилева на 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 мБ и посмотреть), к тому же все равно узким местом становится диск. Памяти можно добавить сколько угодно но потом все равно диск станет узким местом.

(578) да, два сеанса пашут

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

(574) а как примерно в биосе называется опция по отключению ядер? сейчас чего-то покопался - ничего похожего не нашел

(586) МуМу
т.е. инымы словами вы имеете ввиду

что при огромных объемах БД... мы не угонимся за ними наращиванием объемов RAM, так? - я согласен.

т.е. вы вообще рассматриваете исключительно сам MS SQL?

*************** а вот что нужно мне********************
Меня как раз интересует "ЧАСТНЫЙ" случай взаимодействие "SQL" с "сервером 1с" и здесь проявляются ярче всего:
1)частоты CPU
2)скорость работы CPU-RAM
3)скорость обмена SQL -сервер 1с (притом Ethernet Gbit и Оптика - показали себя не ахти((( т.е. пока Оптимум все на одном сервере)

(589) John83
сейчас перезагружу комп скажу название

(589) John83
у меня опция BIOS- "Active Processor Core" -
находится в меню "Main"
(меньше 2-ух ядер - результаты были чуток похуже ИМХО операционка тоже кушать хочет)

Часть конструкций SQL(и не только на запись) работает с БД независимо от наличия памяти.То же касается сервера приложений 1С.  Поэтому независимо от наличия памяти дисковая система потенциально может стать узким местом. Я это не раз наблюдал. То есть счетчик времени жизни страниц в норме а дисковая система нагружена. Это утверждение не является общим. Это адресовано к вашему утверждению относительно важности объема оперативной памяти.

(592) премного благодарен!
поищу - попробую

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

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

МуМу
ну это все понятно касательно MS SQL,

но таки "...утверждению относительно важности объема оперативной памяти..."
я утверждаю немного не так))

поясню:
Объем RAM -конечно важен,
но НЕ МЕНЕЕ важна скорость работы с этой RAM -
т.к. это самый быстрый "НАКОПИТЕЛЬ ДАННЫХ" - то все приложения более менее оптимизированы под работу с Данными именно в RAM.

+(597)
SAP (in memory)- вон вообще предлагают отказаться в будущем от дисковых хранилищ))

(597)
и еще я говорю не про пропускную способность самой RAM,
она как раз на данный день превосходит процессорные возможности ее ПРОКАЧАТЬ)) (если без разгона)

я говорю про CPU-RAM! -
ИМХО важна производительность CPU и организация доступа к RAM/
 например при встроенном в проц. контроллере результаты лучше чем - у CPU -такой-же частоты но контроллер на материнской плате.

по конфигурации компьютера из (566)

в данный момент
1)запустили групповое проведение разных периодов на разных компах в нескольких клиентах
2)запустили так же несколько клиентов - просто покликать по справочникам и документам - ТОРМОЗОВ НЕТ
3)на сервере на дисках - ТОРМОЗОВ НЕТ
4)SQL -транзакций/сек в среднем 100 и пик до 400

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

(601) у нас в тех магазинах, где поставили ССД - они вылетают с регулярностью полгода-год. правда прирост они дают раза в три, это да.

у нас серверные SLC от интел)) SSD X25-E
сдается мне чтобы они вылетели ждать надо годы...

(600)  Вы просто не умеете их готовить:) Подключите меня на 10-ть минут к БД я вам пару запросов таких наклепаю что тормозить будет мама не горюй:) Основные тормоза дают запросы на чтение. Вот тогда то и начнется резкая деградация.

(604) МуМу

эээ я и сам так умею))) даже Одним запросом ложил практически на колени рабочий сервак.

(592) нашел я эту настройку, включил turbo boost.
Для тестирования производительности, использовал загрузку dt.
При этом загрузка отличалась всего секунд на 5-10 (всего ~3.20), хоть на 1м, 2х, хоть на 4х

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

(608)  John83
turbo boost - временно может повысить частоту ядра ... если не юзаются другие и если большая нагрузка именно на этом ядре.

если у вас как и у меня I5 2300 - предел частоты 3.1 Ггц.

+ динамическую смену множителя и частоты можно смотреть например утилитой AIDA ))

+ рекомендую настроить
"Управление питанием" схема = "Максимальная производительность"

(609) у меня-то i5-2550K
сейчас, почитав мануалы, с 3.4 разогнал до 4.6, но все же хотелось использовать "два ядра в одном", но что-то не получается - видать чайник
Надо будет поинтересоваться у знающих людей.
Еще раз спасибо :)

(580) МуМу
всетаки провел по вашей рекомендации замеры "page life expentacy" -
фактически насколько я понял это работа с буфером или иными словами с "Закэшированными данными".

Результаты:
1)если tempDB и сама база на отдельных SSD -
значение этого параметра периодически менялось и иногда падало до Нуля и пики до 1500, но в среднем было очень низким.
2)если tempDB и сама база на отдельных SATA механич.дисках-
значение этого параметра стабильно в районе 840.
*************************
Выводы:
1)SSD - конечно как и ожидалось дает прирост
в среднем проведение документов одновременно в нескольких клиентах было быстрей в два раза по пункту 1)

2)на параметр "page life expentacy" - ориентироваться в  случае SSD - особенно не стоит

(613) ой пордон поправка
 пункт 2)если tempDB(SSD) и база на  SATA механич.диск

+ к (613)
Результаты:
....
....
3)если tempDB и сама база на отдельных SATA механич.дисках-
значение этого параметра стабильно в районе 1000. -время проведение примерно тоже что и пункт 2)

т.е. еще одно подтверждение что параметр "page life expentacy" - важен только в случае механических дисков))
как то так..

(613)(615) Прочитал все, но не понял откуда вывод)) Поясните подробнее пож.

+ (616) вы понимаете физический смысл "page life expentacy"?

фактически насколько я понял это работа с буфером или иными словами с "Закэшированными данными".

дословный перевод "время жизни страницы" ))

(618) Предлагаю вам четко знать (это описано в интернете) и тогда выводы, на мой взгляд, изменятся.
Подсказка:
- Загрузка диска (подчеркиваю любого типа)  - следствие "page life expentacy", а не наоборот.
Поэтому вывод: "т.е. еще одно подтверждение что параметр "page life expentacy" - важен только в случае механических дисков)) " - вообще не о чем.

+(620) Сравните скорость получение данных из памяти (кеша) и с диска (пусть даже SSD)!!!

стоп я говорю про счетчик
SQL:Database\page life expentacy

(622) и я)

хорошо теперь давайте уточним и по порядку))

SQL:Database\page life expentacy - высокое значение параметра - свидетельствует об активном использовании MS SQL Закэшированных данных, так?

(624) Ваша формулировка абстрактная и непонятная. Я применяю следующую - данные удерживаются в кеше MS SQL дольше, когда значение этого счетчика выше.

хорошо перефразирую так

SQL:Database\page life expentacy - высокое значение параметра - это показатель того что Одни и Те-же данные долго лежат в Кеше, так?

(626)Я даже более скажу - счетчик измеряется в секундах. А на русском "Ожидаемая длительность нахождения страницы данных в кеше MS SQL". Давайте вернемся к вашим выводам и их пересмотрим.

и все-таки сначала уточню Ваш ответ на (626) = Да?

))

(628)Философией,софистикой упражняетесь?:)
Общий вывод последней дискусии можно сформулировать следующим образом. Время жизни страниц памяти зависит от наличия памяти а также от специфики ИТ системы.(дисковая система будет в данном случае влиять только на время запросов получаемых не из кеша).Дисковая система не влияет на этот счетчик.  Если ИТ система неоптимальна - аналитические данные будут постоянно вытеснять оперативные что не есть гуд.

(630) МуМу
))
по частям отвечу))
1)"Общий вывод последней дискусии можно сформулировать следующим образом. Время жизни страниц памяти зависит от наличия памяти а также от специфики ИТ системы.(дисковая система будет в данном случае влиять только на время запросов получаемых не из кеша)."
- мой ответ Да согласен

2)"Дисковая система не влияет на этот счетчик. " - тут вы пишете противоположное пункту - 1) "дисковая система будет в данном случае влиять только на время запросов получаемых не из кеша" -
т.е.  Если данные будут браться в основном НЕ ИЗ КЕША - то SQL:Database\page life expentacy - всеравно будет РАВНО БОЛЬШОМУ числу, так?

))

Короче говоря в случае с 1С -
Только Наличие большого количества RAM на SQL-сервере превосходящего Базу Данных по объему позволит активно юзать кеш в случаях:

1) пишем запрос SQL( не а 1с, а именно SQL) - SELECT по каждым табличкам базы 1С - я так делал еще со времен 1с 7.7.

2)если долго не перезагружаем сервер и активно работаем в программе.

(631)Здесь нужно рассуждать логически.В моих утверждениях нет никакого противоречия. В скобках я указал специально ньюансы которые не играют роли но могут ввести в заблуждение. Сформулирую по другому. Проведем мысленный эксперимент.
Запускаем 1000 одинаковых запросов. Запускаем их на одном и том же сервере, только в одном случае один винт а в другом другой. Значение этого счетчика будет неизменным. Сразу хочу сказать что здесь важно эксперимент проводить синхронно. Важно получить диференциал. Потому как если вы просто ничего не будете делать с сервером - время жизни страниц памяти будет расти. Соответсвенно время жизни страниц в двух экспериментах может отличаться только на время выполнения эксперимента.(за счет того что на быстром диске выполнится быстрее) Если его исключить - то оно будет точно одинаковым. В том  то и ценность именно этого счетчика что он является показателем системы а не оборудования(кроме памяти разумеется).

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

)) естественно если ЗАПРОСЫ ОДИНАКОВЫЕ - они выбирают ОДИНАКОВЫЕ ДАННЫЕ - т.е. после первого запроса все будет идти из кеша,
но Если только хватает объема Кеша.

именно по этом я провел эксперимент по групповому проведению документов в разных периодах и одновременно в нескольких клиентах
1)на сервере 6 Гб RAM
2)База размер 66 Гб
3) все на SSD (tempDB и база) - специально для  Шмузер - среднее значение обсуждаемого счетчика =22 (пик 1500- был один раз в течении секунды с резким взлетом и падением.)
4) все на SATA -механических - среднее значение 840 и максимальное 846

(635) Шмузер
а если взять за значение вашего термина "скорость автомобиля" - "скорость проведения документа в 1С" ,
то
из сообщения (636)

автомобиль из пункта 3) до конечной остановки пришел в 2,5 раза быстрей

чем
Автомобиль из пункта 4) до конечной остановки

короче ничего нового в данной ветке я не узнал))
кроме приобретения опыта как заметил специалист из Софт-Поинта

МуМу
(630) - 01.11.12 - 12:05
Философией,софистикой упражняетесь?:)

и ответа на вопрос из (0) так и нет((

(636) Давление у вас высокое в памяти, вот при использовании ссд сервер и понимает, что может часть информации выпустить из памяти наружу и потом относительно быстро ее достать обратно. При использовании сата он видит, что хранить данные на диске накладно по времени доступа, и держит все, что помещается, в памяти, иногда полностью обнуляя кэш.
(637) Вы слово "память" не услышали? У вас время жизни = 0 - высокое давление, что может быть вызвано низкой производительность памяти или недостаточным объемом.

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

Народная медицина какая-то :)

"вы не стали создавать ПО для тестов"
улыбнуло.))))))
Хотя на самом деле тестов использовалось много, НО...

Смотрите на производителей процов - они затачиваю тесты под свои чипы - что не есть реальные задачи.

И что мы видим ооо круто Xeon 10-ядерный(по 2 Ггц) по тестам от Intel рвет Xeon 4-ех ядерный(по 3.3 Ггц) той-же технологии. - ИМХО это чистый маркетинг.
Тест написан под ИДЕАЛЬНО РАСПАРАЛЛЕЛЕНУЮ задачу - что в реальности мало-достижимо.

(642) Для всего есть своя область применения, вы же пытаетесь сделать обобщающие выводы на основе своих наблюдений за частным случаем в плохой лаборатории.
P.S. В конце-концов, даже при использовании приложений, которым более 4-х ядер не нужно, возможно повысить производительность системы, отключив лишние ядра - начнет работать TurboBoost и все 30 мегабайт кэша L3 достанется четырем ядрам.

(643) Шмузер

1)вы на реальных сервера такое видели?))
чтобы простаивали большинство ядер

2)фигу  TurboBoost поднимет одновременно 4-ядра с 2 Ггц до 2.9 даже, а вот если ТОЛЬКО ОДНО ядро будет загружено да такое видел))

ладно всем пока)) покидаю таки эту ветку на месяцок другой))

(609) ну в общем знающие люди мне тут сказали, что отключение процов - это больше для экономии энергии/уменьшения температуры проца
в общем как-то вот так :)

(646) о настройках http://olontsev.ru/2012/11/cpu-power-options-and-sql-server-performance/

Приехала нормальная мать. Разгон Core i5-3570k до 4,6Ггц дает 61,57 в тесте Гилева. Правда память работает на 1333МГц. у кого больше?

продолжение данной темы
на Выбор сервера 1С 8.х (клиент-серверный режим)