У людей стоит компьютер как сервер, нём виндус сервер 2012. Core(ТМ)-i5 4460, памяти 16 Гб (две плашки по 8), ССД диск. База большая, работают давно, но когда была платформа 8.3.10 не жаловались. С последними обновлениями пришлось поставить платформу 8.3.14 и начались слёзы. Всё тормозит, на действия пользователя например открыть форму списка Номенклатуры сперва зависание, потом отмирает. Сперва замирает, потом отмирает. И так многое работает. Котёнок этот уже задолбал зевать. И тестирование исправление делаем, и полнотекстовый поиск обновляем индекс. Диспетчер задач показывает, что программа часто не отвечает. Кто что посоветует по железу поменять? Потому что уже не знаем куда смотреть.

(0) И сколько же там пользователей и какая база файловая или серверная?

И да готов поспорить что RDP да?

Оперативки для УФ надо 4 гб клиенту и до 4 гб на каждого юзера, чем больше их тем меньше на каждого требуется.
С серверной базой еще для sql сервера оперативка нужна и немало.

Короче было бы странно если не тормозило.

(2) *и до 4 гб на каждого юзера на сервере

(0) > не знаем куда смотреть.

Пригласите специалиста.
Ибо тут сейчас вам навангуют разной несусветной ереси на пару сотню постов, которая сможет решить вашу проблему с вероятностью 50/50 - может кто-то что-то угадает, а может и нет - как повезёт.

(1) база файловая, но до этого была серверная. Серверная ещё больше тупила. Тест гилёва показывал на серверной 17, на файловой 18. Отказались от серверной чтобы скуль не отжирал ресурсы. Пользователей 5-7. Часть сидят в терминале, часть на своих компах. И те и те плачут, что плохо. В терминале особого ускорения не наблюдается.

(4) сис. админ говорит, что по железу всё норм. Программист 1с делает все тесты и индексации, по максимуму всё урезал. Но прироста скорости нет. Проц особо не напрягается, но эска тупит.

Справочник номенклатура реально большой. Но может есть решение, которое будет быстро его обрабатывать?

(6) Прекрасная информативность... Что за железо, какой еще софт стоИт - это все сообщать нельзя ни в коем случае, сами обо все должны догадаться

(2) думаете затык в нехватке оперативы?

(6) Пригласите специалиста.
Если те двое, о которых Вы говорите, несут эту чушь, значит они не специалисты.

(6) так в том и дело, что недавно переустановили виндус и ничего не ставили, даже антивирус не стали ставить.

(10) а что мог бы сделать специалист, сверх того, что делается сейчас?

(5) > Тест гилёва показывал на серверной 17, на файловой 18.

Эта разница вообще ни о чем.

Начать надо с того, что выгнать с терминала пользователей. Все должны работать через тонкого клиента или веб-клиента.
Если файловая база - раздавать её через веб-сервер.
Но я бы вернулся на клиент-серверный вариант, выгнал бы терминальщиков с сервера и вообще убрал бы с сервера всё, кроме СУБД и 1С.

Причин тупизны может быть множество.

(12) > а что мог бы сделать специалист?

Найти причину проблем.

(0) удали windows и поставь lubuntu

удивишься, как будет всё летать

(5)(6) чтобы скуль не отжирал ресурсы. Проц особо не напрягается.

Вам не кажется что эти два утверждения несколько противоречат друг другу? Или как можно "отожрать" ресурсы, которые и так никем не заняты?

(15) в терминале на ней можно работать? Из под винды можно подключиться?

"Часть сидят в терминале, часть на своих компах" тема тупо вброс

(15) Сказочник.

(17) > в терминале на ней можно работать?

Зачем?

(17) А можно узнать на чем основана такая приверженность терминалке? Особенно для клиент-серверного режима?

(17) > в терминале на ней можно работать?

Терминальный сервер должен быть отдельным, а не в коем случае не с сервером приложения и СУБД на одной машине. Если уж вам вообще так принципиально наличие терминального сервера.

(5) пятничный подход. Продолжайте

(19) я лично пробовал с erp файловой

(17) нет проблем для никсов организовать сервер терминалов

(21) >  на чем основана такая приверженность терминалке?

Осмелюсь предположить, что автор ветки - упёртый клюшечник и фанат соответствующих костылей под семёрку.

(6) "сис. админ говорит, что по железу всё норм. Программист 1с делает все тесты и индексации, по максимуму всё урезал. Но прироста скорости нет. Проц особо не напрягается, но эска тупит." - выгнать обоих. Пригласить нормальных спецов.

(21)  а что такого плохого  в терминале для УФ?

(17) приверженность терминалке основана только на том, что комп терминальный "мощнее" и сетка вайфайная. Клиенты на своих машинах имеют 4 гб памяти и процы хуже, плюс по сетке будет потеря на передачу данных.

(0) "База большая, работают давно" - разговор ни о чем.  Хочешь решить проблему - давай цифры.

(26) предложите что-то дельное для ускорения, а то "упёртый клюшечник" в тупике.

(30) 6 гигов

(29) Тогда выносите сервер терминалов отдельно.
Но я бы лучше вложился в проводную сеть вместо WiFi.

(27) > выгнать обоих. Пригласить нормальных спецов.

Я уже предлагал. Меня не слушают (((.

Даю совет займитесь сервером

(32) > 6 гигов.

Это маленькая база. Если программист 1С вам сказал, что это большая база, его точно пора менять.

(32) Дождись еще нескольких гигов в размере и получи сюрприз  от файловой базы

(32) база или dt?

(36) тем не менее она тупит. Вопрос не в том какие базы считаются большими или маленькими. Вопрос что она тупит.

(31) Вернись к клиент-серверному режиму. Для чего-то сервер 1С покупали. Правда я уже сомневаюсь, что покупали хоть что-нибудь

(38) база

(39) кривые руки у твоих админов или слишком дешёвые

"Диспетчер задач показывает, что программа часто не отвечает" // Какой процесс?

(39) Будь база реально большой, можно было бы частично объяснить причину тупизны её размерами. А так - причина тупизны лежить исключительно в плоскости квалификации обслуживающего её персонала.

В конце окажется что в настройках схемы питания стояло "Экономия энергии"...
И\или в настройках биоса включен режим экономии энергии.

(41) ну 6 гиг - это считай пустая база.

С вероятностью 99% причина всех бед в беспроводной сети.
Ну не умеет 1С работать нормально по WiFi.

В зависимости от стабильности и качества работы сети проблема решается либо пересаживанием всех в терминал и без какого-либо доступа по сети. Либо развёртыванием веб-сервера и доступом через него.

Но повторюсь. Я бы развернул проводную сеть.

Итак, что вам нужно сделать:
1. Переходите на клиент-сервер.
2. Мониторить загрузку диска, памяти и процессора.
3. Прокачать то, чего не хватило на этапе 2.

(48) + ещё выгнать всех из терминала.

Для сервера СУБД + приложение + терминалка ресурсов сервера из (0) явно недостаточно.

"и сетка вайфайная." - в топку! Сеть ставьте нормальную.

Структуру сетки можете нарисовать?

(2)"Оперативки для УФ надо 4 гб клиенту и до 4 гб на каждого юзера, чем больше их тем меньше на каждого требуется. С серверной базой еще для sql сервера оперативка нужна и немало."

1С в сговоре с производителями железа ))) стимулируют процесс апгрейда

(52) тонкий клиент - он такой тонкий, что толще толстого 8.2 )

(5) В этом весь затык.
Все должны сидеть в терминале и тормозить не будет.
Если хоть один сидит локально на своей машине, то обмен с его машиной данными тормозит работу всем!

(54) Поддерживаю.
Один пользователь по сети всех тормозит, а тут еще и вайфай

(53) Там браузер полноценный внутри уже в 8.3.14 на webkit а не внешний используется

(54) (55) У меня вот недавно такой случай и произошел.
База файловая 3 Гб, 15 пользователей, работают по RDP, база прям летает.
Тут звонки пошли, один другой, жалутся тормозит все.
Тоже начал смотреть, проц отдыхает, диск не загружен, ОЗУ 40% еще есть.
Смотрю, а один зашел в базу со своей машины.
Выгнал его из базы и все стало хорошо.
Пошел на всех компах удалил желтые значки с рабочего стола.

(57) необязательно в терминале, вебпубликация может помочь, но мы допустим на УФ используем rdp, ибо клиенты у нас действительно тонкие  - raspberry pi

(58) Согласен, но у автора уже в терминале сидят, им проще и других туда пересадить.

Хм.. а как может помешать то что кто то не в терминале, а с локального компьютера работает? Какая разница то?

(59) Проще, не всегда правильно

А характеристики сервера кто огласит?
Где валяется база?
На какой сервер заходят по RDP?

(60) было что-то про случаи при котором к ресурсу обращается не один компьютер и что-то про блокировки

чтото это все странно в (0)..
вот сейчас зашел на сервер в одной организации по rdp,
настроена виртуалка под vmware:
i5-3570K, 13 Гб оперативы, винт не SSD, несколько файловых баз примерно по 3 Гб каждая.
в данный момент в БП 3.0 работают 5 человек, по RDP, занято 11 Гб памяти, проц- загрузка не больше 20%.
позвонил им, спросил не тормозит ли что, говорят что все устраивает, все быстро

можно влезть в ваше обсуждение?
тормоза при миксе терминал/собственный комп касаются только УФ? Или на ОФ тоже бывает?
сервер терминалов отдельно, сервер предприятия и БД отдельно
А если серверов терминалов будет несколько (как раз в мае собираемся переезжать на ферму)

+(64) и установлен Server 2008 R2 Standard

(60) Большая разница.
Архитектура файловой базы работает так, что допустим обращении к данным она их тянет к себе на машину одновременно блокируя записи для других. А так как по сети и обычно клиентские машины тормозные, то тормозит все.

(60)файловом варианте очень большой поток информации тянется на клиент + блокировки
(65) ОФ будет примерно тоже самое, опять же все зависит от конфигурации

(65) Тормоза касаются только ОФ.
При УФ данные на клиент не тянутся.
УФ это почтит RDP и есть, если можно провести такую аналогию.

(65) > тормоза при миксе терминал/собственный комп.

Это касается в большей степени файловых баз и конкретных условий тормознутости сети (например, как у автора  ветки, WiFi).

(70) Не только сети, но и комьюетра клиента, пока он обрабатывает данные, все остальные ждут.

(70) спасибо. файловых нет, вайфай местами есть, но там тонкие клиенты (wtware). естественно в терминале

(0) нарой еще один такой же сервер (судя по его конфигурации новый вы не купите, так что работаем с тем, что имеем), поставь туда скуль, и пусть с этого текущего rdp сервера народ подключается к скулю на вот этом новом другом сервере..

(52) (53) Выдыхайте: он имел в виду общую память и под клиента, и под сервер приложений, и под СУБД в расчете на одного пользователя.

(74) Файловая 1С УФ на одном компе локально рекомендация 8 гигов.
УФ файловая на двух компах 4 гига для тонкого или веб-клиента и 4 гига для "сервера".

(75)+ Это для одного сеанса запущенного.
Множество сеансов там не простое умножение по оперативке а все сильно сложнее.

Но 16 гигов памяти в (0) это не просто жопа а нечто за гранью разумного (УФ, RPD, sql) и пробило дно минимальных требований.

(76) *RDP

(75) "Файловая 1С УФ на одном компе локально рекомендация 8 гигов" // До относительно недавнего времени 64б клиентов вообще не было и соответственно 32б клиенты валились только при превышении 2/3 Гб оперативки. Что наблюдалось только при каких-нибудь редкоиспользуемых сценариях - например, жирный какой отчет или массовое удаление записей регистра. Сейчас запустил УТ 11 файловую - на старте отожрала 1 гиг. Зачем же 8?

локальная файловая база (обычная базовая БП3) на 2 гигах памяти это тормоза нереальные и оно постоянно напоминает всплывающими.
Добавляешь 1 гиг до 3 - уже шустрее, 4 гига еще лучше, можно работать если больше ничего не запущено.
Но только 8 гигов позволяют еще браузер с антивирусом кроме 1С запустить и не иметь тормоза.

(78) >Зачем же 8?

Там куча сервисов в фоне одновременно и все через xml обмен и жрут-жрут.

А уж обновление конфы особенно по риб это пипец.
Вес конф типовых cf видел? Как думаешь сколько cf внутри xml файла обмена занимает оперативки?

(80)+ Гыгы Недостаточно памяти при обновлении КА на 2.4.7.150

А, ну так ты под браузер и антивирус еще закладываешь :) Я-то про выделенную / доступную чисто под процесс 1С память спрашивал

(81) Это у него карма такая, если Я не перепутал ник)

(69) "При УФ данные на клиент не тянутся.
УФ это почтит RDP и есть" - это шутка такая?
УФ таскает данных на клиента поболее, чем ОФ. Запись в случае файлового варианта, что ОФ, что УФ - идет с клиента. Запись в случае серверного - идет с сервера.

(84) Не таскаются данные для выполнения запросов и выборок в этом смысле меньше.
HTTP протокола однако, почти RDP протокола однако, оленя не сильно устает.