Comments 23
Можно предположить, что если перейти на оптику, то производительность еще немного увеличится, так как интерфейсы 10GBASE-SR имеют меньшие задержки, чем 10GBASE-T
Соглашусь с вами. Но оптика - это уже оборудование другого уровня.
Ну, на практике мне обнаружить разницу не удалось. Пару лет назад устанавливал новый сервер в том числе под 1С. Был ворох сетевух на 10G, попробовал поиграться. Вставлял модули под оптику, соединял через DAC, ну и сравнивал с простыми 10GBASE-T.
Пытался мерить latency, смотрел отклик ФС по iscsi, результаты тестирования iperf, пробовал и postgres гонять.
Сколь либо значимых отличий не обнаружил. Правда, везде использовал стоковые настройки linux ядра. Может быть после какого-то тюнинга сетевого стека и удалось бы выжать больше из оптики, но я понял что в рамках соседних стоек мне все равно какой тип подключения использовать.
2500 запросов/сек - это ~400 мкс на запрос. Реальное время отклика гигабитных сетей - десятки микросекунд максимум, то есть на порядок быстрее. Допускаю, что снижение этого показателя может говорить о проблемах с сетью, но если там в идеальном раскладе 10% именно отклика сети и 90% чего-то еще - это прямо очень грубая оценка.
В тексте есть ссылка на утилиту. Можете свою написать. Если получите результаты больше 3к з/с для 1-гигабитного интерфейса в одной сессии, то присылайте результаты, будет любопытно посмотреть.
Утилиты для измерения латентности сети и без меня давно написаны. :) И выдают, конечно же, гораздо лучшие показатели, я ведь вам не с потолка цифры называю. У вас же в измерение входят как минимум:
Отправка запроса на сервер SQL
Исполнение запроса
Отправка ответа клиенту
При этом при запросе в 500 символов вы даже в один стандартный фрейм не уложитесь, то есть измеряете на самом деле некий гибрид латентности и пропускной способности сети плюс время отклика собственно сервера SQL. Применять к этом название "отклик сетевого интерфейса" попросту некорректно с точки зрения того, что происходит на самом деле.
То есть если взять сетевую карточку с отрицательной задержкой хотя бы в 350мкс, то в итоге получится околонулевое время отклика в комплексном тестировании. То что нужно для 1С!
Вот так всегда, на самом интересном месте (ц)
Чего делать-то? Ну кроме "поменяйте драйвера, покрутите настройки"
Причин может быть много, но у вас есть инструмент (скачивайте, пользуйтесь на здоровье), который объективно вам покажет, что из точки А в точку Б запросы ходят так себе. Т.е. вы/администратор можете после каждой итерации по настройкам, драйверам и т.д. проводить замеры и понимать, в правильном ли направлении идет движение.
Встроенные Realtek на серверах под видеонаблюдение крайне плохо себя зарекомендовали, через продолжительное время трафик начинает идти с задержками и потерями, как будто переполняется какой-то буфер. Ситуацию спасает любая другая сетевая, например Intel, LR-Link
А что на счет тюнинга настроек сетевух? LRO? GRO? БуферА?
Есть ли толк от увеличения MTU (jumbo frame)?
Как минимизировать негативное влияние высокого RTT на производительность работы с БД?
Увеличение mtu уменьшает количество пакетов и естественно уменьшает задержки)
Но выше уже верно написали, что сеть станет узким местом только если время выполнения запроса в скуле будет стремиться к нулю :)
Или как вариант сервер 1с находится вообще в другом датацентре в другом регионе. Тогда задержки можно будет хоть как-то ощутить. И тут уже переходом с 1Г на 10Г не обойтись всё равно)
Увеличение mtu уменьшает количество пакетов и естественно уменьшает задержки)
Для какого типа трафика? Вооот!
Тогда задержки можно будет хоть как-то ощутить. И тут уже переходом с 1Г на 10Г не обойтись всё равно)
Задержка не станет меньше ни на 10Г, ни на 100Г.
Если у вас типичный объем данных, которым обмениваются клиент и сервер, больше сетевого пакета (что в целом верно в случае 1С), то увеличение размера пакета даст какой-то выигрыш за счет уменьшения накладных расходов на формирование оных, но скорее всего мизерный.
Задержка не станет меньше ни на 10Г, ни на 100Г.
Смотря что считать "задержкой". Если именно латентность сети - станет, но на фоне остальных затрат это уменьшение будет практически не заметно. А если "задержкой" считать время отклика сервера приложения (собственно, это и меряют авторы) - вот там уже может быть существенная разница, т.к. объем данных в сессии обмена трафиком обычно составляет более одного пакета и тут начинает играть не только собственно латентность сети, но и ее пропускная способность.
Почему вы решили, что ваш тест замеряет отклик сети? Такой тест может замерять что угодно - пропускную способность кэша, скорость парсера sql сервера и т.д и т.п. При выполнении запросов столько всего происходит, почему решили, что уперлись именно в сетку?
Странно что не меряли задержку по Ping . Я имею ввиду точную которая меньше 1мс
это можно сделать утилитами типа hrping .
В целом согласен что задержка в сети сильно влияет на производительность 1С ,
больше 10 лет назад статью написал на эту тему. С полным раскладом
https://selis76.narod.ru/matnetw1.html
навигация слева, выводы тут https://selis76.narod.ru/matnetw3.html
Если кратко для сегодняшнего дня
померяйте задержку между серверами которые воткнуты в один хаб для пакета 512 байт она не должна сильно отличаться от соединением кросскабелем
Путем ликвидации узких мест в сети (и сетевых интерфейсах) доведите задержку до показателя в пункте 1)
Для 1 гигабита используйте 4 х портовые карты с teamed lan c балансировкой.
В кластере 1с+субд (в серверной) перейдите на 10 гигабит, только учтите что сервер должен быть достаточно производительным чтобы не стать узким местом. 10 гб это сейчас не так дорого
При тестировании в одинаковых условиях, на тех же сервеоах, почему при последовательной замене карт с 1G на 2,5G и на 10G контрольные показатели возросли не пропорционально? Это такая плохая 10G или такая хорошая 1G карты?
Или все же методика тестирования неадекватна?
Методика вполне разумная, только показывает не то, что заявляют авторы. А "пропорционально" показатели не растут, потому что результат измерений от пропускной способности сети хотя и зависит, но достаточно слабо.
У автора статьи методика тестирования синтетическая и только на запросах. Низкая задержка в сети это только часть времени которая замедляет производительность. Ещё ресурсы тратятся на проц и диск .
Поэтому линейного роста быть не может.
Просто когда сетевой канал загружается на 50проц у вас уже пойдет нелинейная деградация. Причем в 1 Гб больше чем в 10гб
Записки оптимизатора 1С (часть 9). Влияние сетевых интерфейсов на производительность высоконагруженных ИТ-систем