перфмон
Модераторы: Trinity admin`s, Free-lance moderator`s
перфмон
ессно смотрел. 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)
кас. "пачки гигабиток" (я так понимаю речь реально шла все-таки о многокарточном тиминге, уходящем в достойный свич и выходящем из свича таким же тимингом в терминальники
вопрос такой - поднимался ли тсп-стэк на новеле или же все работало по старому доброму IPX?
однозначно согласен с тем, что новелл очень хорошо отдает файлики в сеть, особенно при многопользовательском доступе
но - тогда встает вопрос - а зачем тогда вообще пладить терминальники, коли в коре-свич идет такой ШЛАНГ (многокарточный тиминг) от БД - можно же просто на раб.станциях пускать саму задачу (1С аппликейшн).
поправьте меня если я не прав. по-крайней мере это будет экономнее, нежели покупка терм.серверов формата дуал-ксеон.
интересно было бы посмотреть реально (визуально посмотреть за раб.местом юзера в теч.часа) на производительность схемы новель-толстый ШЛАНГ-свич-ТОЛСТЫЙ ШЛАНГ-терминальник-клиентское место.
еще есть мысль - MNS (Majority Node Set) в Win2k3 clustering или же NSS-mirroring в Netware Cluster может ли позволить данные технологии выдавать данные в сеть , как в свое время SFTIII , распараллеливая сетевую нагрузку (NLSP by Novell on IPX)
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Могу сказать только про важность терминальников - 1С блокирует регистры на время проведения транзакции и медленные машины будут тормозить более быстрые. С терминалами все будет ровнее (при достаточной их мощности). Я что-то сомневаюсь, что все 150 клиентских машин достаточно сильны.
А по поводу большого кэша на контроллере - задумайтесь. Может сильно помочь. Тем более что это можно просто попробовать.
А по поводу большого кэша на контроллере - задумайтесь. Может сильно помочь. Тем более что это можно просто попробовать.
неутешительные выводы
организация нетваре IPX с толстенным тимингом по ГБит карточкам в достойный свич и из свича толстые тиминги до терминалок зконом класса (от 1процовых с HT P4 до дуальных ксеонов). далеее ОБЯЗАТЕЛЬНО Citrix и создание УМНОГО распараллеливания сессий в зависимости от нагрузки на процы терминалок, сетевой трафик до БД и т.д.
я пока не касаюсь производительности именно дисковой подсистемы - так как это ясно, что не софтовый АТА-RAID5 делать надо
согласны со мной?
я пока не касаюсь производительности именно дисковой подсистемы - так как это ясно, что не софтовый АТА-RAID5 делать надо
согласны со мной?
Baklan
Вынося БД на внешний дисковый массив (не принципально какой), все-равно упретесь в производительность связки дисковая_подсистема-процессор-память-сеть и никакой пачковый тиминг не спасет. Другими словами, локальная связка на одном (МОЩНОМ) компе будет отдавать БД быстрее физически вынесенной.
На мой взгляд есть два правильных пути увеличения производительности:
1) решение "в лоб"-мощное железо в виде 4-х процессорного сервера и "все в одном флаконе". Недостатки: дорого и до определенной степени.
2) БД (типа Oracle), которая умеет правильно разноситься по серверному железу. Но M$ SQL (а значит и 1С) это _пока_ не грозит. . Тут "или ишак или падишах...", т.е. остается надеятся что в 1С "узнает" о существования других SQL или MS выпустит новый YUKON.
Все остальное - извращения, сложные и потому чреватые. Часто по бедности.
Все IMHO.
P.S. Забыл про решение:
0) Оптимизация самой БД.
Вынося БД на внешний дисковый массив (не принципально какой), все-равно упретесь в производительность связки дисковая_подсистема-процессор-память-сеть и никакой пачковый тиминг не спасет. Другими словами, локальная связка на одном (МОЩНОМ) компе будет отдавать БД быстрее физически вынесенной.
На мой взгляд есть два правильных пути увеличения производительности:
1) решение "в лоб"-мощное железо в виде 4-х процессорного сервера и "все в одном флаконе". Недостатки: дорого и до определенной степени.
2) БД (типа Oracle), которая умеет правильно разноситься по серверному железу. Но M$ SQL (а значит и 1С) это _пока_ не грозит. . Тут "или ишак или падишах...", т.е. остается надеятся что в 1С "узнает" о существования других SQL или MS выпустит новый YUKON.
Все остальное - извращения, сложные и потому чреватые. Часто по бедности.
Все IMHO.
P.S. Забыл про решение:
0) Оптимизация самой БД.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
1С оптимизации поддается весьма тяжко. Врожденная болезнь.
А по поводу четырехпроцессорки - в принципе можно, и даже не очень дорого (четырехпроцессорный оптерон стоит намного дешевле ксеона), но при таком числе юзверей будет на пределе. Хотя если не планируется рост, то наверное это самый подходящий вариант.
А по поводу четырехпроцессорки - в принципе можно, и даже не очень дорого (четырехпроцессорный оптерон стоит намного дешевле ксеона), но при таком числе юзверей будет на пределе. Хотя если не планируется рост, то наверное это самый подходящий вариант.
не могу не высказаться
4х машинка = 15к я так понял минимум?
речь о смене системы учета (финансов, товаров и т.д.) - скорее риторический вопрос и стОить это будет ЕЩЕ больше, равно как и ERP, работающая на real clustering Oracle я даже не буду писать примерно стоимость такого проекта.
поэтому наверное это не очень уместно - двигать в сторону смены платформы учета.
ведь мы всегда отталкиваемся от того, что уже есть.
а имеет вот что - на данный момент сервер (5к) дуал-ксеон справляется с 80 сессиями в терминалке.
так вот теперь представим что кол-во сессий выросло в 2 раза - вопрос такой - сколько денег и на что нужно потратить?
это как тендер - занять позицию ген.дира - ему важны: сроки реализации, стоимость работ, надежность, возможность дальнейшего расширения (средняя стоимость владения одним раб.местом).
если реентабельнее отдать на переписку конфы 1С в другую более умную франчайзинговую контору и это выйдет дешевле - не вопрос.
ситуация с расширением железа (4х сервер это будет или же iSCSI - не принципиально) она так же прогнозируема - скажем мы вкладываем в первоначальный апгрейд 10к (netware cluster, teaming и т.д.) и в дпльнейшем стоимость владения одним раб.метстом равна скажем 50$
вот к чему интересно прийти
выстроить некую шкалу - ось Y - деньги, ось Х - кол-во рабочих мест (сессий БД). и вот в таком ракурсе выявить лидера (апгрейд железа или же установка новой ERP) на каждом этапе (50 юзеров, 250, 500).
я не думаю, что компания с численностью раб.мест более 500 будет работать на продуктах 1С
речь о смене системы учета (финансов, товаров и т.д.) - скорее риторический вопрос и стОить это будет ЕЩЕ больше, равно как и ERP, работающая на real clustering Oracle я даже не буду писать примерно стоимость такого проекта.
поэтому наверное это не очень уместно - двигать в сторону смены платформы учета.
ведь мы всегда отталкиваемся от того, что уже есть.
а имеет вот что - на данный момент сервер (5к) дуал-ксеон справляется с 80 сессиями в терминалке.
так вот теперь представим что кол-во сессий выросло в 2 раза - вопрос такой - сколько денег и на что нужно потратить?
это как тендер - занять позицию ген.дира - ему важны: сроки реализации, стоимость работ, надежность, возможность дальнейшего расширения (средняя стоимость владения одним раб.местом).
если реентабельнее отдать на переписку конфы 1С в другую более умную франчайзинговую контору и это выйдет дешевле - не вопрос.
ситуация с расширением железа (4х сервер это будет или же iSCSI - не принципиально) она так же прогнозируема - скажем мы вкладываем в первоначальный апгрейд 10к (netware cluster, teaming и т.д.) и в дпльнейшем стоимость владения одним раб.метстом равна скажем 50$
вот к чему интересно прийти
выстроить некую шкалу - ось Y - деньги, ось Х - кол-во рабочих мест (сессий БД). и вот в таком ракурсе выявить лидера (апгрейд железа или же установка новой ERP) на каждом этапе (50 юзеров, 250, 500).
я не думаю, что компания с численностью раб.мест более 500 будет работать на продуктах 1С
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Графики уж сами стройте
А четырехпроцессорка съест примерно в два раза больше, чем двушка (правда вин адвансед сервер потребуется из за количества мозгов). Правда рост цены получается нелинейный. Зато не надо отдельный файл сервер, который тоже денег стоит. И никакого геморроя с сетью. Локально база будет шуршать не в пример быстрее.
Но это потолок. Если планируете дальнейшее расширение, все равно архитектуру железа придется пересматривать.
(iSCSI кстати вам не поможет, нужен просто быстрый файл сервер или NAS)
А четырехпроцессорка съест примерно в два раза больше, чем двушка (правда вин адвансед сервер потребуется из за количества мозгов). Правда рост цены получается нелинейный. Зато не надо отдельный файл сервер, который тоже денег стоит. И никакого геморроя с сетью. Локально база будет шуршать не в пример быстрее.
Но это потолок. Если планируете дальнейшее расширение, все равно архитектуру железа придется пересматривать.
(iSCSI кстати вам не поможет, нужен просто быстрый файл сервер или NAS)
спасибо
NAS или Netware
это уже надо эксперементировать
благо есть на чем
расскажу о результатах с нетварью через недельку
спасибо всем за то, что откликнулись и ответили на мои глупые вопросы
это уже надо эксперементировать
благо есть на чем
расскажу о результатах с нетварью через недельку
спасибо всем за то, что откликнулись и ответили на мои глупые вопросы
1c 7.7 MS SQL 2000
тестировали в свое время - оказалось гораздо медленнее ДБФ
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Эээ нет .
Тут есть такой момент: SQL в силу своей организации безусловно медленнее, чем плоская таблица (потому как пишется/читается доп. количество служебной информации, следовательно, и накладные расходы возрастают). С другой стороны, на больших БД (единицы Гбайт и выше) и относительно большом кол-ве пользователей (50 и выше) SQL позволяет куда как более аккуратно раскладывать нагрузку на подсистемы, полностью исключить проблему переиндексации ( ) для 1С, и - намного "умнее" кэширует.
Тут есть такой момент: SQL в силу своей организации безусловно медленнее, чем плоская таблица (потому как пишется/читается доп. количество служебной информации, следовательно, и накладные расходы возрастают). С другой стороны, на больших БД (единицы Гбайт и выше) и относительно большом кол-ве пользователей (50 и выше) SQL позволяет куда как более аккуратно раскладывать нагрузку на подсистемы, полностью исключить проблему переиндексации ( ) для 1С, и - намного "умнее" кэширует.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 21 гость