Данные параметры применяются только к клиентам 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_wait_up_timeout

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

Время ожидания поднятия PG при операциях, требующих активности всех PG. В данный момент используется листингами объектов в командах, использующих удаление и слияние (vitastor-cli rm, merge и подобные).

Значение по умолчанию вычисляется как 1 + время lease OSD, равное 1 + etcd_report_interval + max_etcd_attempts*2*etcd_quick_timeout.

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.

hostname

  • Тип: строка
  • Можно менять на лету: да

Клиенты используют имя хоста для определения расстояния до OSD, когда включены локальные чтения. По умолчанию для определения имени хоста используется стандартная функция gethostname, но вы также можете задать имя хоста вручную данным параметром.