The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Не заволняются полностью каналы, !*! pilygrim, 15-Ноя-12, 18:08  [смотреть все]
Между двумя роутерами (2811 и 1841) настроены VTI IPSEC - туннели по которым бегает EIGRP.
Всего на роутеры заведено 3 канала по 10М из которых 2 делаю активных (посредством maximum-path 2), также включен cef (ip cef), и на туннельных интерфейсах указан ip load-sharing per-packet.
Всё работает с первого взгядя нормально. Туннели подняты, маршрутизация работает, балансировка работает. Начинаю проверять под нагрузкой. Поставил 2 тачки с центосью по разным сторонам роутеров, поднял на них httpd и стал гонять трафик по http wget'ом. Загрузка 16Mbps и затыкается проц, ну думаю ладно, во всяком случае это объяснимо, далее ставлю с одной стороны виндовую тачку и пытаюсь качнуть тот же файл IE, и получаю скорость в разы меньше при небольшой загрузке процов на роутерах, по CIFS ситуация аналогичная. Причём когда ставлю параллельно несколько закачек, то суммарная скорость растёт и опять упирается в производительность процов на роутерах. Подумал, что это за счёт ограничения количества одновременно открытых TCP-сессий в винде, поменял с 10 (по умолчанию) на 100, ситуация улучшилась, но не сильно. Не могу понять, как решить проблемму... Помогите плиз вариантами...
  • Не заволняются полностью каналы, !*! fantom, 18:39 , 15-Ноя-12 (1)
    >[оверквотинг удален]
    > разным сторонам роутеров, поднял на них httpd и стал гонять трафик
    > по http wget'ом. Загрузка 16Mbps и затыкается проц, ну думаю ладно,
    > во всяком случае это объяснимо, далее ставлю с одной стороны виндовую
    > тачку и пытаюсь качнуть тот же файл IE, и получаю скорость
    > в разы меньше при небольшой загрузке процов на роутерах, по CIFS
    > ситуация аналогичная. Причём когда ставлю параллельно несколько закачек, то суммарная
    > скорость растёт и опять упирается в производительность процов на роутерах. Подумал,
    > что это за счёт ограничения количества одновременно открытых TCP-сессий в винде,
    > поменял с 10 (по умолчанию) на 100, ситуация улучшилась, но не
    > сильно. Не могу понять, как решить проблемму... Помогите плиз вариантами...

    Винду выкинуть???

    • Не заволняются полностью каналы, !*! pilygrim, 18:58 , 15-Ноя-12 (2)
      >[оверквотинг удален]
      >> по http wget'ом. Загрузка 16Mbps и затыкается проц, ну думаю ладно,
      >> во всяком случае это объяснимо, далее ставлю с одной стороны виндовую
      >> тачку и пытаюсь качнуть тот же файл IE, и получаю скорость
      >> в разы меньше при небольшой загрузке процов на роутерах, по CIFS
      >> ситуация аналогичная. Причём когда ставлю параллельно несколько закачек, то суммарная
      >> скорость растёт и опять упирается в производительность процов на роутерах. Подумал,
      >> что это за счёт ограничения количества одновременно открытых TCP-сессий в винде,
      >> поменял с 10 (по умолчанию) на 100, ситуация улучшилась, но не
      >> сильно. Не могу понять, как решить проблемму... Помогите плиз вариантами...
      > Винду выкинуть???

      Ну это совсем не серьёзно...

      • Не заволняются полностью каналы, !*! McS555, 19:26 , 15-Ноя-12 (3)
        >[оверквотинг удален]
        >>> во всяком случае это объяснимо, далее ставлю с одной стороны виндовую
        >>> тачку и пытаюсь качнуть тот же файл IE, и получаю скорость
        >>> в разы меньше при небольшой загрузке процов на роутерах, по CIFS
        >>> ситуация аналогичная. Причём когда ставлю параллельно несколько закачек, то суммарная
        >>> скорость растёт и опять упирается в производительность процов на роутерах. Подумал,
        >>> что это за счёт ограничения количества одновременно открытых TCP-сессий в винде,
        >>> поменял с 10 (по умолчанию) на 100, ситуация улучшилась, но не
        >>> сильно. Не могу понять, как решить проблемму... Помогите плиз вариантами...
        >> Винду выкинуть???
        > Ну это совсем не серьёзно...

        Я правильно понимаю, скорость нормальная когда проверяешь на unix, а проверяешь с виндой маленькая?

        • Не заволняются полностью каналы, !*! pilygrim, 19:41 , 15-Ноя-12 (4)
          >[оверквотинг удален]
          >>>> в разы меньше при небольшой загрузке процов на роутерах, по CIFS
          >>>> ситуация аналогичная. Причём когда ставлю параллельно несколько закачек, то суммарная
          >>>> скорость растёт и опять упирается в производительность процов на роутерах. Подумал,
          >>>> что это за счёт ограничения количества одновременно открытых TCP-сессий в винде,
          >>>> поменял с 10 (по умолчанию) на 100, ситуация улучшилась, но не
          >>>> сильно. Не могу понять, как решить проблемму... Помогите плиз вариантами...
          >>> Винду выкинуть???
          >> Ну это совсем не серьёзно...
          > Я правильно понимаю, скорость нормальная когда проверяешь на unix, а проверяешь с
          > виндой маленькая?

          Не совсем, в несколько потоков (TCP-сессий) я скорость и на винде получаю нормальную, проблема только в том, что я так понимаю, при копировании файлов проводником по CIFS используется одна TCP - сессия на процесс, и вот эта сессия не может выжать максимум... Как только я запускаю несколько потоков/сессий всё получается более-менее нормально, но очень хотелось-бы, чтобы качало и один файл с максимальной скоростью. Перед этим пробовал GRE-туннели с 3DES шифрованием и тюнингом ip mtu 1400 + ip tcp adjust-mss 1360, чтобы избавиться от фрагментации TCP-сегментов, но делу это ровным счётом не помогло.

          • Не заволняются полностью каналы, !*! McS555, 01:15 , 17-Ноя-12 (10)
            >[оверквотинг удален]
            >> виндой маленькая?
            > Не совсем, в несколько потоков (TCP-сессий) я скорость и на винде получаю
            > нормальную, проблема только в том, что я так понимаю, при копировании
            > файлов проводником по CIFS используется одна TCP - сессия на процесс,
            > и вот эта сессия не может выжать максимум... Как только я
            > запускаю несколько потоков/сессий всё получается более-менее нормально, но очень хотелось-бы,
            > чтобы качало и один файл с максимальной скоростью. Перед этим пробовал
            > GRE-туннели с 3DES шифрованием и тюнингом ip mtu 1400 + ip
            > tcp adjust-mss 1360, чтобы избавиться от фрагментации TCP-сегментов, но делу это
            > ровным счётом не помогло.

            Хотя должно и так все работать нормально(у большинства же нормально пашет), но ради интереса, в виндовом регистре уменьши mtu

  • Не заволняются полностью каналы, !*! старый сантехник, 19:47 , 15-Ноя-12 (5)
    Я бы проверил 2 вещи на винде:

    отключение path mtu discovery, по умолчанию включено, не знаю, конечно, как у вас
    отключение или иные игры с параметром, отвечающим за это :) tcp delayed ack

    • Не заволняются полностью каналы, !*! fantom, 11:37 , 16-Ноя-12 (6)
      > Я бы проверил 2 вещи на винде:
      > отключение path mtu discovery, по умолчанию включено, не знаю, конечно, как у
      > вас
      > отключение или иные игры с параметром, отвечающим за это :) tcp delayed
      > ack

      Попробуйте на винду но по ftp например слить, думаю скорее всего там грабли не непосредственно в tcp, а в именно в виндовом протоколе поверх tcp.

      Еще можно снифером посмотреть как идет процесс передачи... если удасться выщемить моменты типа изменения окна в 0 и потом обратно в нормальное значение - то скорее всего это вообще врядли тюнингуется...

      • Не заволняются полностью каналы, !*! pilygrim, 12:44 , 16-Ноя-12 (7)
        >[оверквотинг удален]
        >> отключение path mtu discovery, по умолчанию включено, не знаю, конечно, как у
        >> вас
        >> отключение или иные игры с параметром, отвечающим за это :) tcp delayed
        >> ack
        > Попробуйте на винду но по ftp например слить, думаю скорее всего там
        > грабли не непосредственно в tcp, а в именно в виндовом протоколе
        > поверх tcp.
        > Еще можно снифером посмотреть как идет процесс передачи... если удасться выщемить моменты
        > типа изменения окна в 0 и потом обратно в нормальное значение
        > - то скорее всего это вообще врядли тюнингуется...

        Поставил на винду wget и попробовал покачать файлик по http - скорость сразу возросла до максимально возможной. Т.е. грабли не в виндовом tcp. Также поставил на линух самба-клиента и попробовал по самбе прокачать файлик. Скорость как и на винде низкая... Хрень в общем какая-то. Поставил wireshark чтобы посмотреть tcpstream, но то-ли я чего-то не понимаю, но ничего подозрительного пока не заметил...

        • Не заволняются полностью каналы, !*! pilygrim, 15:38 , 16-Ноя-12 (8)
          >[оверквотинг удален]
          >> поверх tcp.
          >> Еще можно снифером посмотреть как идет процесс передачи... если удасться выщемить моменты
          >> типа изменения окна в 0 и потом обратно в нормальное значение
          >> - то скорее всего это вообще врядли тюнингуется...
          > Поставил на винду wget и попробовал покачать файлик по http - скорость
          > сразу возросла до максимально возможной. Т.е. грабли не в виндовом tcp.
          > Также поставил на линух самба-клиента и попробовал по самбе прокачать файлик.
          > Скорость как и на винде низкая... Хрень в общем какая-то. Поставил
          > wireshark чтобы посмотреть tcpstream, но то-ли я чего-то не понимаю, но
          > ничего подозрительного пока не заметил...

          В общем при анализе TCPStream увидел очень много TCP Retransmision и TCP DupACK
          Проблемма аналогичная http://blogs.technet.com/b/networking/archive/2011/05/16/tcp...

          Но пока не решил...

          В догонку на циске тоже было обсуждение: https://supportforums.cisco.com/thread/201894

          • Не заволняются полностью каналы, !*! fantom, 16:22 , 16-Ноя-12 (9)
            >[оверквотинг удален]
            >> сразу возросла до максимально возможной. Т.е. грабли не в виндовом tcp.
            >> Также поставил на линух самба-клиента и попробовал по самбе прокачать файлик.
            >> Скорость как и на винде низкая... Хрень в общем какая-то. Поставил
            >> wireshark чтобы посмотреть tcpstream, но то-ли я чего-то не понимаю, но
            >> ничего подозрительного пока не заметил...
            > В общем при анализе TCPStream увидел очень много TCP Retransmision и TCP
            > DupACK
            > Проблемма аналогичная http://blogs.technet.com/b/networking/archive/2011/05/16/tcp...
            > Но пока не решил...
            > В догонку на циске тоже было обсуждение: https://supportforums.cisco.com/thread/201894

            Следующий этап - прогнать с линуха на линух по самбе :)
            и если там все будет нормально - таки есть плешь микрософту....

            • Не заволняются полностью каналы, !*! pilygrim, 12:15 , 19-Ноя-12 (11)
              >[оверквотинг удален]
              >>> Скорость как и на винде низкая... Хрень в общем какая-то. Поставил
              >>> wireshark чтобы посмотреть tcpstream, но то-ли я чего-то не понимаю, но
              >>> ничего подозрительного пока не заметил...
              >> В общем при анализе TCPStream увидел очень много TCP Retransmision и TCP
              >> DupACK
              >> Проблемма аналогичная http://blogs.technet.com/b/networking/archive/2011/05/16/tcp...
              >> Но пока не решил...
              >> В догонку на циске тоже было обсуждение: https://supportforums.cisco.com/thread/201894
              > Следующий этап - прогнать с линуха на линух по самбе :)
              > и если там все будет нормально - таки есть плешь микрософту....

              С линуха на линух по самбе тоже самое (низкая скорость)

              • Не заволняются полностью каналы, !*! fantom, 12:28 , 19-Ноя-12 (12)
                >[оверквотинг удален]
                >>>> wireshark чтобы посмотреть tcpstream, но то-ли я чего-то не понимаю, но
                >>>> ничего подозрительного пока не заметил...
                >>> В общем при анализе TCPStream увидел очень много TCP Retransmision и TCP
                >>> DupACK
                >>> Проблемма аналогичная http://blogs.technet.com/b/networking/archive/2011/05/16/tcp...
                >>> Но пока не решил...
                >>> В догонку на циске тоже было обсуждение: https://supportforums.cisco.com/thread/201894
                >> Следующий этап - прогнать с линуха на линух по самбе :)
                >> и если там все будет нормально - таки есть плешь микрософту....
                > С линуха на линух по самбе тоже самое (низкая скорость)

                Тада можно списать на архитектурные недостатки самого протокола....

                • Не заволняются полностью каналы, !*! pilygrim, 15:33 , 19-Ноя-12 (13)
                  >[оверквотинг удален]
                  >>>>> ничего подозрительного пока не заметил...
                  >>>> В общем при анализе TCPStream увидел очень много TCP Retransmision и TCP
                  >>>> DupACK
                  >>>> Проблемма аналогичная http://blogs.technet.com/b/networking/archive/2011/05/16/tcp...
                  >>>> Но пока не решил...
                  >>>> В догонку на циске тоже было обсуждение: https://supportforums.cisco.com/thread/201894
                  >>> Следующий этап - прогнать с линуха на линух по самбе :)
                  >>> и если там все будет нормально - таки есть плешь микрософту....
                  >> С линуха на линух по самбе тоже самое (низкая скорость)
                  > Тада можно списать на архитектурные недостатки самого протокола....

                  Сегодня попробую ещё на семёрке погонять. Вообще, нормальные реализации tcp-стека должны уметь делать reordering сегментов...

                  • Не заволняются полностью каналы, !*! pilygrim, 19:13 , 19-Ноя-12 (14)
                    >>>> Следующий этап - прогнать с линуха на линух по самбе :)
                    >>>> и если там все будет нормально - таки есть плешь микрософту....
                    >>> С линуха на линух по самбе тоже самое (низкая скорость)
                    >> Тада можно списать на архитектурные недостатки самого протокола....
                    > Сегодня попробую ещё на семёрке погонять. Вообще, нормальные реализации tcp-стека должны
                    > уметь делать reordering сегментов...

                    На 7-ке производительность выросла в 2 раза.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру