Как определить скорость сети до сервера 1С ? #437738

Есть подозрение, что админ домена что-то намудрил, т.к. 1С у всех (примерно 50 юзеров) стала работать почти в 2 раза медленнее. например делаю с клиентского компа запрос такой ping -l 65000 ИмяСервера1С выдает время доступа = 11 мс это много или нормально ? и как еще проверить можно ??? спасибо

а сколько шлюзов до сервера? tracert сколько компов показывает? --- не админ, но имхо все что больше 5 мс - зло

по моему на полном пакете 11 мс очень хорошо

ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56 bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=128 time=0.185 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=128 time=0.208 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=128 time=0.289 ms

если это скуль, то счетчик нетворкио можно вот этим затестить

нормально для 100 ты на размер пакета глянь ...

либо жОско тупит сервак, либо флуд по сетке идет

а, ну тогда ping -s65000 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 65000(65028) bytes of data. 65008 bytes from 192.168.0.1: icmp_seq=1 ttl=128 time=1.59 ms 65008 bytes from 192.168.0.1: icmp_seq=2 ttl=128 time=1.64 ms 65008 bytes from 192.168.0.1: icmp_seq=3 ttl=128 time=1.56 ms 65008 bytes from 192.168.0.1: icmp_seq=4 ttl=128 time=1.69 ms

а я не знаю что это такое ))) проверил на своих - 1 мс

правда гигабитка

по дефолту пакет всего 32 байт ...

что есть «по дефолту»? написано же - 56 байт данных (84 всего)

параметр -l задает размер дайтограммы ... по дефолту он равен всего 32 байтам ... здесь протаскивают 65000 байт

=>

еще 1 промежуточный со всех клиентских компов гигабитка ?

да и внимательнее читай

Ключ –l задает размер дейтаграммы без учета длины заголовка (28 байт), посылаемой в эхо-запросе. Допустимыми являются значения от 0 до 65.500, включительно. По умолчанию размер дейтаграммы составляет 32 байта. Манипулируя этим значением, можно выяснить зависимость: скорость доставки – размер дейтаграммы. Если размер дейтаграммы превысит некоторую критическую величину (определяемую каждым промежуточным узлом самостоятельно), дейтаграмма разрезается на несколько пакетов подходящего размера, каждый из которых добирается до конечной точки маршрута самостоятельно, а на узле назначения они вновь собираются в исходную дейтаграмму.

и чО?       -s packetsize              Specifies the number of data bytes to be sent.  The default is 56, which translates into 64 ICMP data bytes when combined with              the 8 bytes of ICMP header data.

все равно 1,5мс при 65028 байт

не, тока на моем и между серваками )

аааа! вот жук! а с обычного клиента не глянешь ?

внематочно прочитай ... в стандартной винде и стандартном пинге параметр -s отвечает за другое -l size        Send buffer size. -s count       Timestamp for count hops (IPv4-only). поэтому при ping -s65000 получаем Value must be supplied for option -s65000.

ping -s 6500 Bad value for option -s, valid range is from 1 to 4.

а кто тебе сказал, что у меня стандартная винда? я с линуксового хоста до скуль-сервера, на котором базы 1сные крутятся пинганул, у меня через 2 свича - за 1,5мс пролетает 65000 байт туда-сюда. значит, у - либо с реакцией сервера, либо с временем прохода пакета по сети уже есть проблема.

на время прохождения пакета влияет толщина канала и размер пакета... для канала толщиной в сотку пакет размером 65000 это допустимо...

А у нас стандартная win server 2003 64 бит SP2 сетка 100 мегабит

при этом надо учитывать, что на все узлы связаны каналами с одной пропуской способностью ... а то был случчай, когда клиентам воткнули гигибитку... а свичии, из-за лени, оставли связаными соткой... и потом репу чесали почему скорость не выросла

Pinging head.bps.com [192.168.1.3] with 32 bytes of data: Reply from 192.168.1.3: bytes=32 time<1ms TTL=128 Reply from 192.168.1.3: bytes=32 time<1ms TTL=128 Reply from 192.168.1.3: bytes=32 time<1ms TTL=128 Reply from 192.168.1.3: bytes=32 time<1ms TTL=128 ----- Pinging head.bps.com [192.168.1.3] with 65000 bytes of data: Reply from 192.168.1.3: bytes=65000 time=12ms TTL=128 Reply from 192.168.1.3: bytes=65000 time=12ms TTL=128 Reply from 192.168.1.3: bytes=65000 time=12ms TTL=128 Reply from 192.168.1.3: bytes=65000 time=12ms TTL=128

значит проблема не в сети... а скорее всего на сервере

т.е. 11-12 мс - это номально ?

счас найду 100мбитку по удаленным сетям, гляну

+ так навскидку - нигде нету уже

процессор сервера приложений 1С загружен не более чем на 6-10% SQL так же 6-10%

дисковая?

зачем в терминале гигабит? у вас сотни компов?

а что и где посмотреть ?

нормально

у меня такой пакет проходит за 2ms, дефолтный - >1ms, правда на гигабите :)

монитор производительности, добавляем счетчик "средняя длина очереди диска", можно добавить "на запись", "на чтение" и цифры сюда (под нагрузкой, конечно)

Прочел "Как определить скорость СВЕТА до сервера 1С ?"

+38 ну и чисто из вежливости: конфиг обоих серверов, есть ли raid (тогда какой), объем баз(ы), число юзеров...

:))

как и все это делают: 1. пишешь в "Выполнить": net send server hello world! 2. одновременно нажимаешь на кнопку секундомера и Enter на клавиатуре 3. Ломишься к северу 4. Как у видишь окошко "hello world!" останавливаешь секундомер

ps: сервис службы сообщений должен быть включен, а то я так неделю стоял у сервера с екундомером

сервера НР 1C: 2.6 Ггц, 2 процессорный (по 4 ядра) память 4 Гб .....RAID есть, но какой не могу точно сказать SQL: 3 Ггц, 2 процессорный (по 2 ядра) память 18 Гб число юзеров (ок 60 чел) в серверах ничего не менялось!!

отличный вариант :))) напомнило из реальности: вызывают, просят разобраться с печатью документов (принтер обычный, без дуплекса, примитивный струйник) показывают проблему: - смотрите, вот я посылаю два листа, принтер печатает один (в этот момент подырвается из-за стола и бежит к принтеру) - видите? я еле успеваю добежать, а мне еще лист перевернуть надо! - зачем? - так мне на обеих сторонах надо напечатать, а я не успеваю перевернуть!!! - <немая сцена> через неделю буха уволили. просто она и учет так же вела. своеобразно т.е. вот raid какой - интересно таки, ну и дисковую очередь померяй - увидим, что там у вас. кстати, а размер лога транзакций не является слишком большим? а то подобное уже было, люди дорастили (при живом штатном админе) лог до 20 гиг (база - 3) и жаловались на тормоза потом :)

т.е. это не юмор? звиздец...

3 боевые базы: Основная 38 Гб (лог 37 Гб) 2я - 3 Гб (лог 0.5 Гб) 3я - 3 Гб (лог 0.7 Гб) Базы на логическом диске Д, логи на Е

Почему-то тему ветки прочёл как "Как определить скорость света до сервера 1С "... Хм...

ну база основная немаленькая... давай мерять диски перфмоном, пока думаю на них. сразу ошибки: если логический диск - виндовый - это смысла не имеет, а вот если LUN - т.е. логический диск, созднный средствами аппаратного raid-контроллера - тогда другое дело. т.е. разбивка д.б. на уровне контроллера, не винды. давай показания и мы все увидим, вслепую не получится

скачай iperf