перфмон

[Baklan]

ессно смотрел. current queue всегда оставался либо 0, либо 1, ну иногда 2, что по курсу MCSE считается примлемым и не является bottleneck
кас. "пачки гигабиток" (я так понимаю речь реально шла все-таки о многокарточном тиминге, уходящем в достойный свич и выходящем из свича таким же тимингом в терминальники
вопрос такой - поднимался ли тсп-стэк на новеле или же все работало по старому доброму IPX?
однозначно согласен с тем, что новелл очень хорошо отдает файлики в сеть, особенно при многопользовательском доступе
но - тогда встает вопрос - а зачем тогда вообще пладить терминальники, коли в коре-свич идет такой ШЛАНГ (многокарточный тиминг) от БД - можно же просто на раб.станциях пускать саму задачу (1С аппликейшн).
поправьте меня если я не прав. по-крайней мере это будет экономнее, нежели покупка терм.серверов формата дуал-ксеон.
интересно было бы посмотреть реально (визуально посмотреть за раб.местом юзера в теч.часа) на производительность схемы новель-толстый ШЛАНГ-свич-ТОЛСТЫЙ ШЛАНГ-терминальник-клиентское место.
еще есть мысль - MNS (Majority Node Set) в Win2k3 clustering или же NSS-mirroring в Netware Cluster может ли позволить данные технологии выдавать данные в сеть , как в свое время SFTIII , распараллеливая сетевую нагрузку (NLSP by Novell on IPX)

[gs]

Могу сказать только про важность терминальников - 1С блокирует регистры на время проведения транзакции и медленные машины будут тормозить более быстрые. С терминалами все будет ровнее (при достаточной их мощности). Я что-то сомневаюсь, что все 150 клиентских машин достаточно сильны.
А по поводу большого кэша на контроллере - задумайтесь. Может сильно помочь. Тем более что это можно просто попробовать.

[Baklan]

организация нетваре IPX с толстенным тимингом по ГБит карточкам в достойный свич и из свича толстые тиминги до терминалок зконом класса (от 1процовых с HT P4 до дуальных ксеонов). далеее ОБЯЗАТЕЛЬНО Citrix и создание УМНОГО распараллеливания сессий в зависимости от нагрузки на процы терминалок, сетевой трафик до БД и т.д.
я пока не касаюсь производительности именно дисковой подсистемы - так как это ясно, что не софтовый АТА-RAID5 делать надо

согласны со мной?

[gs]

Я не спец по IPX и ваще по сетям
А про дисковую и кэш сказал, т.к. это совершенно реальная возможность снизить влияние блокировок 1С. Просто с производительностью кэша никакое количество дисков не сравнится.
А вообще, согласен конечно

[vol123]

Baklan

Вынося БД на внешний дисковый массив (не принципально какой), все-равно упретесь в производительность связки дисковая_подсистема-процессор-память-сеть и никакой пачковый тиминг не спасет. Другими словами, локальная связка на одном (МОЩНОМ) компе будет отдавать БД быстрее физически вынесенной.

На мой взгляд есть два правильных пути увеличения производительности:
1) решение "в лоб"-мощное железо в виде 4-х процессорного сервера и "все в одном флаконе". Недостатки: дорого и до определенной степени.
2) БД (типа Oracle), которая умеет правильно разноситься по серверному железу. Но M$ SQL (а значит и 1С) это _пока_ не грозит. . Тут "или ишак или падишах...", т.е. остается надеятся что в 1С "узнает" о существования других SQL или MS выпустит новый YUKON.

Все остальное - извращения, сложные и потому чреватые. Часто по бедности.

Все IMHO.

P.S. Забыл про решение:
0) Оптимизация самой БД.

[gs]

1С оптимизации поддается весьма тяжко. Врожденная болезнь.

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

[Baklan]

4х машинка = 15к я так понял минимум?
речь о смене системы учета (финансов, товаров и т.д.) - скорее риторический вопрос и стОить это будет ЕЩЕ больше, равно как и ERP, работающая на real clustering Oracle я даже не буду писать примерно стоимость такого проекта.
поэтому наверное это не очень уместно - двигать в сторону смены платформы учета.
ведь мы всегда отталкиваемся от того, что уже есть.
а имеет вот что - на данный момент сервер (5к) дуал-ксеон справляется с 80 сессиями в терминалке.
так вот теперь представим что кол-во сессий выросло в 2 раза - вопрос такой - сколько денег и на что нужно потратить?
это как тендер - занять позицию ген.дира - ему важны: сроки реализации, стоимость работ, надежность, возможность дальнейшего расширения (средняя стоимость владения одним раб.местом).

если реентабельнее отдать на переписку конфы 1С в другую более умную франчайзинговую контору и это выйдет дешевле - не вопрос.

ситуация с расширением железа (4х сервер это будет или же iSCSI - не принципиально) она так же прогнозируема - скажем мы вкладываем в первоначальный апгрейд 10к (netware cluster, teaming и т.д.) и в дпльнейшем стоимость владения одним раб.метстом равна скажем 50$
вот к чему интересно прийти
выстроить некую шкалу - ось Y - деньги, ось Х - кол-во рабочих мест (сессий БД). и вот в таком ракурсе выявить лидера (апгрейд железа или же установка новой ERP) на каждом этапе (50 юзеров, 250, 500).
я не думаю, что компания с численностью раб.мест более 500 будет работать на продуктах 1С

[gs]

Графики уж сами стройте

А четырехпроцессорка съест примерно в два раза больше, чем двушка (правда вин адвансед сервер потребуется из за количества мозгов). Правда рост цены получается нелинейный. Зато не надо отдельный файл сервер, который тоже денег стоит. И никакого геморроя с сетью. Локально база будет шуршать не в пример быстрее.

Но это потолок. Если планируете дальнейшее расширение, все равно архитектуру железа придется пересматривать.

(iSCSI кстати вам не поможет, нужен просто быстрый файл сервер или NAS)

[Baklan]

NAS или Netware
это уже надо эксперементировать
благо есть на чем
расскажу о результатах с нетварью через недельку
спасибо всем за то, что откликнулись и ответили на мои глупые вопросы

[a_shats]

А SQL все ж подумайте - он "умнее" кэширует базу (не блоки файловой системы, а - записи) и позволяет куда как аккуратнее распределять нагрузку на железо сервера.

[Baklan]

тестировали в свое время - оказалось гораздо медленнее ДБФ

[a_shats]

Эээ нет .
Тут есть такой момент: SQL в силу своей организации безусловно медленнее, чем плоская таблица (потому как пишется/читается доп. количество служебной информации, следовательно, и накладные расходы возрастают). С другой стороны, на больших БД (единицы Гбайт и выше) и относительно большом кол-ве пользователей (50 и выше) SQL позволяет куда как более аккуратно раскладывать нагрузку на подсистемы, полностью исключить проблему переиндексации ( ) для 1С, и - намного "умнее" кэширует.