|
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
|
(556) тебе сюда:
http://3nity.ru/viewforum.php?f=40&start=0 |
|||
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
|
(646) о настройках http://olontsev.ru/2012/11/cpu-power-options-and-sql-server-performance/
|
|||
648
kauksi
06.11.12
✎
22:12
|
Приехала нормальная мать. Разгон Core i5-3570k до 4,6Ггц дает 61,57 в тесте Гилева. Правда память работает на 1333МГц. у кого больше?
|
|||
649
sanfoto
29.11.12
✎
10:53
|
продолжение данной темы
на Выбор сервера 1С 8.х (клиент-серверный режим) |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |