Аномально медленная отдача файлов Apache24 через lo0

Проблемы с установкой, настройкой и работой системных и сетевых программ.

Модераторы: GRooVE, alexco

Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Аномально медленная отдача файлов Apache24 через lo0

Непрочитанное сообщение Dmitriy_K » 2016-06-01 13:19:07

Приветствую всех!
Только что столкнулся с какой-то совершенно непонятной аномалией.
На серваке была установлена FreeBSD 10.3 + Apache24 для нескольких мелких сайтов.
Всё работает замечательно, но потребовалось настроить индексацию, и в процессе тестирования обнаружилось, что Apache24 аномально медленно отдаёт большие файлы через локальный интерфейс lo0.
То, что отдаётся вовне за несколько секунд, по lo0 отдаётся примерно за 16-18 минут ! :cz2:
Проверялось через:

Код: Выделить всё

# wget http://www.***/common/101015.pdf
Распознаётся www.*** (www.***)… 127.0.0.1, ::1
Подключение к www.*** (www.***)|127.0.0.1|:80... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа... 200 OK
Длина: 11049247 (11M) [application/pdf]
Сохранение в: «101015.pdf»
101015.pdf             0%[                                                                                                        ]  47,59K  --.-KB/s   ост 18m 42s
^C
Индексация больших PDF оказывается невозможна, но я, вообще, изумлён таким спецэффектом.
Пытался для проверки отлючить PF - не влияет. Больше, кроме самого апача, ничего влиять не может.
Апач работает без всяких jail.

Если кто-то с таким сталкивался, просьба подсказать что делать с таким неожиданным траблом.

Код: Выделить всё

% ifconfig
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
        ether 00:25:90:c0:fa:2a
        inet 188.225.80.102 netmask 0xffffff00 broadcast 188.225.80.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
igb1: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
        ether 00:25:90:c0:fa:2b
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг HostFood.ru

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

Аватара пользователя
Neus
капитан
Сообщения: 1980
Зарегистрирован: 2008-09-08 21:59:56

Аномально медленная отдача файлов Apache24 через lo0

Непрочитанное сообщение Neus » 2016-06-01 18:00:48

А если mtu увеличить до максимума на lo?

Dmitriy_K
сержант
Сообщения: 200
Зарегистрирован: 2009-04-07 6:22:33
Откуда: г.Королёв

Аномально медленная отдача файлов Apache24 через lo0

Непрочитанное сообщение Dmitriy_K » 2016-06-02 13:41:08

Neus писал(а):А если mtu увеличить до максимума на lo?
А как сделать больше системного дефолта и почему на других серваках с более старыми операционками с ним всё работает нормально?

Код: Выделить всё

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
Отправлено спустя 30 минут 57 секунд:
Я успел проделать дополнительное тестирование проблемы.
Поставил nginx и настроил в нём тестовый сайт с тестовым PDF размером 11Мб.
Появилась возможность сравнить скорости отдачи файла nginx и apache24.

1) Nginx оказался намного быстрее. ;-)
Скорость скачки файла через wget составила около 260Кб/с для nginx и около 10Кб/с для apache24! :crazy:
Причём скорость передачи сильно плавает, но конечное время скачки файла для nginx стабильно.

2) Проблема оказалась связана только с локальным интерфейсом lo0 во FreeBSD 10.3
У меня много серваков с весьма схожими настройками под более старыми версиями FreeBSD. На них подобных проблем никогда не было.

Также попробовал сменить алгоритм управления размером окна передачи (net.inet.tcp.cc.algorithm).
Сменил его с "cubic" на "newreno". Изменений не произошло.

Это просто полный капут! :shock: Непонятно что делать.
Попробую ещё поднять эту проблему на forums.freebsd.org

Отправлено спустя 1 час 10 минут 37 секунд:
Проблема оказалась зарыта где-то в настройках системного тюнинга.
Попробовал загрузиться без установки системных переменных и всё заработало.
Получил скорости 575 MB/s и 1,22 GB/s для апача и nginx.
Используемых системных переменных около 60. Попробую их выставлять блоками.

Отправлено спустя 59 минут 40 секунд:
Я нашёл источник проблемы.
Это оказалась переменная net.inet.tcp.recvspace=8192 в sysctl.conf
При установке её в дефолт (65536) пропускная способность lo0 непропорциональным образом увеличивается в 60тыс.раз.

Что интересно. Во FreeBSD более старых, чем версия 9, такого эффекта нет, проверил.
Переменная net.inet.tcp.recvspace всегда позиционировалась как переменная, определяющая затраты системной памяти для обслуживания внешних коннектов к серверу. Исходя из этого, я её и использовал.
Оказалось, что начиная с FreeBSD 9 она воздействует на локальный интерфейс lo0. Хорошо бы понять, только на него или на внешний тоже? (Как-то не заметил подобных вредных последствий этого, хотя использовал давно.)
И ещё интересно, это фича или баг? На мой взгляд, это больше соответствует по своим свойствам багу.
Никакого смысла применения net.inet.tcp.recvspace и net.inet.tcp.sendspace к локальному интерфейсу lo0 нет.