Различия

Показаны различия между двумя версиями страницы.

--- linux:zfs:deep_info [2023/11/03 14:17]
admin
+++ linux:zfs:deep_info [2023/11/04 17:06] (текущий)
admin [Производительность]
@@ Строка 4: / Строка 4: @@
 Zettabyte File System - ФС с деревом Меркла, от Sun Microsystems, создана в 2004-2005 гг для Solaris.\\
 Поддерживает большие объемы данных, объединяет концепции файловой системы, массивов RAID, менеджера логических томов, принципы легковесных файловых систем, представляет простое управление томами хранения данных\\
+<details>
+<summary>:!: Подробнее</summary>
 На момент создания была новаторской, есть открытая реализация "OpenZFS"\\
 Обеспечивает полный контроль над физическими носителями и логическими томами и постоянное поддержание консистентности ФС.\\
@@ Строка 10: / Строка 13: @@
 Собсна в открытом доступе есть именно "OpenZFS", он появился сразу после закрытия исходников первого, основан основателями ZFS\\
 По сути из-за формальностей, OpenZFS распространяется под лицензией "CDDL" из за чего не может быть включена в ядро Linux по умолчанию, поэтому есть танцы с ее установкой, но в целом у каждой собаки есть инструкция как на нее поставить ZFS\\
-<details>
-<summary>:!: Подробнее</summary>
 Основные преимущества:\\
   * объединенное хранилище
@@ Строка 122: / Строка 123: @@
 В рамках пула, каждый уникальный блок данных будет хранится только на одном Vdev\\
 {{:linux:zfs:2023-10-28_14-13.png?direct&400|}}\\
+{{:linux:zfs:2023-11-03_21-47.png?direct&400|}}\\
 <details>
@@ Строка 251: / Строка 252: @@
 ===== ARC =====
-Adaptive Replacement Cache (Адаптивный кэш замены)\\
+Adaptive Replacement Cache (Кэш адаптивной замены)\\
 <details>
@@ Строка 320: / Строка 321: @@
+<details>
+<summary>:!: Про размеры </summary>
+[[https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSARCItsVariousSizes|Doc]]\\
+Текущий общий размер указан в "**arc_size**". ARC и содержит "**MRU**" i "**MFU**", у которых так же есть метрики "**size**", но общий размер это не только сумма этих двух\\
+В общем то содержит в себе "**data_size**", "**metadate_size**", "**bonus_size**", "**dnode_size**", "**dbuf_size**", "**hdr_size**", "**l2_hdr_size**", "**adb_chuck_waste_size**" (adb - сокращение от буферизированные данные)\\
+Основу составляют "**data_size**" и "**metadata_size**"\\
+"**arc_meta_used**" объединяет все (кроме data_size и adb_chuck_waste_size), которое по сути является метаданными в некотором смысле, это объединение важно поскольку регулируется "**arc_meta_limit**"\\
+Даже если вы не включили сжатие для данных, ZFS может использовать его для метаданных. Для отражения этого есть метрики "**compressed_size**" и "**uncompressed_size**", второе показывает сколько данные весили бы если бы все было без сжатия\\
+"**overhead_size**" данные хранящиеся во всех "**arc_buf_t**", классифицируется как накладные расходы т.к. они будут очищены как только на них перестанут ссылаться, если специально не задано иное\\
+"**arc_p**" (сокращение от раздел) является целевым размером для "**MRU**".\\
+Целевой размер "**MFU**" равен "c - p" и не указывается явно\\
+<code bash>
+c -> Is the total cache size (MRU + MFU)
+p -> represents the limit of MRU
+(c - p) -> represents the limit of MFU
+c_max, c_min -> hard limits
+size -> Total amount consumed by ARC
+</code>
+</details>
-****\\
+==== L2ARC ====
+Является вторым кэшем чтения, перехватывает выпадающие из вашего ARC элементы\\
+При применении небольшого, быстрого диска, с большим резервом перезаписи для кэширования данных ARC, вы можете одновременно уменьшить нагрузку чтения в основном хранилище и увеличить производительность чтения\\
 <details>
 <summary>:!: </summary>
+Хоть L2 и пишется на диск, данные на нем не выдерживают перезагрузку, т.к. индексы этих данных разрушены\\
+Применение L2 становится существенным при наличии большого числа пользователей, приложений, вирт машин, имеющих доступ к одному и тому же набору данных\\
+Если ваш рабочий набор больше чем объем памяти, вашим вторым шансом будет L2\\
+:!: Важный момент в том, что для обслуживания L2 так же используется память\\
+Раз L2 содержит целый набор кэшированых данных и метаданных, индекс этих данных находится в основном ARC\\
+Грубо говоря, **каждый гигабайт L2ARC стоит 25Mb ARC** (в частности зависит от размера секторов, св-ва recordsize и др. вещей), в реальности десятки гигов отнимает запросто\\
+L2ARC **кэширует только выпадающие из ARC данные**, то чего не было в основном кэше сюда не попадет\\
+т.е. если в основном кэше запретить кэшировать метаданных то **и здесь их не будет**, даже если выставить соответствующий параметр\\
+Кэширование потоковой передачей по умолчанию отключено (это когда большие файлы) т.к. основная задержка уходит на позиционирование головки, а после чтение происходить очень хорошо, поэтому смысла нет\\
+При нормальной работе ZFS **пишет только 8Мб в секунду** в каждое устр-во L2ARC. Это позволяет избегать преждевременного "высасывания" SSD и т.н. "пробуксовки" кэша\\
+Параметр настраивается "vfs.zfs.l2arc_write_max"\\
 </details>
+<details>
+<summary>:!: </summary>
+</details>
-****
-****
+===== ZIL =====
+Кэш используется не только для чтения но и для записи, применяя т.н. "**Целевой журнал (ZIL, ZFS Intent Log)**"\\
+Каждый пул имеет свой собственный ZIL\\
-<code bash>
+<details>
-</code>
+<summary>:!: </summary>
+ZFS накапливает данные в этом журнале в т.н. **группы транзакций (txgs, transaction groups)**, затем, при наполнении достаточного объема либо по таймауту, txgs записывается на диск\\
+Группа транзакций может содержать порции данных от разных, не связанных процессов\\
+содержит "запросы на запись", порция данных и связанных с ФС метаданных\\
+"ГТ" является списком "что делать", данные чувствительны к отказам системы пока они полностью не будут записаны на диск, в случае отказа ГП потеряется\\
+Уменьшение таймаута может уменьшить объем потенциальной потери но плохо скажется на производительности\\
+Касательно использования диска ZIL и записывания ZIL на диск, тут есть момент с синхронной/асинхронной записью данных\\
+"Пул применяет ZIL только для синхронно- записываемых данных, асинхронные обычно сохраняются в оперативной памяти и фиксируются как часть регулярной группы транзакций"\\
+</details>
+<details>
+<summary>:!: Выделение отдельного устр-ва</summary>
+Отдельное устр-во называется "SLOG (Separate Intent Log)", перемещая ZIL на отдельное устр-во вы избегаете записи одних и тех же данных дважды на одного поставщика хранения (все таки ZIL похоже применяется, точнее пишется на диск, только в случае синхронной записи, это когда приложение ждет от ядра подтверждения записи данных, вот он и записывает их, ф-я подтверждения это стандартная ф-я, типа fsync(), полагаю разрабам пришлось сделать такой финт для поддержки этого функционала\\
+Однако есть момент, при монтировании ФС есть флаги запрещающие синхронную запись, тогда подтверждение будет ложным и мгновенным)\\
+Дак вот, вынос на отдельное устр-во, если оно быстрее аппаратно, ну и запись единожды\\
+Второй момент, отдельное устр-во это только устр-во, ZIL как таковая служба продолжает работать, просто на этом устр-ве, "ZIL" работает на "SLOG", если "SLOG" выходит из строя, ZIL автоматом переключается на основной пул, снова\\
+метрика "**dirty_data_max**" похоже связана с размером ZIL\\
+</details>
+===== Производительность =====
+[[http://onreader.mdl.ru/AdvancedZFS/content/Ch08.html|Doc]]\\
+Обычно имеется четыре основных ресурса:\\
+  * **В/В системы хранения**
+  * **Пропускная способность сети**
+  * **Оперативная память**
+  * **ЦП**
+Производительность системы всегда определяется самым ее медленным компонентом !!!\\
 <details>
 <summary>:!: </summary>
+Например сжатие ZFS уменьшает объем записываемых и считываемых данных, за счет процессорного времени, если оно в избытке конечно же, это частая возможность бустанутся\\
 </details>
-=====  =====
+<details>
+<summary>:!: </summary>
+</details>
 <details>
@@ Строка 356: / Строка 461: @@
 </code>
 </details>
@@ Строка 365: / Строка 471: @@
 </code>
 </details>

zxcx

Инструменты пользователя

Инструменты сайта

Различия

Инструменты страницы