Всем привет.
Проблема. У руководства компании появилось желание вывезти сервер на новое место. На этом сервере установлена 1С 7.7 ТиС база в SQL.

Вопрос. Нормально (без тормозов) ли будут работать 50 пользователей с этой базой через иниернет при условии, что боступ будет НЕ через удаленный рабочий стол а напрямую т.е. у пользователей на местах установлены 1С ки, а путь к базам прописан на удаленный SQL сервер?

Поделитесь опытом. Может есть люди у которых работает в подобном режиме?

тормоза поймаешь

Плохо будет работать, Сразу скажу.

ну это вам тогда какой толщины канал надо будет.

(0) не будут. Даже один пользователь на широком канале не будет. Она на 10МБит тормозит безбожно, а интернет и того тормознее. Только покупать второй сервак под сервер терминалов, иначе никак.

а в чем проблема работать на том серваке удаленно?

(5) В sql

А что нельзя совместить сервер терминалов и SQL? Чем это черевато?

(7) А ты не знаешь?

а смысл прятать сервак за интернетом? мания преследования? или реально рыло в пушку?

Интернет это зло.

(9) примерно понимаю автора, стукни в аську - расскажу

(8) нет - незнаю, поэтому и спрашиваю. А что нитак? Расскажите, пожалуйста.

(0)А пингвины летают?
Как только найдешь решения для пингвинов, то 1С полетит :)

(0)Запосися 1С++ приблудой для написания прямых запросов :)

(12) В поиск. Тема лет семь уже как обсуждена...

Как я понимаю без терминального сервера не обойтись. Тогда вопрос такой. Сколько оперативки заложить и какой проц, чтобы 50 пользователей ТиС 7.7 бед не знали?

(16) Поиском не пользуемся принципиально?

(16) общепринятая рекомендация - не менее 256 мб на каждого пользователя. Поэтому и СКЛ на этом серваке не советуют держать, т.к. будут за оперативку воевать. Да и процессы... Кстати, напомнили, обязательно установите компоненту "снижения 100% нагрузки на сервер в терминале".

(16) у нас 16-ядерный с 32 Гб оперативки на 200 пользователей.. и то..

(0) Лучше б спросил, хватит ли на 50 щей 1 терминала?

(16) все относительно ;)
(7) можно, но не на 50 душ и без AD, работать будет нормально с небольшой базой и человек на 10-15, к примеру

(16) в общем случае: два проца-квада, зеркало под систему, от 16 гиг памяти. но так не подбирают имхо :)

(18) я вас умоляю. зачем 256 метров для 7ки????

(16) вам надо будет 2 сервера как минимум 4х головых под терминал и 1 СКЛ сервер. памяти по 4 гига га каждом терминале

(18) >> не менее 256 мб на каждого пользователя

Вы что сдурели? Это для 8-ки требования. ?-ке 30-50 Мб на лицо за глаза хватит.

(23) думаю, что один сервак (терминальный) - потянет, собсно я это на практике вижу :)

А размер базы sql, то хоть какой?

+25 памяти меньше 8 - не ставил бы

(26) какая разница? разные же сервера

Я бы тоже скуль на одном держал, терминал на другом.

(29) ну по этому вопросу вроде с автором договорились :)

При большом пинге работать по rdp практически невозможно.

(31) ну мы не знаем, какой там пинг будет :)
вариантов как бы нет больше нормальных, разве что цитрикс пробовать (менее прожорливый) - но тут я не советчик, не знаю его
так что налаживать каналы и пытаться работать по rdp

(7) практически ничем не чревато. Терминал все-го лишь отожрет памяти под процессы, и увеличит кванты времени.

(30) Ну и зря - при нормальном объеме памяти, 64 битной винде, многоядерном/многопроцессорном серваке и включенном в сиквеле AWE - никаких проблем совсестного использования не будет.

Если пользователи будут глушить систему кривыми отчетами - то есть средства ограничения загрузки проца (ядра) процессом.

(34) это неправильно с точки зрения разноплановости нагрузок, неправильно идеологически, по деньгам... я думаю, тоже неправильно выйдет :)
т.е. лучше (без фанатизма, конечно) разделять задачи по физическим серверам, собсно это не мною придумано :)

+36 какой конфиг ты предполагаешь на 50 тел и базе... сколько же у них база... ну давай гиг на 10 прикинем. твой вариант?

(36) Это правильно и с финансовой точки зрения, и с точки зрения производительности. С точки зрения затрат на обслуживание резервное копирование и т.д. (всё про совмещение на одном серваке)
(37) 16 Гигов оперативки - за глаза хватит.
200 пользователей, в среднем 32 метра - 6.5 гигов, и гигов 6.5 (можно и меньше) отвести под Сиквел.

(34) всегда думал что AWE - это костыль для 32 бит...

(34) AWE на 64 бит? Неплохо... Наука идёт вперёд семимильными шагами, скот^H процессоры за ней не угоняются...

(40) Знаток Сиквела? Под SQL2000 для использования памяти СИКВЕЛОМ больше 2 гигов - в настройках сиквела под ЛЮБУЮ винду нужно включать AWE.

ДенисЧ, читай, просветляйся.
в принципе из всего текста достаточно знать скрипт

sp_configure 'show advanced options', 1
RECONFIGURE
GO
sp_configure 'awe enabled', 1
RECONFIGURE
GO
sp_configure 'max server memory', 6144
RECONFIGURE
GO
   
http://support.microsoft.com/kb/274750

(41)+ в принципе логично... 2000 скуля на 64 бита то нету...

(41) А что, 2000скл есть в 64бита?

(39) я тоже так думал :)
(40) :)))
это NS перегнал современников ;)
(41) да ты шо? честно, ты неправ :)
http://msdn.microsoft.com/ru-ru/library/ms190673.aspx
"Расширения AWE позволяют 32-разрядным операционным системам обращаться к большим объемам памяти."

http://social.msdn.microsoft.com/forums/en-US/sqlsetupandupgrade/thread/e2ec3fd2-0a8f-41d9-9715-3358f9563d7d
"You don't need to enable AWE via sp_configure if you are running the 64bit version on x64"
(42) AWE необходимо для работы приложений с PAE, которая отсутствует как класс в x64 ОС  :)

(42) Я-то просвещусь. Но про 64 ты подумай... подумай... подумай...

Ребяты, да вы офонарели. У нас на 2*Core2QUAD, 8 Гб оперативы спокойно 40 чел терминалом летают в "тяжелой" базе. притом на серваке и скуль и терминал стоит

(44) вроде поддержка x64 добавлена с sp4 для sql2000, но не юзал и не уверен

(47) как тебе удалось найти двухпроцессорную плату под Core2Quad? :)

(44) С чего ты взял? AWE в сиквеле поэтому и нужно включать, что его 32-битного нет.
(46) О чем думать? сиквел 2000 использует при включенном AWE (AWE не в винде конечно, а в Сиквеле) любое количество памяти в 64-битной винде через системный Кэш.
(47) И база 20 Гигов?

(+50) читать -  AWE в сиквеле поэтому и нужно включать, что его 64-битного нет.

(49) Умение :)

(52) тоже вариант... :)

(50) NS вдумчиво почитай по моим ссылкам, нет AWE в x64, ну нету :)

(52) так ты 4 ноги отпиливал? :))

(54) Блин, ну ты тормоз... AWE есть в сиквеле - AWE вообще метод не винды, а 32-битных приложений, и 64 битная винда умеет выделять 32-битным приложениям использующим AWE необходимую память.
забиваемся на 1000$, и я тебе пишу быстро 32-битный пример? Согласен? Или тебе достаточно того что на серваке где я сижу под 64битную винду крутятся три 20гиговые базы с выделенным под SQL AWE.

(54) Еще как есть
http://www.sql.ru/articles/mssql/2005/070703UsingAWElockedPagesInMemoryOn64bit.shtml

(56) в чем проблема поставить sql x64? собсно я иначе и не предполагал :)
зачем ставить 32-битный скуль на 64-битную винду?

(55) Опечатался: 2*QuadCore Intel Xeon - Everest меня поправил :)

(25) Я тоже из практики. можно купить один очень мощьный, но если он навернется, то вся контора курит бамбук. Да и по цене он выйдет как 2 которые я написал. Тем более терминальные серваки они практически пустые, проц да память.
Лучше для надежности 2 сервака средних чем 1 мощьный. Всеравно 1с7ка 1 сессия сожрет не более 1 ядра

(58) В том, что по 1С 7.7 его нет в природе.

>зачем ставить 32-битный скуль на 64-битную винду?
Может быть куча причин. Как отсутствие лицензии (а наличие лицензии на x86 не означает автоматической лицензии на x64), там и работу специфического софта.
У меня к примеру были куча XP процедур, написанные на Delphi.
Пока под CLR не переписал на C# - так на x64 не мог базы перевести...

(59) я так и понял :)
(57) хм... я чето не понял: имеем (например) w2k8 x64 + sql2005 x64 - и пытаемся включать AWE?
(62) ну мы про 1С по идее
(61) ты прекрасно знаешь, что 7.7 работает с sql2005 :)
вот существование sql2000 x64 - для меня неясно, а 2005 - вполне выручает :)

(63) Про SQL2005  под 7.7 написано уже много, и я на всякий еще написал в этой ветке.

SQL2000 x32 + AWE  быстрее, значительно быстрее и безглючней SQL 2005 x64 (под 1С 7.7)

(64) так я не пойму: почему не зать 2005-й?
кстати сам спросил, сам ответил: http://msdn.microsoft.com/en-us/library/bb469739.aspx
sql2000 x64 существует. AWE для x64 и sql применительно к эске - не нужен. теорема доказана, спасибо за внимание :)

(65) у меня нет таких результатов. т.е. утверждать я бы не стал. опыт использования выявил как минимум - одинаковые результаты, на глюки - не наступал (везет, наверное)

Существует SQL2000 x64 в теории. Если его можно найти и на практике - то нужно дать по балде местному Админу :)

(65) Этот вывод будет верен, если добавим условие что Винда 32бит+PAE? (очень интересует этот вопрос)

(68) сегодня - наверное нет, впрочем если вы умудрились сейчас купить двушку обычную - ну туда же и за x64 сходите :)

(69) Тормозит PAE само по себе.
(70) Насколько я понял - это не x64 SQL 2000, а Fix под 64-битную винду.

(71) ну по-моему - что надо:
"Microsoft® SQL Server™ 2000 (64-bit) provides full native support for the 64-bit version of the Microsoft Windows® operating system. This version of SQL Server 2000 provides many of the features of the 32-bit version, as well as providing support for the extended 64-bit hardware. SQL Server 2000 (64-bit) takes advantage of the large memory capabilities of the 64-bit Windows platform, including support for up to 32 terabytes of physical memory. SQL Server 2000 (64-bit) provides new levels of scalability while providing complete compatibility with the 32-bit version of SQL Server 2000."

хотя я б юзал 2005-й и не заморачивался :)

+72 насчет PAE - имхо прав

+72 вот еще в тему: http://www.microsoft.com/sql/editions/64bit/SQL64bitAdvantages.mspx

(71) Коль пошла такая пьянка спрошу прямо: есть смысл менять операционку на серваке если есть 8Гб памяти, скуль 2000, размер mdf 12Гб - сейчас все работает в режиме РАЕ+АWЕ. Получу ли я существенный прирост скорости при использовании 64битной оси +скуль 2000+АWE на том же железе?

наверно можно и на один сервер загнать (терминал + SQL), только надо не пускать юзеров на жесткие диски со скульными базами. Ну и по процам как-то разделить.
Т.к. у меня 8 процов в скуле тупо простаивают.
Вся фишка удасться так разделить или проще отдельные серваки поставить, ну и 2 сервака как-то надежнее если что слетит, то можно на другой перенести задачи

(76) два сервака - конечно надежнее и в плане масштабируемости лучше и в плане отказоустойчивости. добавилось юзеров - докинул памяти в терминальный, выросла база - пошаманил с дисковой и памятью на скульном, сильно много юзеров стало - добавил второй терминальник. и по деньгам дешевле это.

(76) второй может тупо стоять в резерве, на него просто гнать Бэкапы.
По процам Винда разделит :) в скуле поставить использование всех процов.
(75) прирост получишь, а вот какой непонятно. Плюс глюков будет меньше (глюки связаны с нехваткой памяти <4 Гигов)

(78) сенкс за инфу. короче без опытов не обойтись...

http://msdn.microsoft.com/en-us/library/aa274602(SQL.80).aspx

Hardware Minimum requirements
Computer Intel® Itanium™ and Itanium II processors with 64-bit CPU


Точно есть x64 SQL2000? Или он под итаниумы?

(80) сам не могу понять...

1) Для SQL 2000 есть 64-ая версия.(без панели правда управление но есть)
2) Для использования 2.7 оперативки более эффективно включать 3ГБ а вовсе не PAE.(это уже когда больше но иногда лучше меньше памяти но плоский режим работы)
3)Использование SQL и терминала на оджном серваке не эффективно(дя больших систем дешевле купить два выделенных сервака подешевле).Оптимальные настройки прямо противоположные. Читаем документацию от майкрософта. Кроме того если память и цпу ты разделишь - то как быть с дисковой системой? 7-ка в ряде отчетов может дофига на клиенте нагружать дисковую подсистему
4) SQL 2005 не глючнее 2000 просто ряд доисторических конструкций вызовов динамических курсоров под 2005 начинают работать с неоптимальными планами выполнения запросов.  

Но! Если вопрос производительности для вас не актуален(инф. потоки маленькие и криворких запросов мало) то тогда ставте на один сервак и не партесь - проще сопровождать будет.