Какой клиент сервер купить 32bit или 64 bit

[denics84]

Привет всем! Возник такой вопрос: сейчас работаем на файловой базе 1с 8.2 15 пользователей, база 3гб, в терминальном режиме, железо под сервер новое 4 ядра, 8 gb ОЗУ! проблема в том что в конце года база очень тормозит, нам было предложено купить и поставить клиент сервер под 1с и перейти на базу SQL - настаивают чтобы мы покупали сразу 64 bit платформу, я думаю что достаточно будет и 32 bit!  что посоветуете в моем случае? выкидывать на ветер лишние 40тыс руб на 64bit? если они не будут использоваться в будущем - нехочется!   

[greenLiss]

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

[denics84]

одновременных подключений происходит сразу 15. бухгалтера сидят в одной базе, у каждого в ней по учреждению. если работать одному, тормоза исчезают! просто приехал специалист из 1с - мы ему описали проблему, он ничего смотреть не стал, а сразу же заявил что единственный выход перейти на клиент сервер. вот поэтому и спрашиваю здесь - не доверяю я ему.

[greenLiss]

ну да, 15 многовато...
Смотрите, у вас 8Гб оперативы, если сервер будет на винде, то при 32битной платформе использоваться будет только 4 Гб. А вот если на линуксе... То хрен его знает, т.к. логика винды в линухе не работает.
а вообще, основная разница между 32 и 64 :
В 32х каждый рабочий процесс использует до 2 Gb ОЗУ. В 64х разрядной операционной системе ограничение накладывается физическим объемом ОЗУ. Из-за этого может возникнуть одна ошибочка, при достижении рабочим процессом использования максимального объема памяти.
Одним словом, если на далекое будущее, то можете взять 64, если очень жалко 30 тысяч (кажется такая разница должна быть), то можете взять и 32, но потом может аукнуться...

П.С. Я думаю, что если что-то покупать, то с расчётом на будущее, что бы не платить двойную цену (если планируете этим пользоваться долго).

[denics84]

тогда еще вопрос: у нас на данный момент стоит windows server 2003 32 bit, пойдет ли платформа 1с клиент сервер 64 bit на нем?

[greenLiss]

На 100% не скажу, но на 95% 64битная платформа на 32битную ось не станет.
да и смысл, если вы ось менять не будите на 64битную, покупать платформу 64 нет.

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

Но если уже хотите хорошо проапгрейдиться, с учетом, что всё будет развиваться в геометрической прогрессии(фирма растет, персонал увеличивается по 100 человек в год и т.д.), то нужно купить виндовс сервер 2012 64 (т.к. даже 2008 уже не продается), платформу 64 и сможете легко добавлять на сервер оперативы, которая будет использоваться а не просто простаивать.

П.С. Сейчас у вас на сервере используется только 4 гб оперативы, т.к. 32 разрядная ось больше не видит.

Добавлено: 18 дек 2012, 14:43

Говорю только про количество пользователей, потому, что размер базы в данном случае не имеет значения.

Добавлено: 18 дек 2012, 14:46

[denics84]

почитал тут характеристики по серверному железу и возникли вопросы! У нас сейчас сервер под 1С собран на i7 4 ядра, для серваков желательно ставить xeon с поддержкой 2 процессоров на материнской плате! Вопрос - тогда какой смысл мне ставить 64 bit платформу если 1 проц не потянет. так как хотелось бы?

И еще вопрос: если мы переходим на sql нужны ли нам usb ключи HASP, просто загнули цену ключ на 20 пользователей для 1С 65000руб это реальная цена?

[greenLiss]

Ну я же говорю, если 64, то это на будущее... вот станет через год у Вас + 100 пользователей, проапгрейдите сервак, а 1С уже 64битная стоит.
Просто если вы сейчас оставите всё как есть (ВинСерв 32, железо это же), купите 1С 32, то все будет работать(это разумно, если большого расширения Вашей фирмы не планируется)... Но если Вы начнете активно развиваться, то будете менять не только железо, но и 1С.
Тут уже Вы должны сами прикинуть... Сейчас сэкономить, а когда придет время, потратиться на полный апгрейд, или же сейчас потратиться, и ждать, когда это реально понадобится (что бы сказать:"Хорошо, что мы сразу купили 1С64 и ось64")

И еще вопрос: если мы переходим на sql нужны ли нам usb ключи HASP, просто загнули цену ключ на 20 пользователей для 1С 65000руб  это реальная цена?

Да, это стандартная цена, других не бывает. Если вас пугает эта цена, можете посмотреть на цены SAP

П.С. usb ключи уже не выпускаются, скоро их вообще найти невозможно будет. Сейчас используются программные ключи защиты(активация через интернет). Но если вы сейчас купите usb, то потом сможете заменить на программный. (программный в эксплуатации конечно лучше практически со всех сторон, но я всё еще скучаю по usb

[Multica]

Нашел в теме про usb ключи и хочу задать вопрос. У нас в компании мы стали использовать базу данных на linux но usb ключи старые остались и вот возникает такая ошибка что usb ключ либо виснет либо пропадает и приходится перезапускать службу ( демон ) на линуксе чтобы ключ на 5 чел опять стал виден и начал работать. Вопрос - можно поменять физический usb ключ на программный? Не могу найти ответа подскажите и как это сделать?

[DmitriyF]

Привет всем! Возник такой вопрос: сейчас работаем на файловой базе 1с 8.2 15 пользователей, база 3гб, в терминальном режиме, железо под сервер новое 4 ядра, 8 gb ОЗУ! проблема в том что в конце года база очень тормозит, нам было предложено купить и поставить клиент сервер под 1с и перейти на базу SQL - настаивают чтобы мы покупали сразу 64 bit платформу, я думаю что достаточно будет и 32 bit!  что посоветуете в моем случае? выкидывать на ветер лишние 40тыс руб на 64bit? если они не будут использоваться в будущем - нехочется!

Я бы вообще посоветовал разнести на разные машины СУБД и Сервер 1C. Хватит и 32 битного ключа, т.к. всегда можно докупить или найти сашинку с 2-4 гигами оперативы и туда воткнуть сервер 1С а не лепить его вместе с с СУБД и соответственно разнести нагрузку по кластера. Эффект будет больше чем ставить все в одно место.