Настройка производительности authoring-окружения

В этой статье описаны рекомендации по улучшению производительности authoring-окружения путем настройки параметров и оптимизации конфигурации оборудования.

Требования к серверу

Минимальная установка (~1-10 одновременных пользователей, ~10 сайтов) 

  • 16 ГБ оперативной памяти + 16 ГБ пространства подкачки (Swap Space) или виртуальной памяти (Virtual Memory)
  • 8 ГБ памяти JVM (-Xms 1G -Xmx 8G)
  • 4 ядра ЦП (CPU Core)

Средняя установка (~11-25 одновременных пользователей, ~25 сайтов)

  • 32 ГБ и более ОЗУ + 32 ГБ пространства подкачки (Swap Space) или виртуальной памяти (Virtual Memory)
  • 16 ГБ и более памяти JVM (-Xms 2G -Xmx 16G)
  • 8 и более ядер ЦП (CPU Core)
Большая установка (~26-50 одновременных пользователей, ~50 сайтов)
  • 64 ГБ и более ОЗУ + 64 ГБ пространства подкачки (Swap Space) или виртуальной памяти (Virtual Memory)
  • 32 ГБ и более памяти JVM (-Xms 4G -Xmx 32G)
  • 16 и более ядер ЦП (CPU Core)

Вертикальное масштабирование может быть очень эффективным для масштабирования CMS Studio.

Рекомендации для высокой производительности

Большинство задач, выполняемых DC CMS, тесно связаны с операциями ввода/вывода. Улучшение вашей установки для достижения более эффективной производительности ввода/вывода, вероятно, приведет к значительным преимуществам с самого начала.

Следующие общие рекомендации предназначены для решения этих вопросов:

  1. Быстрая производительность хранения данных в формате RAW (быстрое параллельное чтение и запись).

  2. Использование отдельных устройств хранения для различных целей, таких как логирование, Git, поисковый индекс, подкачка и другие.

  3. Тщательная организация данных на диске с назначением конкретных устройств для различных хранилищ, индексов и т. д.

  4. Резерв половины оперативной памяти для операционной системы и процессов, не относящихся к Java Virtual Machine (JVM).

Настройка производительности сервера

Уровень сервера/оборудования

Диски/устройства хранения данных

Задачей CMS Studio является управление контентом, что подразумевает высокий объем одновременных операций чтения и записи. Чем быстрее тип диска и соединение с компьютером, тем лучшую производительность вы заметите.

Тестирование сырой производительности (raw performance)
  • Быстрый тест без параллелизма или проверку производительности сырого устройства можно выполнить с использованием sudo hdparm -tT /dev/{device}. Пример:

Timing cached reads:   24486 MB in  1.99 seconds = 12284.28 MB/sec
Timing buffered disk reads: 3104 MB in  3.00 seconds = 1033.84 MB/sec
Copy-icon
  • Тестируйте операции ввода/вывода с помощью fio. Пример:

$ fio --randrepeat=1 --ioengine=libaio --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
    test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
    fio-2.2.10
    Starting 1 process
    Jobs: 1 (f=1): [m(1)] [100.0% done] [495.2MB/164.7MB/0KB /s] [127K/42.2K/0 iops] [eta 00m:00s]
    test: (groupid=0, jobs=1): err= 0: pid=9071: Mon Apr 23 10:49:08 2018
        read : io=3071.7MB, bw=485624KB/s, iops=121406, runt=  6477msec
        write: io=1024.4MB, bw=161945KB/s, iops=40486, runt=  6477msec
        cpu          : usr=12.04%, sys=87.77%, ctx=32, majf=0, minf=8
        IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued    : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency   : target=0, window=0, percentile=100.00%, depth=64

    Run status group 0 (all jobs):
            READ: io=3071.7MB, aggrb=485624KB/s, minb=485624KB/s, maxb=485624KB/s, mint=6477msec, maxt=6477msec
            WRITE: io=1024.4MB, aggrb=161944KB/s, minb=161944KB/s, maxb=161944KB/s, mint=6477msec, maxt=6477msec
Copy-icon
  • Тестируйте латентность с помощью ioping. Пример:

$ ioping -c 10 .
  4 KiB from . (ext4 /dev/nvme0n1p3): request=1 time=179 us
  4 KiB from . (ext4 /dev/nvme0n1p3): request=2 time=602 us
  4 KiB from . (ext4 /dev/nvme0n1p3): request=3 time=704 us
  4 KiB from . (ext4 /dev/nvme0n1p3): request=4 time=600 us
  4 KiB from . (ext4 /dev/nvme0n1p3): request=5 time=597 us
  4 KiB from . (ext4 /dev/nvme0n1p3): request=6 time=612 us
  4 KiB from . (ext4 /dev/nvme0n1p3): request=7 time=599 us
  4 KiB from . (ext4 /dev/nvme0n1p3): request=8 time=659 us
  4 KiB from . (ext4 /dev/nvme0n1p3): request=9 time=652 us
  4 KiB from . (ext4 /dev/nvme0n1p3): request=10 time=742 us

  --- . (ext4 /dev/nvme0n1p3) ioping statistics ---
  10 requests completed in 9.01 s, 1.68 k iops, 6.57 MiB/s
  min/avg/max/mdev = 179 us / 594 us / 742 us / 146 us
Copy-icon
Рекомендации

  • Выбирайте несколько устройств вместо одного
    DC CMS обновляет контент, метаданные, поисковые индексы и другие элементы при каждой операции записи. Распределяя определенные типы данных на отдельные устройства хранения, вы облегчаете одновременные действия, тем самым значительно повышая общую производительность.

  • Выбирайте диски высокой скорости
    Не все устройства хранения равны. Чем выше скорость чтения/записи, и чем больше поддерживается одновременных операций и меньше задержка, тем выше уровень производительности. Отдавайте предпочтение использованию устройств с наивысшим значением IOPS для решения наиболее сложных задач хранения данных в порядке важности:

{CMS_HOME}/data/repos (high-concurrency, important)
{CMS_HOME}/data/db (high-concurrency, important)
{CMS_HOME}/data/indexes
{CMS_HOME}/data/logs
{CMS_HOME}/data/mongodb (if in use)
Copy-icon

  • Избегайте подключений с высокой задержкой к диску
    Соединение с высокой задержкой, такое как NAS, часто вызывает проблемы с производительностью. Отдавайте предпочтение локальным дискам или сетям хранения (SAN) для получения более высокой производительности. Протоколы типа NFS или подобные могут внести задержку и вызвать проблемы с производительностью.

  • По возможности используйте отдельные устройства для каждой задачи хранения
    Одним из способов повышения эффективности операций ввода/вывода системы без покупки дорогих устройств хранения данных — это распределение рабочей нагрузки по нескольким устройствам. DC CMS включает в себя несколько операций чтения/записи на диск для различных задач, таких как база данных, репозиторий и логи, каждая из которых имеет различные шаблоны ввода/вывода. Для оптимальной производительности настройте различные хранилища (диски) для различных задач, например:

/dev/{dev0} -> /
/dev/{dev1} -> /opt/cms/data/db
/dev/{dev2} -> /opt/cms/data/repos
/dev/{dev3} -> /opt/cms/data/indexes
/dev/{dev4} -> /opt/cms/logs
/dev/{dev5} -> /opt/cms/data/mongodb
/dev/{dev6} -> /var
/dev/{dev7} -> /home
/dev/{dev8} -> /usr
Copy-icon

Уровень операционной системы

Linux Ulimit

DC CMS включает несколько подсистем, требующих наличия дополнительных файловых дескрипторов на уровне операционной системы.

Указанные ограничения следующие:

[Service]
# Other directives omitted
# (file size)
LimitFSIZE=infinity
# (cpu time)
LimitCPU=infinity
# (virtual memory size)
LimitAS=infinity
# (locked-in-memory size)
LimitMEMLOCK=infinity
# (open files)
LimitNOFILE=65535
# (processes/threads)
LimitNPROC=65535
Copy-icon

Эти значения можно настроить в файле limits.conf, расположенном в /etc/security/.

Вот пример представления вышеупомянутых элементов в файле limits.conf:

#[domain]        [type]  [item]   [value]
...

*                -       fsize    infinity
*                -       cpu      infinity
*                -       as       infinity
*                -       memlock  infinity
*                -       nofile   65535
*                -       nproc    65535

...
Copy-icon

где:

  • domain может быть именем пользователя, именем группы или записью с символом подстановки (wildcard entry)
  • type может быть soft, hard или -
  • item представляет ресурс, для которого установлен лимит

Для дополнительной информации о типах и других настраиваемых элементах обратитесь к странице руководства (man page) вашей операционной системы для limits.conf (например, man limits.conf) или посетите онлайн-страницу руководства для вашей ОС.

Настройка производительности CMS Studio

Уровень JVM

Чтобы настроить размер кучи (heap) и другие параметры для JVM, обновите переменную окружения CATALINA_OPTS до желаемого значения, например, следующим образом:

export CATALINA_OPTS=${CATALINA_OPTS:="-server -Xss1024K -Xms1G -Xmx2G -Dlog4j2.formatMsgNoLookups=true"}
Copy-icon

Уровень сервера приложений Tomcat

Счетчик количества потоков Tomcat Connector

Настройте количество потоков (threads) Tomcat Connector в соответствии с количеством доступных ядер ЦП на сервере, обеспечив оптимальную обработку одновременных запросов.

Чтобы установить максимальное количество активных потоков, а также минимальное количество неактивных и активных потоков, перейдите в файл CMS_HOME/bin/apache-tomcat/conf/server.xml и установите следующее:

maxThreads=”<МАКСИМАЛЬНОЕ_КОЛИЧЕСТВО_ПОТОКОВ>”
minSpareThreads=”<МИНИМАЛЬНОЕ_КОЛИЧЕСТВО_ПОТОКОВ>”>
Copy-icon

В приведенной ниже конфигурации мы установили maxThreads равным 600, а MinSpareThreads равным 100. Для получения дополнительной информации о пулах потоков Tomcat смотрите https://tomcat.apache.org/tomcat-9.0-doc/config/executor.html.

<Connector port="${tomcat.http.port}" protocol="HTTP/1.1" URIEncoding="UTF-8"
           connectionTimeout="20000"
           redirectPort="${tomcat.https.port}"
           maxParameterCount="1000"
           maxThreads="600"
           minSpareThreads="100"
           />
Copy-icon

Уровень приложения DC CMS Studio

Пул подключений к базе данных

Чтобы настроить параметры пула подключений к базе данных, измените свойства, указанные ниже, в файле studio-config-override.yaml, который находится в папке CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension/.

# Defines initial number of database connections in database connection pool
studio.db.pool.initialConnections: 10
# Defines maximum number of active database connections in database connection pool
studio.db.pool.maxActiveConnections: 100
# Defines maximum number of idle database connections to retain in database connection pool.
studio.db.pool.maxIdleConnections: 30
# Defines minimum number of idle database connections to retain in database connection pool.
studio.db.pool.minIdleConnections: 10
Copy-icon

Настройка производительности CMS Deployer

CMS Deployer играет ключевую роль в различных операциях, таких как публикация контента, обновление поискового индекса и модификация метаданных. Эффективность этих операций в значительной степени зависит от производительности ключевых аппаратных компонентов, включая тип диска, сетевое подключение и доступную память. В крупных установках с обширным контентом для индексации CMS Deployer может столкнуться с ограничениями ресурсов, что может привести к потенциальным замедлениям в работе системы.

Для оптимизации производительности и настройки параметров Java Virtual Machine (JVM) можно настроить параметры, такие как размер кучи (heap). Для этого измените значение переменной окружения DEPLOYER_JAVA_OPTS в соответствии с вашими предпочтениями. Пример:

export DEPLOYER_JAVA_OPTS=${DEPLOYER_JAVA_OPTS:="-server -Xss1024K -Xmx1G -Dlog4j2.formatMsgNoLookups=true"}
Copy-icon

Эта настройка позволяет улучшить эффективность CMS Deployer и решить возможные ограничения ресурсов, обеспечивая более плавную работу системы.

Антипаттерны

Вот несколько рекомендаций по тому, что следует избегать при настройке или конфигурации вашего authoring-окружения:

  1. Медленное сетевое хранилище
    Избегайте использования простого сетевого хранилища, такого как NAS (сетевое подключенное хранилище), подключенного по медной сети (copper network) к вашей вычислительной системе. Эта настройка может привести к медленной производительности из-за проблем с задержкой, особенно во время множественных малых операций.

  2. Использование NFS в качестве протокола монтирования
    NFS (сетевая файловая система) - медленный и ненадежный сетевой протокол. Это особенно актуально, когда он монтируется с настройками по умолчанию.

  3. Размещение всех данных на одном диске
    CMS Studio управляет различными типами данных, включая контент, хранящийся в Git, метаданные, связанные с рабочим процессом и содержанием во встроенной базе данных, а также индексы в ElasticSearch. Чтобы избежать медленного доступа, важно не хранить все эти типы данных на одном диске. Это предотвращает конфликты в сценариях с высокой пропускной способностью и обеспечивает более плавную работу.

  4. Использование настроек по умолчанию для крупных установок
    Установки часто поставляются с настройками, оптимизированными для средних или небольших машин. Однако эти параметры по умолчанию могут быть не подходящими для крупных установок. Рекомендуется просматривать и настраивать параметры в соответствии с вашим конкретным окружением, аппаратными возможностями, бизнес-требованиями и best-практиками.

Связанные статьи

Документация для системного администратора