После создания нового диска появляется желание проверить его скорость. Например, линейную.
Обескураживающие цифры, правда? При этом если повторить эксперимент, то скорость чтения упадёт, а скорость записи вырастет до положенных 60-150Мб/с.
Причина этого — в copy-on-write режиме работы блочных устройств, обслуживаемых blktap в Xen Cloud Platform.
Не смотря на то, что место на диске под виртуальные машины резервируется в полном объёме, до момента первой записи в блок, читать из него нечего — вместо этого возвращаются нули со «скоростью интерфейса». А при первой записи блок помечается как используемый и записывается целиком (даже если в него записали 1к). Блок большой — аж 4М, так что килобайтная запись приводит к записи 4Мб. Это приводит к характерному подтормаживанию при первой записи. Последующие попытки уже пишут только поменявшиеся данные — и это происходит на несколько порядков быстрее.
Кстати, именно по этой причине mkfs отрабатывает дольше, чем хотелось бы — при первой записи инод и суперблоков на диск пишется довольно много блоков (больше, чем реальный объём записанных данных).
Причин две: во-первых, если мы выделяем клиентам место на хранилище и на этом месте раньше лежал диск другого клиента — может ли новый владелец прочитать содержимое диска? Ответ — нет, так как до первой записи там «пустота» (читать неоткуда), а при первой записи блок перезатирается целиком. Таким образом, эта функция надёжно защищает данные на удалённом диске от доступа третьих лиц.
Во-вторых, некоторые клиенты создают и удаляют диски большого размера. Зачем ради этого писать этак терабайт с гаком?
После первичной записи скорость нормализуется, так что в большинстве случаев никаких особых мер принимать не нужно. Если же есть опасения в производительности случайного доступа к большому «дырявому» файлу (sparsed), то его перезапись с помощью dd позволит нормализовать производительность.
Кстати, пользуясь случаем, хочу напомнить, что нам очень нужны программисты. От того, как быстро у нас найдутся люди на эту вакансию, зависит то, как быстро у нас появятся новые фичи.
dd if=/dev/xvdb of=/dev/null bs=1M count=1000 1048576000 bytes (1.0 GB) copied, 1.29269 s, 811 MB/s dd if=/dev/zero of=/dev/xvdb bs=1k count=1000 10240000 bytes (10 MB) copied, 24.3481 s, 421 kB/s
Обескураживающие цифры, правда? При этом если повторить эксперимент, то скорость чтения упадёт, а скорость записи вырастет до положенных 60-150Мб/с.
Причина этого — в copy-on-write режиме работы блочных устройств, обслуживаемых blktap в Xen Cloud Platform.
Не смотря на то, что место на диске под виртуальные машины резервируется в полном объёме, до момента первой записи в блок, читать из него нечего — вместо этого возвращаются нули со «скоростью интерфейса». А при первой записи блок помечается как используемый и записывается целиком (даже если в него записали 1к). Блок большой — аж 4М, так что килобайтная запись приводит к записи 4Мб. Это приводит к характерному подтормаживанию при первой записи. Последующие попытки уже пишут только поменявшиеся данные — и это происходит на несколько порядков быстрее.
Кстати, именно по этой причине mkfs отрабатывает дольше, чем хотелось бы — при первой записи инод и суперблоков на диск пишется довольно много блоков (больше, чем реальный объём записанных данных).
Зачем это нужно?
Причин две: во-первых, если мы выделяем клиентам место на хранилище и на этом месте раньше лежал диск другого клиента — может ли новый владелец прочитать содержимое диска? Ответ — нет, так как до первой записи там «пустота» (читать неоткуда), а при первой записи блок перезатирается целиком. Таким образом, эта функция надёжно защищает данные на удалённом диске от доступа третьих лиц.
Во-вторых, некоторые клиенты создают и удаляют диски большого размера. Зачем ради этого писать этак терабайт с гаком?
Что делать?
После первичной записи скорость нормализуется, так что в большинстве случаев никаких особых мер принимать не нужно. Если же есть опасения в производительности случайного доступа к большому «дырявому» файлу (sparsed), то его перезапись с помощью dd позволит нормализовать производительность.
Оффтопик
Кстати, пользуясь случаем, хочу напомнить, что нам очень нужны программисты. От того, как быстро у нас найдутся люди на эту вакансию, зависит то, как быстро у нас появятся новые фичи.
