Серийная загрузка 100 или больше файлов через FTP прервана. Неправильное поведение. На новом ПК с 2011, просто установлена Ubuntu. Никакая другая проблема с Ubuntu. Быстрое действие браузера и загрузка Веб-сайта.
ВОПРОС, Что я мог попробовать, в дополнение к шагам, описанным ниже?
Или есть ли примитивная ошибка или примитивное решение?
Исходный текст, не измененный. Обновления, сделанные путем добавления:
Загрузка FTP нескольких, 1 000 файлов (несколько сайтов) здесь сделаны собственными программами Perl, которые отправляют ряд команд стандарта FTP к стандартному ftp системы LINUX. Эффект: Подобный зеркальному отражению - но позволяет подстроить.
Используемые единственные команды "ftp mput" включают, например, 100 файлов, каждый файл приблизительно 100 КБ. Приблизительно 1 000 файлов на Веб-сайт.
Загрузка на: Веб-сайты с помощью совместно использованного хостинга. Серверы используют Linux, например, Bluehost=Hostmonster или Lunarpages.
В течение лет у меня никогда не было такой проблемы с Fedora. Fedora 13 на ПК с 2006 продолжает делать задание даже сейчас правильно (idential DSL соединение, идентичные аппаратные средства DSL). Я намеренно не обновил Fedora 13. Таким образом, ftp LINUX, возможно, изменился немного тем временем. Но не вероятно, что это - причина.
ПК здесь только используются в качестве поставщика ОС. Данные и собственное программное обеспечение находятся на внешнем HD, являются независимыми от операционной системы и портативными (организованный программным обеспечением Perl).
Новая UBUNTU ПК не делает этого задания отлично при работе над идентичным внешним HD и с идентичной программной средой.
(Только сетевой кабель отличается, но это не должно вызывать проблему. 1 м длиной для старого Fedora ПК, 5 м для новой Ubuntu ПК.)
Тем временем / теперь я имею:
UBUNTU 64b с конца 2011 года на новом ПК / 2011, жесткие диски с интерфейсом SATA.
UBUNTU 32b с конца 2011 года на старом ПК / 2006, PATA (/IDE) жесткие диски.
Это просто поставщики операционной системы. Все данные, программное обеспечение и выполнение сделаны на внешнем HD, который ИДЕНТИЧЕН для обоих случаев.
В обоих случаях описанная проблема происходит. Это НЕ происходит для старого ПК, когда выполнено с Fedora 13 (приблизительно от 2009).
Проблема следовательно очень, вероятно, так или иначе коррелируется к определенным функциям UBUNTU.
Существует очень низкая вероятность, что начиная с FEDORA 13 общая система LINUX изменилась, приведя к этой проблеме.
С быстрым поиском Google до сих пор я не нашел информации о подобных проблемах.
Все остальное UBUNTU хорошо работает на новом ПК с широким экраном. Таким образом, это - с этого времени некоторое время здесь выбор.
Я получаю в эти недели в 10 раз более быстрое Интернет-соединение DSL. Возможно, проблема затем исчезнет. (Я предполагаю, что это НЕ исчезнет.)
С командой, хорошей, я протестировал приоритет-18 (проверенный в gnome-system-monotor - да,-18). Это не помогло.
Я также пытался назвать программу Perl, которая делает задание с sudo. Это не влияло на результат.
Нет никакого правила в том, какой момент времени (который файл) загрузка останавливается. Обычно после нескольких минут - только, после того как это сделало целое задание 2 часов. Существует, возможно, незначительная корреляция к часам пик интернет-использования. Но это не уверено.
Включенные ПОЛНЫЕ длинные программы Perl не были бы полезны здесь. (Различные функции, сайты, специфические особенности...).
Здесь команда OWN (подпрограмма Perl) с проблемой загрузки (пример):
&FTP_c_mput (" www/ppp-de/*.htm")
Это просто делает команду FTP: mput www/ppp-de/*.htm
для ~200 файлов, но (проблема:) останавливается в файле приблизительно 30
- я Весь являюсь автоматическим - следовательно уже с флагом-i, следовательно ничто интерактивное. Таким образом, ошибка из-за тайм-аута никогда не должна обычно происходить.
- v---Всегда в подробном режиме (поэтому результаты в номере 5.2 и 5.3.)
Я все еще должен реализовать в рамках программного обеспечения функцию отладки-d (как рекомендуемый). Это - doubful, которому это поможет - потому что...:
Самый вероятный то, что некоторый процесс, характерный для Ubuntu, создает задержку - так, чтобы программа ftp не предоставляла достаточно быстро следующий файл к удаленному ПК (Интернет-сервер). Но я не заявил задержки нескольких секунд ни для какой другой функции. Все работает прекрасное и быстрое. И я не мог найти корреляцию приблизительно некоторого действия программного обеспечения перед возникновением задач.
Я заявляю на, anently короткий доступ жесткого диска каждые 3 секунды (если ведомое управление действует правильно). Каждые 3 секунды - или быстрее. Не регулярный. Это может иметь простые объяснения. Это даже продолжается, когда нет никакого выполнения приложения - полностью пустой монитор. Но я не полагаю, что причина связана с этим.
-d отмечают для ftp: Не попробованный (в то время как рекомендуется комментарием).
-d отмечают как таковой, не достаточно. Чтобы зарегистрировать ftp, различные шаги требуются (rsyslog.conf...). Вероятность, что на этот раз инвестиции привели бы к успеху, для этого проблемного типа близко к нулю.
Таким образом, я вместо этого продолжу обходное решение: Делая объемную загрузку на Fedora (= ПК 1), все остальные на Ubuntu (= PC2), и попытка другие шаги для нахождения в некотором будущем решения.
Этот дисплей сделан моими собственными программами Perl, следовательно не FTP. Сокращенный. Может включать 100... 300 файлов.
www/xmed-ppp-de/index.htm www/xmed-ppp-de/wweb-pare-med-de.htm www/xmed-ppp-de/wwee-fina-med-de.htm www/xmed-ppp-de/wwfu-cont-med-de.htm www/xmed-ppp-de/wwfu-sepa-med-de.htm
150 Соединений с портом 63555
#...
С 226 файлами успешно переданный
226 7,126 секунд (измеряемый здесь), 10,14 кбайт в секунду
73 985 байтов отправляются в 0.81 secs (89,7 кБайт/с)
локальный: удаленный www/xmed-ppp-de/wyck-tob-bo-med-de.htm: www/xmed-ppp-de/wyck-tob-bo-med-de.htm
200 успешных команд PORT
С новой установленной UBUNTU на новом ПК ряд заканчивается главным образом приблизительно после 30 файлов, варьируясь по случайному способу между 20 und 50, со следующим сообщением об ошибке: - следовательно: Ошибка из-за тайм-аута для МОЕГО ввода - но это был объем FTP, управляют mput, - таким образом, не может действительно быть проблемы скорости печати на МОЕМ ПК...
150 Соединений с портом 63562
#...
С 226 файлами успешно переданный
226 10,317 секунд (измеряемый здесь), 14,02 кбайт в секунду
148 068 байтов отправляются в 6.65 secs (21,8 кБайт/с)
локальный: удаленный www/xmed-ppp-de/wyck-tob-ris-med-de.htm: www/xmed-ppp-de/wyck-tob-ris-med-de.htm
200 успешных команд PORT
421 Тайм-аут - пытается ввести немного быстрее в следующий раз
локальный: удаленный www/xmed-ppp-de/wyck-tob-sto-med-de.htm: www/xmed-ppp-de/wyck-tob-sto-med-de.htm
Никакое соединение управления для команды: Успех
локальный: удаленный www/xmed-ppp-de/wycu-nut-med-de.htm: www/xmed-ppp-de/wycu-nut-med-de.htm
............... и т.д. и т.д. для всего после файлов............
(Вот мой собственный ответ на мой собственный вопрос выше.)
Проблема больше не возникает при использовании более быстрого подключения к Интернету.
Это происходило со скоростью 0,2 Мбит / с (стандартная скорость DSL для загрузки - уровень, как в 2005,2006; не измерено).
Это больше не происходит при скорости 1,2 Мбит / с или аналогичной (текущая скорость загрузки через мобильный доступ в Интернет UMTS, измеренная с помощью http://www.umts-speedtest.com [ 110])
В случае снижения скорости с помощью этой формы мобильного доступа (UMTS) проблема возникает снова. Это может произойти во время ежедневных часов пик сети мобильного доступа в Интернет.
Скорость в течение следующих недель увеличится до 5 Мбит / с (загрузка, 25 или 50 для загрузки). Так что это, вероятно, решит проблему определенным образом.
Этот тип проблемы возникает только для используемого дистрибутива UBUNTU DVD / конец 2011 года (но, вероятно, для всех текущих дистрибутивов UBUNTU).
Это никогда не происходит в Fedora Core, по крайней мере, до версии 13 = 2009. Более поздние версии еще не были проверены. Предполагается, что более поздние и текущие (2011,2012) версии Fedora Core также не будут иметь этой проблемы.
Проблема не очень важна. Это необычно, что такие задания массовой загрузки выполняются для пользователей с низкой скоростью загрузки, как это было в 2005 году.
Утилиты FTP, вероятно, выполняют массовую загрузку другим способом и поэтому, вероятно, не будут затронуты. Проблема, вероятно, возникнет только в том случае, если массовая загрузка выполняется с использованием для файлов 30 ++ базовой команды FTP: mput
Эта команда должна работать для всех скоростей загрузки - также для модемов со стационарным телефоном - и для всех количество файлов.
Так есть ошибка? - Вероятно, просто в смысле некоторой начальной конфигурации по умолчанию. Установка приоритета процесса не решила проблему. Но может случиться так, что проблема связана с вычислительными приоритетами для графических функций высокого уровня текущей Ubuntu (я научился любить их ...).
Возможно, эта проблема с FTP не имеет значения. Перед размещением этого вопроса на этом сайте, я посмотрел через Google, я не нашел кого-то другого, сообщающего тот же тип проблемы.
Может быть и другая совершенно другая причина: нестабильность интернет-соединений из-за текущих локальных изменений здесь,
и с некоторой более высокой уязвимостью от этого для конфигурация UBUNTU (с конца 2011 года), чем конфигурация для Fedora Core (с 2009 года).
Так что давайте забудем об этом ...