Имя: Пароль:
1C
Админ
1с 8.х от чего зависит скорость и Миф о многопроцессорных/многоядерных серверах
0 sanfoto
 
14.10.12
15:24
Не буду описывать предысторию и проведенные тесты..
посмотреть можно тут 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).

У кого есть техническая возможность проверить..протестируйте пожалуйста!
550 kauksi
 
30.10.12
15:32
Интересно, кто нибудь может запустить тест Гилева на AMD FX-8350 (Vishera). Все таки 4Ггц. Интересно было бы посмотреть на попугаи в сравнении с Интелом на такой же частоте. Вроде как уже есть в продаже...
551 МуМу
 
30.10.12
16:40
(594) Да движутся, Сегодня например сравниваем локально шаредмемори с работой через нетпайпс. Предварительно при линейной скорости в два раза ускорение(по сравнению с езернет, в полтора раза больше чем локально).Но это очень выражденный случай. Сейчас вспоминаем ситуацию когда происходила резкая деградация(при превышении определенного количества пакетов). Сейчас почему то не получается смоделировать.
552 МуМу
 
30.10.12
16:58
+(551) Ускорение я писал про инфинибанд. А езернет я имею ввиду 1 GB. 10,40 GB пока не було возможности сравнить.
553 Настоящий Волшебник
 
30.10.12
17:26
Всё не осилил, потому-что скучно. 550 постов обсуждать, что чем быстрее процессор и оперативка, тем быстрее выполняется однопоточное приложение в однопользовательском режиме.
554 МуМу
 
30.10.12
17:32
+(551) В протоколе шаред мемори в вырожденном случае разница составляет 7 %. На реальных системах разница будет доли процентов.
555 sanfoto
 
30.10.12
17:42
(551)МуМу
1)"через нетпайпс" - это что такое уточните?

2)"В протоколе шаред мемори в вырожденном случае разница составляет 7 %." - разница с чем и какая разница прирост или падение? ))
3) замеры чисто SQL или в связке с сервером 1с?
556 aka MIK
 
30.10.12
18:08
Посоветуйте сервачок на 10 пользователей терминал + 8.2 + SQL
557 МуМу
 
30.10.12
18:37
(sanfoto) Кстати в свое время делали перевод интересной статьи по pwd. К сожалению потрогать на стенде это чудо не дали.
Вот ссылка http://softpoint.ru/article_id409.htm  
Что интересного - оказывается в некоторых моментах узким местом может стать шина.:) Только на досупных нам серверах это явление к сожалению наблюдать не удается.

(555)Что касается шаред мемори - проверяли на локально, запускали не 1С(для 1С нужно драйвер подменять, да и то 8.2. не факт что заупстится). Смысл теста - интенсивная, многопоточная  генерация запросов с различным размером пакетов(как на отправку так и на получение). Разница составила не более 7-и процентов в прирост с шаред мемори. В силу этого дальнейшие тесты прекратили. На тестах с 1С будет разница еще меньше, так как будет значительно больше соотношение времени выполнения на SQL и отправки-получения приложением.  Впрочем про это подробнее позже напишем.
558 sanfoto
 
30.10.12
19:28
не дает мне сына переписку вести))
завтра продолжим
559 SachoZ
 
30.10.12
21:39
560 МуМу
 
30.10.12
23:59
(559) И зачем мне туда? Мне и здесь неплохо:)
561 sanfoto
 
31.10.12
07:34
Кстати провели тест на так сказать "Вырожденном" случае:
(тестовый сервер для программистов)

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

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

К чему я клоню - а к тому что СИЛЬНО недооценивают работу с оперативной памятью. т.к. обычно заостряют внимание на загрузке: CPU,сети и дисковой системы.
562 sanfoto
 
31.10.12
07:37
(557) МуМу
касательно ваших тестов проверяли Вы хотя-бы "обмен страниц в секундах, Pages/sec" на на сервере где находится SQL?
Если да, то интересны результаты))
563 sanfoto
 
31.10.12
08:24
http://support.microsoft.com/kb/139609

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

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

Это означает, что какое-то ПО интенсивно юзало память. Например переложило один мегабайта ОЗУ с одного адреса в другой адрес раз эдак 9000. Зачем? Ну например сортировку данных выполняло.
564 Fragster
 
гуру
31.10.12
08:26
(563) это не про (561). там вообще эксперимент уныл.
565 Fragster
 
гуру
31.10.12
08:27
и все там уперлось в диски
566 sanfoto
 
31.10.12
08:50
(565) Fragster
да в диски)) но и работа с памятью была на пределе
эксперимент как я писал с "Вырожденым случаем"

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

4)Запись/Удаление/Чтение огромного количества строк БД(проведение/депроведение "Расчет себестоимости" + Отчет собирающий данные с огромного количества записей регистров(за год). - инициировано будет одним пользователем.
567 sanfoto
 
31.10.12
08:54
+к (561) кстати забыл указать SQL Transaction/s пик до 400
568 sanfoto
 
31.10.12
09:39
+ к (566)
поправка(больше ГБ) - "1)оперативки (RAM всего 6 Гб)"
569 John83
 
31.10.12
09:52
вопрос в тему:
сейчас удаляю документы реализаций (тупо Объект.Удалить()), параллельно решил запустить удаление сч/фактур, при этом общая загрузка проца так и осталась 25% (25-28)
Почему так? Думал, что по-больше загрузка должна быть.
PS загруженность диска (SSD: система и база в одном) минимальная
570 sanfoto
 
31.10.12
10:04
(569)John83
процы какие?
в (0) - все описано)) частоты CPU и скорость CPU-RAM - таки))
571 sanfoto
 
31.10.12
10:05
+ режим 1с клиент-серверный?
572 John83
 
31.10.12
10:06
(570) проц i5 4х-ядерный
забыл сказать, база файловая
573 sanfoto
 
31.10.12
10:16
(566)
результаты теста в сравнении спредыдущим.
1)Очереди к дискам пики выросли 600 до 900
2)загрузка CPU примерно таже
2)обмен страниц/сек пики выросли с 9 000 до 29 000
4)работа других пользователей все гуд как буд-то и нет нагрузки -система работает без задержек.
5) время Депроведения/Проведения(Расчет себестоимости) - уменьшилось почти в 4 раза
6)SQL Transaction/s пик до 600, притом среднее количество поднялось с 20 до 40
*************************************
обратите внимание на пункт 2) и сравните с пункт 5)
574 sanfoto
 
31.10.12
10:22
(572) John83 -у меня такой дестоп))

для файлового варианта - для вашего случая
1)т.к. -1с грузит всеравно одно ядро
- отключаем в BIOS 2-а лишних)) (останется два)
-Включаем TurboBoost
наблюдаем прирост производительности))
575 Fragster
 
гуру
31.10.12
10:22
(566) поставь туда 16 гигов оперативы и проверяй.
ну и будет ли проверка 4 гига на одном сервере vs 2 сервера по 2 гига?
576 sanfoto
 
31.10.12
10:22
6
577 sanfoto
 
31.10.12
10:22
sanfoto

568 - 31.10.12 - 09:39
+ к (566)
поправка(больше ГБ) - "1)оперативки (RAM всего 6 Гб)"
578 Fragster
 
гуру
31.10.12
10:23
(572) в 2-х 1сках запустил?
579 sanfoto
 
31.10.12
10:24
(578 ) Fragster
ой точно упустил из виду что две проги))
тогда нет смысла отключать ядра
580 МуМу
 
31.10.12
10:25
(573) Посмотри в первую очередь на счетчик SQL page life expentacy - это для SQL самый показательный счетчик для работы с памятью.(время жизни страницы). Он показывает как вытесняется быстро память. Будет меньше 500 или будут резкие пики падения - значит не все хорошо.
Но в любом случае твои выводы неверные. Да - если памяти не хватает это действительно не гуд и диск становится сразу же узким местом. Но даже если памяти поставить по максимуму(уж на памяти точно не стоит экономить) все равно диск при такой конфигурации остается потенциально узким местом номер один.
581 sanfoto
 
31.10.12
10:30
...........
2)обмен страниц/сек пики выросли с 9 000 до 29 000
.............
5) время Депроведения/Проведения(Расчет себестоимости) - уменьшилось почти в 4 раза

------------------------
математика
29 000/9 = 3.22 - и примерно на столько-же увеличилась скорость проведения))
582 Fragster
 
гуру
31.10.12
10:30
(581) дык в кэш потому что заколбасило
583 sanfoto
 
31.10.12
10:37
(580) МуМу
"Но в любом случае твои выводы неверные."
весьма расплывчиво какие именно выводы вообще все?))
давайте по порядку:
*******************************************
Выводы:
1)Производительность 1с 8.х больше всего:
- зависит от Частоты Ядра процессора
- зависит от скорости работы CPU-RAM
(кстати к MS-SQL - это тоже относится)

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

3)Чем больше ядер в процессоре - тем ниже Частота ВСЕХ ядер и хуже производительность 1с.
***************************************
добавлю пункт
4)проблему с дисковой системой снимаем SSD
584 Fragster
 
гуру
31.10.12
10:37
(583) так неверные же
585 sanfoto
 
31.10.12
10:43
......и говорят ему земля "есть плоская" ,
а ты НЕВЕРНЫЙ утверждаешь что она "круглая" .... )))
вот как то так
586 МуМу
 
31.10.12
10:50
(sanfoto)Я конкретно про то что мало уделяем внимания оперативной памяти. Это очень вырожденный случай(можно вообще ограничить память на 500 мБ и посмотреть), к тому же все равно узким местом становится диск. Памяти можно добавить сколько угодно но потом все равно диск станет узким местом.
587 John83
 
31.10.12
10:57
(578) да, два сеанса пашут
588 John83
 
31.10.12
11:13
(579) почему же?
наоборот хочется, чтобы было два ядра с полной мощностью
589 John83
 
31.10.12
11:14
(574) а как примерно в биосе называется опция по отключению ядер? сейчас чего-то покопался - ничего похожего не нашел
590 sanfoto
 
31.10.12
11:49
(586) МуМу
т.е. инымы словами вы имеете ввиду

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

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

*************** а вот что нужно мне********************
Меня как раз интересует "ЧАСТНЫЙ" случай взаимодействие "SQL" с "сервером 1с" и здесь проявляются ярче всего:
1)частоты CPU
2)скорость работы CPU-RAM
3)скорость обмена SQL -сервер 1с (притом Ethernet Gbit и Оптика - показали себя не ахти((( т.е. пока Оптимум все на одном сервере)
591 sanfoto
 
31.10.12
11:50
(589) John83
сейчас перезагружу комп скажу название
592 sanfoto
 
31.10.12
12:08
(589) John83
у меня опция BIOS- "Active Processor Core" -
находится в меню "Main"
(меньше 2-ух ядер - результаты были чуток похуже ИМХО операционка тоже кушать хочет)
593 МуМу
 
31.10.12
12:22
Часть конструкций SQL(и не только на запись) работает с БД независимо от наличия памяти.То же касается сервера приложений 1С.  Поэтому независимо от наличия памяти дисковая система потенциально может стать узким местом. Я это не раз наблюдал. То есть счетчик времени жизни страниц в норме а дисковая система нагружена. Это утверждение не является общим. Это адресовано к вашему утверждению относительно важности объема оперативной памяти.
594 John83
 
31.10.12
12:24
(592) премного благодарен!
поищу - попробую
595 МуМу
 
31.10.12
12:25
А насчет важности частоты CPU, скорости памяти , скорость обмена 1С - сервер приложений. Тут вопросов нет. Вопрос насколько это важно и для каких приложений. Например если я пишу самописную конфу, правильно пишу, на 1С, и у меня от сервера приложений к СУБД генерится 1000 запросов в секунду - поверьте время отклика в данном случае побарабану.(влияние менее доли процента)
596 МуМу
 
31.10.12
12:27
По нашим тестам - влияние чувствуется если количество обращений превышает 50 000 в секунду.(для нормального езернета)
597 sanfoto
 
31.10.12
13:04
МуМу
ну это все понятно касательно MS SQL,

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

поясню:
Объем RAM -конечно важен,
но НЕ МЕНЕЕ важна скорость работы с этой RAM -
т.к. это самый быстрый "НАКОПИТЕЛЬ ДАННЫХ" - то все приложения более менее оптимизированы под работу с Данными именно в RAM.
598 sanfoto
 
31.10.12
13:15
+(597)
SAP (in memory)- вон вообще предлагают отказаться в будущем от дисковых хранилищ))
599 sanfoto
 
31.10.12
13:32
(597)
и еще я говорю не про пропускную способность самой RAM,
она как раз на данный день превосходит процессорные возможности ее ПРОКАЧАТЬ)) (если без разгона)

я говорю про CPU-RAM! -
ИМХО важна производительность CPU и организация доступа к RAM/
 например при встроенном в проц. контроллере результаты лучше чем - у CPU -такой-же частоты но контроллер на материнской плате.
600 sanfoto
 
31.10.12
13:55
по конфигурации компьютера из (566)

в данный момент
1)запустили групповое проведение разных периодов на разных компах в нескольких клиентах
2)запустили так же несколько клиентов - просто покликать по справочникам и документам - ТОРМОЗОВ НЕТ
3)на сервере на дисках - ТОРМОЗОВ НЕТ
4)SQL -транзакций/сек в среднем 100 и пик до 400
601 sanfoto
 
31.10.12
14:15
+ к (600)
кстати SSD -далеко не самые быстрые и отпахавшие год с лишним под SQL базами)) - хотя когда сняли проверили утилитой - Она показала что диски как новенькие, и перезаписано на них десятки террабайт.
602 Fragster
 
гуру
31.10.12
14:21
(601) у нас в тех магазинах, где поставили ССД - они вылетают с регулярностью полгода-год. правда прирост они дают раза в три, это да.
603 sanfoto
 
31.10.12
14:30
у нас серверные SLC от интел)) SSD X25-E
сдается мне чтобы они вылетели ждать надо годы...
604 МуМу
 
31.10.12
14:33
(600)  Вы просто не умеете их готовить:) Подключите меня на 10-ть минут к БД я вам пару запросов таких наклепаю что тормозить будет мама не горюй:) Основные тормоза дают запросы на чтение. Вот тогда то и начнется резкая деградация.
606 sanfoto
 
31.10.12
14:43
(604) МуМу

эээ я и сам так умею))) даже Одним запросом ложил практически на колени рабочий сервак.
607 John83
 
31.10.12
14:48
(592) нашел я эту настройку, включил turbo boost.
Для тестирования производительности, использовал загрузку dt.
При этом загрузка отличалась всего секунд на 5-10 (всего ~3.20), хоть на 1м, 2х, хоть на 4х
608 John83
 
31.10.12
14:49
+607 может еще чего-то подкрутить нужно
PS такое впечатление, что неиспользуемые ядра тупо отрубаются, хотя в свойствах отображается прежняя частота
609 sanfoto
 
31.10.12
15:07
(608)  John83
turbo boost - временно может повысить частоту ядра ... если не юзаются другие и если большая нагрузка именно на этом ядре.

если у вас как и у меня I5 2300 - предел частоты 3.1 Ггц.
610 sanfoto
 
31.10.12
15:08
+ динамическую смену множителя и частоты можно смотреть например утилитой AIDA ))
611 sanfoto
 
31.10.12
15:10
+ рекомендую настроить
"Управление питанием" схема = "Максимальная производительность"
612 John83
 
31.10.12
16:28
(609) у меня-то i5-2550K
сейчас, почитав мануалы, с 3.4 разогнал до 4.6, но все же хотелось использовать "два ядра в одном", но что-то не получается - видать чайник
Надо будет поинтересоваться у знающих людей.
Еще раз спасибо :)
613 sanfoto
 
01.11.12
08:15
(580) МуМу
всетаки провел по вашей рекомендации замеры "page life expentacy" -
фактически насколько я понял это работа с буфером или иными словами с "Закэшированными данными".

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

2)на параметр "page life expentacy" - ориентироваться в  случае SSD - особенно не стоит
614 sanfoto
 
01.11.12
08:23
(613) ой пордон поправка
 пункт 2)если tempDB(SSD) и база на  SATA механич.диск
615 sanfoto
 
01.11.12
08:51
+ к (613)
Результаты:
....
....
3)если tempDB и сама база на отдельных SATA механич.дисках-
значение этого параметра стабильно в районе 1000. -время проведение примерно тоже что и пункт 2)

т.е. еще одно подтверждение что параметр "page life expentacy" - важен только в случае механических дисков))
как то так..
616 gallam
 
01.11.12
08:57
(613)(615) Прочитал все, но не понял откуда вывод)) Поясните подробнее пож.
617 gallam
 
01.11.12
09:05
+ (616) вы понимаете физический смысл "page life expentacy"?
618 sanfoto
 
01.11.12
09:05
фактически насколько я понял это работа с буфером или иными словами с "Закэшированными данными".
619 sanfoto
 
01.11.12
09:07
дословный перевод "время жизни страницы" ))
620 gallam
 
01.11.12
09:10
(618) Предлагаю вам четко знать (это описано в интернете) и тогда выводы, на мой взгляд, изменятся.
Подсказка:
- Загрузка диска (подчеркиваю любого типа)  - следствие "page life expentacy", а не наоборот.
Поэтому вывод: "т.е. еще одно подтверждение что параметр "page life expentacy" - важен только в случае механических дисков)) " - вообще не о чем.
621 gallam
 
01.11.12
09:11
+(620) Сравните скорость получение данных из памяти (кеша) и с диска (пусть даже SSD)!!!
622 sanfoto
 
01.11.12
09:18
стоп я говорю про счетчик
SQL:Database\page life expentacy
623 gallam
 
01.11.12
09:20
(622) и я)
624 sanfoto
 
01.11.12
09:23
хорошо теперь давайте уточним и по порядку))

SQL:Database\page life expentacy - высокое значение параметра - свидетельствует об активном использовании MS SQL Закэшированных данных, так?
625 gallam
 
01.11.12
09:26
(624) Ваша формулировка абстрактная и непонятная. Я применяю следующую - данные удерживаются в кеше MS SQL дольше, когда значение этого счетчика выше.
626 sanfoto
 
01.11.12
09:31
хорошо перефразирую так

SQL:Database\page life expentacy - высокое значение параметра - это показатель того что Одни и Те-же данные долго лежат в Кеше, так?
627 gallam
 
01.11.12
09:37
(626)Я даже более скажу - счетчик измеряется в секундах. А на русском "Ожидаемая длительность нахождения страницы данных в кеше MS SQL". Давайте вернемся к вашим выводам и их пересмотрим.
628 sanfoto
 
01.11.12
09:52
и все-таки сначала уточню Ваш ответ на (626) = Да?
629 sanfoto
 
01.11.12
11:11
))
630 МуМу
 
01.11.12
12:05
(628)Философией,софистикой упражняетесь?:)
Общий вывод последней дискусии можно сформулировать следующим образом. Время жизни страниц памяти зависит от наличия памяти а также от специфики ИТ системы.(дисковая система будет в данном случае влиять только на время запросов получаемых не из кеша).Дисковая система не влияет на этот счетчик.  Если ИТ система неоптимальна - аналитические данные будут постоянно вытеснять оперативные что не есть гуд.
631 sanfoto
 
01.11.12
12:27
(630) МуМу
))
по частям отвечу))
1)"Общий вывод последней дискусии можно сформулировать следующим образом. Время жизни страниц памяти зависит от наличия памяти а также от специфики ИТ системы.(дисковая система будет в данном случае влиять только на время запросов получаемых не из кеша)."
- мой ответ Да согласен

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

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

2)если долго не перезагружаем сервер и активно работаем в программе.
634 МуМу
 
01.11.12
12:39
(631)Здесь нужно рассуждать логически.В моих утверждениях нет никакого противоречия. В скобках я указал специально ньюансы которые не играют роли но могут ввести в заблуждение. Сформулирую по другому. Проведем мысленный эксперимент.
Запускаем 1000 одинаковых запросов. Запускаем их на одном и том же сервере, только в одном случае один винт а в другом другой. Значение этого счетчика будет неизменным. Сразу хочу сказать что здесь важно эксперимент проводить синхронно. Важно получить диференциал. Потому как если вы просто ничего не будете делать с сервером - время жизни страниц памяти будет расти. Соответсвенно время жизни страниц в двух экспериментах может отличаться только на время выполнения эксперимента.(за счет того что на быстром диске выполнится быстрее) Если его исключить - то оно будет точно одинаковым. В том  то и ценность именно этого счетчика что он является показателем системы а не оборудования(кроме памяти разумеется).
635 Шмузер
 
01.11.12
12:45
(613) "значение этого параметра периодически менялось и иногда падало до Нуля и пики до 1500, но в среднем было очень низким." - вас попросили измерить максимальную скорость автомобиля, а вы вместо этого наблюдали аз автомобилем весь день и пришли к выводу, что иногда он ехал очень быстро, а иногда стоял на парковке :)
636 sanfoto
 
01.11.12
12:51
)) естественно если ЗАПРОСЫ ОДИНАКОВЫЕ - они выбирают ОДИНАКОВЫЕ ДАННЫЕ - т.е. после первого запроса все будет идти из кеша,
но Если только хватает объема Кеша.

именно по этом я провел эксперимент по групповому проведению документов в разных периодах и одновременно в нескольких клиентах
1)на сервере 6 Гб RAM
2)База размер 66 Гб
3) все на SSD (tempDB и база) - специально для  Шмузер - среднее значение обсуждаемого счетчика =22 (пик 1500- был один раз в течении секунды с резким взлетом и падением.)
4) все на SATA -механических - среднее значение 840 и максимальное 846
637 sanfoto
 
01.11.12
13:05
(635) Шмузер
а если взять за значение вашего термина "скорость автомобиля" - "скорость проведения документа в 1С" ,
то
из сообщения (636)

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

чем
Автомобиль из пункта 4) до конечной остановки
638 sanfoto
 
01.11.12
13:08
короче ничего нового в данной ветке я не узнал))
кроме приобретения опыта как заметил специалист из Софт-Поинта

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

и ответа на вопрос из (0) так и нет((
639 Шмузер
 
01.11.12
13:14
(636) Давление у вас высокое в памяти, вот при использовании ссд сервер и понимает, что может часть информации выпустить из памяти наружу и потом относительно быстро ее достать обратно. При использовании сата он видит, что хранить данные на диске накладно по времени доступа, и держит все, что помещается, в памяти, иногда полностью обнуляя кэш.
(637) Вы слово "память" не услышали? У вас время жизни = 0 - высокое давление, что может быть вызвано низкой производительность памяти или недостаточным объемом.
640 Шмузер
 
01.11.12
13:19
(638) Вы же хотели экспериментально подтвердить свои теоретические выводы, но эксперименты проводили на стендах с разной конфигурацией, что не дало возможности увидеть реальные закономерности. Более того, вы не стали создавать ПО для тестов, вам хватило показателей при повседневной нагрузке, которая далеко не в любой момент времени имеет эталонный характер.
641 Шмузер
 
01.11.12
13:20
Народная медицина какая-то :)
642 sanfoto
 
01.11.12
13:43
"вы не стали создавать ПО для тестов"
улыбнуло.))))))
Хотя на самом деле тестов использовалось много, НО...

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

И что мы видим ооо круто Xeon 10-ядерный(по 2 Ггц) по тестам от Intel рвет Xeon 4-ех ядерный(по 3.3 Ггц) той-же технологии. - ИМХО это чистый маркетинг.
Тест написан под ИДЕАЛЬНО РАСПАРАЛЛЕЛЕНУЮ задачу - что в реальности мало-достижимо.
643 Шмузер
 
01.11.12
14:10
(642) Для всего есть своя область применения, вы же пытаетесь сделать обобщающие выводы на основе своих наблюдений за частным случаем в плохой лаборатории.
P.S. В конце-концов, даже при использовании приложений, которым более 4-х ядер не нужно, возможно повысить производительность системы, отключив лишние ядра - начнет работать TurboBoost и все 30 мегабайт кэша L3 достанется четырем ядрам.
644 sanfoto
 
01.11.12
14:22
(643) Шмузер

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

2)фигу  TurboBoost поднимет одновременно 4-ядра с 2 Ггц до 2.9 даже, а вот если ТОЛЬКО ОДНО ядро будет загружено да такое видел))
645 sanfoto
 
01.11.12
14:51
ладно всем пока)) покидаю таки эту ветку на месяцок другой))
646 John83
 
02.11.12
23:23
(609) ну в общем знающие люди мне тут сказали, что отключение процов - это больше для экономии энергии/уменьшения температуры проца
в общем как-то вот так :)
647 Demiurg
 
03.11.12
18:30
648 kauksi
 
06.11.12
22:12
Приехала нормальная мать. Разгон Core i5-3570k до 4,6Ггц дает 61,57 в тесте Гилева. Правда память работает на 1333МГц. у кого больше?
649 sanfoto
 
29.11.12
10:53