Скорость загрузки файла с Amazon S3 падает до ‹2 кбит/с = очень медленная загрузка (на машине, с которой он был загружен)

Основная проблема:

Мы столкнулись с очень странным поведением в нашей текущей настройке инфраструктуры:

  • скорость загрузки файла с Amazon S3 падает до ‹2 кбит/с (после примерно 10 загрузок с совершенно нормальной скоростью загрузки), если файл загружается с того же IP-адреса/машины, с которой он был загружен
  • на других наших машинах мы можем загрузить файл пару тысяч раз и не увидеть такого поведения

Дополнительные детали:

  • машины настроены одинаково, используя puppet
  • все они являются виртуальными машинами под управлением Ubuntu 12.04.4 на KVM с libvirtd на хостах Ubuntu 12.04.4 и 13.04.
  • каждая виртуальная машина имеет свой собственный общедоступный IP-адрес, с которого исходит трафик
  • через пару минут-часов можно снова скачать файл со скоростью >5 мб/с пару раз (кажется раз 10)
  • файлы загружаются из приложений rails с помощью гема тумана

Тесты с wget:

Используя wget, вы видите этот вывод на затронутых машинах для файла, который мы загрузили:

--2014-07-31 16:33:38--  http://s3-eu-west-1.amazonaws.com/not_the_real_file_url
Resolving s3-eu-west-1.amazonaws.com (s3-eu-west-1.amazonaws.com)... 178.236.6.160
Connecting to s3-eu-west-1.amazonaws.com (s3-eu-west-1.amazonaws.com)|178.236.6.160|:80...      connected.
HTTP request sent, awaiting response... 200 OK
Length: 2801149 (2.7M) [text/plain]
Saving to: `/dev/null'

0% [                                ] 10,111      1.05K/s  eta 68m 26s

и так остается на 68м! (хотя по истечении этого времени загрузка завершается)

И этот вывод для случайного файла, размещенного на amazon s3 кем-то другим:

--2014-07-31 16:39:21--  https://s3.amazonaws.com/Minecraft.Download/versions/14w31a/minecraft_server.14w31a.jar
Resolving s3.amazonaws.com (s3.amazonaws.com)... 72.21.211.199
Connecting to s3.amazonaws.com (s3.amazonaws.com)|72.21.211.199|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10342238 (9.9M) [application/octet-stream]
Saving to: `/dev/null'

32% [====================================>    ] 3,370,945    747K/s  eta 12s

Наш текущий обходной путь

Наше текущее решение — использовать наш HAProxy в качестве прозрачного HTTP-прокси.

Это означает, что у нас есть внешний интерфейс «cloud.example.com» и внутренний интерфейс, который сначала заменяет запросы HOST на «s3-eu-west-1.amazonaws.com», а затем использует s3-eu-west-1.amazonaws. com:80 в качестве сервера. Для Amazon это выглядит так, как будто запрос исходит от нашего прокси-сервера, и мы можем снова загружать файлы, которые мы хранили на S3, тысячи раз. :)

[2014-07-31 16:56:57 +0200] RUN[28] AVG: '0.9612743812142854' s, LAST_RUN: '0.711118431' s
--2014-07-31 16:56:57--  https://cloud.example.com/not_the_real_file_url
Resolving cloud.example.com (cloud.example.com)... 1.2.3.4
Connecting to cloud.example.com (cloud.example.com)|1.2.3.4|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2801149 (2.7M) [text/plain]
Saving to: `/dev/null'

100%[====================>] 2,801,149   2.47M/s   in 1.1s

ubuntu amazon-web-services amazon-s3 kvm libvirt
person pangdudu    schedule 31.07.2014    source источник
comment
Звучит как какое-то зло со стороны вашего провайдера :/   -  person Undo    schedule 31.07.2014
comment
Мы размещены по адресу: Hetzner (что-то вроде крупного немецкого провайдера). Я спрошу их, могут ли они объяснить такое поведение. До сих пор у нас не было таких проблем с нашими машинами.   -  person pangdudu    schedule 31.07.2014
comment
Хорошо, я проверил с нашим провайдером сейчас. они исключили, что это проблема на их стороне. Я думаю, это должно быть как-то связано с настройкой нашего сервера (ubuntu). Отключение ufw ничего не решило. Опубликую, если я наконец найду причину этой странной проблемы.   -  person pangdudu    schedule 15.09.2014

Ответы (1)


arrow_upward
3
arrow_downward

Хорошо, решил.

Я все еще изучаю, почему это решило проблему, но вот что исправило ее сейчас:

Как я описал выше, поведение происходит в Ubuntu 12.04.5 KVM-Guest, работающем в системе Ubuntu 12.04.4 KVM-Host. Сегодня я посмотрел, используем ли мы разные ядра (linux-image-*) для гостей (что все еще может произойти, поскольку мы еще не предоставляем им puppet).

В гостевых KVM, где у нас странное поведение загрузки S3 со скоростью ‹5 КБ/с, мы используем:

  • Linux 3.8.0-44-общий

В гостевых KVM со скоростью загрузки S3 > 5 МБ/с мы используем:

  • Linux 3.2.0-68-virtual (фактически любой *-virtual решит эту проблему)

Надеюсь, это поможет вам, если вы столкнулись с той же проблемой. Я опубликую больше, если я действительно понимаю, почему это происходит.

Конечно: я знаю, что вы должны использовать *-виртуальное ядро ​​​​на гостевой виртуальной машине. Почему загрузка только S3 идет медленно, хотя меня это смущает.

person pangdudu    schedule 15.09.2014