Наткнулся на такой косяк и хачу, чтобы больше не кто на нем не споткнулся.... сэкономит кучу времени... По собственному опыту проверено, что windows server 2012 standard да и другие версии 12 оси серверной я думаю не лучше.... при установке компоненты узел сеансов удаленных рабочих столов 1с 8.3 в моем случае начинает жутко тормозить .... формы открываются очень долго .... если судить по замерам документ ЧЕКККМ с установленным узлом 5-8 секунд... без узла 0.8-2 сек, разница очень существенная, это и касается других документов, а так же и проведение и формирование отчетов увеличивается в разы и никакая оптимизация железа Вам в этом не поможет.... Ответ тех. Поддержки майкрософт "Пишите на форму течнет Вам может быть чем ни будь помогут". Так что кто готовиться ставить 2012 ось + серв. терминалов под него 1000 раз подумайте....
По теме из базы знаний
- Создание дополнительного кластера 1С предприятия для Windows Server 2012 на одном физическом сервере
- PostgreSQL + 1С Сервер + Windows Server 2012 R2
- Настройка PostgreSQL для работы в связке с 1С 8.х на платформе Windows Server 2012, объём БД более 200 Гб
- Удаленный рестарт сервиса 1С на Windows Server 2012 R2 (перезапуск агента 1С на кластере не под администратором)
- Увеличение шрифта на терминальных серверах Windows Server 2012 и 2016 для приложений RemoteApp
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Вот объясните мне, нафига ставить платформу 8.3 и сервер терминалов?! Удаленный рабочий стол является вариантом тонкого клиента. Вы в курсе, что начиная с версии 8.2 в 1С появился свой тонкий клиент?
У вашей 8.3 режим работы толстый клиент обычное приложение или просто такой модный тренд "тонкий клиент на тонком клиенте тонким клиентом погоняет"?
П.С.: Более полу года Windows 2012 R2 + MS SQL 2012 - нет нареканий ни по стабильности, ни по производительности.
У вашей 8.3 режим работы толстый клиент обычное приложение или просто такой модный тренд "тонкий клиент на тонком клиенте тонким клиентом погоняет"?
П.С.: Более полу года Windows 2012 R2 + MS SQL 2012 - нет нареканий ни по стабильности, ни по производительности.
(3) h00k, А потому что проще купить один сервак и загнать туда всю толпу и пусть там все делают чем покупать и делать типа офисного компа каждую машину, у меня 40 юзверей. Про тонкий килент конечно вкурсе... Я соглашусь с тем что если связку 1с + sql оставить на сервере а килентскую часть запускать у юзверя все работает на ура... Я говорю именно про узел сеансов удленных рабочих столов, естественно что эта компонента свзяана с сервером терминалов.
(16) asved.ru, Я бы так не сказал хотя все это нада подсчитывать сколько лицензии будут стоить и как будет работать))) у меня в парке стоят пк старые... и + ко всему можно ставить тонкие кклиенты... а не покупать нормальные офисные компы на каждое раб место..
(19) Buldog57, на современном "тонком клиенте" вполне может быть запущена linux-версия тонкого клиента 1С или веб-клиент. И никаких RDS CAL не нужно. Более того, мы даже можем использовать Linux/Postgre в серверной части и вообще получить все лицензирование (за исключением 1С, естественно) на халяву.
(19) Buldog57,
Вся прелесть ситуации заключается в том, что если у вас нет процессоров древнее пентиум 4, то локально запущенный тонкий клиент 8.3 будет работать даже с меньшими проблемами чем на среднем терминальном сервере.
А если сервер 1С опубликовать на веб-сервере и подключаться к базе тонким клиентом по http, то соединение будет стабильнее чем RDP и почти не чувствительно к шалостям админов.
Управляется все это хозяйство групповыми политиками, что в свою очередь позволяет централизованно администрировать клиентские рабочие места с минимальными временными затратами.
у меня в парке стоят пк старые
Вся прелесть ситуации заключается в том, что если у вас нет процессоров древнее пентиум 4, то локально запущенный тонкий клиент 8.3 будет работать даже с меньшими проблемами чем на среднем терминальном сервере.
А если сервер 1С опубликовать на веб-сервере и подключаться к базе тонким клиентом по http, то соединение будет стабильнее чем RDP и почти не чувствительно к шалостям админов.
Управляется все это хозяйство групповыми политиками, что в свою очередь позволяет централизованно администрировать клиентские рабочие места с минимальными временными затратами.
(22) h00k, Извиняюсь что влезаю.
Мы в свою очередь отказались от Тонкого клиента по одной причине: в случае потери соединения с базой вся забитая, но не сохраненная в документах пользователей информация попросту терялось! А с учетом того что интернет связь до сих пор оставляет желать лучшего, боюсь этот вариант не совсем подходит для комфортной работы... В терминале же, даже при потере связи вся набранная информация остается! И даже если отключат электричество, можно на следующий день зайти и продолжить работу на том месте, на котором прервались...
Мы в свою очередь отказались от Тонкого клиента по одной причине: в случае потери соединения с базой вся забитая, но не сохраненная в документах пользователей информация попросту терялось! А с учетом того что интернет связь до сих пор оставляет желать лучшего, боюсь этот вариант не совсем подходит для комфортной работы... В терминале же, даже при потере связи вся набранная информация остается! И даже если отключат электричество, можно на следующий день зайти и продолжить работу на том месте, на котором прервались...
(23)
Это при подключении тонкого клиента по протоколу 1С или при подключении тонкого клиента по протоколу http?
Спрашиваю именно по тому, что подключение по протоколу http, почти всегда, позволяет дождаться восстановления соединения. Были случаи когда клиент минут 10 висел, потом связь восстановилась и работа была продолжена.
в случае потери соединения с базой вся забитая, но не сохраненная в документах пользователей информация попросту терялось!
Это при подключении тонкого клиента по протоколу 1С или при подключении тонкого клиента по протоколу http?
Спрашиваю именно по тому, что подключение по протоколу http, почти всегда, позволяет дождаться восстановления соединения. Были случаи когда клиент минут 10 висел, потом связь восстановилась и работа была продолжена.
(5)Во первых - не проще, а ваше заблуждение видимо связано с недостатком опыта.
Во вторых - совмещение ролей на одном физическом сервере: Сервера БД (Сервер 1С + SQL ) и Терминального сервера крайне нежелательно и не рекомендуется ни Майкрософт, ни 1С.
Во вторых - совмещение ролей на одном физическом сервере: Сервера БД (Сервер 1С + SQL ) и Терминального сервера крайне нежелательно и не рекомендуется ни Майкрософт, ни 1С.
(7) h00k, по поводу во первых... Смотря с какой колокольни смотреть.. Заблуждение это Вы имеете ввиду что проще всех на сервер загнать?, если так интересно почему же?
По поводу во вторых... Да я в кусре что не рекомендуется ... был вариант загнать всех в терминал на виртуалку.
По поводу во вторых... Да я в кусре что не рекомендуется ... был вариант загнать всех в терминал на виртуалку.
(7)
Поискал ветку, с трудом, но :
Кто же это написал? Бааа, да это же h00k! Вы уж определитесь, коллега, таки рекомендуется совмещать или нет? А то такой плюрализм мнений в одной голове попахивает шизофренией.
совмещение ролей на одном физическом сервере: Сервера БД (Сервер 1С + SQL ) и Терминального сервера крайне нежелательно и не рекомендуется ни Майкрософт, ни 1С.
Помнится, не так давно тут меня уверяли, что эта рекомендация устарела. Вот только кто это утверждал, и будет ли его мнение авторитетно для вас?
Поискал ветку, с трудом, но :
"Кстати, рекомендацию держать MS SQL сервер и сервер терминалов на разных компах никто не отменял."
С выходом 1С: Предприятие 8.2.17 - данная рекомендация стала не актуальна, а в подобных случаях ещё и вредна. Так-как скорость обмена "Сервер 1С <-> SQL сервер" по сети гораздо ниже скорости обмена через shared memory.
С выходом 1С: Предприятие 8.2.17 - данная рекомендация стала не актуальна, а в подобных случаях ещё и вредна. Так-как скорость обмена "Сервер 1С <-> SQL сервер" по сети гораздо ниже скорости обмена через shared memory.
Кто же это написал? Бааа, да это же h00k! Вы уж определитесь, коллега, таки рекомендуется совмещать или нет? А то такой плюрализм мнений в одной голове попахивает шизофренией.
(10) Cooler, Вы путаетесь. В одном случае идет речь о размещении пользовательских процессов на сервере с SQL и сервером приложения 1С, что плохо по определению, а в другом - о размещении сервера приложения и SQL на одном хосте, что правильно исходя из поддержки Shared memory.
(13) Я не путаюсь, это вы пытаетесь меня запутать "пользовательскими процессами". В обоих случаях речь идет (читайте приведенные цитаты) о совмещении сервера терминалов и сервера SQL.
И вот насчет этого совмещения путается многоуважаемый h00k, то опровергая рекомендацию их не совмещать, то сам давая такую.
И вот насчет этого совмещения путается многоуважаемый h00k, то опровергая рекомендацию их не совмещать, то сам давая такую.
(10)Cooler
Забавный вы, в том сообщение речь шла о разнесении серверов 1С:Предприятие, MS SQL и сервера терминалов на разные физические сервера. Я указал конкретный дистрибутив 1С: Предприятие, начиная с которого разнесение сервера 1С: Предприятие и сервера MS SQL на разные физические сервера существенно замедляет работу.
А по поводу сервера терминалов:
Ну да, я слегка промахнулся с цитируемым текстом, бывает... Вы лучше свои сообщения еще раз перечитайте, коллега...
Кто же это написал? Бааа, да это же h00k! Вы уж определитесь, коллега, таки рекомендуется совмещать или нет?
Забавный вы, в том сообщение речь шла о разнесении серверов 1С:Предприятие, MS SQL и сервера терминалов на разные физические сервера. Я указал конкретный дистрибутив 1С: Предприятие, начиная с которого разнесение сервера 1С: Предприятие и сервера MS SQL на разные физические сервера существенно замедляет работу.
А по поводу сервера терминалов:
У вас слишком простая задача, для которой достаточно одного правильно настроенного севера.
И еще, для 1С: Предприятие - есть тонкий клиент, терминал - другой вариант тонкого клиента. Зачем вам масло масляное?!
Настройте на сервере web-сервер и подключайтесь к базам тонким клиентом через http - жизнь резко проще станет, особенно в плане стабильности 1С.
(с) Я, с того же поста...
И еще, для 1С: Предприятие - есть тонкий клиент, терминал - другой вариант тонкого клиента. Зачем вам масло масляное?!
Настройте на сервере web-сервер и подключайтесь к базам тонким клиентом через http - жизнь резко проще станет, особенно в плане стабильности 1С.
Ну да, я слегка промахнулся с цитируемым текстом, бывает... Вы лучше свои сообщения еще раз перечитайте, коллега...
(17)
Лично я говорил только о совмещении сервера терминалов и сервера SQL. Найдите хоть одно мое слово о сервере 1С:Предприятие?
P.S. Согласен быть "забавным", только бы не занудным всезнайкой, неспособным признать свою неправоту - меня от таких людей "так блевать и кидат!"
в том сообщение речь шла о разнесении серверов 1С:Предприятие, MS SQL и сервера терминалов на разные физические сервера.
В каком "в том"? Извините, телепатией не владею.
Лично я говорил только о совмещении сервера терминалов и сервера SQL. Найдите хоть одно мое слово о сервере 1С:Предприятие?
Вы лучше свои сообщения еще раз перечитайте
Я прекрасно помню, что и когда писал. В отличие от вас, коллега...
P.S. Согласен быть "забавным", только бы не занудным всезнайкой, неспособным признать свою неправоту - меня от таких людей "так блевать и кидат!"
Использую терминальный доступ на базе Win2012. 1С-ка летает.
Не стоит вводить в заблуждение коллег. Пожалуй стоит посмотреть где руки приложили. Скорее всего в настройках винды в части сети. Ну и приложения (1С, например) должны быть установлены корректно для использования на терминальных серверах, а не setup-next-next-finish.
Не стоит вводить в заблуждение коллег. Пожалуй стоит посмотреть где руки приложили. Скорее всего в настройках винды в части сети. Ну и приложения (1С, например) должны быть установлены корректно для использования на терминальных серверах, а не setup-next-next-finish.
По поводу размещения сервера 1с с SQL на одном физическом сервере, к какому мнение все таки пришли.
У меня сейчас на одном сервере i5 с RAM 16 Гб крутится 1с сервер и на ней же SQL сервер. Одновременно работают 5 человек. Плюс по веб-сервисам постоянно идет обмен со сторонними приложениями. Все принципе норм крутится без глюков, разве что иногда SQL съедает всю оперативку, лечится перезапуском сервера.
Теперь вот в связи с планируемым увеличением нагрузки, хочу все перенсти на новый сервер намного мощнее на Widows Server 2012, и на нем же поставить и 1с и SQL.
У меня сейчас на одном сервере i5 с RAM 16 Гб крутится 1с сервер и на ней же SQL сервер. Одновременно работают 5 человек. Плюс по веб-сервисам постоянно идет обмен со сторонними приложениями. Все принципе норм крутится без глюков, разве что иногда SQL съедает всю оперативку, лечится перезапуском сервера.
Теперь вот в связи с планируемым увеличением нагрузки, хочу все перенсти на новый сервер намного мощнее на Widows Server 2012, и на нем же поставить и 1с и SQL.
Подскажите.
Планируется Win Server Standart 2012 OLP
На нем будет стоять сервер 1С и Sql Express (для начала). К нему будут подключаться с 5 компьютеров по локальной сети и с 3-х компьютеров по rdp.
Что нужно будет покупать для работы если в организации компьютер=пользователь и только 3 из них будут подключаться по rdp.
Я так понял что понадобятся 4 Dvc CAL и 4 RDP CAL ? Или же для пользователей, которые просто в локалке будут подключаться к SQL тоже нужно приобретать лицензии?
Что можно будет поставить в триальном режиме для тестирования? Какие калы нужны?
Планируется Win Server Standart 2012 OLP
На нем будет стоять сервер 1С и Sql Express (для начала). К нему будут подключаться с 5 компьютеров по локальной сети и с 3-х компьютеров по rdp.
Что нужно будет покупать для работы если в организации компьютер=пользователь и только 3 из них будут подключаться по rdp.
Я так понял что понадобятся 4 Dvc CAL и 4 RDP CAL ? Или же для пользователей, которые просто в локалке будут подключаться к SQL тоже нужно приобретать лицензии?
Что можно будет поставить в триальном режиме для тестирования? Какие калы нужны?
Dvc CAL и RDP CAL по 3 лицензии если 3 пользователя,Sql Express вроде бы бесплатный так что я думаю что лицензий не надо, а вот к 1с надо на все подключения.
В режиме тестирование не надо лицензии мне кажется, а ставить можете все что душе пожелается ограничения только по времени работы пробной версии. Пр косяк 2012 я писал вроде люди говорят что все норм работает, но я так и откатился на 2008р2 интерпрайс.
В режиме тестирование не надо лицензии мне кажется, а ставить можете все что душе пожелается ограничения только по времени работы пробной версии. Пр косяк 2012 я писал вроде люди говорят что все норм работает, но я так и откатился на 2008р2 интерпрайс.
(29), Essentials под облачные технологии, напаритесь осваивать, просто только в рекламе.
(31), УТ10 будет работать любая, sql лучше.
Лицензий Microsoft в триале не нужно, а 1С нужно.
В сервере, по-моему, главное - это использование серверной матплаты, памяти ЕСС и процессора типа Xeon,
пусть даже дешевых, ну и винчестеров пошустрее. Тогда все будет хорошо.
А вот если используется клиентский комп с i5 и несерверной матплатой, то могут быть тормоза при большой базе.
SQL Express только для баз меньше 5Гб.
(31), УТ10 будет работать любая, sql лучше.
Лицензий Microsoft в триале не нужно, а 1С нужно.
В сервере, по-моему, главное - это использование серверной матплаты, памяти ЕСС и процессора типа Xeon,
пусть даже дешевых, ну и винчестеров пошустрее. Тогда все будет хорошо.
А вот если используется клиентский комп с i5 и несерверной матплатой, то могут быть тормоза при большой базе.
SQL Express только для баз меньше 5Гб.
(32) Павел здравствуйте!
Так чем ваша история закончилась, WEB , через браузер, Тонкий клиент через http, или всё таки остались на RDP подключениях. Появилась проблема апгрейда . 3 файловых базы, одна из них бухгалтерия, одновременно до 10 раб мест. предыдущий специалист раскидал базы по двум не серверным компам на win7prof, база с бух-ей с 3 юзерами на i3 c 8гигами оперативы по рдп тупит, иногда даже при открытии журналов. На sql переходить не буду по финансовым соображениям. Стою перед выбором рдп или тонкий клиент по http, заодно и сет перевести на 1 гБит хочу.
Так чем ваша история закончилась, WEB , через браузер, Тонкий клиент через http, или всё таки остались на RDP подключениях. Появилась проблема апгрейда . 3 файловых базы, одна из них бухгалтерия, одновременно до 10 раб мест. предыдущий специалист раскидал базы по двум не серверным компам на win7prof, база с бух-ей с 3 юзерами на i3 c 8гигами оперативы по рдп тупит, иногда даже при открытии журналов. На sql переходить не буду по финансовым соображениям. Стою перед выбором рдп или тонкий клиент по http, заодно и сет перевести на 1 гБит хочу.
(33) История не моя, а автора темы. Про ваш же случай я писал. У меня тормозило и на 16 гигах из-за i3.
Нужен серверный комп и серверная ОС, даже например win 2003,тогда тормозить не будет.
SQLexpress бесплатный до 5 Гб. Сомневаюсь, что ваши 3 юзера могут догнать базу до 5 Гб, поэтому пользуйтесь, будет все лучше. Когда базу догонят до 5, тогда можете обратно переконвертировать в файловую, если боитесь.
Нужен серверный комп и серверная ОС, даже например win 2003,тогда тормозить не будет.
SQLexpress бесплатный до 5 Гб. Сомневаюсь, что ваши 3 юзера могут догнать базу до 5 Гб, поэтому пользуйтесь, будет все лучше. Когда базу догонят до 5, тогда можете обратно переконвертировать в файловую, если боитесь.
(34) ОК. Спасибо!
ясно, контору видимо просто обманули купив им в раб. станцию объявив сервером.
Подскажите, если к примеру каталог с файловой бухгалтерией весит 1 гиг, при переходе на скул размер базы наверняка меняется вот только в какую сторону? Да, и технологический журнал тоже переносится или нет?
Спасибо!
ясно, контору видимо просто обманули купив им в раб. станцию объявив сервером.
Подскажите, если к примеру каталог с файловой бухгалтерией весит 1 гиг, при переходе на скул размер базы наверняка меняется вот только в какую сторону? Да, и технологический журнал тоже переносится или нет?
Спасибо!
(35)
По моему опыту в MSSQL увеличивается вдвое. Т.е. файловая 1Гб будет MSSQL - 2Гб (до 5 Гб далеко) Я переносил через dt, журнал не переносился.
посмотрел а там на 7-е про
Семерки вместо сервера, Posgre вместо MS - все это ухудшает работу.
Лучше просто 2003 с большой памятью на серверном железе.(можно старом, достаточно дешевом б/у)
Подскажите, если к примеру каталог с файловой бухгалтерией весит 1 гиг, при переходе на скул размер базы наверняка меняется вот только в какую сторону?
По моему опыту в MSSQL увеличивается вдвое. Т.е. файловая 1Гб будет MSSQL - 2Гб (до 5 Гб далеко) Я переносил через dt, журнал не переносился.
посмотрел а там на 7-е про
Семерки вместо сервера, Posgre вместо MS - все это ухудшает работу.
Лучше просто 2003 с большой памятью на серверном железе.(можно старом, достаточно дешевом б/у)
(39)
Да не, лучше уж Постгри или ДБ2, чем файловый вариант. Трёх звенка, конечно, помедленней немного будет - если правильно настроить, то процентов на 20, но по надёжности хранения, скорости восстановления данных и уж тем более по масштабированию существенно превосходит файловые варианты БД.
Так что, если с базой работает больше трёх пользователей и есть возможность использовать сервер 1С с какой-нибудь СУБД, то лучше использовать.
А какую СУБД использовать - дело десятое... понятно, что лучше использовать ту, которую хорошо знаешь. Но, если вопрос упирается в стоимость лицензий, то можно и свободно-распространяемую СУБД поставить да потихоньку изучить. Самое смешное, что обычно, такой подход обходится дороже чем просто закупить нужное количество лицензий, но затраты на ФОТ почему то забывают посчитать, при подобной "экономии".
Posgre вместо MS - все это ухудшает работу.
Да не, лучше уж Постгри или ДБ2, чем файловый вариант. Трёх звенка, конечно, помедленней немного будет - если правильно настроить, то процентов на 20, но по надёжности хранения, скорости восстановления данных и уж тем более по масштабированию существенно превосходит файловые варианты БД.
Так что, если с базой работает больше трёх пользователей и есть возможность использовать сервер 1С с какой-нибудь СУБД, то лучше использовать.
А какую СУБД использовать - дело десятое... понятно, что лучше использовать ту, которую хорошо знаешь. Но, если вопрос упирается в стоимость лицензий, то можно и свободно-распространяемую СУБД поставить да потихоньку изучить. Самое смешное, что обычно, такой подход обходится дороже чем просто закупить нужное количество лицензий, но затраты на ФОТ почему то забывают посчитать, при подобной "экономии".
(33)
Плохой выбор - тонкий клиент через http будет подтормаживать, да и RDP, при более чем 5 одновременно работающих пользователях, мало чем поможет.
Сервер 1С Предприятие, лучше х64, плюс PostgreeSQL или MS SQL Dev проблему точно решит. А все остальные варианты только немного отсрочат тот момент, когда с базами станет совсем невозможно работать.
Стою перед выбором рдп или тонкий клиент по http, заодно и сет перевести на 1 гБит хочу.
Плохой выбор - тонкий клиент через http будет подтормаживать, да и RDP, при более чем 5 одновременно работающих пользователях, мало чем поможет.
Сервер 1С Предприятие, лучше х64, плюс PostgreeSQL или MS SQL Dev проблему точно решит. А все остальные варианты только немного отсрочат тот момент, когда с базами станет совсем невозможно работать.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот