CRM 2 Количество процессов rphost на скорость работы 1с не влияет... #690223

CRM 2 Количество процессов rphost на скорость работы 1с не влияет...

Как это не влияют? Попробуй создать сотню.

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

а ты в 6 сеансах попробуй грузить

обработка паралельно не работает

Судя по всему количество ума на длину полоски тоже не влияет

Тогда остаётся только переименовать тему: CRM 2 Количество процессов rphost на скорость работы не работающей параллельно обработки не влияет... Привет К.О.!

>>пробовал грузить по 65 000 позиций номенклатуры, что один процесс , что 6 скорость одинаковая твой сеанс только в одном процессе всё равно, и не должно влиять ничего. А вот другие юзеры паралельно с тобой в сеансе будут сидеть не комфортно, а когда их 6 - уйдут в другой сеанс. Правда при такой загрузке наверное тоже некомфортно им будет

это не совсем верно

конечно. Но судя по - пусть хоть так, чем текущие представления о работе процессов

самое обидное, когда расчет себестоимости за месяц идет в 1 процессе и грузит на 100% тока 1 проц из 16 (

а если б был 1 процесс всего - грузил бы 16 ядер? с чего вдруг? в 8.3 может быть, а сотальные не умеют

А с чего это 8.3 смогла?

я грю может быть, не смотрел. В 8.3 в сервер 1с много вкусного добавили, может и это сделали? я хз

почему это не совсем верно? "А вот другие юзеры паралельно с тобой в сеансе будут сидеть не комфортно, а когда их 6 - уйдут в другой сеанс. Правда при такой загрузке наверное тоже некомфортно им будет"

сеансы пользователей получают разные процессы rphost или это хаотичный процесс?

частично хаотичный, ты можешь управлять этим косвенно, выставляя производительность процесса в настройках. Решает в какой процесс пихнуть сеанс - сервер 1с

параметр производительности процесса не влияет собсвенно на его производительность как таковую, это для распределения нагрузки между процессами. Например 2 процесса с параметрами 500 и 1000 - должно быть из 30 сеансов : 10 на первом , 20 на втором (1000), это в идеале, всё относительно

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

мне одно непонятно при количестве пользователей 20 и работающей обработке загрузки данных, ОС win x 64 количество ядер проца 12 , что оптимальней для скорости работы? 1) создать 2 процесса rphost 2) создать 12 процессов rphost

Вы там каждый день грузите по 65 Кпозиций номенклатуры?

При  20 пользователях много процессов не нужно, я бы при такой конфигурации поставил 3-4 процесса.

взято из практики? или существуют формулы расчета?

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

не пойму как rphost отдает память? допустим rphost съел 10 гигов памяти, обработка закончила работать, когда rphost память освободит?

Зависит от разрядности сервера предприятия и от версии платформы

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

походу у меня не освобождет ... сервер 64x , платформа 1С:Предприятие 8.2 (8.2.18.109)

сделай несколько рпхостов и настрой перезагрузку раз в сутки

можно кривыми обработками убить процессы, обычно мусорщик 1с работает норм, но если написано криво - может и не очистить. На 20 пользователей - 1-2 процесса за глаза вобще

Я так понимаю память освобождается если сеанс долго не активен, если есть активность в сеансе то память может и не освободится вовсе.

для 64-х битного сервера предприятия, согласен, минимум парочку нужно

50 юзеров могут нормально в одном rphost жить.

немогут, рпхост может и подвиснуть, поэтому резерв нужен. А так в сферическом серваке

если там запускают обработки которые раздувают его до 10-ти гигов - не соглашусь)