diff --git a/docs/config.en.md b/docs/config.en.md index 9ddc512a..d0ef1821 100644 --- a/docs/config.en.md +++ b/docs/config.en.md @@ -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) diff --git a/docs/config.ru.md b/docs/config.ru.md index b2e5aed5..8ec1c103 100644 --- a/docs/config.ru.md +++ b/docs/config.ru.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) diff --git a/docs/config/client.en.md b/docs/config/client.en.md new file mode 100644 index 00000000..b64ea4a9 --- /dev/null +++ b/docs/config/client.en.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. diff --git a/docs/config/client.ru.md b/docs/config/client.ru.md new file mode 100644 index 00000000..15252808 --- /dev/null +++ b/docs/config/client.ru.md @@ -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 +- Можно менять на лету: да + +Максимальное число параллельных операций записи при сбросе буферов на сервер. diff --git a/docs/config/network.en.md b/docs/config/network.en.md index b4d152bb..6fe6bf8b 100644 --- a/docs/config/network.en.md +++ b/docs/config/network.en.md @@ -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. diff --git a/docs/config/network.ru.md b/docs/config/network.ru.md index f82c5d4c..43239dc2 100644 --- a/docs/config/network.ru.md +++ b/docs/config/network.ru.md @@ -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. diff --git a/docs/config/src/client.en.md b/docs/config/src/client.en.md new file mode 100644 index 00000000..2e94c864 --- /dev/null +++ b/docs/config/src/client.en.md @@ -0,0 +1,4 @@ +# Client Parameters + +These parameters apply only to clients and affect their interaction with +the cluster. diff --git a/docs/config/src/client.ru.md b/docs/config/src/client.ru.md new file mode 100644 index 00000000..8b9c1eec --- /dev/null +++ b/docs/config/src/client.ru.md @@ -0,0 +1,4 @@ +# Параметры клиентского кода + +Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD) и +затрагивают логику их работы с кластером. diff --git a/docs/config/src/client.yml b/docs/config/src/client.yml new file mode 100644 index 00000000..7dc3bbaf --- /dev/null +++ b/docs/config/src/client.yml @@ -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: | + Максимальное число параллельных операций записи при сбросе буферов на сервер. diff --git a/docs/config/src/included.en.md b/docs/config/src/included.en.md index 3a8b8954..dc37def3 100644 --- a/docs/config/src/included.en.md +++ b/docs/config/src/included.en.md @@ -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}} diff --git a/docs/config/src/included.ru.md b/docs/config/src/included.ru.md index 457fd2e9..49d00475 100644 --- a/docs/config/src/included.ru.md +++ b/docs/config/src/included.ru.md @@ -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}} diff --git a/docs/config/src/network.yml b/docs/config/src/network.yml index b3d92a21..9dea2d0f 100644 --- a/docs/config/src/network.yml +++ b/docs/config/src/network.yml @@ -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. diff --git a/docs/intro/features.en.md b/docs/intro/features.en.md index 6c492fef..287a9d2d 100644 --- a/docs/intro/features.en.md +++ b/docs/intro/features.en.md @@ -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 diff --git a/docs/intro/features.ru.md b/docs/intro/features.ru.md index 54e7f231..f0e0266d 100644 --- a/docs/intro/features.ru.md +++ b/docs/intro/features.ru.md @@ -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) ## Драйверы и инструменты