перфмон

Как создать сервер оптимальной конфигурации.

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
Baklan
Junior member
Сообщения: 14
Зарегистрирован: 13 май 2004, 21:22
Контактная информация:

перфмон

Сообщение Baklan » 14 май 2004, 13:39

ессно смотрел. 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
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 14 май 2004, 13:48

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

Baklan
Junior member
Сообщения: 14
Зарегистрирован: 13 май 2004, 21:22
Контактная информация:

неутешительные выводы

Сообщение Baklan » 14 май 2004, 14:17

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

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

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 14 май 2004, 14:27

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

vol123
Advanced member
Сообщения: 53
Зарегистрирован: 01 апр 2004, 02:13
Откуда: Москва

Сообщение vol123 » 14 май 2004, 16:37

Baklan

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

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

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

Все IMHO.

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

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 14 май 2004, 16:57

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

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

Baklan
Junior member
Сообщения: 14
Зарегистрирован: 13 май 2004, 21:22
Контактная информация:

не могу не высказаться

Сообщение Baklan » 14 май 2004, 16:58

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
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 14 май 2004, 17:15

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

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

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

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

Baklan
Junior member
Сообщения: 14
Зарегистрирован: 13 май 2004, 21:22
Контактная информация:

спасибо

Сообщение Baklan » 14 май 2004, 17:18

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

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 14 май 2004, 18:06

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

Baklan
Junior member
Сообщения: 14
Зарегистрирован: 13 май 2004, 21:22
Контактная информация:

1c 7.7 MS SQL 2000

Сообщение Baklan » 15 май 2004, 12:06

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

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 17 май 2004, 10:55

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

Ответить

Вернуться в «Серверы - Конфигурирование»