Мне это кажется в высшей степени неправдоподобным, даже смешным.
Я вхожу на сервер CentOS по SSH. Я FTP на другой сервер и начинаю передачу большого файла (загрузка на другой сервер).
Через некоторое время (обычно около 3-30 секунд) я отключаюсь от SSH.
У меня никогда не было проблем на любом другом сервере, где меня выгнали из SSH из-за пропускной способности FTP.
root@my_server [/home/my_folder/public_html]# ftp xx.xxx.xx.xx
Connected to xx.xxx.xx.xx.
220 (vsFTPd 2.3.5)
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (xx.xxx.xx.xx:root): buttle_butkus
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd speedtest
250 Directory successfully changed.
ftp> 2gb_file.tar.gz
local: 2gb_file.tar.gz remote: 2gb_file.tar.gz
227 Entering Passive Mode (xx,xxx,xx,xx,xxx,xxx).
Connection closed by host
Disconnected
Компания по размещению серверов заявила, что это потому, что «вся пропускная способность используется FTP». Я никогда не слышал о таком, но прежде чем сказать им, что они сумасшедшие, я хотел спросить здесь экспертов.
Они также предложили мне изменить UserBandwidth параметр в pure-ftpd.conf равным 15. Это 15 килобайт / с при соединении 100 Мбит / с. Я думаю, мне нужно оставить около 99,9 Мбит / с для SSH ??
Я изменил его, но это все равно не повлияло на скорость загрузки (все еще очень быстро). Возможно, этот параметр влияет только на внешних пользователей, входящих на сервер по FTP. Я вошел в систему по SSH, а FTP вышел.
Спасибо.
РЕДАКТИРОВАТЬ: добавление части захваченного tshark трафика (IP-адреса частично скрыты):
544 111.343171 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
545 117.486826 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
546 125.464960 xx.xx.94.90 -> xx.xx.195.90 TCP [TCP Previous segment lost] ssh
> csd-monitor [SYN, ACK] Seq=498204672 Ack=2219931860 Win=8192 [TCP CHECKSUM INC
ORRECT] Len=0
547 129.774351 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
548 154.348760 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
549 203.497887 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
550 279.243718 xx.xx.195.90 -> xx.xx.230.39 SSH Encrypted response packet len=9
52
Кажется, решение было найдено, но я не уверен. Обслуживание клиентов хоста сервера ужасное. Но на данный момент проблема больше не возникает. Я могу передавать большие файлы и не загружаться с терминала SSH через 20-30 секунд.
Они изменили дуплексный режим сети на FULL с HALF.
Ознакомьтесь с этой статьей в Википедии о несоответствии дуплексного режима: http://en.wikipedia.org/wiki/Duplex_mismatch
Согласно статье, несоответствие дуплекса вызывает огромную пробку в сети. Служба поддержки клиентов хоста сервера ранее обвиняла пропускную способность, говоря, что соединение SSH было разорвано из-за того, что файлы, которые я отправлял по FTP, были слишком большими. Они сказали, что я должен заплатить за дополнительную пропускную способность, чтобы решить проблему. Это явно не помогло бы. Независимо от того, насколько велика полоса пропускания, несоответствие дуплексного режима подавило бы ее. Я до сих пор не совсем понимаю, почему это может убить сеанс терминала, но, вероятно, пробка из-за передачи FTP задерживает пакеты SSH, которые поддерживают сеанс. Но обычно он падает в течение 20-30 секунд, что для этого слишком рано.
Я сказал службе поддержки клиентов, что они испортили некоторые настройки при установке порта 100 Мбит / с в декабре (ранее было 10 Мбит / с). Я не уверен, происходило ли это раньше, поскольку нам редко нужно передавать файлы оттуда по FTP. Вот их ответ:
По вашему запросу 29 декабря 2012 года мы вручную обновили этот порт сервера до 100 Мбит / с. Он был установлен правильно. Сетевые моды можно изменить в любое время с помощью команды «mii-tool». Вносили ли вы какие-либо изменения в настройки сети или принудительно перезагружали сервер? Я вижу, что сервер перезапустился 9 дней назад. Была ли это попытка безопасного перезапуска? Возможно, недавняя попытка перезапуска изменила настройку.
Есть ли у вас какой-либо другой сервер с такой же проблемой? затем просто выполните следующую команду и убедитесь, что ваш сервер работает в полнодуплексном режиме
***** ethtool eth0 | grep -i дуплекс