EXT4 или XFS EXT4 более распространена, однако XFS более производительна для Kafka
Отключаем noatime для точки монтирования для сегментов журналов
Вне зависимости от файловой системы, выбранной в качестве точки монтирова- ния для сегментов журналов, рекомендуется указывать параметр монтирования noatime. Метаданные файла содержат три метки даты/времени: время создания (ctime), время последнего изменения (mtime) и время последнего обращения к фай- лу (atime). По умолчанию значение атрибута atime обновляется при каждом чтении файла. Это значительно увеличивает число операций записи на диск. Атрибут atime обычно не слишком полезен, за исключением случая, когда приложению необхо- дима информация о том, обращались ли к файлу после его последнего изменения (в этом случае можно применить параметр realtime). Kafka вообще не использу- ет атрибут atime, так что можно спокойно его отключить. Установка параметра noatime для точки монтирования предотвращает обновления меток даты/времени, но не влияет на корректную обработку атрибутов ctime и mtime.
Корректировка настроек по умолчанию сетевого стека Linux — обычное дело для любого приложения, генерирующего много сетевого трафика, так как ядро по умолчанию не приспособлено для высокоскоростной передачи больших объемов данных. На деле рекомендуемые для Kafka изменения не отличаются от изменений, рекомендуемых для большинства веб-серверов и других сетевых приложений. Вначале необходимо изменить объемы (по умолчанию и максимальный) памяти, выделяемой для буферов отправки и получения для каждого сокета. Это значи- тельно увеличит производительность в случае передачи больших объемов данных. Соответствующие параметры для значений по умолчанию буферов отправки и получения каждого сокета называются net.core.wmem_default и net.core.rmem_default соответственно, а разумное их значение будет 2 097 152 (2 Мбайт). Имейте в виду, что максимальный размер не означает выделения для каждого буфера такого пространства, а лишь позволяет сделать это при необходимости. Помимо настройки сокетов необходимо отдельно задать размеры буферов отправки и получения для сокетов TCP с помощью параметров net.ipv4.tcp_wmem и net.ipv4.tcp_rmem. В них указываются три разделенных пробелами целых числа, определяющих минимальный размер, размер по умолчанию и максимальный размер соответственно. Пример этих параметров — 4096 65536 2048000 — означает, что минимальный размер буфера 4 Кбайт, размер по умолчанию — 64 Кбайт, а максимальный — 2 Мбайт. Максимальный размер не может превышать значений, задаваемых для всех сокетов параметрами net.core.wmem_max и net.core.rmem_max. В зависимости от настоящей загрузки ваших брокеров Kafka может понадобиться увеличить максимальные значения для повышения степени буферизации сетевых соединений. Существует еще несколько полезных сетевых параметров. Можно включить оконное масштабирование TCP путем установки значения 1 параметра net.ipv4.tcp_window_scaling, что позволит клиентам передавать данные эффективнее и обеспечит возможность буферизации этих данных на стороне брокера. Значение параметра net.ipv4.tcp_max_syn_backlog большее, чем принятое по умолчанию 1024, по- зволяет повысить число одновременных подключений. Значение параметра net.core.netdev_max_backlog, превышающее принятое по умолчанию 1000, может помочь в случае всплесков сетевого трафика, особенно при скоростях сетевого подключения порядка гигабит, благодаря увеличению количества пакетов, помещаемых в очередь для последующей обработки ядром.
Выбираем G1
В обычном режиме работы для выполнения всего этого G1 требуются минималь- ные настройки. Для корректировки его производительности используются два параметра.
- MaxGCPauseMills. Задает желаемую длительность паузы на каждый цикл сбор- ки мусора. Это не фиксированный максимум — при необходимости G1 может превысить эту длительность. По умолчанию данное значение равно 200 мс. Это значит, что G1 будет стараться планировать частоту циклов сборки мусора, а также числа зон, обрабатываемых в каждом цикле, так, чтобы каждый цикл занимал примерно 200 мс.
- InitiatingHeapOccupancyPercent. Задает долю в процентах от общего размера кучи, до превышения которой сборка мусора не начинается. Значение по умол- чанию равно 45. Это значит, что G1 не запустит цикл сборки мусора до того, как будет использоваться 45 % кучи, включая суммарное использование зон как новых (Eden), так и старых объектов. Брокер Kafka весьма эффективно использует память из кучи и создает объекты, так что можно задавать более низкие значения этих параметров. Приведенные в дан- ном разделе значения параметров сборки мусора признаны вполне подходящими для сервера с 64 Гбайт оперативной памяти, где Kafka работала с кучей размером 5 Гбайт. Этот брокер мог работать при значении 20 параметра MaxGCPauseMills. А значение параметра InitiatingHeapOccupancyPercent установлено в 35, благодаря чему сборка мусора запускается несколько раньше, чем при значении по умолчанию. Сценарий запуска Kafka по умолчанию использует не сборщик мусора G1, а но- вый параллельный сборщик мусора и конкурентный сборщик мусора маркировки и очистки. Это можно легко изменить посредством переменных среды. Изменим приведенную ранее команду запуска следующим образом: