Медленно работает 1с на новом сервере #698471

Купили новый сервер, не сильно крутой но все же. мат плата: intel s2600cp Xeon e5-2609 16 ГБ озу с частотой 1600 10ый рейд поставили sql server 2012 так вот медленно работает 1С. Операции подвисают на несколько минут. Проверял тестом Гилева результат 10 файловый вариант 46. Если сравнить с тестами других пользователей файловой версии то там все много быстрее. В чем может быть дело? оперативной памяти выделяется по умолчанию( оч много) но процесс съедает не больше 8 ГБ. Подскажите в чем может быть дело?

платформа кстати 8.2.16.368

в поиск тема, идентичная данной, поднимается раз в неделю

Конечно я пользовался поиском. И все в подобных темах людям что-то отвечают. Я  может быть  плохо себе представляю нынешние реалии и такой сервер для 15 юзеров уже слабый. Но почему такой низкий результат теста нагрузки?

кривые руки, установлено много мусора, проблемы с сеткой....

RLS? Была, вроде, такая багофича в 8.2 Могет, плохие планы запросов стряпает на скуль

обнови платформу, куле

На отклик 1с оч сильно влияет частота камня и памяти но камень больше. Заменив камень хотя бы на 3 Ггц проведение ускорится в 2 раза.

Фигня.

ну не в 2 раза но заметно...

небось по старой доброй памяти один рпхост отдувается за всех пользователей ?

В настройках электропитания, в старой конфигурации, в версии платформы, в кривых руках наконец...

В регламентах, в антивирусе, в количетсве процессов, в ограничении по памяти, и.т.д.... И как только наши пращуры поднимали 8.0 на оборудовании 2006 года..

и чего? На одном рпхосте работа пользователей замедляется пропорционально их количеству. На 2-х и более рмнгр начинает тупить при раздаче фоновых заданий рпхостам, в результате фоновое выполнение отчетов и длительные операции выполняются в 10 раз медленнее... Вот и сидишь, выбираешь режимы работы...

дык в том то и прикол.. что тогда, в старые времена, наши предки гнали гигагерцы не запарываясь на оптимизацию питания и всякие там внутренние инструкции.. вон, пообщайся с предками - услышишь старые байки про 3хгигагерцовые процессоры... а сейчас, тьфу, срамота.. "в режиме турбо 2.6"

умные люди ставят 8.3, включают режим "1 процес на сеанс" и в конфигурацию вносят константу "не использовать длительные операции" :)

В гробу я видел. Падение производительности операций записи в 10 раз если есть хотя бы один живой план обмена началось с 8.2.19 и в 8.3 до сих пор не вылечено. Нафиг-нафиг. Да и не откажутся уже пользователи от длительных операций. Удобно, привыкли.

Поставили 10 рейд - "это прелестно"(с), но может конфигурацию рейда дадите?

хм, странно, а я вот смотрю - никто не оценил длительные операции... большинство с кем общаюсь по привычке работают "последовательно"  - то есть если они запустили отчет то им надо увидеть результат.. и они сидят и ждут отчета.. никто не лезет паралельно еще что то формировать.

про 10 раз это откуда такое ?

Так они у тебя поди и не знают, что отчет в режиме формирования доступен для работы? А еще у меня толпа собственных АРМов/мастеров/обработок, получающих данные из внешних систем, рассчитывающих статистические прогнозы и прочие вещи, которые вполне могут выполняться асинхронно. И работают в параллели, и пользователь отрабатывает информацию по мере поступления ее на экран.

сразу вспоминается старый сервер терминалов с 2гб оперативки,  комплексной семеркой и 40 пользователей на нем... (работало нормально)

Что есть "длительные операции"? P.S. Сильно не пинайте

юзай механизм "Длительные операции" в БСП Абзац "Длительные операции"

спс!

На сколько пользователей нужно ставить 1 репхост? я не так много дел имел с 1Ской её не так давно перевели из файловой в SQL и теперь купили сервер. Вы поймите что я с такими вещами не сталкивался а теперь пришлось.Кривыми руками это отличная отговорка. а немного напрячься уже никто не хочет? SQL  съедает 4-5 гигов оперативки доступной остается еще около 6-7 гигов.

А можно кратко для тех у кого нет партнеской учетки?

+ также можно посмотреть какая схема энергосбережения сейчас на сервере...