Низкая производительность при монтировании файлового ресурса Azure на виртуальной машине Linux

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

Однако при подключении общего файлового ресурса Azure по протоколу SMB я наблюдаю очень низкую производительность записи.

Настройка выглядит следующим образом: я ' Мы запустили Canonical: UbuntuServer: 16.04-LTS: последняя ВМ на ВМ Standard_DS2 .

Когда процесс загрузки завершится, я следую официальным инструкциям , чтобы смонтировать файловый ресурс Azure через SMB.

sudo apt-get install cifs-utils
sudo mkdir -p /mnt/azure
sudo mount -t cifs //<storageaccount>.file.core.windows.net/<file-share-name> /mnt/azure/ -o vers=3.0,username=<storageaccount>,password=<base64-encoded>,dir_mode=0777,file_mode=0777,serverino

Затем я запускаю этот простой тест производительности записи:

time for i in $(seq 1 500); do echo "hello!" > /mnt/azure/hello.txt; done

real    0m20.673s
user    0m0.032s
sys     0m0.124s

Как видно, это требует более 20 секунд для завершения. Для сравнения, запустив тот же тест на моем локальном компьютере (с SSD-накопителем), я вижу следующие числа:

time for i in $(seq 1 500); do echo "hello!" > hello.txt; done

real    0m0.031s
user    0m0.004s
sys     0m0.024s

То есть выполняется примерно за 30 милли секунд. Таким образом, при работе с файловым ресурсом Azure коэффициент потери производительности составляет почти 1000.

Ожидаются ли такие показатели производительности или я чего-то упускаю?

3
задан 10 March 2017 в 12:01
2 ответа

Да.

Имейте в виду, что хотя локальный диск и Azure Files по своей сути являются сетевыми хранилищами, более поздние используют API ввода/вывода вместо прямого аппаратного доступа. Задержка будет намного выше. Сказали, что давайте попробуем простую математику:

Вы делаете 500 запросов и каждый раз при открытии и закрытии соединения:

500 запросов / 20.673.sec = 24.18 Req/sec

24.18 / 1000 = 0,02418s для завершения каждого запроса, что замечательно.

Если вам нужна производительность для работы с малым и/или большим количеством файлов, то Azure File Storage не для вашего случая использования. Теоретически оно может достигать 1000 IOPS и 60 МБ/с.

Кроме того, давайте посмотрим правде в глаза, SMB/CIFS очень медленно работает с небольшими файлами.

1
ответ дан 3 December 2019 в 06:56

Я не уверен, что это вся проблема, так как это действительно кажется большой разницей, но имейте в виду:

  1. Azure File Storage - стандартное хранилище, а не премиум-класса, так что это все вращающийся диск, никакого SSD, он всегда будет медленнее вашего SSD.
  2. Ваша работа по сети сейчас, что добавляет немного времени, а это тоже. Различные по размеру ВМ имеют разные ограничения, D2 будет ограничен примерно 1.5Gb/s
1
ответ дан 3 December 2019 в 06:56

Теги

Похожие вопросы