Различия

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

--- linux:zfs:deep_info [2023/10/29 06:18]
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>
@@ Строка 246: / Строка 247: @@
 Сколько IOPS даст оперативная память, столько и будет. При этом целостность ZFS обеспечивает в любом случае - при потере питания произойдет откат на последнюю целую транзакцию\\
 В худшем случае теряется последние несколько сек записи, то что настроено в "**tgx_timeout**", по умолчанию до 5 сек и плюс на заданный размер\\
+</details>
+===== ARC =====
+Adaptive Replacement Cache (Кэш адаптивной замены)\\
+<details>
+<summary>:!: Некоторая статистика</summary>
+[[https://utcc.utoronto.ca/~cks/space/blog/linux/ZFSOnLinuxARCMemoryStatistics|Doc]]\\
+ZFS сообщает некоторую информацию об ARC в **/proc/spl/kstat/arcstats**\\
+Параметром размера является "**arc_c**". Который ARC считает целевым размером\\
+Есть три метрики ОЗУ "**memory_all_bytes**", "**memory_free_bytes**" и "**memory_available_bytes**", общий, доступный и доступный для расширения ZFS объем оперативы, по мнению ZFS конечно же\\
+Доступный ей объем может быть отрицательным, тогда ARC сжимается\\
+"**memory_availabe**" это "**memory_free**" минус "**arc_sys_free**" (параметр, сколько ОЗУ нужно оставлять системе, по умолчанию 1/32, хотя говорится 1/64 от общего объема)\\
+Может ли ARC расти в данный момент, показано в "**arc_no_grow**", равен 1 когда нет. Как правило включается и остается включенным если "**memory_available**" меньше 1/32 от "**arc_c**"\\
+При приближении к этому значению ARC значительно замедляет рост, вроде как\\
+Если "**arc_need_free**" не равно нулю, значит ZFS пытается (по крайней мере на это значение) уменьшить ARC. Тут просто раскрывается некоторая информация поэтому необязательно отображает всю освобождаемую память\\
 </details>
-****\\
+<details>
+<summary>:!: Управление памятью</summary>
+В контуре управления памятью ядра Linux есть т.н. "сжиматели" (наверняка есть лучше перевод), (функции обратного вызова) которые вызываются подсистемами (например ZFS) для уменьшения используемой памяти\\
+Работает в два этапа, сначала ядро спрашивает подсистему сколько памяти она может вернуть, затем просит ее сделать это\\
+Базовый объем памяти который ARC может вернуть, представляет собой сумму "**evictable**" (mru,mfu,data,metadata) (фактически механизм более сложный) [[https://github.com/openzfs/zfs/blob/master/module/os/linux/zfs/arc_os.c#L135|GH]], разовый объем ограничивается [[https://openzfs.github.io/openzfs-docs/man/master/4/zfs.4.html#zfs_arc_shrinker_limit|zfs_arc_shrinker_limit]] (160Mb ?)\\
+При каждом сжатии, ARC уменьшается на запрошенную ядром величину, "**arc_no_grow** устанавливается в true" - ???.\\
+Если сжатие происходит с помощью "**kswapd_Linux**", то это косвенный механизм, увеличивается метрика "**memory_indirect_count**", если же процесс пытается выделить память а ее нет и напрямую запускает процесс освобождения, это прямой механизм, растет "**memory_direct_count**"\\
+Собсна прямое освобождение указывает на проблему и является плохим состоянием\\
+ARC имеет ограничения на объем хранимых метаданных (как общие **arc_meta_used** так и для "dnode" **dnode_size**). Когда ARC сжимает метаданные, ему может потребоваться обрезать себя, заставив ФС освободить "dnodes" и другие вещи которые в данный момент удерживаются. В эти моменты увеличивается **arc_prune** (мнение что по одному на каждую смонтированную ФС)\\
+Когда ARC удаляет данные, он может увеличивать две статистики, "**evic_skip**" и "**evic_not_enough**". Последняя выражает кол-во случаев когда при выселении не удалось выселить достаточно чтобы достичь целевой суммы.\\
+Первое - "кол-во буферов, пропущенных из-за того что в них выполняется ввод-вывод, являются буферами косвенной предварительной выборки, которые просуществовали недостаточно долго или не принадлежат SPA, из которого пытаемся выселить"\\
+"**Anon**" буферы которые не связаны с DVA, буферы в которых хранятся "грязные" (предварительные, полагаю) копии блоков, прежде чем они будут записаны в стабильное хранилище. Они считаются частью "**arc_mru**" которую нельзя освободить. Они получают DVA по мере их записи и мигрируют в "arc_mru"\\
+В "Anon" хоть и есть статистика "**evictable**", она всегда равна нулю, т.к. эти данные не подлежат удалению\\
+Некоторая часть подсчитанного здесь пространства может быть "отдана в аренду", отображается в метрике "**arc_loaned_bytes**"\\
+В рамках настройки записи ZFS временно резервирует для них пространство ARC, о текущем резервировании сказано в "**arc_tempreserve**".\\
+Общий объем "грязных" данных в ARC равен "**arc_tempreserve**" + "**anon_size**" - "**arc_loaned_bytes**"\\
+Если ZFS решает ограничить выделение новой памяти для записи, увеличивается метрика "**memory_throttle_count**", что является редкостью видимо\\
+</details>
+<details>
+<summary>:!: Еще про сокращения памяти</summary>
+[[https://utcc.utoronto.ca/~cks/space/blog/linux/ZFSOnLinuxARCTargetSizeChanges|Doc]]\\
+Целевой и фактический размеры ARC здесь различаются, фактический обычно быстро вырастает до целевого\\
+Сокращение может быть вызвано т.н. "жатвой" ("**Reaping**"), это общая ф-я ZFS, при которой выделенный поток ядра просыпается по крайней мере раз в секунду и проверяет не стала ли "**memory_availabel_bytes**" отрицательной\\
+Если так то ZFS ставит "**arc_no_grow**" и запускает процесс освобождения памяти, уменьшая целевой размер ARC на
+<code bash>
+((arc_c - arc_c_min) / 128) - memory_available_bytes
+</code>
+Процесс может быть вызван и немедленно при считывании очередного блока в память ZFS, после проверки "**memory_available_bytes**" на отрицательность\\
+Путь "**сжатия**" вызывается с помощью общей функции управления памятью ядра Linux, это другой процесс освобождения ARC\\
+При "жатве" часто немного уменьшается целевой размер ARC (300/400mb)\\
+При каждом сжатии растет статистика "**memory_direct_count**" либо "**memory_indirect_count**", при "**жатве**" никакая статистика не увеличивается\\
+</details>
+<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>
@@ Строка 268: / Строка 382: @@
+===== ZIL =====
+Кэш используется не только для чтения но и для записи, применяя т.н. "**Целевой журнал (ZIL, ZFS Intent Log)**"\\
+Каждый пул имеет свой собственный ZIL\\
+<details>
+<summary>:!: </summary>
+ZFS накапливает данные в этом журнале в т.н. **группы транзакций (txgs, transaction groups)**, затем, при наполнении достаточного объема либо по таймауту, txgs записывается на диск\\
-****
+Группа транзакций может содержать порции данных от разных, не связанных процессов\\
+содержит "запросы на запись", порция данных и связанных с ФС метаданных\\
-****
+"ГТ" является списком "что делать", данные чувствительны к отказам системы пока они полностью не будут записаны на диск, в случае отказа ГП потеряется\\
+Уменьшение таймаута может уменьшить объем потенциальной потери но плохо скажется на производительности\\
+Касательно использования диска ZIL и записывания ZIL на диск, тут есть момент с синхронной/асинхронной записью данных\\
+"Пул применяет ZIL только для синхронно- записываемых данных, асинхронные обычно сохраняются в оперативной памяти и фиксируются как часть регулярной группы транзакций"\\
+</details>
-<code bash>
-</code>
+<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>
@@ Строка 293: / Строка 461: @@
 </code>
 </details>
@@ Строка 302: / Строка 471: @@
 </code>
 </details>

zxcx

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

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

Различия

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