В общем возникла необходимость перейти с файловой на SQL читаю различные статьи по теме. И вот что вычитал: При неправильном распределении памяти сервер 1С хавает все что может не оставляя SQL ну там буквально чуть остается и соответственно поскольку практически все операции с базой производит SQL, которому не дали нормально оперативы, приходим к тормозам... Я так понимаю сервер 1с это своего рода буфер между пользователем(для которого кстати клиентской части x64 вообще не существует в природе) и сервером SQL.
Вот я и не пойму какой вообще смысл ставить серверную часть 1с x64, есть ли в этом необходимость вообщето... если кто в курсе разъясните пожалуйста или на почитать конкретной ссылкой помащите...

не ставь, сыкономишь кучу денег на лицензии.

сервер 1с это не просто буфер. при управляемом режиме он выполнят огромное количество функций и требует ресурсов не намного меньше скуля. а 64 - как минимум чтобы памяти больше ел

"сервер 1С хавает все что может не оставляя SQL" если ставить на один сервак - то все возможно.
но грамотный подход - разделить на две железки

(0) Программист - это буфер между монитором и креслом.

(4) Ага а самый страшный вирус находится на расстоянии 20-30 см от монитора...
Я не углублялся в детали так-то но при таком подходе и ваше изречение про программиста имеет смысл :)
(2)Переход на SQL из-за объема документов ну и соответственно ограничения по размеру файла базы в файловом варианте... сейчас уже 8 гигов а и года не прошло...
никаких управляемых приложений нет необходимости использовать тока набивка документов вывод различнейших отчетов...
(3)Хммм... я как-то не думал об этом только начал изучать литературу по теме

(0)[При неправильном распределении памяти сервер 1С хавает все что может не оставляя SQL]
бред

(6)"После переустановки сервера "1С: Предприятие 8" пользователи жалуются на резкое падение производительности. Специалист по внедрению ПП "1С: Предприятие", производивший переустановку – лишь удивляется – мол, хотел как лучше, система должна была начать работать быстрее... Анализ ситуации показал, что серверу "1С: предприятие 8" была выделено слишком много ресурсов: его процессы (см. пункт 3) rphost заняли 15.5 Гб из 16Гб оперативной памяти сервера, в результате для уступчивого MS SQL Server практически не осталось доступной оперативной памяти.
" (с)

(6) Я не сам придумал я же написал что читаю статьи ...

(3) +100500. Остальное ересь.

(8) статья херовая

(9) Уважаемый так есть смысл ставить именно 1с Сервер x64 + платформу x32 или и сервер и клиент стаить 32

Gray776, имхо: если естьвыдержка, то ссылка на первоисточник желательна.

(7) Что у вас за база, что rphostы съели 15 гиг? Судя по малому размеру ОЗУ на серваке, база некрупная.

(13)Та это не у нас это из статьи а у нас база УПП ну там кароче отраслевая механизм УПП задействован не очень сильно... Дописано там прилично...
Никто и не ожидал что база начнет расти как на дрожжах вот скоро год а она уже порядка миллиона документов содержит ну чуть меньше ну 700 000 и даже при незадействованном механизме версионирования  скоро превысит допустимый объем. Про тормоза я уже и не говорю... тормозит но терпимо...

(12)http://www.portal-ug.ru/blog/corp/34.php
Пожалуйста
мне не жалко...

И периодически не мешает перезапускать сервер приложений (например, раз в неделю), тогда он не будет съедать по 15 Гб.

Просто я пришел к выводу что для 6 пользователей (ну реально там постоянно столько и работает ключ на 10 но столько просто нет терминалов) вполне SQL x64 +сервер-клиент 1C x32 сойдет... или я не прав? Работа в основном сведена к практически непрерывному круглосуточному набиванию документов ну там заказаов накладных...

(17) Если есть возможность покупайте сразу 64-х. Нету покупайте 32 и мониторте ошибки

(0) обмены большие на х32 сервере 1С могут просто не проходить, например

(17) На х32 бывают. С х64 меньше головной боли. Особенно, кстати, при работе с УПП.

+(20) " На х32 проблемы бывают."

(17) Была история - что на x32 не могли немного доработанную конфу обновить, при сравнении с конфигурацией поставщика вылетал конфигуратор.

(18)Та был бы смысл а возможности руководство пускай изыскивает...
Ну если 32 больше глючит... Проверить бы... блин у 1с ки нет случайно никаких вариантов типа потестить программу :)

(23) Обратитесь к ближайшему крупному франчу. Может удастся договорится взять ключ на тестирование.

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

Но лучше все таки взять сразу х-64.

(23) Эмулятор?

(24) Еще один недостаток - руководство не поймет. Как же так только что кучу денег за 1С отвалили и опять платит?

(24)аха-ха-ха Это да... я не знаю как оно отнесется вообще когда обраю необходимостью переходить с файловой версии на SQL... Тут пока внедряли на доработки неплохо вбхухали и года еще не прошло... разозлится руководство и пересадит бухов за счеты нафик :)))

(27) Мне интересно - как 6 человек наколотили миллион документов, и каким образом уже держится на файловой базе?

(28) сам в шоке но факт
а так бьют круглосуточно кучу заказаов потом на основании кучи заказов накладные и приходники ну и чуть чуть документов по производству и складу сырья

(27) >> как оно отнесется вообще когда обраю необходимостью переходить с файловой версии на SQL...

Это не твоя проблема.

Опомнись!
Для предприятия лицензия на сервер 1С - это копейки.
Директор в ресторане за день может легко оставить денег на три сервера.

(29) С такими оборотами и не позволить себе купить сервер 1С х64?
Для начала можно на SQL не разоряться, а на DB2 временно пожить.

(30) та я и не парюсь нашей организации купить по силам ... просто как отнесется рукодство :)

(31)Ну я как бы думаю SQLexpress поюзать он жеж бесплатный

(33) Уверен, что впишитесь в ограничение на размер для SQLexpress?

(30) "Директор в ресторане за день может легко оставить денег на три сервера."
Ну так после ресторана останутся воспоминания. А от лицензий ему что будет? Ни тепло, ни холодно.

(34)Ну я сразу обрисую ситуацию если что... Если будут проблемы скажу не хватает бесплатного покупайте платный... Думаю руководство устроит растянуть затраты на некоторое время чтоб не сразу все оплачивать... а если уложимся и то лучше ...

(35) Как только всё станет колом, тогда будут воспоминания намного дольше, чем от ресторана

Ну буду ладно начну счас тестить с эмуляторами... Мне же надо конкретно говорить в каком программном обеспечении есть необходимость :)

(36) 4 гига вам хватит? При условии что у вас файловая уже больше

(32) А у них есть выбор?
Альтернатива - усугубление проблем производительности и риск разрушения базы.

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

А сколько будет стоить восстановление данных, если вдруг еще и последний файловый архив не поднимется?

(39)Упс неувязочка однако... блин еще и SQL

(40)Та архивы делаем 2 раза в сутки утром и вечером...

(39) Выгрузил dt весит всего немногим больше 300 метров... странно

(43) Он сжимается хорошо.
Кстати, dt в качестве архива использовать нельзя.

(44)та мы и не используем мы zip  используем :)

(43) А что dt должно быть больше базы? По факту в среднем размер dt файла меньше скульного файла в 10-15 раз

Т.е. если загрузить в скуль как раз и будет 3,5 - 4 гига

Плюс ограничения памяти в 1 гиг

(44) dt в качестве архива использовать нельзя.

Холиварное заявление

(29) Действительно интересный случай. Расчет себестоимости не запускаете? Табеля там, зарплату не считаете?

Может версионность включена? и картинки храните в базе?

(48)Нет только расчеты с покупателями поставщиками и производство там деже БУ только для кассовых документов ведется остальное только УУ

(14) > Никто и не ожидал что база начнет расти как на дрожжах вот скоро год а она уже порядка миллиона документов содержит ну чуть меньше ну 700 000

700 000 / 6 / 22*12 = 442

То есть каждый из 6 пользователей на протяжении года вдалбливал по 442 документа в день?

(49)смотрел в регистре (блин не помню точно как он называется) Там вообще ничено не написано ну типа ничего не разрешено ничего не прещено версионировать я так думаю нет у нас версионирования значит

(47) Хорошо - можно использовать, если после выгрузки проверять возможность его обратной загрузки. Ну или жить с 0.1% вероятности не восстановления данных из dt. Правда, когда этот % придет, задумаешься.

(51) Да даже больше могут вколачивать они попервой как устроятся медленно бьют, а потом уже не глядя вот скока документов ты за 8 часов забьешь7 и потом там автоматом на основании заказов ыформируются накладные на основании накладной проведенной приходник

(51) Не нуди :) Ну преувеличил чуток автор. Откуда в его dt на 300 метров милиону документов взяться :)

(55)Ну может и приувеличил кста могу глянуть сколько документов в сутки набивают в среднем

(53) За 6,5 лет использования ниразу проблем небыло. Причем из dt активно восстанавливаем по разным причинам

(51)(54)Но больше они вбивают редко когда аврал типа слетевшей базы и необходимости сутки прошлые набить и сегодняшнее тоже набить

(57) Проскакивают такие темы. Не зря 1С в руководстве пишет, что архивы файловой версии надо делать копированием .1CD

(58) ...это жестоко

(59) Поэтому и говорю, что это холиварное заявление

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