Cервер aqvarius 2-xeon-а: 1.8 и 1.7 (есть ругань сист. на данный мезальянс) и 1.5Г озу, рейд на 3-х сказевых винтах, скорость ограниченна контролером на 10000 об, Win2003 srv, обслуживает штук 20 машин, XP, храня в AD профиля и устр-ва. юсеров и штук 10 машин, позволяя терминально (Citrix) работать в 1с (версия 7ххх), причем 6 машин (бухг) в основном работают с одной базой 500Мег весом в dbf версии 1C,
остальные в SQL-ной версии 1с с другой базой. обмен баз данными - ночью с помощью OLE. И те и другие сплошь проводят время в ожидании завершения транзикаций.
машины связаны через 3com-ский свич, порт куда воткнут сервер прописан как гигобитный, правда сетевуха, все одно, почему то определяется как сотка, но вроде не с сетью тормоза.
мне видится, что конфигур сервера вполне достаточная, что бы потянуть столько пользователей цитрикса. как проверить? и где может спрятаться проблема
кроме производительности сервака, сети и неоптимизированных запросов 1с? Может кто сталкивался? Может проблема в совмещении 2-х типов 1с (dbf & sql) на одном серваке.
Уже башка раскалывается, и нет идей для проверки. Хотелось бы доставить памяти или другое железо подкинуть, но где его возьмешь. Есть в запасе неплохой однопроцессорный сервер на который повесили чисто задачи служить шлюзом, но есть зихеровский роут и фаревол, так что можно этот сервак высвободить. Какие задачи стоит на него повесить, что бы разгрузить основной сервак? Сеть вроде тестерами проверяли. В случае если запускаешь 1 С на локальных тачках, то тормоза еще суровее, машины разные но ниже чем 1500МГц селерон нет. Столь же успешно тормозят при лок работе и селерон 2400 с 256М ОЗУ

Конфигурация 1С стандартная или самописная?
1С 7.хх суть однопользовательская хрень. Пока кто-то проводит корректировку документов или создает отчет, остальные висят, ждут...
Особенно, если самописная. Такого "програмеры" одинэсники понаваяют, что месяц из очереди не вылезешь.
С цитриха убирать не стоит. 1С-у там самое место.

Цитата(ASpid @ 20.7.2005, 10:31)

И те и другие сплошь проводят время в ожидании завершения транзикаций.

Просто 1С v7.x блокирует всю базу, а не определенную таблицу.
В результате чего, создание больших отчетов влечет собой постановку в очередь всех.
Все ждут, когда он создастся... Потом следующий. И т.д.
В 8-й версии, говорят, это победили...
Железом тут не поможешь. С точки зрения системы все разумно.
Ну разве, что кроме базы на DBF. Можно было бы ее тоже в SQL закинуть. Благо проблем тут нет.

Спасибо за ответ. Я тоже на 1С грешил почти исключительно. Как бы узнать разобрались ли с этой заморокой в 8 версии. может кто откликнется? и почему во многих конторах 1с терминально на серваке послобее и с большим кол-вом пользователей вроде нормально работает? 1с-ники скорректировали режим работы самих бухгалтеров или отткорректировали саму базу, используется более мощный сервак или? А насчет перевести все на 1С SQL так там тоже говорят SQL "липовый" запрос такой составляет, что все одно массив здоровенный на локальную тачку тянет. только вот врооде как на нем блакируется не вся база на время создания отчета а лишь необходимая таблица. Если это так то выйгрышь в производительности работы бухг все же возможен при переходе на SQL. я правильно понимаю, господин Snowy?

Цитата

Как бы узнать разобрались ли с этой заморокой в 8 версии.

Да. Восьмую они научили более-менее грамотно работать с SQL.
В 7-й возможность SQL сделана, как пришлепка. Т.е. работа идет, как с DBF, только местонахождение данных несколько другое.

Цитата

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

Меньший объем данных, меньше необходимость собирать отчеты за большие периоды, грамотный пользователь (который знает что ему нужно, а не "что будет, если сюда тыкнуть"). Факторы разные бывают.

Цитата

1с-ники скорректировали режим работы самих бухгалтеров или отткорректировали саму базу, используется более мощный сервак или?

Просто ушли от тупости полной блокировки базы. И даже местами научились SQL использовать.

Цитата

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

По сути, для 1С почти пофигу, где располагаются таблицы. Этим занимается прослойка интерфейса базы. 1С просто говорит "заблокировать" и блокирует ВСЁ. Независимо от того, на SQL это все лежит или в DBF. Если кто-то успел заблокировать до него, то висит, ждет. Потом сам блокирует, когда база освободится. Постепенно выстраивается очередь, работа встает.

Цитата

Если это так то выйгрышь в производительности работы бухг все же возможен при переходе на SQL. я правильно понимаю, господин Snowy?

Нет. Просто уменьшится нагрузка на диск и файловую систему в частности. Объем данных слегка приуменьшится. Но главное - ниже вероятность повреждения и утери данных. Т.к. DBF порой и резервное копирование не спасает.
Соптимизировать здесь можно только бухгалтеров. Провести воспитательную работу. Объяснить, что при запросе длинного отчета, ждут не только они, а вообще все. Уговорить не создавать отчеты каждые 5 минут, а сохранять результаты в Excel и с ними уже работать.
Добавлено @ 09:07
Модератору:
Плиз, перенесите тему в "SAP,ERP".
Быть может мудрый Stron меня в чем-то поправит, а может чего умное подскажет...

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

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

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

Я бы не был так уверен в сети - уж очень крутая для 1С машина - посмотри на серваке загрузку системы.
На счет: "...машины связаны через 3com-ский свич, порт куда воткнут сервер прописан как гигобитный, правда сетевуха, все одно, почему то определяется как сотка... - Вобще то гигабитная сеть и сотка имеют разные протоколы обмена. Чтоб поиметь сеть 1С достаточно чтобы на одной из машин возникала ошибка - кабель к примеру имеет плохой контакт, или в окнах что то напутано - сервак будет упорно ожидать получение данных со скоростью как у самой дохлой машины.

Ясно, у самой дохлой сотка а этого не мало для 1С

Цитата(Guest @ 24.7.2005, 14:19)

Ясно, у самой дохлой сотка а этого не мало для 1С

- Тут дело не в скорости настроеного протокола, а в том, сколько пакетов теряется и сколько возникает коллизий.