Добрый день всем.

Столкнулся с непонятным поведением одного старого сервера в нагрузочном тесте. При скорости входящего трафика в районе 300Мбит/с - полет нормальный, однако где-то после ~360Мбит - все прерывания собираются на одно ядро.

[root@cat ~]# uname --all
Linux cat 2.6.32-573.7.1.el6.x86_64 #1 SMP Tue Sep 22 22:00:00 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[root@cat ~]# ethtool -i eth0
driver: e1000e
version: 3.2.5-k
firmware-version: 1.0-0
bus-info: 0000:04:00.0

[root@cat ~]# cat /proc/interrupts | grep eth
 49:    3899076    3127071    3138498    3129201    3021226    3024870    3021558    3031263   PCI-MSI-edge      eth0

[root@cat ~]# cat /proc/softirqs | grep RX
  NET_RX:   13273515   20093759   20261881   20181581   11821256   11702301   11883894   11702684

[root@cat ~]# sysctl -a | grep -E 'netdev|backlog|weight'
net.core.dev_weight = 64
net.core.netdev_max_backlog = 1000
net.core.netdev_rss_key = 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
net.core.netdev_budget = 300
net.ipv4.tcp_max_syn_backlog = 2048

[root@cat ~]# cat /sys/class/net/eth0/queues/rx-0/rps_cpus
00

[root@cat ~]# cat /proc/irq/49/smp_affinity
ff

[root@cat ~]# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off

[root@cat~]# ethtool -c eth0
Coalesce parameters for eth0:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 3
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 0
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 0

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

[root@cat ~]# cat /proc/net/softnet_stat
1220c6f5 00000000 0005668a 00000000 00000000 00000000 00000000 00000000 00000000 005e1cce
126639dd 00000000 000352c3 00000000 00000000 00000000 00000000 00000000 00000000 00e07895
12955ce5 00000000 00032a67 00000000 00000000 00000000 00000000 00000000 00000000 00e2f100
1893a083 00000000 00083e69 00000000 00000000 00000000 00000000 00000000 00000000 00dccfe3
0e5324de 00000000 00040a2f 00000000 00000000 00000000 00000000 00000000 00000000 005fce5f
0c54c177 00000000 0002232b 00000000 00000000 00000000 00000000 00000000 00000000 006025ae
0c8125ea 00000000 00030479 00000000 00000000 00000000 00000000 00000000 00000000 00619b8c
13edcf79 00000000 00092307 00000000 00000000 00000000 00000000 00000000 00000000 005912cd

При выключенном RPS и трафике в 330Мбит загрузка CPU выглядит так:

Cpu0  : 33.3%us,  2.9%sy,  0.0%ni, 49.3%id,  0.0%wa,  0.0%hi, 14.5%si,  0.0%st
Cpu1  : 19.7%us, 12.7%sy,  0.0%ni, 66.2%id,  0.0%wa,  0.0%hi,  1.4%si,  0.0%st
Cpu2  :  7.4%us,  7.4%sy,  0.0%ni, 77.9%id,  5.9%wa,  0.0%hi,  1.5%si,  0.0%st
Cpu3  : 14.1%us, 23.9%sy,  0.0%ni, 54.9%id,  1.4%wa,  0.0%hi,  5.6%si,  0.0%st
Cpu4  : 42.9%us,  8.6%sy,  0.0%ni, 40.0%id,  0.0%wa,  0.0%hi,  8.6%si,  0.0%st
Cpu5  :  3.0%us,  1.5%sy,  0.0%ni, 92.5%id,  0.0%wa,  0.0%hi,  3.0%si,  0.0%st
Cpu6  : 28.0%us, 57.3%sy,  0.0%ni,  6.7%id,  0.0%wa,  0.0%hi,  8.0%si,  0.0%st
Cpu7  : 20.0%us, 41.4%sy,  0.0%ni, 28.6%id,  0.0%wa,  0.0%hi, 10.0%si,  0.0%st

При трафике 380Мбит:

Cpu1  :  5.9%us,  9.8%sy,  0.0%ni, 82.4%id,  2.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  1.9%sy,  0.0%ni, 98.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  : 41.2%us, 37.3%sy,  0.0%ni, 21.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni, 98.0%id,  2.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  3.8%us,  7.5%sy,  0.0%ni, 88.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,100.0%si,  0.0%st

Соответственно все отложенные прерывания собираются на одном ядре. При этом обычные прерывания в interrupts для eth0 в этот момент останавливаются. Нагуглил, что при превышении budget в NAPI переключается обработка пакетов на отложенные прерывания, как «более дешевые». Однако на деле это оказывается не так.

Что пробовал сделать: 1) Включать RPS (первоначально он и был включен, но с ним нагрузка при трафике в 330Мбит выше, чем без) на все ядра, на все ядра кроме того, на которое заведены прерывания сетевой карты, попроцессорно 2) Менять маску smp_affinity в разных вариациях - на все ядра, попроцессорно, на одно ядро. 3) Увеличивать netdev_max_backlog, netdev_budget, netdev_weight и другие. 4) Менять режимы rx-usecs

В итоге всех изменений где-то меньше теряется пакетов, где-то загрузка CPU поменьше, но главное не меняется - после пересечения рубежа в ~350Мбит прекращают тикать interrupts сетевой карты, а все softirqs собираются на каком-то одном (случайном) ядре.

Подскажите, в какую сторону копать?

Всем добрый день.

Столкнулся с задачей - нужно отбрасывать любой первый входящий UDP-пакет с любого IP. То есть, при поступлении пакета с IP x.x.x.x, DROP'ать его, любые следующие пакеты с данного IP нужно пропускать.

Что в настоящий момент: 1) Двухпроцессорный Xeon E5-2600 серии с linux на борту, никаких conntrack конечно и т.п. 2) Около 3Mpps и 1Gbps входящего трафика 3) Одновременно около 2Mpps различных source IP.

Опытным путем выяснено, что hashlimit с трудом выполняет задачу, но при этом утилизируя все ядра в полку (свободных ресурсов не остается вообще) и есть потери пакетов. Учитывая, что в будущем нагрузка будет только расти, вариант не подходит.

Причины вычислительной сложности задачи в общем-то понятны, для пропуска пакетов со второго необходимо вести список всех IP источников, а их там пара миллионов.

Возможно, кому-то известны какие-то способы/модули iptables для снижения нагрузки? Штатные средства не подойдут явно, но может кто какой модуль знает.

Добрый день.

Имеется серверная платформа Intel S5500 с установленным свежим CentOS 7, ядро 3.10.0-123.20.1.el7.x86_64. Версия BIOS платформы S5500.86B.01.00.0064.050520141428, тоже свежая.

На борту сетевая карта:

Handle 0x001C, DMI type 10, 6 bytes
On Board Device Information
        Type: Ethernet
        Status: Enabled
        Description: Intel 82576EB Ethernet

[root@* ~]# ethtool -i eth0
driver: igb
version: 5.0.5-k
firmware-version: 1.4.3
bus-info: 0000:01:00.0

Проблема в том, что на сервере неадекватно высок расход CPU на сетевые прерывания. Там, где аналогичные машины (супермикры кстати), расходуют 10% CPU на 100% утилизацию полосы сетевой карты синтетическим тестом, на этой машине уходит все 100% CPU и идет значительный packet loss. При том что конфиграция серверов аналогичная.

Я по началу грешил на firmware сетевой карты. Обновил BIOS и все что с ним прилагается на свежую версию, но там та же верси я 1.4.3 идет.

Вот так выглядит perf top здорового сервера:

 38.21%  svr                     [.] 0x00000000000fd929                                                                                               ♦
  3.88%  sr.so                   [.] 0x0000000000027079                                                                                               ▒
  2.16%  [kernel]                      [k] ipt_do_table                                                                                                     ▒
  1.43%  tcpdump                       [.] 0x0000000000005391                                                                                               ▒
  1.38%  [kernel]                      [k] ____nf_conntrack_find                                                                                            ▒
  1.32%  libc-2.17.so                  [.] __random                                                                                                         ▒
  1.31%  [kernel]                      [k] fib_table_lookup                                                                                                 ▒
  0.99%  [kernel]                      [k] _raw_spin_lock_bh                                                                                                ▒
  0.92%  libc-2.17.so                  [.] _int_malloc                                                                                                      ▒
  0.76%  de.so                 [.] CElementIDs::GetElement(ElementID)                                                                               ▒
  0.72%  [kernel]                      [k] igb_clean_rx_irq                                                                                                 ▒
  0.64%  libstdc++.so.6.0.19           [.] 0x0000000000068fa3                                                                                               ▒
  0.60%  [kernel]                      [k] tg_load_down                                                                                                     ▒
  0.50%  de.so                 [.] CElement::CallEventNoParent(char const*, CLuaArguments const&, CElement*, CPlayer*)                              ▒
  0.46%  [kernel]                      [k] inet_getpeer                                                                                                     ▒
  0.46%  libc-2.17.so                  [.] _int_free                                                                                                        ▒
  0.44%  [kernel]                      [k] nf_conntrack_in                                                                                                  ▒
  0.44%  libc-2.17.so                  [.] malloc                                                                                                           ▒
  0.44%  [kernel]                      [k] _raw_spin_lock                                                                                                   ▒
  0.44%  [kernel]                      [k] rcu_nocb_kthread                                                                                                 ▒

А вот так у «курильщика»

 35.61%  svr                     [.] 0x0000000000039183                                                                                               ♦
 15.31%  [kernel]                      [k] _raw_spin_lock_bh                                                                                                ▒
  3.94%  st.so                   [.] 0x0000000000007707                                                                                               ▒
  2.14%  cr.so                [.] amx_Exec                                                                                                         ▒
  1.43%  tcpdump                       [.] 0x000000000005cc7f                                                                                               ▒
  1.17%  cr.so                [.] amx_Exec                                                                                                         ▒
  1.10%  [kernel]                      [k] ____nf_conntrack_find                                                                                            ▒
  1.10%  libc-2.17.so                  [.] __random                                                                                                         ▒
  1.08%  [kernel]                      [k] ipt_do_table                                                                                                     ▒
  0.94%  [kernel]                      [k] fib_table_lookup                                                                                                 ▒
  0.71%  libc-2.17.so                  [.] _int_malloc                                                                                                      ▒
  0.62%  [kernel]                      [k] tg_load_down                                                                                                     ▒
  0.56%  crashdetect.so                [.] amx_Exec                                                                                                         ▒
  0.51%  libstdc++.so.6.0.19           [.] std::_Rb_tree_increment(std::_Rb_tree_node_base*)                                                                ▒
  0.49%  [kernel]                      [k] __schedule                                                                                                       ▒
  0.47%  [kernel]                      [k] nf_conntrack_free                                                                                                ▒
  0.47%  [kernel]                      [k] _raw_spin_unlock_bh                                                                                              ▒
  0.43%  [kernel]                      [k] igb_clean_rx_irq                                            

Напрягает _raw_spin_lock_bh. Но пока непонятно, куда копать дальше.

Добрый день, коллеги.

Столкнулся с проблемой оптимальной работы сетевого стека Linux на 2-х серверах одинаковой конфигурации (2хXeon, конфигурация железа полностью одинакова). Несущественные отличия есть в версии ядра, и версия драйвера сетевой карточки отличается. Однако, на «менее производительном» сервере версия драйвера сетевой карты новее, так что не спешу пока ничего обновлять.

В тесте на одной машине 1Mpps UDP мелкопакетного трафика (около 350Мбит) принимается и обрабатывается легко и непринужденно с большим запасом (загрузка 8-ми ядер, обрабатывающих прерывания очередей сетевой карты, около 40%).

На другом же сервере тот же тест 1Mpps UDP мелкопакетного трафика загружает 8 ядер процессора на 100%, есть существенный packet loss.

Понятно, что вероятность проблемы в драйвере или ядре есть, и она велика, однако, на проблемном сервере софт новее (ядро и драйвер), и обновлять пока не спешу. Потому хотелось бы услышать от вас какие-то наводки в отношении того, на что обратить еще внимание в настойках. Сам все на что мог подумать уже сравнил.

Что-то я усомнился в элементарном. На сервер флудят с миллиона фальшивых адресов с достаточно большим pps, пакеты попадают (и должны) в цепочку с правилами hashlimit. Таблица хешей не велика и переполняется. Увеличение размера таблиц приводит к деградации производительности. Соответственно стоит задача отбросить пакеты в начале цепочки, чтобы они не дошли до hashlimit. При этом сами правила hashlimit идут с действиями log (логируем если пакетов больше, чем Х), drop(дропаем если пакетов больше чем Х+10) и accept(дополнительное правило лимитирует число новых пакетов). Соответственно, даже если я дропну пакеты в начале цепочки, как минимум в последний accept они попадут (вдруг пакет все-таки нужно разрешить по этому правилу).

В общем понимаю что вопрос тривиальный, но дабы проверить себя ))

Добрый день, коллеги.

Хотелось бы услышать людей с реальным опытом тюнинга TCP-стека на ядре 2.6. Статей в интернете 100500, и 95% из них переводы/копипаст одного и того же. И все это я уже проштудировал.

Столкнулся с тем, что для новых TCP-соединений первое время (около 2-3 перезодов по страницам сайта, допустим) задержки выше, чем обычно.

Стоит nginx, весь контент в кеше. При первоначальной загрузке основная страница загружается барузер посетителя за 400-500 мс (при пинге до сервера в районе 120). 2-я страница за 280 мс. Третья - четвертая тоже 280 мс. Далее все страницы загружаются за 150 мс. Сам nginx тут не причем. Проблема наблюдается именно при работе с новыми соединениями. Если закрыть браузер, все повторяется; если подождать в пределах keep-alive и продолжить серфинг - все грузится за те же 150мс. Но стоит браузер перезапустить и на новых соединениях опять начнется с 500 мс. Конечно, дело не в браузере.

Природа долгой первой загрузки ясна (разрешение DNS и установка соединения, видимо). Но непонятно почему потом некоторое время все отдается по 280 мс. А потом вдруг 150. Хотелось бы сразу 150.

sysctl:

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 0

kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296

net.ipv4.ip_conntrack_max = 2621440
net.ipv4.netfilter.ip_conntrack_max = 2621440

net.core.netdev_max_backlog = 3000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# and ip route change default via 35.28.51.2 dev eth0 initcwnd 10
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_tw_reuse = 1

Помимо всего прочего пытался вертеть по разному:

net.ipv4.tcp_no_metrics_save
net.ipv4.tcp_congestion_control (остановится на htcp)
net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_max_tw_buckets
net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_moderate_rcvbuf
net.ipv4.tcp_window_scaling

Добрый день, товарищи.

Разыскиваю способ визуализации MP3 треков подобным образом: http://www.youtube.com/watch?v=erzh8h7TnEE

На ходе имеем название трека, фоновую картинку и основные цвета, а с помощью программы хотелось бы генерировать таймер и «частотный монитор», такой, как на видео. В принципе, если будет просто таймер и монитор на прозрачном фоне, то потом смогу без проблем наложить это дело на фон.

Ах да, программка должна работать из командной строки, с выводом файл. Ну и работать сама нормально, т.к. надо базу из 8 тысяч песен визуализировать будет (для стриминга).

Есть у кого какие мысли?

Добрый день.

В интернете еще остались круворукие админы, которые не удосужились включить проверку sip на выходе из своих as. как результат моё приложение, использующее udp транспорт, периодически какие-то козлы закидывают фейковыми запросами подключения, чем создают определенные проблемы.

Не подскажете способы борьбы с такой ерундой? В гугле только влючение rp_filter и DROP трафика с приватных сетей, что как бы ниочем совсем.

Всем доброе утро!

В наличии сервер с Dual Xeon, на нем вертится панель управления услугами (ПУ) и MySQL для этих услуг. В настоящее время сервер забит под завязку. Т.к. сама ПУ и MySQL являются достаточно критичными (от их доступности зависит работа связанных услуг на других машинах), то решил масштабировать не добавлением новых серверов, а созданием кластера из двух.

Особенности тут такие:
1) Связанные услуги имеют постоянное подключение к MySQL (такова специфика приложения);
2) Все услуги с указанной машиной в локальной сети, обращаются к ней по имени хоста.

Планируется, что кластер будет защищать от:
1) Аппаратного или программного отказа одной из машин;
2) Недоступности одной из машин с внешних сетей.

Сам кластер планируется реализовывать следующим образом:
- На оба сервера ставим одинаковый набор по: apache c ПУ, mysql-proxy, mysql.
- Настраиваем master-master репликацию mysql.
- Настраиваем mysql-proxy на статическое распределение запросов между серверами по базам (чтобы разделить нагрузку ~50/50, и не писать в одну базу одновременно), на каждом сервере.

По задумке, если мониторинг фиксирует проблемы, то просто меняется IP-адрес хоста на DNS-сервере на вторую машину, а она уже готова принять все запросы, т.к. благодаря master-master данные актуальны (ну, почти) и, дальше, в зависимости от ситуации:
1) В случае проблем аппаратных, mysql-proxy это зафиксирует и перестанет отправлять запросы на проблемную машину, обрабатывая все локально;
2) В случае недоступности IP с внешних сетей, mysql-proxy будет иметь связь с проблемной машиной локально, и будет её использовать как обычно.

Просьба тех, кто имеет опыт, оценить чудо-схему и дать комментарии. Я понимаю прекрасно, что в случае аварий вторая машина будет загружена под полку, это в данном случае не имеет значения (решим другим способом). Отдельно следующее:
1) Я слышал, что mysql-proxy дает больше геморроя, чем пользы, так ли это?
2) Какой TTL стоит использовать на DNS сервере для этой записи? Если слишком маленький, боюсь это убьет всю производительность на ожидание ответа от DNS-серверов.
«В случае недоступности IP с внешних сетей» - это значит, что ЦОД просто отправит их в блекхолл, бывает такое.
3) Как посоветуете определять внешнюю доступность IP-адреса? Не хотелось бы ставить внешние точки мониторинга, если там будут проблемы со связью до ЦОД-а, то пойдут свистопляски ...
4) Вообще кто-то такое использует, или я фигню написал?

Спасибо.

UDP: Естественно, схема с переключением IP на DNS выбрана не случайно. Возможны реальные отключения IP-адресов ЦОД'ом, никакие virtual ip в ЦОД'е не реализованы и их реализация в данной ситуации невозможна, когда ЦОД специально блокирует IP - инфраструктура должна на это реагировать и подстраиваться. Использовать сторонние услуги невозможно из-за высоких требований к низким задержкам.

Apache 2.2.17 + PHP 5.2.17 + PHPMyAdmin 3.5.1 К PMA доступ по https. При Импорте архива с базой в PMA загрузка идет ровно 60 секунд, после чего соединение отваливается (сервер разорвал соединение, 101 ошибка). В логах никаких ошибок.

Я уже всю голову сломал. Что может быть? На другой машине с точно таким же набором софта такой проблемы нет.

php_value post_max_size 512M php_value upload_max_filesize 512M php_value memory_limit 512M php_value max_execution_time 300 php_value max_input_time 300 Timeout 60 (пробовал 300, разницы нет)

Основные непонятки в том что перечисленный софт полностью идентично настроен на двух машинах. Но на одной такая вот ерунда... Думаю в сторону параметров sysctl или другого софта, что может участвовать.

Товарищи, есть идеи?

Итак, есть веселый Apache. Есть долгие php-скрипты. К ним относятся установщик IPB, и скрипт качающий файл в 10мб с удаленного сервера. Оба скрипта выполняются около 30 секунд. Клиент отправляет запрос выполнения, и ожидает ответа бесконечно. В этом проблема и состоит. Т.е. скрипт уже давно выполнился, сделал все что надо (не вылетел, отработал полностью), а соединение все висит. Если его не трогать то так и будет бесконечно в браузере ожидаться загрузка страницы. Кто сталкивался?

Там стоит apache mpm-itk и mod_php, timeout 60 секунд, KeepAlive on/off - разницы нет. Я то и не знаю что еще там в apache можно выкрутить, по сути других параметров то и нет.

nginx отдает всю статику и проксирует на бэкенд запросы динамики + не найденную статику. Проблема в том, что у apache стабильно висит около 30 процессов с владельцем apache, это как я понимаю те самые процессы, что отдаются не найденную статику. Он не обрабатывают динамику, а потому для них не установлен UID:GID.

Так вот, как заставить mpm не плодить отдельные процессы под такие запросы? В конфигурации указано четко - не более 10 процессов, но ему как-то пофиг.

Такая конфигурация <IfModule itk.c> StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 450 MaxClients 450 MaxRequestsPerChild 10000 </IfModule>

Хитрые разработчики добавили в новую версию ПО проверку на число IP адресов на системе, чтобы злые и коварные хостеры не могли запустить у себя это приложение. А у меня на каждой машине over 100 IP.

Может подскажет кто-нибудь способ спрятать от софтины список IP, оставив один, нужный? Виртуалка не подойдет под эти цели, приложений много запускается (по кол-ву IP, да), каждый в виртуалку если и засуну - будет неэффективно.

Спасибо всем заранее за участие,

Случилась засада, попал в ДЦ, где не дают KVM. Установка ОС только автоматическая, накатывается образ, и RAID-1 можно собрать только на живой системе. Дважды по разным мануалам делал, толку 0. Не запускается после ребута, ошибку на консоли посмотреть не могу (и никто не может)... Хрен знает что делать, без данных с консоли во время загрузки исправлять - пальцем в небо.

Руководствовался этими мануалами http://linux.dell.com/files/whitepapers/Software_RAID_on_Red_Hat_Enterprise_L... http://www.howtoforge.com/how-to-create-a-raid1-setup-on-an-existing-centos-r...

Возможно кому приходилось в такой ситуации raid-1 поднимать, что посоветуете? KVM не будет точно, увы, посмотреть что в консоли никто тоже не сможет.

Спасибо.

В общем, сабж... Файлы с ведущей точкой показываются нормально, но если в имени файла есть "..", то его нет в листингах на клиенте. Пробовал с разных клиентов, даже с mc на сервере сам к себе по FTP подключиться. Кто знает в чем дело? Офф. документация говорит только об отключении вывода файлов с "." и "..", а о включении только ".", но не "..". Да и ".." там видимо понимается как выход в предыдущую директорию. Настройки ProFTP дефолтные, проверял на нескольких серверах - тот же прикол.