Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | |
Дело в том еще.. 10.12.04 13:31 Число просмотров: 3130
Автор: DrMasik Статус: Незарегистрированный пользователь
|
Дело в том еще, что может быть база самописная. Если не самописная, то хорошо бы было удалить из нее все, что не нужно - существенно уменьшает размер базы. К тому же нужно провести тщательный анализ сырца. Как правило много чего можно и нужно оптимизировать...
Сколько пользователей сидит на серваке и зачем такие тачки мощЬные, если все крутится под термиком?
|
|
<networking>
|
Есть ли выгода от использования какого-нибудь другого (не-IP) протокола при перекачке больших массивов данных по Ethernet? 03.12.04 10:06 [HandleX]
Автор: HandleX <Александр М.> Статус: The Elderman
|
Решили «масштабировать» 1С. Терминалы пускаем на одном серкваке, M$ SQL на другом.
Хотим связать сервера по гигабитному Ethernet без свичей и хабов чисто карта-в-карту.
И вот Subj. Поскольку маршрутизация и вся прочая хрень не нужна, то и протокол может «попроще» поюзать? Скажем, NetBEUI, или IPX?
Эх, жаль нету сетевой библиотеки SQL-сервера «Чисто по Ethernet» ;-)
Щас фанаты новела, чувствую, к IPX склонять начнут. ;-)
Единственное плохо, что из всех сетевых библиотек, используемых SQL-сервером, проканают вроде как только 2 — «Multiprotocol», что использует RPC, и Named Pipes... Ясен перец что это дополнительный презерватив...
Всё больше склоняюсь к IPX/SPX...
Ваше мнение, господа?
Заранее всем спасибо за ответы.
|
|
Результаты. 20.12.04 17:19
Автор: HandleX <Александр М.> Статус: The Elderman
|
Всё решилось само собой — M$ SQL Server валится с Access Violation при попытке использования сетевой библиотеки IPX/SPX ;) Плюнул, и пустил всё по IP. Стало на душе спокойнее ;-)
Тем более, что сетевые карты держат на аппаратном уровне всякие TCP/IP offload — вот и пусть себе держат.
|
| |
Отрицательный результат провышения производительности - тоже... 20.12.04 18:19
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 20.12.04 18:21 Количество правок: 1
|
> Всё решилось само собой — M$ SQL Server валится с Access
> Violation при попытке использования сетевой библиотеки
> IPX/SPX ;) Плюнул, и пустил всё по IP. Стало на душе
> спокойнее ;-)
>
> Тем более, что сетевые карты держат на аппаратном уровне
> всякие TCP/IP offload — вот и пусть себе держат.
Отрицательный результат провышения производительности - тоже результат.
Можно, конечно побороться с тем, чтоб оно не валилось и закончить эксперимены, но я бы не посоветовал тратить время. Принципиально большой разницы между протоколами нет. В полутракилобайтном фрейме у одного из протоколов может быть чуть побольше служебной информации. Но эта разница всего несколько байт. Стало быть выигрыш/проигрыш на большем количестве переданной полезной информации может составлять порядка процента. Время обработки фрейма на современных процессорах при простой сети ничтожно мало, по сравнению с передачей его по сети. Разница все равно была бы не велика и еще не известно в чью пользу.
Я в свое время увидел как трансферились файлы по Юниксовым машинам через АйПи. Получалось ~7-8 Мб/сек. В то время я заметил, что прокачка с Новелевского сервака по АйПиИкс достигала 9. Нужно учесть много других параметров - сами компы, скорости дисков, загрузку другими задачами, загрузку сети "общая шина" другими РС и пр. Хотя процы были достаточно хилые. Надо отдать должное Новелю - напревзайденная сетевая файл-серверная ОС. А АйПиИкс хоть скорее всего и быстрее, но отмер, потому что на столько же (чуть-чуть) тупее.
Замерами надо узкое место искать. Может оказаться, что все они узкими и окажутся.
|
| | |
Забыли о сетевом процессоре, который ИМХО у Интел достаточно "умен" и заточен под ИП. 20.12.04 18:39
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | | |
Глубоко сомневаюсь, что интеловцы часть функций по обработке... 21.12.04 10:43
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 21.12.04 10:46 Количество правок: 4
|
|
Глубоко сомневаюсь, что интеловцы часть функций по обработке IP запихнули в чип. Некоторый эффект должен быть, если это так, но незначительный, чтоб таким изратом заниматься. А сомневаюсь, потому что сильно нужно модифицировать сетевую часть операционки, которая должна будет по всяким сетевым делам более высокого уровня через драйвер в чип лезть. Сетевому чипу и своих функций хватает.
|
| | | | |
Хых... Вот привожу настраиваемые в _Win2k_ параметры карты Intel Pro 1000 MT. 21.12.04 14:06
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 21.12.04 18:52 Количество правок: 2
|
Offload receive IP checksum
Offload receive TCP checksum
Offload transmit IP checksum
Offload transmit TCP checksum
Вот так. IMHO при длине пакета в ~1,5 килобайта считать контрольную сумму для каждого пакета достаточно ресурсоёмкая задача, чтобы ею пренебрегать, особенно на гигабитных картах.
Что интересно, карта Intel Pro 100 кроме всяких checksum offload имеет ещё и параметр Offload IP Security, что достаточно непонятная тема ;-)
Kerberos чтоли оффлоадит? А вот у MS нестандартный Kerberos... ;-)
А по поводу "сильно нужно модифицировать сетевую часть операционки" -- чего там переделывать, если инкапсуляция IP по Ethernet предельно стандартизирована... Просто не просчитывать поле checksum в драйвере TCP/IP, а карта (с включенным параметром offload) сама посчитает и проставит уже в своём буфере.
А некоторые карты ещё могут делать и Offload IP Defragment, коренным образом переваривая принятое ;-)
Ещё прикольная тема Jumbo Frames — можно размер фрейма Ethernet сделать от 9014 до 16128 байт, что при соотв. IP MTU Size может дать выигрыш в скорости. Но оборудование должно быть совместимое, конечно же.
|
| | | | | |
Мало того, у интела в доках сказано 28.12.04 06:34
Автор: AlexD <Alexander> Статус: Member
|
|
Что ихний драйвер грузит в сетевуху кусок прошивки.
|
| | | | | | |
Драйвер сетевухи, надеюсь, а не протокола. Тогда при чем тут протокол? 28.12.04 10:20
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
|
|
| | | | | | | |
При том, что сейчас везде рассчитано на наличие tcpip 03.01.05 08:01
Автор: AlexD <Alexander> Статус: Member
|
|
|
| | | | | |
Круто, на счет чексумов согласен. Думаю, что 3СОМ умеют то... 21.12.04 16:09
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Offload receive IP checksum
> Offload receive TCP checksum
> Offload transmit IP checksum
> Offload transmit TCP checksum
>
> Вот так. IMHO при длине пакета в ~1,5 килобайта считать
> контрольную сумму для каждого пакета достаточно
> ресурсоёмкая задача, чтобы ею пренебрегать, особенно на
> гигабитных картах.
Круто, на счет чексумов согласен. Думаю, что 3СОМ умеют то же самое. Не определена ли эта функция в стандарте. Если б эта карточка еще табличку IP<=>MAC строила/хранила, сама бы разбиралась по адресу и маске надо ли пакет через шлюз кидать или напрямую, трансляцию адресов добавить, фильтрацию - вот круто было бы.
|
| | | | | | |
Ага, и получился бы Cisco router на PCI карте :) 21.12.04 18:49
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 21.12.04 18:50 Количество правок: 1
|
|
|
|
Может проще добавить еще по сетевухе в сервер на разные РСИ каналы (не только слоты!) и в транк их. 10.12.04 13:40
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| |
Уже карта гигабитная куплена... Завтра начну всё делать. 11.12.04 11:26
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | |
ре:Уже карта гигабитная куплена... Завтра начну всё делать. 13.12.04 12:07
Автор: Garick <Yuriy> Статус: Elderman
|
Я подразумевал поставить по две 1гб карты в сервер и объеденить их в транк. Во первых скорость увеличивается, во вторых избыточность (при неисправности одной из двух - сеть продолжает работать на одной). Но эти сетевухи должны поддерживать режим транка.
ЗЫ: Не встречал я пока в статьях и тест-репортах 100% утилизацию 1гб адаптера, даже в синтетических тестах, не говоря уже о реальных бизнес ориентированых тестах. ИМХО и одного адаптера хватит.
|
| | | |
А раз не встречал 100% утилизацию _одной_ карты, зачем ещё и транк советуешь? ;-) 14.12.04 11:46
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | | | |
Может это частный случай, уникальный:-))) И встречный вопрос "Зачем "ускорять" протоколы?" 14.12.04 15:13
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | | |
? про транк 13.12.04 14:01
Автор: DrMasik Статус: Незарегистрированный пользователь
|
|
Народ, поведайте про этого зверя и как его творить.
|
| | | | |
краткий ответ "? про транк" 13.12.04 14:13
Автор: Garick <Yuriy> Статус: Elderman
|
> Народ, поведайте про этого зверя и как его творить.
Для сетевых под вынь
в менегере (обычно утилита от производителя сетевой) делается объединение адаптеров - получается сетевое подключение, которое настраивается как обычно. На свиче - см. мануал по свичу. (циска делает практически без проблем)
ЗЫ: как происходит балансировка нагрузки, избыточность, контроль передачи не разбирался.
|
|
Как не заманчиво поиметь выигрыш в скорости применив IPX на... 06.12.04 19:24
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
|
Как не заманчиво поиметь выигрыш в скорости применив IPX на гигабитном линке - сомнения грызут. Выигрыш этот пожалуй нивелируется тем что в бедную НТшку воткнут одновременно и IPX и IP. Соответственно меньше надёжность, а возможно что и общая скорость сетевой подсистемы умнеьшится от наличия двух поддерживаемых протоколов в системе. И потом, будт ли сиквел работать не по IP?
|
| |
Попробую. 07.12.04 09:29
Автор: HandleX <Александр М.> Статус: The Elderman
|
> Как не заманчиво поиметь выигрыш в скорости применив IPX на
> гигабитном линке - сомнения грызут. Выигрыш этот пожалуй
> нивелируется тем что в бедную НТшку воткнут одновременно и
> IPX и IP. Соответственно меньше надёжность, а возможно что
> и общая скорость сетевой подсистемы уменьшится от наличия
> двух поддерживаемых протоколов в системе.
Спорить можно много, но мне кажется несколько иначе... Я пока не архитектор OS и сетевых протоколов, но вроде как фрейм Ethernet имеет поле "тип протокола". IMHO куча различных процедур самой OS сотрут на нет «лишнее» ветвление для передачи кадра обработчику протокола. Второй момент, что обработчик протокола занимает лишнюю память... Но и это не важно для современных систем. В общем я буду это всё делать скоро. Буду тестировать. Результаты обязательно доложу.
Конфигурация такая:
SQL-сервер: Win2k сервер + MS SQL 2000, 2xIntel Xeon 2,8 ГГц, 2Г ОЗУ, диски SCSI RAID0 2x, сетевые карты встроенные на матери, обе Intel, одна 100, другая 1000 мегабит.
Сервер терминалов: Win2k сервер + терминалы + 1С, 2xIntel серверные PIII 1133 МГц, 2Г ОЗУ, 1 SCSI винт, сетевые карты одна встроенная на матери Intel 100 мегабит, вторая в PCI64x66Мгц 1000 мегабит на чипе Alcom (говорят, не очень плохой ;-)).
100-мегабитами сервера будут соединены в общий свитч по протоколу IP, а 1000 соединю витой парой карту в карту по IPX.
При этом от IPX отвяжу всё лишнее (сервер, браузер и т.п.), просто чистый протокол.
> И потом, будт ли сиквел работать не по IP?
Да. Майкрософтский SQL-сервер имеет клиентские и серверные библиотеки подключения по IPX/SPX.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
