ЛВС Помогите определится

1С 7.7 Торговля+Склад, конфа рукописная, прикручено Адресное хранение по ячейкам (в стадии доработки). DBF базы.
Сервак HP Proliant DL320G5 (1 * Xeon 3040, 1.87 Ghz, 2.0 RAM, HDD SATA 160 gb (система+сфоп) и HDD SATA 320 gb (база занимает 2.5 Gb).
Windows Server Enterprise 2003 R2, SP2, расвернут сервер терминалов.
Из софта, что постоянно в памяти висит - Nod32 и Kerio WinRoute (для запасного канала инета)

Было 35-40 пользователей - вертелось приемлимо.
В связи с расширением конторы количество юзерей стало 78 голов - 95% сидит в базе постоянно. Загрузка процессора очень редко падает ниже 70-80%, файл подкачки от 2,1 до 3,3 Гб.
Ошибки транзакции при проведении документов до 5-8 минут могут выскакивать.

Первое решение - добавить ram. Вопрос - сколько максимум увидит WSER2003R2 Enterprise? на сайте микрософта указана частичная поддержка до 32 Гб на одной странице и до 64 Гб на другой. Вопрос снят - данная модель сервера имеет "потолок" в 8 Гб.

Память заказал - добью до 8 Гб парой линеек.

Второе решение - купить и поставить Microsoft SQL Server для распределения базы (вот с этим не сталкивался никогда) - поможет ли? От RDP отказыватся компания не будет - оплачено. Ну и, понятно, 1С придется менять с файловой на SQL и тоже 7.7.

Основной вопрос - нужен и поможет ли SQL или продолжать "играть" с аппаратной частью сервака?

а в чем суть перехода то? sql конечно лучше.... но у вас транзакции скорее всего из за ошибки в коде...

На 100% не поручусь за отсутствие ошибок, но если сделать локальную копию - летает. Если выкинуть всех пользователей и оставить до 30 пользователей - работает нормально. от 50 начинаются висяки. Читал про SQL - манит вот такая фишка про доступ к файлам базы данных:

Опять же тут /lofiversion/index.php/t10878.html про транзакции, DBF и SQL... Вообще вопрос как будет работать данный монстр на одном серваке (терминал + MS SQL Serv)? Кто-нить внедрял такое?

Большого выигрыша от перехода на SQL при такой пользовательской активности пользователей с версией 7.7. не добьетесь...
Хотя есть варианты тонкой подстройки SQL базы и использования 1С++ для увеличения производительности. Но я этим не увлекался.
Можно провести ряд работ для оптимизации самой БД, если конфа писалась на основе типовой, попробовать убрать лишние измерения в регистрах, лишние регистры, которые не используются при работе. Еще вариант обрезать базу с удалением 1ssystem для полного обнуления и пересчета итогов, но это временное облегчение.
В версии 7.7. есть одно очень узкое горлышко, которое и вызывает указанные Вами ошибки, и от него не избавиться - называется общий журнал, это таблица, которую блокирует любой пользователь каждый раз, когда записывает или проводит любой пользователь, соответственно на время записи+проведения документа.
Проверьте, на всякий случай, не используются модальные окна для оповещения пользователя об ошибке при проведении документа.

2Itsys:
Благодарю за развернутый ответ. Но т.к. я больше системный администратор чем админ 1С - вопрос:

Вы говорите про окно подтверждения/ошибки выполнения операции? При проведении реализации выходит окно с названием в шапке "Комментарии к выполненным операциям". Оно называется "модальным"?

Модальное окно, это сообщение с кнопками "Ок" или "Да Нет", т.е. то, которое ждет каких-то действий пользователя, чтобы продолжить обработку, а транзакция активна и соответственно все это время блокировка активна.

Нет, этого нет.

Уже лучше

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

SQL -
а лучше перейти на 8 и связку с sql))

Вы уверены, что они работают, а не мучаются?
Очень многое зависит от конфигурации, если использовать типовую, то там очень много "универсальных" механизмов. Можно написать вполне шуструю, заточенную под определенные вещи самописку, которая будет нормально держать и более 100 пользователей. Весь вопрос в оптимизации процедур, доступа к данным.
Вот пример: 1С в типовой УТ 8 отказалась от проверки остатков задним периодом, посчитав, что пересчет итогов будет сильно тормозить процесс проведения документов и подведя под это теор базу, что если документ проводится задним числом, то это уже свершившийся факт и его надо зафиксировать, а потом разбираться с минусами, кода Вы на них нечаянно наткнетесь. Тоже самое сделано с довольно медленным механизмом проведения по партиям - при проведении документа партии не распределяются, а сделана отдельная обработка, которая распределяет партии по ночам, когда нормальные пользователи не работают, правда эту фичу можно отключить и распределять партии при проведении каждого документа. И это все очень сильно влияет на производительность.
Еще в семерке очень сильно влияет на производительность работа с документами у которых большие табличные части. 1000 документов, в которых есть по 1 строке, проедутся намного быстрее, чем 1 документ с 1000 строк. Это связано с теми же "универсальными механизмами", когда результат проведения по одному регистру сваливается в таблицу значения, которая отжирает кучу оперативки, потом эта таблица сворачивается с 1000 до 999, но свертка требует колоссальных вычислительных ресурсов, потом эта таблица копируется, после этого проводится еще один регистр, данные проведения выгружаются в третью таблицу и т.д.

Всем СПС за ответы. Буду пробовать на соседнем сервере и копии текущей базы.