«Сетевой интерфейс» - его значение в информационной системе 1С (7.7./8.1./8.2./8.3) Протестируй свою сеть.
Является ли сеть узким местом в производительности вашей информационной системы (например, в информационной системе 1С) – этот вопрос задают себе многие специалисты и сами же отвечают себе: «нет», после анализа «загруженности сети», но все ли так тривиально…? «Загруженность сети» определяется пропускной способностью и трафиком пакетов, который проходит через нее в текущий момент – достаточно ли только этого показателя.
Комментарии
Избранное
Подписка
Сортировка:
Древо
Чтобы доказать, что важна не только пропускная способность сети, Вы сравнили три контроллера (с пропускными способностями 1Гбит, 5 Гбит и 10 Гбит) и пришли к выводу что, внезапно, оптимальным является контроллер с самой высокой пропускной способностью(10Гбит), так? Но при этом приписываете эту "победу" некоемому абстрактному "времени отклика" (которое у вас, похоже от пропускной способности не зависит?). Или я что-то упустил?
Добрый день, коллеги.
С прошедшими всех праздниками
Теперь по комментариям:
(1) Не так важно оборудование для исследования, целью статьи было следующее:
"Развеять миф о том, что если у вас не загружена сеть, то проблем с сетью нет", для этого сделано много замеров (большинство не вошло в конечную статью). Неожиданностью и для нас оказалось, что отклик в сетевом интерфейсе 10Гб в 2 раза лучше, чем для 1 Гб/с, но пока эти исследования не проведешь - не докажешь этот факт.
Почему " "победу" некоемому абстрактному "времени отклика" " - это не абстрактная характеристика, просто большинство сетевых плат для Ethernet продаются без нее, а она очень важна как раз для трафика информационной системы.
(3) Нет, замеряли своими методами через отправку/получения маленького пакета.
(4) "Ваш совет устанавливать насколько возможно более производительное серверное оборудование без споров принимаем" - нет, это не совсем вывод статьи. Вывод: учитывать отклик очень важно при выборе оборудования. + Приведена интересная таблица для оценки разницы. Приведу пример: стоит выбор между 100Мб/с и 1 Гб/с. Администратор утверждает, что сеть 100 Мб/с загружена на 15%, следовательно, сетевой интерфейс справляется и обновления не требуется. При большом количестве пакетов (запросов в секунду) отклик повлияет на скорость системы в целом, значит надо провести доп. работы для исследования этого параметра и выводы администратора не правильны (вероятность ошибки большая).
По поводу общей производительности (память, ЦПУ, диск) - много можно сказать, тем более что мы этим активно занимаемся - softpoint.ru. Не совсем по теме статьи. Если будут вопросы, пишите в личку.
(6) Мы активно участвовали в обсуждении темы автора, есть с чем согласны - есть то, с чем не согласны.
Жду дальнейших вопросов
С прошедшими всех праздниками
Теперь по комментариям:
(1) Не так важно оборудование для исследования, целью статьи было следующее:
"Развеять миф о том, что если у вас не загружена сеть, то проблем с сетью нет", для этого сделано много замеров (большинство не вошло в конечную статью). Неожиданностью и для нас оказалось, что отклик в сетевом интерфейсе 10Гб в 2 раза лучше, чем для 1 Гб/с, но пока эти исследования не проведешь - не докажешь этот факт.
Почему " "победу" некоемому абстрактному "времени отклика" " - это не абстрактная характеристика, просто большинство сетевых плат для Ethernet продаются без нее, а она очень важна как раз для трафика информационной системы.
(3) Нет, замеряли своими методами через отправку/получения маленького пакета.
(4) "Ваш совет устанавливать насколько возможно более производительное серверное оборудование без споров принимаем" - нет, это не совсем вывод статьи. Вывод: учитывать отклик очень важно при выборе оборудования. + Приведена интересная таблица для оценки разницы. Приведу пример: стоит выбор между 100Мб/с и 1 Гб/с. Администратор утверждает, что сеть 100 Мб/с загружена на 15%, следовательно, сетевой интерфейс справляется и обновления не требуется. При большом количестве пакетов (запросов в секунду) отклик повлияет на скорость системы в целом, значит надо провести доп. работы для исследования этого параметра и выводы администратора не правильны (вероятность ошибки большая).
По поводу общей производительности (память, ЦПУ, диск) - много можно сказать, тем более что мы этим активно занимаемся - softpoint.ru. Не совсем по теме статьи. Если будут вопросы, пишите в личку.
(6) Мы активно участвовали в обсуждении темы автора, есть с чем согласны - есть то, с чем не согласны.
Жду дальнейших вопросов
Здравствуйте, с праздниками! :-) Ваш совет устанавливать насколько возможно более производительное серверное оборудование без споров принимаем, но думаем что при 300 пользователях узким местом в этой связке является не сетевой интерфейс, а количество и качество оперативной памяти SQL-сервера (процессор нагружен) и почему-то рейд-массив сервера 1С8 (процессор сервера 1С8 не нагружен, но смотрим на растущий объем памяти и дампы под процессы rphost). Ничем другим кроме процессов сервера 1С8 и процессов клиентов 1С8 жесткие диски сервера 1С8 не заняты, однако часто выходят из строя. Подскажите пожалуйста, как это обосновать, вероятно жесткие диски "летят" потому, что сервер 1С8 ввиду низкой загрузки процессора со стороны ПО сервера и клиентов 1С гоняет слишком много темпов?
Насколько я понял, Вы намекаете, что сетевое оборудование разных производителей и разных моделей, на физическом уровне с разной скоростью реагирует на команду системы по формированию пакета для передачи в сеть?
А вывод? Быть может производители указывают в характеристике продукции параметр на который следует обратить внимание при покупке, кроме скорости поддерживаемой сети?
А вывод? Быть может производители указывают в характеристике продукции параметр на который следует обратить внимание при покупке, кроме скорости поддерживаемой сети?
(7)
"... недостаточно памяти. То есть отдельный сервер 1С все же нужен"(с)
Сергей (ksnik).
Архитектура NUMA и есть 2, 4, 8 "отдельных" серверов в одной "коробке".
С самым быстрым интерфейсом между этими "серверами" - оперативная память.
С возможностью поставить суммарный большой объем оперативной памяти (с учетом лимита объема памяти на один узел).
С возможностью отдать/управлять всем объемом памяти "коробки" ;-) на конкретную задачу, который (объем) Вы никогда не сможете обеспечить на обычной архитектуре.
"... недостаточно памяти. То есть отдельный сервер 1С все же нужен"(с)
Сергей (ksnik).
Архитектура NUMA и есть 2, 4, 8 "отдельных" серверов в одной "коробке".
С самым быстрым интерфейсом между этими "серверами" - оперативная память.
С возможностью поставить суммарный большой объем оперативной памяти (с учетом лимита объема памяти на один узел).
С возможностью отдать/управлять всем объемом памяти "коробки" ;-) на конкретную задачу, который (объем) Вы никогда не сможете обеспечить на обычной архитектуре.
(8) hogik, почитал про когерентность кэш-памяти бо оперативка просто-напросто надолго забивается при обработки наборов данных запросов, но кажется что не очень подходит для борьбы с нехваткой памяти, кажется нужно делать как можно мощней проц и больше памяти MSSQL, на сервере 1С работать над утечкой памяти и неизвестно чем еще, неизвестно как выбирать железо в связке"оперативка-рейд" чтоб не ломалось.
Интересная информация у QLogic: "Introduction to Ethernet Latency"
Latency
Range (μs)
Technology Applications
50 – 125 μs
1gb ethernet (TcP/iP) • Multi-tasking: multiple
high-bandwidth applications
running simultaneously
• Bulk data transfer
• Transactional database
backup and applications
• Web (front-end for
data centers)
5 – 50 μs 10gb ethernet
(TcP/iP)
• Bulk data transfer
• real-time video streaming
• Database backup and
applications
3 – 5 μs rDMA, rocee, and
iWArP
• high Performance computing
• high-frequency Trading (hfT)
• inter-process communication
(iPc) cluster
• low-latency applications
Sub-3 μs infiniBand (QDr) and
proprietary
• high Performance computing
• high frequency Trading (hfT)
• Ultra-low latency applications
А в спецификациях на картах Ethernet не пишут Latency (отклик).
Latency
Range (μs)
Technology Applications
50 – 125 μs
1gb ethernet (TcP/iP) • Multi-tasking: multiple
high-bandwidth applications
running simultaneously
• Bulk data transfer
• Transactional database
backup and applications
• Web (front-end for
data centers)
5 – 50 μs 10gb ethernet
(TcP/iP)
• Bulk data transfer
• real-time video streaming
• Database backup and
applications
3 – 5 μs rDMA, rocee, and
iWArP
• high Performance computing
• high-frequency Trading (hfT)
• inter-process communication
(iPc) cluster
• low-latency applications
Sub-3 μs infiniBand (QDr) and
proprietary
• high Performance computing
• high frequency Trading (hfT)
• Ultra-low latency applications
А в спецификациях на картах Ethernet не пишут Latency (отклик).
Статья конечно интересная, но сервер - это не только сетевая карта и провода. На скорость работы оного поболе влияют ЖД и память (из личного опыта), причем не обязательно увеличение последней, на третье место поставлю процессор. Да еще Винда сама по себе со временем начинае притормаживать, если не проводить определенных манипуляций, так уж она запрограммирована своими создателями, от этого никуда!
(17) AVMCo,
Если статья интересная, где "+"))
А если серьезно, я бы не использовал слово " поболе влияют ЖД и память (из личного опыта)", а заменил бы на чаще. Но, учитывая тот факт, что сам занимаюсь проблемами производительности, могу казать так - проблемы сети не всегда так очевидны, и их понимание в контексте учетных систем главная задача статьи.
(18) мне ситуация напоминает анекдот (без обид):
"Вовочкана биологии пишет лаб. работу.
1. Оторвал таракану лапку, говорю: "Беги!" Бегит
2. Оторвал таракану вторую лапку, говорю: "Беги!" Бегит
3. Оторвал таракану все лапки, говорю: "Беги!" Не бегит
ВЫВОД: Таракан без ног не слышит!"
(19) К основной цели статьи ваше пояснение мало относится: имеется в виду некая операция (отчет частный случай) учетной системы, которая отправляет достаточно большое количество запросов к серверу БД. "Отчет" - использовался, так как часто приходится сталкиваться с большим количеством запросов именно в отчетах))
p.S> Программа для замеров сети у пользователей скоро будет выложена.
Если статья интересная, где "+"))
А если серьезно, я бы не использовал слово " поболе влияют ЖД и память (из личного опыта)", а заменил бы на чаще. Но, учитывая тот факт, что сам занимаюсь проблемами производительности, могу казать так - проблемы сети не всегда так очевидны, и их понимание в контексте учетных систем главная задача статьи.
(18) мне ситуация напоминает анекдот (без обид):
"Вовочкана биологии пишет лаб. работу.
1. Оторвал таракану лапку, говорю: "Беги!" Бегит
2. Оторвал таракану вторую лапку, говорю: "Беги!" Бегит
3. Оторвал таракану все лапки, говорю: "Беги!" Не бегит
ВЫВОД: Таракан без ног не слышит!"
(19) К основной цели статьи ваше пояснение мало относится: имеется в виду некая операция (отчет частный случай) учетной системы, которая отправляет достаточно большое количество запросов к серверу БД. "Отчет" - использовался, так как часто приходится сталкиваться с большим количеством запросов именно в отчетах))
p.S> Программа для замеров сети у пользователей скоро будет выложена.
интересно, что значит "в высоконагруженной системе большое количество пользователей формируют отчеты"???? - как то странно звучит - для этого есть другие решения: тех же кубов или программные - правильно написать этот отчет, что бы он исполнялся на сервере - отговорки используют стандартные для "высоконагруженной системы" - это моветон.... или некомпетенция.
Гигабит...Это уже 125 Мб/с, ну, ладно, 100...Скорость, которой должно с лихвой хватать для работы 1-2-3 пользователей(да и харды в режиме случайного чтения ненамного быстрее выдают)...А, как правило, замедление существенное при работе от сети.Толстого клиента точно, серверный вариант, наверно, тоже...Сеть настроить не всегда доступно, поэтому файловые базы жму ТИИСом, начинают шевелиться побыстрее...
Выложили приложение для замеров отклика сети.
Можно проверить на реальном оборудовании (лучше в нерабочее время))
Жду от Вас вопросов, готов оперативно ответить.
Обратите внимание на деградацию параметра: количество запросов в единицу времени для одной сессии.
Можно проверить на реальном оборудовании (лучше в нерабочее время))
Жду от Вас вопросов, готов оперативно ответить.
Обратите внимание на деградацию параметра: количество запросов в единицу времени для одной сессии.
у нас на предприятии между сервером 1с и СУБД был канальчик в 1ГБ/с
одновременно работали ~20 пользователей
на сервере крутили стандартные БП, ЗУП и +"специальная разработка" для предприятия на базе 1С8
по мере увеличения нагрузки на эту "специальную" разработку, от пользователей начали поступать жалобы на медленную отзывчивость и вскоре ошибки с таймаутами (!!!)
временное решение нашлось путем внедрения нового коммутатора с функцией LinkAgregation
и объединением 2х каналов по 1ГБ/с в один на 2ГБ/с на обоих серверах
в тот момент я тоже уверовал в прямую зависимость скорости работы сервер1с-сервер СУБД от скорости сет.интерфейсов
одновременно работали ~20 пользователей
на сервере крутили стандартные БП, ЗУП и +"специальная разработка" для предприятия на базе 1С8
по мере увеличения нагрузки на эту "специальную" разработку, от пользователей начали поступать жалобы на медленную отзывчивость и вскоре ошибки с таймаутами (!!!)
временное решение нашлось путем внедрения нового коммутатора с функцией LinkAgregation
и объединением 2х каналов по 1ГБ/с в один на 2ГБ/с на обоих серверах
в тот момент я тоже уверовал в прямую зависимость скорости работы сервер1с-сервер СУБД от скорости сет.интерфейсов
Обработка любопытная, хотя видно что "рабочий инструмент" - не все работает как нужно.
Но главное - информацию для анализа дает. Одно неудобно - требуется установка. Для серверов - не везде можно поставить, да и не всегда хочется ставить. Что-нибудь "портабельное" возможно?
Но главное - информацию для анализа дает. Одно неудобно - требуется установка. Для серверов - не везде можно поставить, да и не всегда хочется ставить. Что-нибудь "портабельное" возможно?
(26) aspirator23,
Спасибо за отклик.
"Не все работает как нужно" - можете конкретно указать, чтобы можно было доработать.
По поводу "портабельности" - установка программы требуется для удобства, если нет возможности на сервере сделать установку, можно установить программу на любом компьютере, далее каталог установки копировать на сервер, открывать с шары... Или я не так вас понял?
Спасибо за отклик.
"Не все работает как нужно" - можете конкретно указать, чтобы можно было доработать.
По поводу "портабельности" - установка программы требуется для удобства, если нет возможности на сервере сделать установку, можно установить программу на любом компьютере, далее каталог установки копировать на сервер, открывать с шары... Или я не так вас понял?
(27) Спасибо, все заработало. Вопросы снимаются: если "повертеть, покрутить" - все становится понятным.
Если на SQl работает одна БД, то сервер приложений 1с, размещенный на другом сервере, открывает одну сессию?
Следовательно деградации скорости сетевого соединения характерна для случая когда к одному SQl обращаются с нескольких серверов приложений 1с?
Если на SQl работает одна БД, то сервер приложений 1с, размещенный на другом сервере, открывает одну сессию?
Следовательно деградации скорости сетевого соединения характерна для случая когда к одному SQl обращаются с нескольких серверов приложений 1с?
(28) aspirator23,
количество соединений с MS SQL не связано с количеством серверов приложений 1С или рабочих процессов.
Оно связано с необходимостью в зависимости от количества одновременно работающих пользователей.
Деградация характерна для случаев, когда есть много пользователей (скажем более 5 пользователей) выполняют операции 1С с большим количеством небольших запросов к серверу MS SQL. В качестве примера можно привести Инталев 1С, учитывая ее архитектуру, для выполнения отчета может понадобится более 50000 запросов к MS SQL, получается что скорость сети имеет в этом случае очень большое значение и ее деградация при многопользовательской работе сказывается на длительности этих отчетов и всех операций.
количество соединений с MS SQL не связано с количеством серверов приложений 1С или рабочих процессов.
Оно связано с необходимостью в зависимости от количества одновременно работающих пользователей.
Деградация характерна для случаев, когда есть много пользователей (скажем более 5 пользователей) выполняют операции 1С с большим количеством небольших запросов к серверу MS SQL. В качестве примера можно привести Инталев 1С, учитывая ее архитектуру, для выполнения отчета может понадобится более 50000 запросов к MS SQL, получается что скорость сети имеет в этом случае очень большое значение и ее деградация при многопользовательской работе сказывается на длительности этих отчетов и всех операций.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|