Add documentation for the write-back cache
parent
294a754c9e
commit
6fd2cf5df6
|
|
@ -33,6 +33,7 @@ In the future, additional configuration methods may be added:
|
|||
|
||||
- [Common](config/common.en.md)
|
||||
- [Network](config/network.en.md)
|
||||
- [Client](config/client.en.md)
|
||||
- [Global Disk Layout](config/layout-cluster.en.md)
|
||||
- [OSD Disk Layout](config/layout-osd.en.md)
|
||||
- [OSD Runtime Parameters](config/osd.en.md)
|
||||
|
|
|
|||
|
|
@ -36,6 +36,7 @@
|
|||
|
||||
- [Общие](config/common.ru.md)
|
||||
- [Сеть](config/network.ru.md)
|
||||
- [Клиентский код](config/client.ru.md)
|
||||
- [Глобальные дисковые параметры](config/layout-cluster.ru.md)
|
||||
- [Дисковые параметры OSD](config/layout-osd.ru.md)
|
||||
- [Прочие параметры OSD](config/osd.ru.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,103 @@
|
|||
[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Client Parameters
|
||||
|
||||
-----
|
||||
|
||||
[Читать на русском](client.ru.md)
|
||||
|
||||
# Client Parameters
|
||||
|
||||
These parameters apply only to clients and affect their interaction with
|
||||
the cluster.
|
||||
|
||||
- [client_max_dirty_bytes](#client_max_dirty_bytes)
|
||||
- [client_max_dirty_ops](#client_max_dirty_ops)
|
||||
- [client_enable_writeback](#client_enable_writeback)
|
||||
- [client_max_buffered_bytes](#client_max_buffered_bytes)
|
||||
- [client_max_buffered_ops](#client_max_buffered_ops)
|
||||
- [client_max_writeback_iodepth](#client_max_writeback_iodepth)
|
||||
|
||||
## client_max_dirty_bytes
|
||||
|
||||
- Type: integer
|
||||
- Default: 33554432
|
||||
- Can be changed online: yes
|
||||
|
||||
Without [immediate_commit](layout-cluster.en.md#immediate_commit)=all this parameter sets the limit of "dirty"
|
||||
(not committed by fsync) data allowed by the client before forcing an
|
||||
additional fsync and committing the data. Also note that the client always
|
||||
holds a copy of uncommitted data in memory so this setting also affects
|
||||
RAM usage of clients.
|
||||
|
||||
## client_max_dirty_ops
|
||||
|
||||
- Type: integer
|
||||
- Default: 1024
|
||||
- Can be changed online: yes
|
||||
|
||||
Same as client_max_dirty_bytes, but instead of total size, limits the number
|
||||
of uncommitted write operations.
|
||||
|
||||
## client_enable_writeback
|
||||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
- Can be changed online: yes
|
||||
|
||||
This parameter enables client-side write buffering. This means that write
|
||||
requests are accumulated in memory for a short time before being sent to
|
||||
a Vitastor cluster which allows to send them in parallel and increase
|
||||
performance of some applications. Writes are buffered until client forces
|
||||
a flush with fsync() or until the amount of buffered writes exceeds the
|
||||
limit.
|
||||
|
||||
Write buffering significantly increases performance of some applications,
|
||||
for example, CrystalDiskMark under Windows (LOL :-D), but also any other
|
||||
applications if they do writes in one of two non-optimal ways: either if
|
||||
they do a lot of small (4 kb or so) sequential writes, or if they do a lot
|
||||
of small random writes, but without any parallelism or asynchrony, and also
|
||||
without calling fsync().
|
||||
|
||||
With write buffering enabled, you can expect around 22000 T1Q1 random write
|
||||
iops in QEMU more or less regardless of the quality of your SSDs, and this
|
||||
number is in fact bound by QEMU itself rather than Vitastor (check it
|
||||
yourself by adding a "driver=null-co" disk in QEMU). Without write
|
||||
buffering, the current record is 9900 iops, but the number is usually
|
||||
even lower with non-ideal hardware, for example, it may be 5000 iops.
|
||||
|
||||
Even when this parameter is enabled, write buffering isn't enabled until
|
||||
the client explicitly allows it, because enabling it without the client
|
||||
being aware of the fact that his writes may be buffered may lead to data
|
||||
loss. Because of this, older versions of clients don't support write
|
||||
buffering at all, newer versions of the QEMU driver allow write buffering
|
||||
only if it's enabled in disk settings with `-blockdev cache.direct=false`,
|
||||
and newer versions of FIO only allow write buffering if you don't specify
|
||||
`-direct=1`. NBD and NFS drivers allow write buffering by default.
|
||||
|
||||
You can overcome this restriction too with the `client_writeback_allowed`
|
||||
parameter, but you shouldn't do that unless you **really** know what you
|
||||
are doing.
|
||||
|
||||
## client_max_buffered_bytes
|
||||
|
||||
- Type: integer
|
||||
- Default: 33554432
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum total size of buffered writes which triggers write-back when reached.
|
||||
|
||||
## client_max_buffered_ops
|
||||
|
||||
- Type: integer
|
||||
- Default: 1024
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum number of buffered writes which triggers write-back when reached.
|
||||
Multiple consecutive modified data regions are counted as 1 write here.
|
||||
|
||||
## client_max_writeback_iodepth
|
||||
|
||||
- Type: integer
|
||||
- Default: 256
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum number of parallel writes when flushing buffered data to the server.
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Параметры клиентского кода
|
||||
|
||||
-----
|
||||
|
||||
[Read in English](client.en.md)
|
||||
|
||||
# Параметры клиентского кода
|
||||
|
||||
Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD) и
|
||||
затрагивают логику их работы с кластером.
|
||||
|
||||
- [client_max_dirty_bytes](#client_max_dirty_bytes)
|
||||
- [client_max_dirty_ops](#client_max_dirty_ops)
|
||||
- [client_enable_writeback](#client_enable_writeback)
|
||||
- [client_max_buffered_bytes](#client_max_buffered_bytes)
|
||||
- [client_max_buffered_ops](#client_max_buffered_ops)
|
||||
- [client_max_writeback_iodepth](#client_max_writeback_iodepth)
|
||||
|
||||
## client_max_dirty_bytes
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 33554432
|
||||
- Можно менять на лету: да
|
||||
|
||||
При работе без [immediate_commit](layout-cluster.ru.md#immediate_commit)=all - это лимит объёма "грязных" (не
|
||||
зафиксированных fsync-ом) данных, при достижении которого клиент будет
|
||||
принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
|
||||
что в этом случае до момента fsync клиент хранит копию незафиксированных
|
||||
данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
|
||||
|
||||
## client_max_dirty_ops
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 1024
|
||||
- Можно менять на лету: да
|
||||
|
||||
Аналогично client_max_dirty_bytes, но ограничивает количество
|
||||
незафиксированных операций записи вместо их общего объёма.
|
||||
|
||||
## client_enable_writeback
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
- Можно менять на лету: да
|
||||
|
||||
Данный параметр разрешает включать буферизацию записи в памяти. Буферизация
|
||||
означает, что операции записи отправляются на кластер Vitastor не сразу, а
|
||||
могут небольшое время накапливаться в памяти и сбрасываться сразу пакетами,
|
||||
до тех пор, пока либо не будет превышен лимит неотправленных записей, либо
|
||||
пока клиент не вызовет fsync.
|
||||
|
||||
Буферизация значительно повышает производительность некоторых приложений,
|
||||
например, CrystalDiskMark в Windows (ха-ха :-D), но также и любых других,
|
||||
которые пишут на диск неоптимально: либо последовательно, но мелкими блоками
|
||||
(например, по 4 кб), либо случайно, но без параллелизма и без fsync - то
|
||||
есть, например, отправляя 128 операций записи в разные места диска, но не
|
||||
все сразу с помощью асинхронного I/O, а по одной.
|
||||
|
||||
В QEMU с буферизацией записи можно ожидать показателя примерно 22000
|
||||
операций случайной записи в секунду в 1 поток и с глубиной очереди 1 (T1Q1)
|
||||
без fsync, почти вне зависимости от того, насколько хороши ваши диски - эта
|
||||
цифра упирается в сам QEMU. Без буферизации рекорд пока что - 9900 операций
|
||||
в секунду, но на железе похуже может быть и поменьше, например, 5000 операций
|
||||
в секунду.
|
||||
|
||||
При этом, даже если данный параметр включён, буферизация не включается, если
|
||||
явно не разрешена клиентом, т.к. если клиент не знает, что запросы записи
|
||||
буферизуются, это может приводить к потере данных. Поэтому в старых версиях
|
||||
клиентских драйверов буферизация записи не включается вообще, в новых
|
||||
версиях QEMU-драйвера включается только если разрешена опцией диска
|
||||
`-blockdev cache.direct=false`, а в fio - только если нет опция `-direct=1`.
|
||||
В NBD и NFS драйверах буферизация записи разрешена по умолчанию.
|
||||
|
||||
Можно обойти и это ограничение с помощью параметра `client_writeback_allowed`,
|
||||
но делать так не надо, если только вы не уверены в том, что делаете, на все
|
||||
100%. :-)
|
||||
|
||||
## client_max_buffered_bytes
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 33554432
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальный общий размер буферизованных записей, при достижении которого
|
||||
начинается процесс сброса данных на сервер.
|
||||
|
||||
## client_max_buffered_ops
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 1024
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное количество буферизованных записей, при достижении которого
|
||||
начинается процесс сброса данных на сервер. При этом несколько
|
||||
последовательных изменённых областей здесь считаются 1 записью.
|
||||
|
||||
## client_max_writeback_iodepth
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 256
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное число параллельных операций записи при сбросе буферов на сервер.
|
||||
|
|
@ -30,7 +30,6 @@ between clients, OSDs and etcd.
|
|||
- [etcd_slow_timeout](#etcd_slow_timeout)
|
||||
- [etcd_keepalive_timeout](#etcd_keepalive_timeout)
|
||||
- [etcd_ws_keepalive_timeout](#etcd_ws_keepalive_timeout)
|
||||
- [client_dirty_limit](#client_dirty_limit)
|
||||
|
||||
## tcp_header_buffer_size
|
||||
|
||||
|
|
@ -240,17 +239,3 @@ etcd_report_interval to guarantee that keepalive actually works.
|
|||
|
||||
etcd websocket ping interval required to keep the connection alive and
|
||||
detect disconnections quickly.
|
||||
|
||||
## client_dirty_limit
|
||||
|
||||
- Type: integer
|
||||
- Default: 33554432
|
||||
- Can be changed online: yes
|
||||
|
||||
Without immediate_commit=all this parameter sets the limit of "dirty"
|
||||
(not committed by fsync) data allowed by the client before forcing an
|
||||
additional fsync and committing the data. Also note that the client always
|
||||
holds a copy of uncommitted data in memory so this setting also affects
|
||||
RAM usage of clients.
|
||||
|
||||
This parameter doesn't affect OSDs themselves.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,6 @@
|
|||
- [etcd_slow_timeout](#etcd_slow_timeout)
|
||||
- [etcd_keepalive_timeout](#etcd_keepalive_timeout)
|
||||
- [etcd_ws_keepalive_timeout](#etcd_ws_keepalive_timeout)
|
||||
- [client_dirty_limit](#client_dirty_limit)
|
||||
|
||||
## tcp_header_buffer_size
|
||||
|
||||
|
|
@ -251,17 +250,3 @@ etcd_report_interval, чтобы keepalive гарантированно рабо
|
|||
- Можно менять на лету: да
|
||||
|
||||
Интервал проверки живости вебсокет-подключений к etcd.
|
||||
|
||||
## client_dirty_limit
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 33554432
|
||||
- Можно менять на лету: да
|
||||
|
||||
При работе без immediate_commit=all - это лимит объёма "грязных" (не
|
||||
зафиксированных fsync-ом) данных, при достижении которого клиент будет
|
||||
принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
|
||||
что в этом случае до момента fsync клиент хранит копию незафиксированных
|
||||
данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
|
||||
|
||||
Параметр не влияет на сами OSD.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,4 @@
|
|||
# Client Parameters
|
||||
|
||||
These parameters apply only to clients and affect their interaction with
|
||||
the cluster.
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
# Параметры клиентского кода
|
||||
|
||||
Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD) и
|
||||
затрагивают логику их работы с кластером.
|
||||
|
|
@ -0,0 +1,124 @@
|
|||
- name: client_max_dirty_bytes
|
||||
type: int
|
||||
default: 33554432
|
||||
online: true
|
||||
info: |
|
||||
Without [immediate_commit](layout-cluster.en.md#immediate_commit)=all this parameter sets the limit of "dirty"
|
||||
(not committed by fsync) data allowed by the client before forcing an
|
||||
additional fsync and committing the data. Also note that the client always
|
||||
holds a copy of uncommitted data in memory so this setting also affects
|
||||
RAM usage of clients.
|
||||
info_ru: |
|
||||
При работе без [immediate_commit](layout-cluster.ru.md#immediate_commit)=all - это лимит объёма "грязных" (не
|
||||
зафиксированных fsync-ом) данных, при достижении которого клиент будет
|
||||
принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
|
||||
что в этом случае до момента fsync клиент хранит копию незафиксированных
|
||||
данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
|
||||
- name: client_max_dirty_ops
|
||||
type: int
|
||||
default: 1024
|
||||
online: true
|
||||
info: |
|
||||
Same as client_max_dirty_bytes, but instead of total size, limits the number
|
||||
of uncommitted write operations.
|
||||
info_ru: |
|
||||
Аналогично client_max_dirty_bytes, но ограничивает количество
|
||||
незафиксированных операций записи вместо их общего объёма.
|
||||
- name: client_enable_writeback
|
||||
type: bool
|
||||
default: false
|
||||
online: true
|
||||
info: |
|
||||
This parameter enables client-side write buffering. This means that write
|
||||
requests are accumulated in memory for a short time before being sent to
|
||||
a Vitastor cluster which allows to send them in parallel and increase
|
||||
performance of some applications. Writes are buffered until client forces
|
||||
a flush with fsync() or until the amount of buffered writes exceeds the
|
||||
limit.
|
||||
|
||||
Write buffering significantly increases performance of some applications,
|
||||
for example, CrystalDiskMark under Windows (LOL :-D), but also any other
|
||||
applications if they do writes in one of two non-optimal ways: either if
|
||||
they do a lot of small (4 kb or so) sequential writes, or if they do a lot
|
||||
of small random writes, but without any parallelism or asynchrony, and also
|
||||
without calling fsync().
|
||||
|
||||
With write buffering enabled, you can expect around 22000 T1Q1 random write
|
||||
iops in QEMU more or less regardless of the quality of your SSDs, and this
|
||||
number is in fact bound by QEMU itself rather than Vitastor (check it
|
||||
yourself by adding a "driver=null-co" disk in QEMU). Without write
|
||||
buffering, the current record is 9900 iops, but the number is usually
|
||||
even lower with non-ideal hardware, for example, it may be 5000 iops.
|
||||
|
||||
Even when this parameter is enabled, write buffering isn't enabled until
|
||||
the client explicitly allows it, because enabling it without the client
|
||||
being aware of the fact that his writes may be buffered may lead to data
|
||||
loss. Because of this, older versions of clients don't support write
|
||||
buffering at all, newer versions of the QEMU driver allow write buffering
|
||||
only if it's enabled in disk settings with `-blockdev cache.direct=false`,
|
||||
and newer versions of FIO only allow write buffering if you don't specify
|
||||
`-direct=1`. NBD and NFS drivers allow write buffering by default.
|
||||
|
||||
You can overcome this restriction too with the `client_writeback_allowed`
|
||||
parameter, but you shouldn't do that unless you **really** know what you
|
||||
are doing.
|
||||
info_ru: |
|
||||
Данный параметр разрешает включать буферизацию записи в памяти. Буферизация
|
||||
означает, что операции записи отправляются на кластер Vitastor не сразу, а
|
||||
могут небольшое время накапливаться в памяти и сбрасываться сразу пакетами,
|
||||
до тех пор, пока либо не будет превышен лимит неотправленных записей, либо
|
||||
пока клиент не вызовет fsync.
|
||||
|
||||
Буферизация значительно повышает производительность некоторых приложений,
|
||||
например, CrystalDiskMark в Windows (ха-ха :-D), но также и любых других,
|
||||
которые пишут на диск неоптимально: либо последовательно, но мелкими блоками
|
||||
(например, по 4 кб), либо случайно, но без параллелизма и без fsync - то
|
||||
есть, например, отправляя 128 операций записи в разные места диска, но не
|
||||
все сразу с помощью асинхронного I/O, а по одной.
|
||||
|
||||
В QEMU с буферизацией записи можно ожидать показателя примерно 22000
|
||||
операций случайной записи в секунду в 1 поток и с глубиной очереди 1 (T1Q1)
|
||||
без fsync, почти вне зависимости от того, насколько хороши ваши диски - эта
|
||||
цифра упирается в сам QEMU. Без буферизации рекорд пока что - 9900 операций
|
||||
в секунду, но на железе похуже может быть и поменьше, например, 5000 операций
|
||||
в секунду.
|
||||
|
||||
При этом, даже если данный параметр включён, буферизация не включается, если
|
||||
явно не разрешена клиентом, т.к. если клиент не знает, что запросы записи
|
||||
буферизуются, это может приводить к потере данных. Поэтому в старых версиях
|
||||
клиентских драйверов буферизация записи не включается вообще, в новых
|
||||
версиях QEMU-драйвера включается только если разрешена опцией диска
|
||||
`-blockdev cache.direct=false`, а в fio - только если нет опция `-direct=1`.
|
||||
В NBD и NFS драйверах буферизация записи разрешена по умолчанию.
|
||||
|
||||
Можно обойти и это ограничение с помощью параметра `client_writeback_allowed`,
|
||||
но делать так не надо, если только вы не уверены в том, что делаете, на все
|
||||
100%. :-)
|
||||
- name: client_max_buffered_bytes
|
||||
type: int
|
||||
default: 33554432
|
||||
online: true
|
||||
info: |
|
||||
Maximum total size of buffered writes which triggers write-back when reached.
|
||||
info_ru: |
|
||||
Максимальный общий размер буферизованных записей, при достижении которого
|
||||
начинается процесс сброса данных на сервер.
|
||||
- name: client_max_buffered_ops
|
||||
type: int
|
||||
default: 1024
|
||||
online: true
|
||||
info: |
|
||||
Maximum number of buffered writes which triggers write-back when reached.
|
||||
Multiple consecutive modified data regions are counted as 1 write here.
|
||||
info_ru: |
|
||||
Максимальное количество буферизованных записей, при достижении которого
|
||||
начинается процесс сброса данных на сервер. При этом несколько
|
||||
последовательных изменённых областей здесь считаются 1 записью.
|
||||
- name: client_max_writeback_iodepth
|
||||
type: int
|
||||
default: 256
|
||||
online: true
|
||||
info: |
|
||||
Maximum number of parallel writes when flushing buffered data to the server.
|
||||
info_ru: |
|
||||
Максимальное число параллельных операций записи при сбросе буферов на сервер.
|
||||
|
|
@ -28,6 +28,8 @@
|
|||
|
||||
{{../../config/network.en.md|indent=2}}
|
||||
|
||||
{{../../config/client.en.md|indent=2}}
|
||||
|
||||
{{../../config/layout-cluster.en.md|indent=2}}
|
||||
|
||||
{{../../config/layout-osd.en.md|indent=2}}
|
||||
|
|
|
|||
|
|
@ -28,6 +28,8 @@
|
|||
|
||||
{{../../config/network.ru.md|indent=2}}
|
||||
|
||||
{{../../config/client.ru.md|indent=2}}
|
||||
|
||||
{{../../config/layout-cluster.ru.md|indent=2}}
|
||||
|
||||
{{../../config/layout-osd.ru.md|indent=2}}
|
||||
|
|
|
|||
|
|
@ -259,23 +259,3 @@
|
|||
detect disconnections quickly.
|
||||
info_ru: |
|
||||
Интервал проверки живости вебсокет-подключений к etcd.
|
||||
- name: client_dirty_limit
|
||||
type: int
|
||||
default: 33554432
|
||||
online: true
|
||||
info: |
|
||||
Without immediate_commit=all this parameter sets the limit of "dirty"
|
||||
(not committed by fsync) data allowed by the client before forcing an
|
||||
additional fsync and committing the data. Also note that the client always
|
||||
holds a copy of uncommitted data in memory so this setting also affects
|
||||
RAM usage of clients.
|
||||
|
||||
This parameter doesn't affect OSDs themselves.
|
||||
info_ru: |
|
||||
При работе без immediate_commit=all - это лимит объёма "грязных" (не
|
||||
зафиксированных fsync-ом) данных, при достижении которого клиент будет
|
||||
принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
|
||||
что в этом случае до момента fsync клиент хранит копию незафиксированных
|
||||
данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
|
||||
|
||||
Параметр не влияет на сами OSD.
|
||||
|
|
|
|||
|
|
@ -31,6 +31,7 @@
|
|||
- [RDMA/RoCEv2 support via libibverbs](../config/network.en.md#rdma_device)
|
||||
- [Scrubbing](../config/osd.en.md#auto_scrub) (verification of copies)
|
||||
- [Checksums](../config/layout-osd.en.md#data_csum_type)
|
||||
- [Client write-back cache](../config/client.en.md#client_enable_writeback)
|
||||
|
||||
## Plugins and tools
|
||||
|
||||
|
|
|
|||
|
|
@ -33,6 +33,7 @@
|
|||
- [Поддержка RDMA/RoCEv2 через libibverbs](../config/network.ru.md#rdma_device)
|
||||
- [Фоновая проверка целостности](../config/osd.ru.md#auto_scrub) (сверка копий)
|
||||
- [Контрольные суммы](../config/layout-osd.ru.md#data_csum_type)
|
||||
- [Буферизация записи на стороне клиента](../config/client.ru.md#client_enable_writeback)
|
||||
|
||||
## Драйверы и инструменты
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue