Вопрос

Мой вопрос нацелен на постгры, но ответы могут быть достаточно хорошими из любого фона базы данных.

Мои предположения правильны:

  • Диски имеют фиксированный размер блока?
  • Рейд -контроллер может иметь различный размер блока? Один блок RAID разбит на несколько настоящих дисковых блоков?
  • В файловой системе также есть независимый размер блока, который снова распределяется на размер блока RAID?
  • Postgres работает с фиксированными 8K -блоками. Как здесь происходит сопоставление с размером блока файловой системы? Блоки Postgres 8K объединены файловой системой?

При настройке системы лучше всего иметь все блоки на 8K? Или настройки не реально? Мне также было интересно, могут ли некоторые «неправильные» настройки размера блока угрожать целостности данных в случае сбоя? Может быть, если блок Postgres 8K должен быть разделен на несколько дисковых блоков?

Или ничего не объединяется, и поэтому я теряю пространство диска с каждым несоответствием между определенными размерами блоков?

Это было полезно?

Решение

Дисковые секторы

Диск имеет размер фиксированного сектора, обычно 512 байт или 4096 байт на некоторых современных дисках; Эти диски также будут иметь режим, в котором они эмулируют 512 байтовых секторов. Диск будет иметь треки с различным количеством секторов; Треки ближе к внешней стороне диска имеют больше секторов, так как у них больше места для данной битной плотности. Это обеспечивает более эффективное использование дискового пространства; Как правило, трек будет иметь что -то вроде 1000 512 байтовых секторов на современном диске.

Некоторые структуры форматирования также могут включать в себя информацию об исправлении ошибок в SECOTRS, которая проявляется в дисках, форматируемых низкоуровневыми секторами 520 или 528 байтов. В этом случае сектор все еще имеет 512 байта пользовательских данных. Ни Windows, ни Linux не поддерживают это напрямую, хотя I5OS (IBM Iseries) и различные контроллеры SAN делают.

Обычно сектор/трек/трек переводится в логический блок -адрес; Из -за исторических проблем с обратной совместимостью геометрия (Heads x Sectors x Tracks), наблюдаемая операционной системой (особенно на дисках IDE и SATA), обычно имеет мало общего с его физической структурой.

Рейд -размер полосы

Контроллер RAID может иметь размер полосы для массива, используя полосы (например, RAID-5 или RAID-10). Если массив имеет (для Exmaple) полосу 128K, каждый диск имеет 128 тыс. Смежных данных, а затем следующий набор данных будет на следующем диске. Обычно вы можете рассчитывать на получение приблизительно одной полосы за революцию диска, поэтому размер полосы может повлиять на производительность на определенных рабочих нагрузках.

Выравнивание раздела

Разделение диска может точно соответствовать или не совпадать с полосой RAID, и может вызвать снижение производительности из -за скидных считываний, если он не выровнен. Некоторые системы (например, Server Windows 2008) автоматически настраивают разделы для выравнивания с размерами громкости диска. Некоторые (например, сервер Windows 2003) не будут, и вам нужно использовать утилиту раздела, которая поддерживает выравнивание полос, чтобы убедиться, что они это делают.

Размер блока файловой системы

Файловая система будет выделять блоки хранения в кусках определенного размера. Как правило, это настраивается - например, NTFS будет поддерживать единицы распределения от (IIRC) 4K до 64K. Несоответствие разделам и блоков файловой системы для Raid Stripes может привести к чтению блока с одной файловой системой для генерации нескольких дисковых доступа, где будет необходимо только один, если файловая система блокирует правильно с помощью RAID Stripes.

Размер блока базы данных

База данных будет выделять пространство в таблице или индекс в некотором заданном размере блока. В случае SQL Server это 8K, а 8K - по умолчанию во многих системах. В некоторых системах, таких как Oracle, это настраивается, и на PostgreSQL это вариант времени сборки. На большинстве систем распределение пространства по таблицам обычно выполняется в больших кусках, с блоками, выделенными в этих кусках.

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

Ввод/ocunking

Обычно СУБД на самом деле выполняет свой/вывод в кусках более чем одного блока. Например, на SQL Server все ввод -вывод выполняется в кусках 8 блоков, всего 64 тыс. Всего). На Oracle это настраивается. Случайный осмотр документов PostgreSQL не показывает конкретного описания того, делает ли PostgreSQL это, поэтому я не уверен, как это работает на этой платформе.

Когда вводный/вывод чанк больше, чем размер блока файловой системы, или с смещением с границами RAID -полосы диск из БД может вызвать несколько записей диска, что генерирует штраф за производительность.

Использование пространства диска

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

  • Рейдовые полосы и перегородки - раздел должен начинаться на границе рейдовой полосы.

  • Распределение ввода/вывода файловых систем и границы полосы RAID/раздела - граница RAID полосы должна соответствовать устройству распределения файловой системы и должна быть кратно размером блока распределения файловой системы.

  • Диск размер записи и размер распределения файловой системы. Должны быть отношения 1: 1 между операциями ввода/вывода базы данных и операциями ввода/вывода файловых систем.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с dba.stackexchange
scroll top