1С 80/81 - это трехзвенная система. Первое звено - MS SQL сервер (через AWE доступно до 64 Gb физической памяти), второе сервер 1С (использует 2-3 GB физической памяти), третье - клиент.

Я так понимаю, что Navision - это двухзвенка.
А вот насчет Axapta не знаю.
Но если вдруг Axapta трехзвенка, то может ли она использовать AWE, т.е. более 2-3 гб памяти?

Ну и в общем вопрос, если вы знаете трехзвенки, то в каких из них реализована поддержка AWE?
Хотя понятно, что то же 1С на 64 битной ОС может использовать любое количество оперативки, поэтому вопрос касается 32 разрядных приложений.

Какая связь между трехзвенкой и AWE?
AWE - это метод использования памяти

(1) Почитай вопрос внимательно.... ВНИМАТЕЛЬНО!

акцапта не вдруг трехзвенка... есть у них AOS  - тот же 1С.сервер..

(3) Вообще именно Майкрософт трёхзвенную архитектуру и предложил как "современную". Одноэсу ничего не оставалось как подчиниться. Ибо ОС от Майкрософта..

(3) АОС жрет больше 3 гб или не переваривает?

Папа Гапа, а чего вам не нравится в трехзвенной архитектуре? Отличная по задумке вещь. Если люди придумали СУБД для централизованного хранения данных, то почему бы не придумать механизм для централизованной обработки этих данных? Идея хорошая, и MS тут ни при чем. Это теория, не зависящая от конкретной компании.

(4) При чем тут Майкрософт. К этому многие умные люди приходить стали. Вот к примеру Фаулера почитать ...

Вопрос в том, что MS реализовала поддержку больших объемов ОЗУ как в 32-битных версиях СУБД MS SQL (через дополнительный механизм ОС AWE 32-битный MS SQL может взять до 64 ГБ ОЗУ), так и в 64-битных (прямая поддержка ОС), а 1С в своей реализации сервера приложений в 32-битах ничего делать не стала и уперлась в 2/3 ГБ ограничение 32-битной архитектуры (а в 64-битной версии сервера выезжает за счет прямой поддержки ОС указанных объемов).

Вопрос вот в чем - знает ли кто-нибудь из уважаемой аудитории Мисты примеры написанных/реализованных серверов ПРИЛОЖЕНИЙ под 32-битные Windows, использующих механизм AWE для работы с оперативной памятью более 4 ГБ для задач обработки данных, поступающих в сервер приложений от СУБД.

(8) Так а зачем напрягаться реализуя поддержку AWE, если 64-битная ОС скоро станет нормой, по крайней мере на серверах?

(10) Скоро - это когда? Кстати, а переход с серверной 32-разрядной винды на 64-разрядную бесплатен?

Скоро только сказка сказывается. Много вы знаете 64-битных серверов? А я вот не знаю пока ни одного, хотя через мои руки прошло их около 25.

из-за 1С никто не будет просто так переводить существующие 32-битные сервера на 64-битную платформу. Недостаточна мотивация.

по крайней мере это справедливо для 1С и крупных корпораций. Для Оракла будут, потому что знают давно. А 1С... все знают о ней как о бухгалтерской системе малого и среднего бизнеса. А теперь подумайте, что вам (как представителю 1С Франчайзи, предлагающего автоматизировать что-нибудь в крупной компании) скажут, если вы предложите им перевести существующую инфраструктуру с 32-бит на 64. Боюсь, что вас просто пошлют и люди продолжат выбор поставщика решения по автоматизации. Это касается тех контор, где ИТ-инфраструктура 32-битная. А контор, у которых все с нуля уже разворачивается на 64 битах, по пальцам пересчитать можно.

1С новичок на этом рынке, и это она должна подстраиваться под него, а не диктовать свои условия.

Хочешь завоевать рынок - пиши так, чтобы максимум клиентов без лишних хлопот могли использовать твой софт. И от удовольствия платить денежки.

а пока получается порнография - SQL видит до 64 ГБ и способен работать с БД практически неограниченного размера, а сервер приложения 1С способен получить результаты запроса размером не более 1 ГБ. Для домашней бухгалтерии покатит, а для корпоративной системы - нет.

(13) Зачем переводить ВСЕ сервера. Достаточно сервер приложений 1С.

(17) Не всякий SQL, батенька... надо еще и по этому поводу напрячь :)

Вроде как можно построить кластер серверов приложений, да и как-то слабо представляется задача для 1С , не решаемая даже внутри 1Гб

а почему мы должны для построения кластера:

а) потратить 10 тыс. $ для покупки каждого серверного компьютера
б) купить за 5-6 тыс. $ к нему техподдержку (гарантию) производителя на некий срок, чтобы обеспечить себя запчастями на период жизни компьютера
в) купить заданное количество Windows Server с заданным количеством лицензий (еще 5-6 тыс. $)
г) купить заданное количество серверов 1С:Предприятие 8 (ключики-то локальные, персонализированные для каждого сервера)

Итого получается от 20 тыс. $ за дополнительный полностью оснащенный требуемым софтом узел кластера. Спрашивается, какого черта, если (при использовании AWE) мы могли бы просто купить дополнительных мозгов где-нибудь за 1-2 тыс. $ и довести объем ОЗУ сервера до 16-32 ГБ.

При всем при этом есть мнение авторитетных специалистов, что даже кластер 1С не снимает проблему нехватки памяти для данной ИБ.

нафига НАМ нести такие дополнительные расходы, чтобы позволить 1С завоевать рынок корпоративных информационных систем?

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

+ (21) Скоммуниздить виндофз дата-центер + СКЛ-ентерпрайз :)

и потом - кому хуже? нам, потому что мы заморачиваемся с попытками выжать из сервера еще пару килобайт. Разработчикам, которым 1С прямо советует, что им следует в конфигурации переписать все запросы так, чтобы они не возвращали огромных результатов. А вам охота этим заниматься?

кластер для сервера приложения можно развернуть на линуксе... но это конечно на любителя...

(23) Это типа в каждый ларек по трехзвенке с Ораклом?

1С - решение для своей ниши. Быть основой для корпоративной среды - "слабы в коленках-с".

КонецЦикла - мы не та контора, чтобы коммуниздить. А потом, данная рекомендация касается SQL сервера. А с ним и так проблем нет. А вы сможете на компьютере, в котором установлена 32-бит Windows Server 2003 Datacenter Edition и SQL Enterprise, а также набито 64 ГБ ОЗУ, дать Серверу 1С Предприятие 8 хотя бы 3,000001 ГБ? ;) Боюсь, что в таком случае ваши 60 гиг озу будут халяву давить, а начальство с вас будет спрашивать - а чего это сервер 1С Предприятия не берет больше 3 гигов, а на практике и вообще эта цифра ограничена 1,5 гигами. Что с вами будет в такой ситуации?

>Быть основой для корпоративной среды - "слабы в коленках-с".
Это не наша позиция - это позиция 1С, на которую мы повелись и теперь расхлебываем.

типа сервер - масштабируемое решение и все такое... А на самом деле вся масштабируемость заканчивается на 1,5 Гб ОЗУ, выделенных серверу и после преодоления которых начинается пресловутая ошибка SDBL.

а база падает.

так все же, знает кто-нибудь другие сервера приложений под Win32 платформу, успешно работающие с большими объемами ОЗУ?

(29) >>Это не наша позиция - это позиция 1С, на которую мы повелись и теперь расхлебываем.

Странные вы какие-то... Обычно "внедрятелей от 1С" гоняют ссаными тряпками из офисов. Причем вполне аргументированно. И никто не ведется.

(20) Не забывай, что если каждый юзверь из ста запустит отчет на 10 мбайт одновременно, вот тебе и гиг... ;-) Сервер то один.

да достаточно одного, который сформирует запрос вида SELECT * FROM САМАЯ_БОЛЬШАЯ_SQL_ТАБЛИЦА_В_БАЗЕ_ДАННЫХ_ОБЪЕМОМ_100_ГИГАБАЙТ.

и пипец. Сервер 1С захочет усосать весь результат запроса в своей несчастной памяти 1,5 гига и задохнется, сказав на последок ошибка SDBL.

(33) у нас две системы основных на Оракле и на УПП, так вот последние 5 заводов взяли именно УПП, хоть и отговаривали из-за непроверенных значений масштабируемости.

Вот и получается, что Сервер 1С вместо места, где за клиента (не имеющего больших ресурсов) централизованно обрабатываются большие объемы данных (тяжелые отчеты и т.п.) превратился в самое узкое звено системы.

Dziden2 - а они еще с ошибкой SDBL не сталкивались? Если нет, то данных мало еще набрали.

запросы в БД пока еще мало данных возвращают, не превышающих пороговых для восьмерки значений.

а когда накопят, начнутся еженочные перезагрузки сервера 1С, а когда надо будет перезагружать его два раза в сутки, тогда и начнут искать тех, кто это затеял.

(39) а в каких отраслях внедряли и примерно узкие места можешь описать?

да вот щас нам в энергетике внедряют. и начала всплывать эта проблема.

(41) не нафиг нафиг, это их решение и им предлагали выбор, та и вроде в договорах все написано ...

(30) Вообще-то масштабируемость бывает вертикальная и горизонтальная ...

(28) А каким местом думали, когда покупали под 1С 32-битный сервер с 64 ГБ ОЗУ?

(43) а на какой таблице?

А вы не пробовали 2,3,4 процесса сервера запускать? они ж в кластер объединяются...

(45) а зачем думать - сначала сделали, а потом ищут виноватых...

>А каким местом думали, когда покупали под 1С 32-битный сервер с 64 ГБ ОЗУ?
Да сервер-то пока имеет стартовые 4 Гб с расчетом на то, что с ростом нагрузки память можно будет нарастить (мать тянет 64 Гб максимум). Но с учетом того, что сервер 1с оказался типичным Win32 приложением и AWE не использует, обесценивает эту идею напрочь. Да и вообще наверное все идеи по развертыванию кластеров серверов 1С.

(28) У нас на сервере токо 4 гига и запросы я стараюсь писать нормальные (7.7 + ВК)

(35) и пускай юзера читают распечатки? :)

Лузеры какие-то... пригласите специалистофф... :)

(52) +1000

(37) и чо? Думаешь кто решения принимает - что-то в этом смыслит?

во-первых мы пока еще сидим на 8.0
во-вторых почитали инет и кто уже перешел на 8.1 говорят о том, что ошибка SDBL в этой версии не устранена. Устранить ее кардинально можно, переписав полностью сервер 1С под AWE, что я так понимаю 1С вообще не хочет делать
в-третьих - вопрос по поводу распараллеливания рабочих процессов сервера (каждый в своем адресном пространстве по 2/3 Гб) надо спрашивать у разработчиков.
в-четвертых. В рамках одного рабочего процесса можно всегда дать такой запрос, результат которого превысит существующий предел, что мы видимо уже имеем на практике. И не всегда возможно распараллеливание запросов, например такого как Select * from table - тут бери да доставай данные из базы.
в-пятых, о чем думала 1С, когда собиралась сопрягать свою программу (а сервер 1с для SQL - типичный клиент) с таким действительно масштабируемым решением как SQL. Что база никогда не достигнет критического порога?

(48) +1 Если брали сервер "на вырост", надо было сразу смотреть на 64 бита. Кстати, поправьте меня, если я ошибаюсь, 32-битные процы вроде уже не производят?

(49) AWE это костыли, в которых пропал смысл с распространением 64-битной архитектуры. Какой смысл в поддержке этих костылей относительно новой платформой?

(55) >>о чем думала 1С, когда собиралась сопрягать свою программу (а сервер 1с для SQL - типичный клиент) с таким действительно масштабируемым решением как SQL. Что база никогда не достигнет критического порога?

вы еще не знаете как 7.7 с SQL работает без внешних приблуд... взяли люди базу dbf, присобачили сбоку кривой в сиську парсер - зато переделывать ничего не надо...

(55) странные люди, почему то за буржуйский софт готовы муллионы платить, а тут строят систему я так понимаю уровня корпоративной ИС и жмутся на 64-битный сервер и незначительными расходами на уровне корпорации на апгрейд софта. Вы еще не вспомнили про ограничение 256 таблиц, которое идет от MS SQL...

(36) из серии у меня друг сервак завалил ???
(39) или мало специалистов умеющих селект * делать ;)
Без проблем прибью сервер приложений работающий на 64 Гб грамотным запросом, ведь кроме селект * есть еще джоины ;)

сдается мне господа что вы сами с ошибкой SDBL еще не сталкивались или у вас базы маленького размера. По поводу 7.7 - так там метод работы с данными совсем другой - через курсор можно прокрутить выборку любого размера. Зато медленно, поэтому вы и перешли на ВК. Я посмотрел бы на вашу систему, если SQL на вашего клиента, где у вас ВК для прямого доступа стоит, что будет с его памятью, если SQL вернет ему огромный результат запроса. На примере приложения на VB могу сказать, что программа получает-получает данные, пока весь своп не кончится, после чего XP падает с сообщением Out of memory. 1С не исключение. Поэтому 1С и придумала сервер 1С.

про джойны вообще молчу. вот там кстати распараллеливание запросов по отдельным процессорам отлично работает.

(49) "Но с учетом того, что сервер 1с оказался типичным Win32 приложением и AWE не использует, обесценивает эту идею напрочь."

Сервер 1С бывает типичным Win32 приложением, и типичным Win64 приложением. А прежде чем выдвигать идеи, нужно знакомиться с документацией и системными требованиями.

ну чего, приговор один что-ли? всем дружно переходить на 64-бита? Все из здесь присутствующих уже это сделали?

кстати, а под линуксом в принципе нет AWE, а сервер 1с есть... что в этом случае сервер 1с может сожрать?

(60) как раз сталкивались и успешно решали ее и как бонус получаешь уменьшение расходов памяти на клиенте, уменьшение времени получения результата. А доводить хрюшу до переполения свопа - много ума не надо, хоть 10 серверов имей в очереди :). Мода сейчас такая что ли плевать на расходуемые ресурсы?

вот вы мне и скажите, как сервер 1С под линуксом работает? много присутствующих здесь знают работающих реализаций и могут поделиться опытом реализации КИС на 1С под никсами?

(63) Думаю что те, кому нужно много ОЗУ -- сделали.

(64) Линукс тоже бывает 64-битный.

тогда пора под восьмерку разрабатывать ВК для прямого доступа к SQL ^)

(67) я это и имею ввиду... для доступа к большой памяти в линухе не нужен аве никакой

однако по сабжу так никто ничего и не сказал. Пожалуй, ответом в какой-то степени такую формулировку:
1) Win32 серверов приложений никто не знает
2) Обществу известны два сервера приложений - сервер приложений 1C Win64 и сервер приложений 1С Linux64.

(66) тестовая база работает... все вроде ок, только вот нагрузки на нее нет почти, так что ничО сказать не могу

>На примере приложения на VB
открой для себя  серверные курсоры.
>Сервер 1С вместо места, где за клиента
ппц. это надо на sql обрабатывать. а не на третем звене.

Скажите, а как в 8.1. запустить несколько процессов.
Можно ли для каждого юзверя запустить отдельный процесс?

Linux-версия сервера 1С не работает с MS SQL. Следовательно возникает необходимость перевода еще одного компьютера на платформу Linux, чтобы развести их по разным компам. Уже два линукса потребуются.

(73) для каждого юзера - это уже маразм... а вот по количеству ядер - самое то

(74) работает ;)

Открыл уже давно. Быстро работают? И много народа их используют? именно в паре с 1С?

Цитата с оффсайта http://v8.1c.ru/overview/CommonCommVariant.htm#Server

Особенности рабочих серверов под управлением Linux
не могут взаимодействовать с СУБД Microsoft SQL Server;
не поддерживается работа с СОМ-объектами;
аутентификация на сервере выполняется по протоколу Kerberos;
не доступна работа с Интернет-соединением.

ладно, я понял... все это по большому счету танцы с бубнами, которые 1С перекладывает со своих плеч на внедренцев (оптимизация запросов в конфигурации) и на админов (Linux, Win64 и пр...)

(78) - фиг знает, там же по tcpip все, какая разница? я не пробовал, но при создании ИБ из консоли серверов - есть возможность выбора мсскуля...

кстати linux может распараллеливать рабочие процессы только по количеству ядер. это принцип реализации многопроцессорности в этой архитектуре.

Почитал вот про сапр3: "SAP BW architecture also does not support AWE"
У чуваков тоже полно проблем с селектами * ;)
Это цитата из брошшурки "The Advantages of Running SAP Applications on SQL Server 2000 (64-Bit)"

(78) а под линукс бесплатно реализовали работу с com-объектами (не касаясь 1с)?

BW это ихнее хранилище данных, обертка вокруг движка базы данных

(81) а чем это от виндыыыы отличается???

насчет линукса ничего не знаю. это честно говоря вообще такое отклонение от заданного маршрута. Вот щас админа спросил про возможную перспективу внедрения линукса в компании - еле увернулся от удара в нос :)

(86) все с вами понятно :)

>а чем это от виндыыыы отличается??? а винде пофигу сколько у нее процессов и сколько процессоров. она может однопоточное приложение запустить на одном процессоре, а может размазать по 16. Там процессоры - такой же ресурс, которым распоряжается ОС. Другой принцип. Но давайте здесь не будем подымать извечный спор. Пока на линуксе работает один человек, и то в режиме тестирования.

Можно констатировать, что для решения проблемы ошибки SDBL сообщество предлагает мигрировать на линукс?

(86) а чем вам в данной ситуации поможет linux?

64-битный

снимет проблемы с памятью

>распараллеливать рабочие процессы только по количеству ядер
рыдал. как же оно на 128 процессорных спарках идет?

(89) Предлагает мигрировать на 64-битную ОС. Винда тоже такая бывает.

(88) прекрати неСти бред.

(88) она ПОТОКИ приложения по ядрам размазывает... линух тоже... а вот у 1с ,что 7.7, что 8.х - поток один, так что больше 1 ядра ни в винде, ни в линухе оно не заюзает, как не проси (я про клиент)....

(88) "а винде пофигу сколько у нее процессов и сколько процессоров. она может однопоточное приложение запустить на одном процессоре, а может размазать по 16"

Я тихо плакаю под столом.

(88) прекрати неСти бред.
В TaskManager для примера на многопроцессорной машине запустите WinRAR старой версии (однопоточный). И гляньте, как однопоточный процесс размазывается по ядрам.

ладно, что мы спорим?

ситуация мне понятна.

(98) а то, что нагрузка больше, чем 100%/(количество ядер)+1-2% системы никогда не вырастет, не замечал? (если ничего другого не запускать)

спорить не буду ни с кем больше. тем более не за этим ветка открыта.

Тогда может другую ветку открыть на такую тему:
Кто-нибудь из людей, столкнувшихся с ошибкой SDBL и не ставших переписывать конфигурацию, а мигрировавших на платформу Win64 + Сервер 1С 64, выполнил успешно эту процедуру и могут ли они поделиться опытом такого перехода. Интересует процесс перехода и встретившиеся на этом пути трудности.

(103) Ну дык открой ...

2GrayMagellan как то давным давно залазил в свойства сервера 1С 8.0 как компненты СОМ, там была галка "3GB"...

Возможно я как всегда и не в тему, но ключик /3gb применим только к ос. В boot.ini))  А без него и 7.7 и 8.0 отваливаются при 2 гб на процесс. Именно грубо ОТВаливаются, а не скажем просто культурно перестают жрать память по типу уважающих себя приложений. Вероятно AWE решило бы проблему для скл сервера и для сервера предприятия в 32 бит среде.
Но вот клиент, клиент едино память кушал и будет кушать. А 64-бита не тестировал. Скажите слепому, они вообще (64 бит 1с) существуют в природе???
Ибо на 1с.ru нет 64 битного щеконадутия.

У нас установлен сервер под двумя квадовыми ксеонами 5335 под Windows 2003 EE 32 bit с 8 Gb памяти. Задействовано PAE.
Все видится и работает без проблем.

(107) О как! Стало быть, вся мировая ит-общественность думает не в ту сторону... А мужики то еще не знают... Все, ушел открывать всем глаза ))

(106) а как еще клиент красиво транслирует запросы в сиквел. песня. по ляму селектовых сбросов на каждый чих (8.0)

(55) Еще в 8.1.8 заявлено: "Оптимизирована работа с оперативной памятью за счет размещения выборок больших размеров во временных файлах на диске.
При работе с большими выборками следует иметь достаточно свободного места на тех дисках, на которых размещаются временные файлы сервера и клиента."

http://users.v8.1c.ru/Info/Platform/8_1_8_76/V8Update.htm

(59) да и джойнов не надо

Select * From Таблица1, Таблица2, Таблица3

без всяких условий :)))

Блин, одни теоретики е-мае.... У нас УПП, сильно перелопаченая (особенности производств), куча неоптимизированных запросов (внедряльщики так себе). Одновременно в базе 107 пользователей. Пока на платформе 8.0 сидели, SDBL просто задалбала, по 3-4 перезагрузки сервера в день. Перешли на 8.1, и забыли как выглядит ошибка SDBL. При этом сервак тот-же, 32 битный.... Это реальная практика!!! В теории и слона завалить можно голыми руками, юзайте практику господа....

to d_Fedor. О! Действительно, наконец-то нашелся один человек, который сталкивался с этой проблемой и решил ее. Вопрос такой к вам, d_Fedor:
сколько памяти у вас установлено в системе и сколько памяти забрал себе сервер 1С - максимальное значение из ваших практических наблюдений (если вы осуществляли мониторинг ресурсов, потребляемых сервером).

Вот что я еще нарыл по этой теме.
Суть не в том, что программисты пишут кривые запросы, а суть в том, что сервер 1С постоянно потребляет память, в то время как он ограничен двумя гигами. Как только доходит до предела в 2 гига, так сразу и начинает выдавать ошибку SDBL при попытке выполнить любую операцию, требующую еще памяти. Описание и дополнительные материалы вот по этой ссылке:

http://dmaltk.narod.ru/SDBL_Error_in_1C_Enterprise_8.htm

(114)
>> Суть в том, что администраторы в компании разворачивают несколько серверов 1С, объединенных в кластер

Не совсем верно, кластер может работать и на одном компьютере и на одном ключе, следовательно, никаких затрат от компании не нужно, т.е. эконом-выход для 32-битных версий - в разворачивании кластера на одном сервере.

Америку открыл=)

(114)  
>> одноминутном интервале наступают моменты, когда сервер 1С простаивает в течение одной минуты. Этого достаточно, чтобы DCOM гасила процесс, освобождая ресурсы сервера 1С

Гм, интересно, то бишь он сбрасывается, даже если потребляет какой-то объем памяти? ;-)

перезапуск тра ля ля это конечно хорошо..а если работа круглосуточно?
имхо надо рыть в стоону постоянной очистки памяти сторонней утилитой на 32 - битной версии.
в пошлой конторе во время массовых перепроведений не раз талкивался с такой хернёй..
переход на x64 решил этот вопрос..

(28) я смогу, скока надо столько и дам.
Есть такое понятие как процессы. Много памяти - запусти много процессов сервера 1С. Хоть каждый процесс в отдельности и будет ограничен 3 Гб, но в целом будет использоваться вся память.

(73) file://localhost/C:/Program%20Files/1Cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167953

Сейчас еще раз отмониторил Сервер 1С:Предприятие 8.0. Действительно, предложенный метод отлично работает. В течение получаса процесса сервера не существовало. Потом он запустился, поработал в течение 2-х минут, после чего DCOM опять его прикрыла. Больше в обозреваемом промежутке времени процесс Сервера 1С 8.0 не запускался. Итог - Сервер 1С работает тогда, когда он нужен клиентам, запускаясь при надобности выполнить какую-либо работу (днем, пока существовали подключения клиентов, процесс работал непрерывно), а ночью завершаясь, когда нечего делать. Я имею ввиду, когда ночные работы тоже выполнены и наступает пауза в работе сервера 1С. В общем, предложенный метод гасить процесс сервера когда он не нужен, с помошью DCOM (которая его хостит) хорошо поможет тем организациям, где в работе сервера существуют хотя бы минутные периоды бездействия, в которые DCOM может его погасить и тем самым освободить занимаемую процессом память. Для тех организаций, которые работают на сервере в режиме 24/7 и нет даже минутки простоя, данный метод не подойдет. Таким наверное придется мигрировать на 64-битный софт, чтобы не заморачиваться с постоянным ручным перезапуском Сервера 1С 8.0.
Кстати, мониторинг Сервера 1С 8.1 пока показывает, что процесс также обладает неким свойством гаситься - из 25 дней, в течение которых компьютер непрерывно работает, процесс сервера отработал всего 6 дней. В течение этого времени он забрал 1,12 Гб виртуальной памяти, из которых в непосредственно в ОЗУ размещено 0,73 Гб. И по субъективным наблюдениям, скорость потребления памяти ниже, чем у Сервера 1С 8.0, хотя на 8.0 работают 35 человек в среднем темпе на заказной конфигурации, а на сервере 8.1 крутится типовая ЗУП, в которой редко сидит больше 5 человек. Так что пока нельзя однозначно утверждать, что Сервер 8.1 медленнее набирает память, чем Сервер 8.0. Вот если бы кто-нибудь, кто выполнил реальный переход на x64 (64-битная ОС и 64-битный Сервер 8.1) дали здесь свои впечатления о трудностях и прелестях перехода на 64-битную платформу, это был бы ценный опыт для тех, кого 2 Гб на серверах 1С достали в 32-битной платформе.

Bizon2005
119 - 04.05.08 - 14:18
(28) я смогу, скока надо столько и дам.
Есть такое понятие как процессы. Много памяти - запусти много процессов сервера 1С. Хоть каждый процесс в отдельности и будет ограничен 3 Гб, но в целом будет использоваться вся память.

Вот, уважаемый Бизон, давайте рассмотрим такую ситуацию. Вы научились порождать много процессов серверов 1С, каждому из которых может быть безболезненно выделено до 2 Гб виртуальной памяти (3 Гб он никогда не достигнет), и всего на компьютере, где хостятся эти серверы 1С, запустили десять процессов. Каждый взял по 2 Гб, в компьютере у вас набито 64 Гб ОЗУ. Итого получаем все серверы 1С взяли в сумме 10*2=20 Гб ОЗУ. Прекрасная картина. А теперь подумайте вот над чем - предположим, что вы запускаете формирование какого-нибудь отчета. И в рамках выполнения этого отчета какой-нибудь один запрос генерируется на клиенте. Он передается на сервер 1С, и менеджер серверов 1С в кластере поручает серверу 1С №9 отработать этот запрос. К тому моменту, положим, процесс сервера 1С №9 потребил 1 Гб виртуальной памяти (50% от возможного значения). А база у вас 50 Гб, и результат выборки будет составлять, к примеру, из нее, 1,25 Гб. И вот вам SQL начинает выдавать результаты этого запроса объемом 1,25 Гб в ваш сервер 1С №9. Тот засасывает в свою память результаты запроса, и как только память достигнет отметки 2 Гб, ваш сервер №9 вернет клиенту ошибку SDBL. Хотя рядом с ним могут быть еще запущены процессы серверов 1С №8 (к примеру, взял 230 Мб памяти, еще доступно 1,67 Гб), и процесс сервера №10, который вообще только что стартовал и пока потребил только 5 Мб памяти. При всем при этом у вас в сумме из 64 Гб установленного ОЗУ занято только 20 Гб, и доступно еще 44 Гб ОЗУ. А ваш клиент словил ошибку SDBL. А все почему? Потому что один запрос выполняется в рамках одного процесса сервера 1С, и память всех 10 запущенных процессов серверов 1С не может быть объединена в один мощный кусок объемом 20 Гб. Не забывайте, что стандартно в архитектуре Windows каждому процессу выделяется отдельное, защищенное адресное пространство, недоступное другим процессам (если не принято специальных мер). Речь идет о том, что одиночный экземпляр сервера 1С 8.0 не может потребить больше 2 Гб виртуальной памяти. Как только он ее превышает - клиенту выдается ошибка SDBL. И неважно, что рядом у вас запущено еще десяток процессов серверов 1С.

Суть в том, что 1С не может пока реализовать в своем сервере приложения грамотное управление памятью, как это сделано в серверных продуктах Microsoft (та же Windows или SQL сервер). Это я не ругаю 1С, просто это уже системное программирование и теория управления ресурсами операционных систем, а 1С пишет прикладные программы. Так зачем писать то, что уже написано системными программистами (управление памятью, к примеру) в операционных системах? Проще закрывать процесс и возвращать потребленную память назад в ОС. А уж она ее дефрагментирует, упорядочит как надо и подготовит к повторной выдаче серверу 1С. Плохо только тем конторам, которые жестко работают в режиме 24/7 и сервер 1С ни скриптами, ни DCOM`ом вырубать нельзя.

Вот и щас тоже еще раз проверил - нет в списке процессов сервера 1С 8.0. Нет сервера - нет проблем :) Когда понадобится - тогда DCOM его и запустит.