Размер блок: Размеры и вес блок-контейнера | RmRail

03.09.2023

By alexxlab

0 Comment

Содержание

Размер блока в CSS

Главная > Учебник CSS >

Размеры блока по умолчанию

Если в CSS размеры блока не заданы, то они формируются так:

Ширина определяется шириной окна страницы или шириной внешнего блока. Блок занимает всю ширину окна страницы или внешнего блока за исключением отступов.
Высота блока устанавливается такой, чтобы в блок поместилось всё содержимое.

Для примера создадим блок без указания размеров и посмотрим, как он выглядит. Чтобы видеть размеры блока, зададим рамку с помощью свойства border.

Стиль:

7
8
9
10

div
  {
  border: 1px solid Red;
  }

HTML код:

14	<div>Блок без указания размеров</div>

Попробуйте менять ширину окна браузера, Вы увидите, что ширина блока тоже меняется.

Установка размеров блока в CSS

Для установления размеров блока есть свойство width, которое устанавливает ширину, и свойство height, которое устанавливает высоту.

В значениях этих свойств указываются размеры блока в любых единицах, существующих в CSS, например в пикселях. При указании значения, единицы обязательно нужно указывать.

Добавим на страницу ещё один блок с шириной 500 пикселей и высотой 200 пикселей.

15	<div>Блок с размерами</div>

Размеры можно указывать в процентах от внешнего блока. Если внешнего блока нет, то размер будет в процентах от размера страницы. Попробуем оба варианта. В блок с размерами поместим ещё один блок и укажем ему ширину 70%. Также создадим отельный блок и тоже укажем ширину 70%

15
16
17
18
19

<div>
  Блок с размерами
  <div>В процентах от внешнего блока</div>
</div>
<div>В процентах от страницы</div>

Обратите внимание — при изменении ширины окна браузера отдельный блок меняет свою ширину. А тот, который внутри другого блока, остаётся неизменным, ведь его ширина зависит от размера, заданного точно.

У размеров есть значение:

width: auto;

height: auto;

При этом значении размеры блока определяются также, как если они не заданы. Это значение используется, если размер ранее был задан, а теперь его нужно вернуть к начальному.

Также у размеров есть значение:

width: inherit;

height: inherit;

При этих свойствах блок получает значения размеов от родительского элемента.

Браузеры, особенно старые, по-разному определяют CSS размеры блока. Поэтому при установлении размеров нужно тщательно проверять отображение страницы.

Минимальные и максимальные размеры блока

Если в CSS размер блока не задан точно и может меняться, то можно установить минимальный и максимальный размер. Для этого есть свойства min-width, max-width, min-height, max-height.

Для примера создадим ещё один блок размером также 70%. Установим ему минимальную ширину 600 пикселей. Когда Вы будете уменьшать окно браузера, этот блок уменьшится только до 600 пикселей, а далее будет неизменным.

20
21

<div>
Блок в процентах с минимальной шириной</div>

Содержимое за пределами блока

Если блоку заданы размеры, то часть содержимого может не поместиться в блок и оказаться за его пределами. Свойство overflow определяет, как отображается эта часть содержимого. Значения:

overflow: visible — отображается и не учитывает границы (по умолчанию)

overflow: hidden — не отображается

overflow: scroll — содержимое не выходит за границы, а у блока есть полосы прокрутки

overflow: auto — пока содержимое полностью помещается в блок, полос прокрутки нет. А когда содержимое перестаёт помещаться, они появляются

overflow: inherit — значение принимается от родительского элемента

Создадим блок с контентом, выходящим за его пределы. Свойство overflow пока не устанавливаем.

22
23
24
25

<div>
Элемент<br>с большим<br>количеством<br>содержимого<br>
которое<br>занимает<br>несколько<br>строк</div>
<div>Следующий элемент</div>

Текст этого блока выходит за границы и накладывается на другие элементы страницы.

Установим свойство overflow:

<div>

Теперь содержимое за границами блока не отображается. Для текста это не подходит, ведь пользователь не сможет его прочитать. Попробуйте установить другие значения. Со значением scroll блок имеет обе полосы прокрутки. А со значением auto горизонтальной прокрутки нет, ведь содержимое помещается в блок по ширине.

Существуют свойства overflow-x и overflow-y, которые отдельно устанавливают отображение содержимого по ширине и высоте. Они имеют те же значения.

Изменение размеров в CSS — Изучение веб-разработки

Назад
Обзор: Building blocks
Далее

В предыдущих уроках вы познакомились с некоторыми способами изменения размеров элементов на веб-странице с помощью CSS. Понимание того, насколько велики будут различные элементы в вашем дизайне — важно, и в этом уроке мы подведем итог по различным способам задания размеров элементов с помощью CSS и расскажем о некоторых терминах, связанных с размерами, которые помогут вам в будущем.

Необходимые условия:	Базовая компьютерная грамотность, Установка базового ПО, базовые знания работы с файлами, основы HTML (Введение в HTML), и общее представление о том, как работает CSS (Введение в CSS.)
Цель:	Изучить различные способы задания размеров объектов в CSS.

Элементы HTML имеют размеры по умолчанию, заданные до того, как на них повлияет какое-либо правило CSS. Простой пример — изображение. Изображение имеет ширину и высоту, определенные в файле изображения. Этот размер называется — внутренний размер, он исходит из самого изображения.

Если вы разместите изображение на странице и не измените его высоту и ширину, используя атрибуты тега <img> или CSS, оно будет отображаться с использованием этого внутреннего размера. В примере ниже, мы установили для изображения рамку, чтобы вы могли видеть размер файла.

С другой стороны, пустой <div> не имеет собственного размера. Если вы добавите <div> в свой HTML-код без содержимого, а затем установите для него рамку, как мы это делали с изображением, вы увидите линию на странице. Это схлопнувшиеся границы элемента — содержимое, которое могло бы удерживать ее в открытом состоянии, отсутствует. В нашем примере ниже эта граница растягивается на всю ширину контейнера, потому что это элемент блочный, поведение которого должно быть вам знакомо. У него нет высоты, потому что нет содержимого.

В приведенном выше примере попробуйте добавить текст внутри пустого элемента. Этот текст теперь становится охваченным границами, потому что высота элемента определяется содержимым. Следовательно, размер этого <div> устанавливается размером содержимого. Как и в предыдущем примере, этот размер является внутренним размером — размер элемента определяется размером его содержимого.

Конечно, мы можем задать элементам нашей страницы определенный размер. Размер, который присваивается элементу (содержимое, которого затем должно соответствовать этому размеру), называется

внешним размером.

Возьмите наш <div> из примера выше и установите ему специальные значения width и height и теперь он будет иметь эти размеры, независимо от того, какого размера содержимое в него помещается. Как мы узнали в нашем предыдущем уроке о переполнении, заданная высота блока может вызвать переполнение содержимого, если размер содержимого больше, чем внутреннее пространство элемента.

Из-за этой проблемы перекрытия, жестко задавать высоту элементов с помощью длины или процентного соотношения — это то, что нужно делать с большой осторожностью.

Использование процентного соотношения

Во многих отношениях проценты действуют как единицы длины, и, как мы обсуждали в уроке, посвященном значениям и единицам, они часто могут использоваться как взаимозаменяемые с длиной. При использовании процентов вы должны знать, от чего этот процент рассчитывается. В случае блока внутри другого блока, если вы зададите дочернему блоку процентную ширину, это будет процент от ширины родительского контейнера.

Это потому, что проценты рассчитываются в зависимости от размера содержащего элемент блока. Если процентное соотношение не применяется, наш <div> будет занимать 100% доступного пространства, так как это элемент блочного типа. Если мы зададим ему ширину в процентах, он займет процент от пространства, которое он обычно заполняет.

Margins и paddings в процентах

Если вы установите margins и padding в процентах, вы можете заметить странное поведение. В приведенном ниже примере у нас есть блок. Мы присвоили внутреннему блоку margin 10% и padding 10%. Padding и margin сверху и снизу имеют тот же размер, что и margins слева и справа.

Например, вы можете ожидать, что процентное значение верхнего и нижнего margins будет в процентах от высоты элемента, а процентное левое и правое margins — в процентах от ширины элемента. Тем не менее, это не так!

При использовании margins и padding, заданных в процентах, значение рассчитывается на основе inline размера блока — следовательно, ширины при работе с горизонтальным языком. В нашем примере все поля и отступы составляют 10% width. Это означает, что вы будете иметь margins и padding одинакового размера по всему полю. Этот факт стоит запомнить, если вы действительно пользуетесь процентами.

Помимо возможности установить фиксированный размер, мы можем использовать CSS чтобы задать элементу минимальный или максимальный размер. Если у вас есть блок, который может содержать разное количество содержимого, и вы хотите, чтобы он всегда был определенной минимальной высоты, вы можете установить для него свойство min-height. Блок всегда будет минимальной заданной высоты, пока содержимого не станет больше, чем места в блоке.

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

Это очень полезно при работе с переменным объемом контента, избегая при этом переполнения.

Часто max-width применяют для уменьшения масштаба изображений, если недостаточно места для их отображения.

Например, если бы вы установили width: 100% для изображения, а его внутренняя ширина была меньше, чем его контейнер, изображение было бы вынуждено растягиваться и становиться больше, в результате чего оно выглядело бы пикселизированным.

Если бы вы вместо этого применили max-width: 100%, и внутренняя ширина изображения была бы меньше, чем его контейнер, изображение не будет принудительно растягиваться и становиться больше, что предотвращает пикселизацию.

В приведенном ниже примере мы использовали одно и то же изображение трижды. Первому изображению было задано width: 100% и оно находится в контейнере, который больше его ширины, поэтому он растягивается до ширины контейнера. Второму изображению задано max-width: 100%, изображение достигло 100% своей ширины не растягивается, чтобы заполнить контейнер. Третье поле снова содержит то же изображение, также с max-width: 100% в этом случае вы можете увидеть, как он уменьшилось, чтобы поместиться в контейнер.

Этот метод используется для создания отзывчивых изображений, чтобы при просмотре на меньшем устройстве они соответствующим образом уменьшались. Однако вам не следует использовать эту технику для загрузки действительно больших изображений с последующим их уменьшением в браузере. Изображения должны иметь соответствующий размер, чтобы быть не больше, чем они должны быть для самого большого размера, отображаемого в дизайне. Загрузка слишком больших изображений замедлит работу вашего сайта и может стоить пользователям больше денег, если они используют лимитированное соединение.

Примечание: Узнайте больше о методах создания адаптивных изображений.

Вьюпо́рт — это видимая область вашей страницы в браузере, который вы используете для просмотра сайта. В CSS у нас есть единицы измерения, которые относятся к размеру вьюпорта — vw единицы ширины вьюпорта и vh высоты вьюпорта. Используя эти единицы измерения, вы можете изменять размер чего-либо относительно вьюпорта пользователя.

1vh равен 1% от высоты вьюпорта и 1vw равен 1% ширины вьюпорта. Вы можете использовать эти единицы измерения для размеров блоков, а также текста. В приведенном ниже примере у нас есть блок размером 20vh и 20vw. В блоке есть буква A, которой присвоено значение font-size 10vh.

Если вы измените величину vh и vw — это изменит размер блока или шрифт; изменение размера вьюпорта также изменит их размеры, поскольку они имеют размер заданный относительно вьюпорта. Чтобы увидеть изменение примера при изменении размера вьюпорта, вам нужно будет загрузить пример в новое окно браузера, размер которого можно изменить (поскольку встроенное приложение <iframe>, содержащее показанный выше пример, является его окном просмотра). Откройте пример, измените размер окна браузера и посмотрите, что происходит с размером поля и текста.

Размеры объектов задаваемые в соответствии с вьюпортом могут быть полезны в ваших проектах. Например, если вы хотите, чтобы основная секция отображалась перед остальным контентом, установите для этой части страницы высоту 100vh, это приведет к выталкиванию остального контента ниже видимой области, что означает, что он появится только после того, как страницу прокрутят вниз.

В этой статье мы рассмотрели многое, но можете ли вы вспомнить самую важную информацию? Вы можете найти дополнительные тесты, чтобы убедиться, что вы сохранили эту информацию, прежде чем двигаться дальше — см. Проверка своих навыков: задание размеров (en-US).

Этот урок дал вам краткое изложение некоторых ключевых проблем, с которыми вы можете столкнуться при определении размеров объектов в Интернете. Когда вы перейдете к CSS раскладке, изменение размеров станет очень важным для освоения различных методов раскладки, поэтому перед тем, как двигаться дальше, стоит разобраться в концепциях.

Назад
Обзор: Building blocks
Далее

Каскад и наследование
Селекторы CSS
- Селекторы типа, класса и ID
- Селекторы атрибута
- Псевдоклассы и псевдоэлементы
- Комбинаторы
Блочная модель(The box model)
Фон и границы
Обработка разных направлений текста
Переполнение содержимого
Значения и единицы измерения
Размеры в CSS
Элементы изображений, форм и медиа-элементы
Стилизация таблиц
Отладка CSS
Организация вашей CSS

Found a content problem with this page?

Edit the page on GitHub.
Report the content issue.
View the source on GitHub.

Want to get more involved?

Learn how to contribute.

This page was last modified on 7 нояб. 2022 г. by MDN contributors.

Порядковые номера биткойнов: споры о размере блока биткойнов

О чем споры о размере блока биткойнов?

Ordinals предложили захватывающий новый сдвиг в повествовании о блокчейне Биткойн, позволив пользователям вписывать данные в каждый отдельный сатоши, наименьшую единицу Биткойн. Эти данные варьируются от видео до файлов и многого другого, создавая в процессе цифровые артефакты.

Однако размещение больших объемов данных непосредственно в цепочке блоков напрямую влияет на размер блока Биткойн — и без того спорный вопрос для цепочки криптовалют и пользовательской базы Биткойн. По мере роста спроса на ординалы размер блока также является одной из ключевых проблем, которые необходимо решить сообществу.

Давайте разберемся, в чем суть дебатов о размере порядкового блока и каковы их последствия для блокчейна.

Что такое спор о размере блока биткойнов?

Дебаты о пространстве блоков биткойнов всегда были горячим вопросом в сообществе биткойнов, даже до того, как были введены ординалы. Он основан на том факте, что размер блока биткойнов определяет, сколько биткойн-транзакций может быть включено в конкретный блок. Чем больше размер блока, тем быстрее могут обрабатываться транзакции — ключевой аргумент в пользу увеличения размера блока.

Однако увеличение размера блока BTC может произойти за счет децентрализации. Обработка блока большего, чем средний, размера требует лучшего оборудования и пропускной способности, что создает барьер для входа на рынок майнеров. Узлу также потребуется загружать много данных, чтобы работать.

Споры о размере блока были в центре многих решений по обновлению биткойнов и изменений протокола. Одним из самых громких решений стал SegWit в 2017 году, который в итоге увеличил ограничение на размер блока с 1 МБ до 4 МБ. Это, однако, также привело к хард-форку и созданию Bitcoin Cash с членами сообщества, которые возражали против изменения.

Порядковые номера: за самыми большими блоками Биткойн

Обновление Биткойн, которое произошло в 2021 году, Taproot улучшил обновление SegWit, объединив несколько биткойн-транзакций вместе и увеличив емкость блока. Однако уникальность Taproot заключается в том, что он представил концепцию «свидетельских» данных, позволяющую пользователям публиковать отслеживаемые данные в блокчейне через сатоши. По сути, саты можно было пронумеровать. Это породило создание ординалов.

Учитывая характер порядковых данных, они могут занимать довольно много места в блокчейне. Давайте посмотрим на изменения в размере блока биткойнов после порядковых номеров.

Средний размер блока биткойнов и ограничение

В то время как средний размер блоков раньше колебался в пределах 1-2 мегабайт, данные Glassnode показывают, что в последнее время средний размер блока биткойнов составляет 3-3,5 МБ. Это очень близко подводит нас к пределу размера блока Segwit в 4 МБ, и прогнозируется, что это среднее значение будет только увеличиваться.

Большинство самых больших блоков Биткойн были созданы после того, как в январе 2023 года были введены порядковые номера.

Самый большой блок, 3,9 МБ, был в основном «порядковым» блоком — изображением лысого бородатого волшебника Taproot и всего 63 транзакциями. Излишне говорить, что этот рекордный блок возродил дискуссию вокруг пространства блока Ordinals.

Блокировка Аргумент в пользу ординалов

Хотя нельзя отрицать, что ординалы занимают довольно много места, аргументы в пользу ординалов в основном сосредоточены на том, что это не так уж и плохо.

Во-первых, давайте разберемся, как работает экономика добычи биткойнов. Майнеры получают биткойны в качестве вознаграждения за каждый добытый ими блок. Эти вознаграждения состоят из двух основных компонентов: вознаграждения за блок и комиссии за транзакцию. Награды за блоки фиксированы для каждого блока, и они уменьшаются вдвое за каждый цикл деления биткойнов вдвое. Это означает, что стимулы для майнеров сокращаются вдвое каждые четыре года, что может быть компенсировано только увеличением стоимости биткойнов.

Порядковые номера могут помочь с этой проблемой. Сторонники утверждают, что увеличение размера блока означает более высокую комиссию за транзакцию. Более высокие комиссии за транзакции могут стимулировать увеличение количества операций майнеров, что принесет пользу системе в целом. Например, Ordinals заработала майнерам более 1,31 миллиона долларов, а запуск крупных проектов принес более 170 тысяч долларов в день.

Блок-аргумент против порядковых номеров

Биткойн изначально задумывался как платежная система, и критики утверждают, что блоки с надписью биткойн вместо этого используются в качестве хранилища файлов. Учитывая ограничение размера блока Биткойна, использование блоков для чего-либо, кроме финансовых транзакций, не устраивает критиков.

Кроме того, хранение файлов в блокчейне приводит к множеству масштабных проблем, в частности к раздуванию сети, как мы видели ранее в Ethereum.

По мере увеличения размера блоков увеличивается вероятность перегрузки сети. Это может вызвать волновой эффект на скорость транзакций, что приведет к задержкам. В сети, которую уже критикуют за медленное подтверждение транзакций, задержки во времени блокировки могут стать серьезной проблемой. Несмотря на то, что сеть Lightning Network и компьютеры Trust предприняли шаги для решения этой проблемы, для ординалов может потребоваться более совершенная инфраструктура.

Более высокие комиссии за транзакции из-за ординалов также представляют риск для пользователей, которые полагаются на блокчейн Биткойн для повседневных транзакций. Например, нигерийские объемы P2P BTC в начале 2022 года превысили 400 миллионов долларов. Увеличение комиссий может создать системный риск доступа к этой системе, где сеть Биткойн может стать слишком дорогой для использования.

К порядковому номеру или не к порядковому?

Как мы видим, введение ординалов может иметь долгосрочные последствия для функционирования блокчейна Биткойн. С одной стороны, это может привести к увеличению активности в цепочке, а с другой — вызвать проблемы с пользовательским интерфейсом.

Хотя порядковые номера, безусловно, вызвали некоторые споры, они также вызвали всплеск интереса к биткойнам, открыв новые варианты использования цепочки, помимо NFT. Например, такие инновации, как суверенные накопительные пакеты, используют ту же базовую технологию, что и Ordinals, но с намерением масштабировать блокчейн.

Хотя возможные проблемы с Ordinals еще предстоит решить, одно можно сказать наверняка: Ordinals показали нам способ расширения экосистемы самого безопасного блокчейна в мире. Во многих отношениях он уже предлагал функциональные возможности, выходящие за рамки того, что изначально предполагал Сатоши Накамото, когда они впервые создавали цифровой актив.

Поделиться этой статьей

Выгодно ли клиентам AWS размер блока 64 КБ для хранилища SQL Server?

Алекс Заренин, Аарон Адамс, Суприт Кришнаппа С. и Викас Бабу Гали | на 11 МАЯ 2023 | в Amazon Elastic Block Store (Amazon EBS), Amazon FSx для файлового сервера Windows, базы данных, передового опыта, Windows на AWS | Постоянная ссылка | Делиться

В этом сообщении блога мы поделимся результатами тестирования производительности Microsoft SQL Server с использованием Amazon FSx для Windows File Server (Amazon FSx) и Amazon Elastic Block Store (Amazon EBS) с размерами блоков в диапазоне от 16 КБ до 64 КБ, чтобы доказать или опровергнуть распространенное мнение о том, что для оптимальной производительности SQL Server требуется блок размером 64 КБ.

Введение

Интернет изобилует рекомендациями использовать размер блока 64 КБ или единицы распределения при форматировании накопителей для баз данных SQL Server. Многие из этих предложений возникли в эпоху вращающихся жестких дисков и SQL Server 2005 и 2008. С тех пор архитектура хранения претерпела изменения, особенно с появлением дисков SSD, которые стали преимущественно использоваться в высокопроизводительных развертываниях баз данных. Кроме того, после SQL Server 2008 были представлены более новые версии SQL Server с различными улучшениями доступа к хранилищу.

Обоснование этих рекомендаций связано с тем, как SQL Server управляет хранилищем. Основной единицей хранения данных в SQL Server является страница размером 8 КБ с восемью смежными страницами данных, представляющими экстент размером 64 КБ. В последнее время в некоторых статьях и сообщениях в блогах утверждается, что большинство операций чтения и записи в современных версиях SQL Server не выполняются в экстентах размером 64 КБ. Несмотря на это, рекомендации по единице выделения 64 КБ по-прежнему появляются в документации Microsoft. Поэтому некоторые клиенты, развертывающие экземпляры отказоустойчивого кластера SQL Server (FCI), выразили обеспокоенность тем, что Amazon FSx для Windows использует единицу выделения 16 КБ при форматировании хранилища.

Чтобы решить эти проблемы, мы провели серию тестов производительности SQL Server, чтобы определить, влияет ли размер единицы распределения на производительность SQL Server. Учитывая разнообразие рабочих нагрузок SQL Server, мы сосредоточились на обычном случае рабочих нагрузок OLTP. Для запуска тестов мы использовали HammerDB, ведущее программное обеспечение для бенчмаркинга и нагрузочного тестирования.

Подход к тестированию производительности

Чтобы избежать возможных узких мест в сети при подключении к Amazon FSx, мы разместили наш экземпляр SQL Server в облаке Amazon Elastic Compute Cloud (Amazon EC2), оптимизированном для памяти r6i. 32xlarge , обеспечивающий пропускную способность сети 200 Гбит/с. В качестве тестовой рабочей нагрузки мы создали базу данных HammerDB TPROC-C, которая очень похожа на обычные базы данных OLTP. Чтобы изучить влияние производительности хранилища на SQL Server, мы настроили эту базу данных с 75 000 хранилищ, в результате чего размер базы данных составляет примерно 8 ТБ. Этот размер значительно превышает 1 ТБ оперативной памяти, доступной на инстансе r6i.32xlarge EC2, используемом для тестирования. При настройке тестового скрипта HammerDB мы выбрали опцию «Использовать все хранилища», чтобы увеличить нагрузку на подсистему хранения.

Чтобы зафиксировать максимальную производительность, достигнутую для каждой конфигурации хранилища, мы провели несколько тестов с различными уровнями нагрузки от 362 до 1024 виртуальных пользователей. Чтобы обеспечить статистическую согласованность, мы провели три теста для каждого уровня нагрузки и рассчитали среднее значение результатов.

Тестирование с различными единицами распределения на Amazon FSx для Windows

При создании файловой системы Amazon FSx для Windows выделенное хранилище форматируется с использованием единиц выделения 16 КБ или размера блока. Для проведения нашего тестирования мы привлекли группу обслуживания Amazon FSx, чтобы помочь нам в создании пользовательских инстансов Amazon FSx с единицами распределения 16 КБ, 32 КБ и 64 КБ. Помимо разницы в размере блока, мы одинаково настроили все три экземпляра Amazon FSx с объемом хранилища 26 ТБ, чтобы достичь 80 000 операций ввода-вывода в секунду и пропускной способности 2 ГБ/с. Эта настройка позволила нам приписать любую разницу в производительности SQL Server единственному отличающемуся свойству — размеру блока.

В таблице 1 представлены результаты наших испытаний, а на рисунке 1 показана соответствующая диаграмма. Вот производительность SQL Server для каждой контрольной точки, представленная показателем новых заказов в минуту (NOPM) HammerDB:

Таблица 1. Результаты тестирования производительности SQL Server в зависимости от размера блока FSx.

Рис. 1. Результаты тестирования производительности SQL Server в зависимости от размера блока FSx.

Данные в Таблице 1 и на Рисунке 1 показывают, что производительность SQL Server при тестировании HammerDB смоделированной рабочей нагрузки OLTP не зависит от размера единицы распределения — результаты для разных размеров блоков статистически неразличимы в пределах повторяемости HammerDB!

Чтобы объяснить эти результаты, мы также собрали средние объемы операций чтения и записи на операцию с диском, используя метрики Amazon CloudWatch для Amazon FSx.

Рисунок 2. Средний размер операции READ, размер блока 16 КБ.

Рис. 3. Средний размер операции READ, размер блока 32 КБ.

Рис. 4. Средний размер операции READ, размер блока 64 КБ.

Как показано на рисунках 2, 3 и 4, средний размер операции чтения составляет чуть более 8 КБ. Это говорит о том, что большинство операций чтения работают с одной страницей размером 8 КБ, и очень немногие операции чтения обрабатывают более одной страницы за раз. Обратите внимание на ту же ситуацию для операций записи, как показано на рисунках 5, 6 и 7.

Рис. 5. Средний размер операции записи, размер блока 16 КБ.

Рис. 6. Средний размер операции записи, размер блока 32 КБ.

Рис. 7. Средний размер операции записи, размер блока 64 КБ.

Тестирование с разным размером блока на Amazon EBS

Затем мы выполнили следующий логический набор тестов для SQL Server, настроенного на использование тома Amazon EBS в качестве хранилища базы данных. Чтобы результаты тестов Amazon EBS были сопоставимы с нашими результатами для Amazon FSx, мы настроили наш инстанс Amazon EC2, на котором размещена база данных SQL Server, с объемом IO2 Block Express EBS 26 ТБ и выделенным IOPS 80 000. Учитывая простоту форматирования томов EBS, мы расширили нашу серию тестов, включив тома, отформатированные с блоками по 4 КБ и 8 КБ, помимо блоков по 16, 32 и 64 КБ, соответствующих нашему форматированию хранилища для Amazon FSx.

В таблице 2 и на рисунке 8 представлены результаты нашего тестирования производительности. Из-за вертикального масштаба с высоким разрешением на рисунке 8 может показаться, что разные размеры блоков приводят к разным уровням производительности, но это всего лишь артефакт масштаба. Разница между результатами для соответствующих точек данных составляет около 0,5%, что находится в пределах точности бенчмаркинга HammerDB.

Таблица 2. Результаты тестирования производительности SQL Server в зависимости от размера блока EBS.

Рис. 8. Результаты тестирования производительности SQL Server в зависимости от размера блока EBS.

Как и при использовании Amazon FSx, средний размер операций чтения и записи постоянно составлял около 9 КБ, когда мы использовали том EBS с различными размерами единиц распределения.

Заключение

На основании результатов нашего тестирования мы пришли к выводу, что для моделируемой рабочей нагрузки OLTP с использованием HammerDB производительность SQL-сервера не зависит от размера единицы распределения базовой подсистемы хранения. Это должно облегчить беспокойство наших клиентов по поводу форматирования хранилища Amazon FSx с блоками по 16 КБ.

Даже при использовании Amazon EBS в качестве подсистемы хранения для развертывания SQL Server, когда клиенты имеют полный контроль над форматированием тома, нет необходимости форматировать том блоками по 64 КБ для достижения наилучшей производительности для рабочей нагрузки SQL Server OLTP.

Хотя существуют и другие аспекты работы SQL Server, такие как резервное копирование, которые не были включены в наше тестирование, наши результаты показывают, что для обычных операций OLTP размер блока хранилища не влияет на производительность.

AWS может помочь вам оценить, как ваша компания может получить максимальную отдачу от облака. Присоединяйтесь к миллионам клиентов AWS, которые доверяют нам миграцию и модернизацию своих наиболее важных приложений в облаке. Чтобы узнать больше о модернизации Windows Server или SQL Server, посетите страницу Windows на AWS. Свяжитесь с нами, чтобы начать миграцию сегодня.

ТЕГИ: Amazon FSx, EBS, Microsoft, оптимизация, производительность, SQL Server, хранилище

Алексей Заренин

Алекс Заренин — ведущий архитектор решений в Amazon Web Services. Он работает с компаниями, предоставляющими финансовые услуги, разрабатывая и внедряя широкий спектр технических решений. Обладая знаниями в области технологий Microsoft, Алекс имеет более чем 30-летний технический опыт как в коммерческом, так и в государственном секторах. Алекс имеет докторскую степень. в области компьютерных наук из Нью-Йоркского университета.

Аарон Адамс

Аарон Адамс — архитектор решений в AWS, базирующийся в Нью-Йорке. Он помогает корпоративным клиентам на северо-востоке США ускорить внедрение облака AWS, предоставляя рекомендации по архитектуре для разработки инновационных и масштабируемых решений. До прихода в AWS он провел большую часть своей карьеры в качестве системного инженера предпродажной подготовки в области резервного копирования и аварийного восстановления, помогая клиентам соответствовать требованиям и нормативным требованиям, а также защищаться от программ-вымогателей.

Суприт Кришнаппа С.

Суприт Кришнаппа С. — консультант по базам данных в группе профессиональных услуг Amazon Web Services. Он работает с корпоративными клиентами, предлагая техническую поддержку и разрабатывая клиентские решения для проектов баз данных, а также помогая им в переносе и модернизации существующих баз данных в облако AWS.

Викас Бабу Гали

Викас Бабу Гали — специалист по архитектуре решений, специализирующийся на рабочих нагрузках Microsoft в Amazon Web Services.