Объемная загрузка через FTP прервана приблизительно после 50 файлов

1. Проблема:

Серийная загрузка 100 или больше файлов через FTP прервана. Неправильное поведение. На новом ПК с 2011, просто установлена Ubuntu. Никакая другая проблема с Ubuntu. Быстрое действие браузера и загрузка Веб-сайта.

ВОПРОС, Что я мог попробовать, в дополнение к шагам, описанным ниже?
Или есть ли примитивная ошибка или примитивное решение?

Исходный текст, не измененный. Обновления, сделанные путем добавления:

• Декабрь 7 2011: информация, добавленная ниже в 3,2)
• Декабрь 9,2011: добавленный: 4.d) 4.e)
• Декабрь 10,2011: добавленный 4.f)

2. Больше фактов:

Загрузка FTP нескольких, 1 000 файлов (несколько сайтов) здесь сделаны собственными программами Perl, которые отправляют ряд команд стандарта FTP к стандартному ftp системы LINUX. Эффект: Подобный зеркальному отражению - но позволяет подстроить.
Используемые единственные команды "ftp mput" включают, например, 100 файлов, каждый файл приблизительно 100 КБ. Приблизительно 1 000 файлов на Веб-сайт.

Загрузка на: Веб-сайты с помощью совместно использованного хостинга. Серверы используют Linux, например, Bluehost=Hostmonster или Lunarpages.

3.1) До сих пор у меня никогда не было такой проблемы.

В течение лет у меня никогда не было такой проблемы с Fedora. Fedora 13 на ПК с 2006 продолжает делать задание даже сейчас правильно (idential DSL соединение, идентичные аппаратные средства DSL). Я намеренно не обновил Fedora 13. Таким образом, ftp LINUX, возможно, изменился немного тем временем. Но не вероятно, что это - причина.

ПК здесь только используются в качестве поставщика ОС. Данные и собственное программное обеспечение находятся на внешнем HD, являются независимыми от операционной системы и портативными (организованный программным обеспечением Perl).

Новая UBUNTU ПК не делает этого задания отлично при работе над идентичным внешним HD и с идентичной программной средой.

(Только сетевой кабель отличается, но это не должно вызывать проблему. 1 м длиной для старого Fedora ПК, 5 м для новой Ubuntu ПК.)

3.2) Специфические особенности UBUNTU вызывают, вероятно, проблему (добавленный декабрь 7,2011)

Тем временем / теперь я имею:

UBUNTU 64b с конца 2011 года на новом ПК / 2011, жесткие диски с интерфейсом SATA.

UBUNTU 32b с конца 2011 года на старом ПК / 2006, PATA (/IDE) жесткие диски.

Это просто поставщики операционной системы. Все данные, программное обеспечение и выполнение сделаны на внешнем HD, который ИДЕНТИЧЕН для обоих случаев.

В обоих случаях описанная проблема происходит. Это НЕ происходит для старого ПК, когда выполнено с Fedora 13 (приблизительно от 2009).

Проблема следовательно очень, вероятно, так или иначе коррелируется к определенным функциям UBUNTU.

Существует очень низкая вероятность, что начиная с FEDORA 13 общая система LINUX изменилась, приведя к этой проблеме.

С быстрым поиском Google до сих пор я не нашел информации о подобных проблемах.

Все остальное UBUNTU хорошо работает на новом ПК с широким экраном. Таким образом, это - с этого времени некоторое время здесь выбор.
Я получаю в эти недели в 10 раз более быстрое Интернет-соединение DSL. Возможно, проблема затем исчезнет. (Я предполагаю, что это НЕ исчезнет.)

4.a), установка Priority не помогает.

С командой, хорошей, я протестировал приоритет-18 (проверенный в gnome-system-monotor - да,-18). Это не помогло.

4.b), sudo использование не помог

Я также пытался назвать программу Perl, которая делает задание с sudo. Это не влияло на результат.

4.c) неправильное Поведение

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

4.d) Никакая справка от: исходный код,-i флаг,-v флаг (добавленный 9 декабря 2011)

Включенные ПОЛНЫЕ длинные программы 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, которому это поможет - потому что...:

4.e), самая вероятная проблемная причина - я предполагаю (добавленный декабрь 9,2011)

Самый вероятный то, что некоторый процесс, характерный для Ubuntu, создает задержку - так, чтобы программа ftp не предоставляла достаточно быстро следующий файл к удаленному ПК (Интернет-сервер). Но я не заявил задержки нескольких секунд ни для какой другой функции. Все работает прекрасное и быстрое. И я не мог найти корреляцию приблизительно некоторого действия программного обеспечения перед возникновением задач.

Я заявляю на, anently короткий доступ жесткого диска каждые 3 секунды (если ведомое управление действует правильно). Каждые 3 секунды - или быстрее. Не регулярный. Это может иметь простые объяснения. Это даже продолжается, когда нет никакого выполнения приложения - полностью пустой монитор. Но я не полагаю, что причина связана с этим.

4.f) функция Debug? ftp-d (добавленный декабрь 10,2011)

-d отмечают для ftp: Не попробованный (в то время как рекомендуется комментарием).

-d отмечают как таковой, не достаточно. Чтобы зарегистрировать ftp, различные шаги требуются (rsyslog.conf...). Вероятность, что на этот раз инвестиции привели бы к успеху, для этого проблемного типа близко к нулю.

Таким образом, я вместо этого продолжу обходное решение: Делая объемную загрузку на Fedora (= ПК 1), все остальные на Ubuntu (= PC2), и попытка другие шаги для нахождения в некотором будущем решения.

5.1. Пример: Это - дисплей управления во время загрузок

Этот дисплей сделан моими собственными программами 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

5.2. Пример: стандартный дисплей программы ftp похож:

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

5.3. Пример: дисплей при прерывании:

С новой установленной 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

............... и т.д. и т.д. для всего после файлов............