|
Есть теория, что сервер 1с 8.3 использует только 1 ядро процессора. Так ли это? | ☑ | ||
---|---|---|---|---|
0
33554432
14.06.16
✎
06:16
|
Есть теория, что сервер 1с использует только 1 ядро процессора. Так ли это?
|
|||
1
zak555
14.06.16
✎
06:19
|
ос какая?
|
|||
2
IamAlexy
14.06.16
✎
06:20
|
1процесс=1ядро
по этому и рекомендуют делать и рассчитывать количество рпхостов так чтобы их было по количеству ядер примерно.. |
|||
3
33554432
14.06.16
✎
06:31
|
а в 8.3 есть настройка количества процессов? если есть то где она?
|
|||
4
Aleksey
14.06.16
✎
06:32
|
(3) Смотря какая разрядность 1С
|
|||
5
33554432
14.06.16
✎
06:32
|
(4)
64 |
|||
6
33554432
14.06.16
✎
06:35
|
теория возникла из банального эксперимента. на простом компе, настроенном как сервер, 1с работает в 3 раза быстрее, чем 2-процессорный мощный сервер. Другого объяснения не вижу.
|
|||
7
Lama12
14.06.16
✎
06:54
|
(6) Сервер не для скорости делают, а для надежности.
|
|||
8
33554432
14.06.16
✎
07:03
|
(7)
для скорости тоже. Ну это же смешно, что 2 12-ядерных процессора, по суммарной производительности в 5 раз превосходящие десктопный компьютер, работают в итоге в 3 раза медленнее десктопного компьютера. |
|||
9
rphosts
14.06.16
✎
07:17
|
(6)тут конечно телепаты и экстрасенсы... все в курсе как ты ставил там и там
угадай сколько процессов имени меня грузит проц, если кроме них на сервере ничего нет: ![]() |
|||
10
rphosts
14.06.16
✎
07:17
|
||||
11
КМ155
14.06.16
✎
07:32
|
(8)[для скорости тоже]
для скорости нужна тактовая частота CPU, если твой смешной 12 ядерный процессор тикает на жалких 2 Ггц, то его порвёт даже смартафон |
|||
12
Провинциальный 1сник
14.06.16
✎
07:42
|
(2) Это заблуждение. Один процесс может запускать множество потоков (thread), каждый может выполняться на своём ядре. При этом адресное пространство общее.
|
|||
13
vde69
14.06.16
✎
08:11
|
(11) для скорости нужны прямые руки а не частота...
|
|||
14
Провинциальный 1сник
14.06.16
✎
08:20
|
+(12) И кстати, если есть возможность работы на одном РП - то лучше использовать один. В 8.2 при наличии нескольких рпхостов сильно тупит инициализация фоновых заданий.
|
|||
15
oslokot
14.06.16
✎
08:34
|
(13) и частота.
|
|||
16
MrStomak
14.06.16
✎
08:49
|
(8) Это же смешно, когда дизельный седельный тягач MAN, мощностью в 5 раз большей, чем жигули, проигрывает жигулям в скорости перевозки 1 кг картошки!!! Где справедливость??!
(2) Это ж надо такое сказать.. |
|||
17
Фрэнки
14.06.16
✎
09:06
|
(16) // Это ж надо такое сказать..
А есть чем опровергнуть? |
|||
18
xxTANATORxx
14.06.16
✎
09:20
|
ура пацаны, все выбрасываем сервера стоимостью многолярдов, ставим десктопы, из сабжа вытекает что десктопы производительнее
|
|||
19
lodger
14.06.16
✎
09:36
|
день сурка какой-то. это не тот же чувак с 2 оптеронами против интел и7?
|
|||
20
hhhh
14.06.16
✎
09:43
|
(18) ну так и есть. Все эти накрученные многоядерные на 90% лохотрон. Чтобы подороже продать. Вешают нам лапшу на уши.
|
|||
21
MrStomak
14.06.16
✎
09:57
|
(17)
Да блин, этот бред еще и опровергать надо чтоли? Берешь запускаешь обработку в 2х сеансах и смотришь как загрузятся 2 ядра на сервере. Очевидно, IamAlexy спутал узлы NUMA и ядра процессора. В результате, получилась фигня. В разделе ТВКВ вроде была статья Морозова, что rphost нужно размножать по количеству узлов NUMA. |
|||
22
Фрэнки
14.06.16
✎
10:11
|
(21) два сеанса <=> два процесса
или два сеанса <=> один с двумя тредами? |
|||
23
MrStomak
14.06.16
✎
10:20
|
(22) Два сеанса может наплодить хоть 20 тредов, все это может выполняться в 1 процессе rphost. Что совершенно не требует "количество rphost по количеству ядер"
|
|||
24
Фрэнки
14.06.16
✎
10:43
|
(23) как происходит появление нового треда, для этого что-то нужно прописывать в программном коде или системны планировщик сам множит треды от балды?
|
|||
25
Провинциальный 1сник
14.06.16
✎
10:44
|
(24) Любой серверный вызов порождает тред, очевидно.
|
|||
26
Фрэнки
14.06.16
✎
10:47
|
(25) очевидно, что это он ДОЛЖЕН делать, иначе треда просто не будет.
Ну и где этот тред останется? В адресном пространстве родного процесса? |
|||
27
MrStomak
14.06.16
✎
12:19
|
(24) Появление треда прописано в платформе, ты ничего явно не создаешь.
На клиенте треды могут создаваться из кода через "ПодключитьОбработчикОжидания", на сервере через ФоновыеЗадания.Выполнить, но это косвенное создание треда. (26) Я не понял смысла вопроса. Тред может быть только там, где создан. Тред не может перейти в другое адресное пространство. А потом вызов закончится и треда вообще не будет. Но все треды могут принадлежать одному rphost и загрузить сколько хочешь ядер. |
|||
28
mistеr
14.06.16
✎
12:31
|
(25) Где настраивется максимальное количество этих потоков в процессе?
|
|||
29
Фрэнки
14.06.16
✎
12:40
|
(27) не загрузят они "сколько хочешь ядер" - нет у процесса доступа в один и тот же квант процессорного времени доступа к нескольким ядрам.
|
|||
30
nordbox
14.06.16
✎
12:47
|
(0) Для начала надо понимать что такое многозадачность и какая она бывает
|
|||
31
MM
14.06.16
✎
12:55
|
(27) А платформа не использует пул потоков? Всегда ли при соединении создаётся поток, а при отключении удаляется?
ПодключитьОбработчикОжидания разве не через таймер сделан? Вероятнее всего оконный, а не ядерный. |
|||
32
MM
14.06.16
✎
13:23
|
(29) Так ведь предметом планирования времени процессоров являются потоки, а не процессы, в которых они живут. Проблема с таким распределением может быть только в NUMA-архитектуре, там планировщик может по другому действовать.
|
|||
33
MrStomak
14.06.16
✎
13:27
|
(29) Запусти винрар и посмотри, как у процесса "нет доступа в один и тот же квант процессорного времени доступа к нескольким ядрам"
|
|||
34
nordbox
14.06.16
✎
13:27
|
Смотря какая операционка
|
|||
35
Фрэнки
14.06.16
✎
15:16
|
||||
36
Fragster
гуру
14.06.16
✎
15:18
|
(0) запусти http://fragster.ru/perfomanceTest/ когда у тебя один рабочий процесс
|
|||
37
Провинциальный 1сник
14.06.16
✎
15:19
|
(35) А при чем тут винда? В линуксе почти то же самое. Правда, там треды это форкнутые процессы, но поведение аналогично.
|
|||
38
ЛучшаяДевушка в СССР
14.06.16
✎
15:25
|
боже ж мой, как вы во всем этом разбираетесь?
зашла и я, может пойму, почему там, где обычно все летает, 8.3 еле поворачивается, но нет - столько умных слов я не осилю... |
|||
39
MM
14.06.16
✎
15:41
|
(38) сколько сотен пользователей работало в базе, на старой версии и на 8.3, что конфигурация работала медленно? В 8.3 сделали упор на большое количество пользователей, медленные каналы связи и веб-клиенты, в старых версия не было проблем с этим?
(34) А какие варианты ОС рассматриваются? Те что уже не на поддержке должно исключить (< Vista). |
|||
40
MrStomak
14.06.16
✎
15:44
|
(35) Сказать то что хотел, приводя ссылку значения которой не понимаешь?
|
|||
41
ЛучшаяДевушка в СССР
14.06.16
✎
15:56
|
(39) база файловая, розница 2.1, стоит веб-сервер, пользователей 2 (сеансов 3-4), один подключается через веб, второй локально... локально даже все открывается со скрипом, веб соединение вообще может печать этикетки 5 минут выдавать...
мне кажется, что файловая ТиС и УТ даже по сети не так тормозили, как эта... меньше двух пользователей - куда уж меньше... и базу для меньше 5 пользователей советуют файловую... ну вот файловая... я даже если одна подключаюсь локально - медленно все... |
|||
42
MM
14.06.16
✎
16:01
|
(41) для меньше 5 пользователей есть http://1c.ru/news/info.jsp?id=17577 , его же не просто так продают
|
|||
43
ЛучшаяДевушка в СССР
14.06.16
✎
16:11
|
(42) а веб-сервер тогда зачем?
а если я одна буду работать, мне тоже нужен сервер (хоть мини, хоть не мини)? все же базы раньше на 7.7, 8.1, 8.2 быстро работали локально, а эта нет... можно сделать распределенку для розницы же, тем более, что все равно куплены для каждого магазина отдельные поставки, так я одна не могу нормально быстро работать в базе локально... с такой скоростью, как я делаю это на такой же машине в ут 10.3... это вообще вопрос к платформе или к конфигурации? |
|||
44
MrStomak
14.06.16
✎
16:16
|
(43) Это вопрос к управляемым формам прежде всего.
По сравнению с обычными дополнительно происходит сериализация и десериализация. За универсальность, тонкие каналы и возможность использования web платим производительностью. Плюс конфигурации стали намного больше, больше качается кеш, дольше поиск по нему и т.д. |
|||
45
IamAlexy
14.06.16
✎
16:18
|
ну так что в итоге?
я зашел в базу десятью пользователями и у меня в настройках стоит "1 сеанс на процесс" - сколько у меня будет процессов и как они расположатся по ядрам если у меня 10 ядер ? |
|||
46
mehfk
14.06.16
✎
16:20
|
(45) Создай 10 фоновых заданий одновременно, да посмотри.
|
|||
47
IamAlexy
14.06.16
✎
16:20
|
(3) можешь подогнать через настройку количества баз/сеансов.. примерно..
то есть если у меня допустим 10 пользователей и 4 ядра и они работают в одной базе - то я делаю настройку - 3 сеанса на процесс.. и каждый четвертый сеанс инициирует новый процесс который падает в наиболее свободное по загрузке ядро на момент создания процесса. |
|||
48
IamAlexy
14.06.16
✎
16:21
|
(46) в зависимости от моих настроек они радостно наплодят рпхостов которые займут наиболее свободные ядра..
я собственно про это выше и писал.. |
|||
49
ЛучшаяДевушка в СССР
14.06.16
✎
16:22
|
(44) и чем лечить? кроме сервера? ни на каком компе не будет это нормально работать? я для примера открыла ут 10.2 и розницу 2.1 рядом, вывела на печать этикетку - в ут посчитала до трех, в рознице до 60-ти примерно...
|
|||
50
IamAlexy
14.06.16
✎
16:24
|
(49) у тебя "тормозит", вернее менее отзывчиво работает именно интерфейс..
так что - ничем. если у тебя в "локальном и монопольном" режиме база работает медленно - в серверном если ты сервер на своей машине поставишь оно быстрее работать не будет.. |
|||
51
IamAlexy
14.06.16
✎
16:25
|
вывод этикетки в 60 секунд это не нормально.. даже для УФ...
|
|||
52
MrStomak
14.06.16
✎
16:26
|
(49) Такой разницы не должно быть. Розница развернута без веб-сервера, база находится на сетевом ресурсе?
|
|||
53
MrStomak
14.06.16
✎
16:28
|
(45) Немедленно убирай эту убийственную настройку! 1 сеанс на процесс - это жесть просто.
http://its.1c.ru/db/metod8dev#content:4136:hdoc:_top:количество%20рабочих%20серверов "В 64-разрядном сервере "1С:Предприятия" один rphost может полностью использовать и оперативную память, и процессорные ресурсы сервера. Поэтому для 64-разрядного сервера "1С:Предприятия" нормальным следует считать запуск одного рабочего процесса на один сервер." |
|||
54
ЛучшаяДевушка в СССР
14.06.16
✎
16:31
|
(50) хорошо, это я на своем компе тестирую, ничем ему помочь не могу... а клиенту надо ж что-то посоветовать)) комп сменить? или что?
(51) я быстрее считала, может секунд 30 получится, если в секундах мерять... и это не вывод этикетки на печать - это нажать кнопку Печать, чтобы вывелась таблица (правда есть куча характеристик), выбираю одну характеристику, жму печать и считаю до 30-ти... если выбираю товар без характеристик и жму печать в форме номенклатуры - до 21 досчитала) |
|||
55
IamAlexy
14.06.16
✎
16:32
|
(53) это было для примера.
ок. вопрос сугубо практический: 1. у тебя 32битный сервер, один процесс и 2 сеанса. каждый пользователь в сеансе запускает по тяяяяжолому отчету, для упрощения сделаем вид что отчеты старые и не плодят фоновых заданий. сколько ядер будет занято и соответственно уйдут в максимум по загрузке? 2. вопрос в продолжение к вопросу №2: эти же два сеанса но в РАЗНЫХ процессах запускают те же отчеты - сколько на этот раз будет занято ядер и в каком случае отчеты сформируются быстрее? |
|||
56
MrStomak
14.06.16
✎
16:33
|
(55) 1. 2 ядра
2. 2 ядра. В последнем случае могут быть расходы на маршалинг, вариант №1 быстрее. |
|||
57
IamAlexy
14.06.16
✎
16:34
|
(55) вопрос в догонку конечно же про память - отчеты генерятся с количеством строк по 100 000 в каждом и на СКД - что будет с памятью?
|
|||
58
IamAlexy
14.06.16
✎
16:34
|
(56) странно - с каких версий платформ они стали занимать 2 ядра?
можешь показать скрин где видно как один rphost.exe загрузил 2 ядра? |
|||
59
IamAlexy
14.06.16
✎
16:35
|
(56) хм.. практика показывает что как раз второй вариант быстрее.. весьма и весьма
|
|||
60
ЛучшаяДевушка в СССР
14.06.16
✎
16:35
|
(52) это я сейчас на своей машине пробую, здесь у меня без веб-сервера...
у клиента стоит веб-сервер, база на компьютере там же, я там подключалась локально - очень медленно все просиходит... еще иногда подключаюсь через тим к компу, в базу захожу локально и что- то делаю в базе, при этом есть одно веб-соединение в магазине розничном, звонят из розницы - если вы работаете в базе, выйдете, пожалуйста, у нас все висит... |
|||
61
MrStomak
14.06.16
✎
16:37
|
(58) Всегда занимали 2 ядра.
Запусти (36) и сам смотри. (59) Это твои субъективные впечатления, практика ничего подобного не показывает. 1С официально рекомендует для х64 1 рабочий процесс, на х86 несколько только по причине ограничения памяти на процесс. Для многосокетных систем может быть кривое распределение по ядрам, потому для них есть рекомендация использовать несколько рабочих серверов. |
|||
62
MrStomak
14.06.16
✎
16:39
|
(57) 32-разрядный сервер может упираться в лимит по памяти. Это грозит ошибкой "Недостаточно памяти на сервере". В случае, если памяти для отчетов достаточно, они будут формироваться чуть-чуть быстрее, чем на х64 за счет более быстрой адресации памяти.
|
|||
63
ЛучшаяДевушка в СССР
14.06.16
✎
16:40
|
+(60) при таком раскладе подключить второй магазин вообще не представляется возможным... не будут же они посменно работать, одни днем, другие ночью...
вообще, имеет права на существование такая схема - один рабочий комп, на котором развернут веб-сервер, и два-три магазина, которые подключаются через тонкий клиент со своих компов из розницы (не через браузер)? и какой должен быть комп основной, чтобы он это потянул? (сорри, надо, наверное, отдельную ветку) |
|||
64
MM
14.06.16
✎
16:41
|
(61) Это о NUMA? Разве система сможет правильно разделить одно адресное пространство процесса на несколько узлов NUMA, каждый со своей памятью, даже если разные потоки будут честно разделены между ядрами?
|
|||
65
MrStomak
14.06.16
✎
16:44
|
(64)
http://kb.1c.ru/articleView.jsp?id=89 "Следует иметь в виду, что поддержка NUMA в кластере серверов 1С полноценно пока не реализована. Сервер 1С не управляет распределением ресурсов по NUMA узлам, полностью полагаясь в этом на операционную систему, что не всегда даёт оптимальный результат." |
|||
66
MM
14.06.16
✎
16:52
|
(65) Вот только 8.3 не позволяет точно указать количество rphost, потому и приходится так исхитряться.
|
|||
67
Fragster
гуру
14.06.16
✎
16:55
|
(66) по ссылке так и написано
|
|||
68
IamAlexy
14.06.16
✎
17:00
|
хм.. субъективизм вещь такая..
как бы вы не рассказывали что "на самом деле" - на практике все же разница очевидна, и пользователи ее видят.. но вы поколебали мою уверенность что "1с сама нихрена не умеет многопоточность и надо делать количество процессов по количеству ядер" как раз у меня сейчас новый сервак почти настроился, скуль ставится - как доставится запущу тесты фрагстера и гилева - в режиме нескольких процессов и в режиме одного процесса- посмотрим попугаи какие будут.. |
|||
69
MM
14.06.16
✎
17:03
|
(67) не сказал бы. В 8.2 этот параметр был явным, а по ссылке предлагается завести кучу рабочих процессов кратную числу узлов, если число пользователей известно.
(61) 8.3 умеет переносить сеансовые и др. данные в rphost, когда он один? В 8.1 это был веский аргумент не ставить флаг много процессов. |
|||
70
MrStomak
14.06.16
✎
17:06
|
(69) Сеансовые данные в клиент-серверной архитектуре все же находятся в ведении процесса rmngr
|
|||
71
MrStomak
14.06.16
✎
17:09
|
(68) Тесты рассчитаны на работу с данными, что немного уводит нас от анализа работы самого rphost (параллельность будет ограничена блокировками sql).
Намного проще написать обработку с кодом вида Пока Истина Цикл КонецЦикла. |
|||
72
IamAlexy
14.06.16
✎
17:19
|
(71) ну... если не верить тестам то чему верить ? Пользователям?
ну так они однозначно говорят что когда много процессов - работать быстрее и комфортнее и в целом "и не такое уж гомно эта ваша 1С" но мы решили пользователям не верить же.. так что остаются тесты.. |
|||
73
MrStomak
14.06.16
✎
17:31
|
(72)
Мне вот сложно в таком стиле вести дискуссию. Кажется очевидным, что следует получать объективные данные. Когда анализу подвергается возможность использования нескольких ядер одним rphost, разумно анализировать именно этот аспект, а не запускать, к примеру, тесты PCMark. Упомянутые тесты показывают производительность записи в базу данных. Процесс записи данных в базу физически выполняется процессом сервера СУБД, а не rphost. Т.е. влияние rphost там будет видно только тогда, когда процесс записи будет достаточно быстрым и перестанет быть узким местом - то есть не на каждой инсталляции. Т.е. результаты тестов скорее будут примерно одинаковыми, но влияние многопоточности на стороне rphost там может быть минимально. А если нагружать математику без привязки к СУБД, то это отвечает на вопрос загрузки ядер одним процессом rphost совершенно однозначно. |
|||
74
Провинциальный 1сник
14.06.16
✎
20:00
|
(72) Когда несколько РП - то тормозит инициализация фоновых процессов. Оптимально один рабочий рпхост и один резервный. Плюс наши любимые повторные вызовы и хранилища значений с COM-объектами намного приятнее работают с одним процессом, чем с кучей.
|
|||
75
Fram
14.06.16
✎
23:03
|
(63) Мне кажется, у вас все в диск упирается. Помониторьте счетичик. Первый шаг - это замена ХДД на быстрый ССД. Второй - вынос темп файлов на отдельный ССД.
|
|||
76
ЛучшаяДевушка в СССР
15.06.16
✎
10:42
|
(75) спасибо! будем пробовать
|
|||
77
vde69
15.06.16
✎
10:48
|
(75) все гораздо проще: http://wiki.mista.ru/doku.php?id=it:analiz_sql_block
|
|||
78
Карупян
15.06.16
✎
10:50
|
(77) Уже устарела, сейчас основные блокировки - это блокировки сервера 1с
|
|||
79
vde69
15.06.16
✎
10:51
|
(68) 64х сервер - замечательно умеет работать по всем ядрам, для него несколько рхостов делать надо только в отдельных и весьма специфических случаях (вроде резервирования нагрузки)
|
|||
80
MM
15.06.16
✎
10:55
|
(79) В статье 1С речь не о ядрах, а о NUMA-узлах.
http://kb.1c.ru/articleView.jsp?id=89 (77), (78) там тормоза на файловой базе через однопоточный веб-сервер. |
|||
81
ЛучшаяДевушка в СССР
15.06.16
✎
11:07
|
(77) может и проще, но тут "При появлении тормозов при работе с SQL", а у нас нет sql-сервера именно в данном случае...
|
|||
82
Fragster
гуру
15.06.16
✎
11:24
|
(81) если файловая через веб сервер, то:
1: всех пускать через веб (даже локальных и терминальных) 2: если активных пользователей больше 3-х воспользоваться заляпухой, например http://catalog.mista.ru/public/242527/ |
|||
83
Провинциальный 1сник
15.06.16
✎
11:40
|
(80) Что за хрень эта нума?
|
|||
84
Провинциальный 1сник
15.06.16
✎
11:42
|
(83) Я в том смысле, что для современных процессоров нет никакого смысла учитывать эту самую нуму. Всё равно снаружи они - обычные SMP, с общей памятью. А нюансы кэширования - внутренннее дело ядра.
|
|||
85
MM
15.06.16
✎
11:48
|
(84) В настройках MS SQL NUMA может учитываться, хотя это тонкая настройка.
|
|||
86
Fragster
гуру
15.06.16
✎
11:48
|
(84) у тебя нет многосокетных серверов?
|
|||
87
uno-group
15.06.16
✎
12:26
|
Это только у меня 1с чаще упирается в дисковые операции, а не количество процессоров и их мощность. Локальный комп с ССД диском сделает нацатипроцесорный сервак, если тестить 1-2 экземпляра 1с. Если их с полсотни запустить то уже буде видна разница
|
|||
88
Провинциальный 1сник
15.06.16
✎
15:16
|
(86) Есть, конечно. И что? Два сокета в режиме SMP. В точности так же как и многоядерный проц.
|
|||
89
Провинциальный 1сник
15.06.16
✎
15:17
|
(85) В том и суть, что если не углубляться в тонкости и не ловить проценты - то можно с чистой совестью на это забить, принимая все ядра равноценными.
|
|||
90
Fragster
гуру
15.06.16
✎
15:49
|
(88) в smp системах у тебя по пропускной способности памяти будет более узко, чем в NUMA системах (коих среди относительно новых многосокетных - большинство). Эмуляция SMP в NUMA - это еще бОльший затык в производительности по шине памяти, так как ось не знает, как привязать процессы и их память к физическому размещению и может быть так, что процесс крутится на процессоре одной ноды, а память у него - на другой, и процессор обращается к "дальней" памяти, тратя намного больше тактов на эти обращения, чем в NUMA режиме при поддержке его осью.
|
|||
91
MrStomak
16.06.16
✎
08:49
|
(88) все ядра используют один контроллер памяти. Мультисокетные же системы либо содержат несколько контроллеров (они уже давно переехали в процессор) либо вынуждены конкурировать за доступ к 1. Второй случай - чистый smp. Первый - либо smp без аппаратного решения по доступу к чужой памяти и как следствие не позволяющий без специально разработанного софта иметь доступ к чужой, который будет все равно медленный, либо NUMA, в котоом эта задача решена на аппаратном уровне.
(89) Тут есть и оборотная сторона - доступ к удаленной памяти может быть не таким медленным, а из-за того, что ОС пытается этого избежать, получаем проблему с rphost, который грузит только один сокет с ближней памятью, остальные простаивают. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |