Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD и т.п.) и затрагивают логику их работы с кластером.

client_iothread_count

  • Тип: целое число
  • Значение по умолчанию: 0

Число отдельных потоков для обработки ввода-вывода через TCP сеть на стороне клиентской библиотеки. Включение 4 потоков обычно позволяет поднять пиковую производительность каждого клиента примерно с 2-3 до 7-8 Гбайт/с линейного чтения/записи и примерно с 100-150 до 400 тысяч операций ввода-вывода в секунду, но ухудшает задержку. Увеличение задержки зависит от процессора: при отключённом энергосбережении CPU это всего ~10 микросекунд (равносильно падению iops с Q=1 с 10500 до 9500), а при включённом это может быть и 500 микросекунд (равносильно падению iops с Q=1 с 2000 до 1000). На работу RDMA данная опция не влияет.

Рекомендуется включать клиентские потоки ввода-вывода, если вы не используете RDMA и хотите повысить пиковую производительность клиентов.

client_retry_interval

  • Тип: миллисекунды
  • Значение по умолчанию: 50
  • Минимальное значение: 10
  • Можно менять на лету: да

Время повтора запросов ввода-вывода, неудачных из-за неактивных PG или ошибок сети.

client_eio_retry_interval

  • Тип: миллисекунды
  • Значение по умолчанию: 1000
  • Можно менять на лету: да

Время повтора запросов ввода-вывода, неудачных из-за повреждения данных или незавершённых удалений EC-объектов (состояния PG has_incomplete). 0 отключает повторы таких запросов и клиенты не блокируются, а вместо этого просто получают код ошибки EIO.

client_retry_enospc

  • Тип: булево (да/нет)
  • Значение по умолчанию: true
  • Можно менять на лету: да

Повторять запросы записи, завершившиеся с ошибками нехватки места, т.е. ожидать, пока на OSD не освободится место.

client_max_dirty_bytes

  • Тип: целое число
  • Значение по умолчанию: 33554432
  • Можно менять на лету: да

При работе без 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
  • Можно менять на лету: да

Максимальное число параллельных операций записи при сбросе буферов на сервер.

nbd_timeout

  • Тип: секунды
  • Значение по умолчанию: 300

Таймаут для операций чтения/записи через NBD. Если операция выполняется дольше таймаута, включая временную недоступность кластера на время, большее таймаута, NBD-устройство отключится само собой (и, возможно, сломает примонтированную ФС).

Вы можете установить таймаут в 0, чтобы никогда не отключать устройство по таймауту, но в этом случае вы вообще не сможете удалить устройство, если процесс NBD умрёт - вам придётся перезагружать сервер.

nbd_max_devices

  • Тип: целое число
  • Значение по умолчанию: 64

Максимальное число NBD-устройств в системе. Данное значение передаётся модулю ядра nbd как параметр nbds_max, когда его загружает vitastor-nbd.

nbd_max_part

  • Тип: целое число
  • Значение по умолчанию: 3

Максимальное число разделов на одном NBD-устройстве. Данное значение передаётся модулю ядра nbd как параметр max_part, когда его загружает vitastor-nbd. Имейте в виду, что (nbds_max)*(1+max_part) обычно не может превышать 256.

osd_nearfull_ratio

  • Тип: число
  • Значение по умолчанию: 0.95
  • Можно менять на лету: да

Доля занятого места на OSD, начиная с которой он считается “почти заполненным” в выводе vitastor-cli status.

Помните, что часть клиентских запросов может зависнуть или завершиться с ошибкой, если на 100 % заполнится хотя бы 1 OSD!

Однако, в отличие от Ceph, заполненные на 100 % OSD Vitastor не падают (в Ceph заполненные на 100% OSD вообще не могут стартовать), так что вы сможете восстановить работу кластера после ошибок отсутствия свободного места без уничтожения и пересоздания OSD.