Ajuste de desempenho¶
Esta é uma lista de técnicas de aprimoramento de desempenho para sua instalação OTOBO. Os tópicos incluem configuração, codificação, uso de memória e muito mais.
Módulo de Índice do Ticket¶
O módulo de índice de tickets pode ser definido através da configuração do sistema Ticket::IndexModule
. Existem dois módulos de backend que constroem o índice para a Visão de filas:
Kernel::System::Ticket::IndexAccelerator::RuntimeDB
- Esta é a opção padrão, que gerará cada exibição de fila em tempo real a partir da tabela de tickets. Você não terá problemas de desempenho até ter cerca de 60.000 tickets abertos em seu sistema.
Kernel::System::Ticket::IndexAccelerator::StaticDB
O módulo mais poderoso, deve ser usado quando você tiver acima de 80.000 tickets abertos. Ele usa uma tabela
ticket_index
extra, que será preenchida com palavras-chave com base nos dados do ticket. Use o seguinte comando para gerar um índice inicial após a alterar de back-ends:otobo> /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild
Índice de pesquisa de tickets¶
O OTOBO usa um índice de pesquisa especial para realizar pesquisas de texto completo nos campos de artigos de diferentes canais de comunicação.
Para criar um índice inicial, use este comando:
otobo> /opt/otobo/bin/otobo.Console.pl Maint::Ticket::FulltextIndex --rebuild
Nota
A indexação real do artigo ocorre por meio de um trabalho do daemon do OTOBO em segundo plano. Enquanto os artigos que acabaram de ser adicionados ao sistema são marcados para indexação imediatamente, pode acontecer que o índice esteja disponível apenas após alguns minutos.
Existem algumas opções disponíveis para ajustar o índice de pesquisa:
Ticket::SearchIndex::IndexArchivedTickets
- Defina se os tickets arquivados serão incluídos no índice de pesquisa (desativado por padrão). É aconselhável manter o índice pequeno em sistemas grandes com tickets arquivados. Se isso estiver ativado, os tíquetes arquivados serão encontrados em pesquisas de texto completo.
Ticket::SearchIndex::Attribute
Configurações básicas do índice de texto completo.
Configuração
Ticket::SearchIndex::Attribute
Nota
Execute o seguinte comando para gerar um novo índice:
otobo> /opt/otobo/bin/otobo.Console.pl Maint::Ticket::FulltextIndexRebuild
WordCountMax
- Define o número máximo de palavras que serão processadas para criar o índice. Por exemplo, apenas as primeiras 1000 palavras de um corpo de artigo são armazenadas no índice de pesquisa de artigos.
WordLengthMin
eWordLengthMax
- Usado como limites de comprimento de palavra. Somente palavras com um comprimento entre esses dois valores são armazenadas no índice de pesquisa de artigos.
Ticket::SearchIndex::Filters
Filtros baseados em expressões regulares excluem partes do texto original do índice de texto completo.
Configuração
Ticket::SearchIndex::Filters
Existem três filtros padrão definidos:
- O primeiro filtro remove caracteres especiais como: , & < > ? ” ! * | ; [ ] ( ) + $ ^ =
- O segundo filtro remove as palavras que começam ou terminam com um dos seguintes caracteres: ‘ : .
- O terceiro filtro remove as palavras que não contêm um caractere de palavra: a-z, A-Z, 0-9, _
Ticket::SearchIndex::StopWords
Palavras de parada em inglês para o índice de texto completo. Essas palavras serão removidas do índice de pesquisa.
Configuração
Ticket::SearchIndex::StopWords###en
Existem chamadas stop-words definidas para alguns idiomas. Essas stop-words serão ignoradas ao criar o índice de pesquisa.
Ver também
Se seu idioma não estiver nas definições de configuração do sistema ou você desejar adicionar mais palavras, você poderá adicioná-las a esta configuração:
Ticket::SearchIndex::StopWords###Custom
Pesquisa de documentos¶
O OTOBO usa o Elasticsearch para sua funcionalidade de pesquisa de documentos. Para uma boa introdução aos conceitos, instalação e uso do Elasticsearch, siga as instruções em Getting Started guide.
Tamanho Heap¶
O Elasticsearch é escrito em Java e, portanto, é executado em uma Java Virtual Machine (JVM) em qualquer nó do cluster. Essa JVM usa uma parte da memória, chamada heap, cujo tamanho pode ser configurado no arquivo de configuração jvm.options
.
As configurações mínima e máxima do heap são definidas por padrão para um valor de 1 GB e podem ser modificadas com as seguintes opções:
- Tamanho mínimo de heap
Xms1g
. - Tamanho máximo de heap
Xms1g
.
Se o Xms
tiver um valor menor que o Xmx
, a JVM redimensionará o heap usado sempre que o limite atual for excedido, até que o valor de Xmx
seja atingido. Esse redimensionamento faz com que o serviço seja pausado até ser concluído, o que pode diminuir a velocidade e a reatividade das ações de pesquisa ou indexação. Portanto, é altamente recomendável definir essas configurações para um valor igual.
Aviso
Se o tamanho máximo do heap for excedido, o nó do cluster relacionado para de funcionar e pode até desligar o serviço.
Quanto maior o valor máximo do heap for definido, mais memória poderá ser usada pelo Elasticsearch, o que também aumentará as possíveis pausas para coleta de lixo, realizadas pela JVM. Portanto, é recomendável definir um valor para Xmx
, que não exceda 50% da memória física.
Para obter mais informações e boas regras práticas sobre o tamanho da pilha, acesse`the official documentation <https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html>`__.
Alocação de disco¶
Ao executar o serviço, o Elasticsearch inspeciona o espaço em disco disponível. Com base no resultado, ele decide se alocar novos shards para um nó do cluster. Em alguns casos, ele até realoca os fragmentos longe de um nó. Esse comportamento é determinado pela capacidade do disco atual. Ele pode ser definido pelas configurações no arquivo de configuração elasticsearch.yml. Aqui estão algumas configurações relevantes. Eles vêm com bons valores padrão, mas podem ser importantes na solução de problemas.
cluster.routing.allocation.disk.watermark.low
- Valor padrão de 85%. Quando esse limite for excedido, o Elasticsearch não alocará mais shards para o nó do cluster relacionado. A operação desse nó não é influenciada e os dados ainda podem ser indexados e pesquisados.
cluster.routing.allocation.disk.watermark.high
- Valor padrão de 90%. Quando esse limite for excedido, o Elasticsearch tentará realocar os shards existentes para outros nós que tenham espaço suficiente disponível.
cluster.routing.allocation.disk.watermark.flood_stage
- Valor padrão de 95%. Quando esse limite é excedido, o Elasticsearch atualiza a configuração de todos os índices, que têm pelo menos um fragmento alocado para o nó do cluster relacionado, para blocos de índice somente leitura. Especificamente, eles são sinalizados com
index.blocks.read_only_allow_delete
.Após essa atualização, não é mais possível indexar novos dados a esses índices. Os índices são restritos a pesquisas e para excluir ações apenas.
Nota
Se o flood stage for excedido e determinados índices estiverem configurados no modo somente leitura, essa configuração não será alterada automaticamente pelo Elasticsearch. Se os discos relacionados contiverem espaço livre suficiente novamente devido a ações manuais, será necessário alterar a configuração novamente para o modo normal manualmente.
Para obter mais informações sobre marcas d’água de disco e alocação de shard com base em disco, acesse the official documentation.
Armazenamento de artigos¶
Existem dois módulos de back-end diferentes para o armazenamento de artigos por telefone, email e artigos internos. O armazenamento de artigos usado pode ser configurado na configuração Ticket::Article::Backend::MIMEBase::ArticleStorage
.
Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageDB
Este módulo padrão armazenará anexos no banco de dados. Também funciona com vários servidores front-end, mas requer muito espaço de armazenamento no banco de dados.
Nota
Não use isso com instalações grandes.
Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageFS
Use este módulo para armazenar anexos no sistema de arquivos local. É rápido, mas se você tiver vários servidores front-end, verifique se o sistema de arquivos é compartilhado entre os servidores. Coloque-o em um compartilhamento NFS ou, de preferência, em uma SAN ou solução semelhante.
Nota
Recomendado para grandes instalações.
Você pode alternar de um back-end para outro em tempo real. Você pode alternar o back-end na configuração do sistema e, em seguida, executar este utilitário de linha de comando para colocar os artigos do banco de dados no sistema de arquivos ou vice-versa:
otobo> /opt/otobo/bin/otobo.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS
Você pode usar o --target
opção para especificar o backend de destino.
Nota
Todo o processo pode levar um tempo considerável para ser executado, dependendo do número de artigos que você possui e da energia da CPU disponível e / ou capacidade da rede.
Se você deseja manter anexos antigos no banco de dados, pode ativar a opção de configuração do sistema Ticket::Article::Backend::MIMEBase::CheckAllStorageBackends
para garantir que o OTOBO ainda os encontre.
Arquivando Tickets¶
Como o OTOBO pode ser usado como um sistema à prova de auditoria, excluir tickets fechados pode não ser uma boa ideia. Portanto, há um recurso que permite arquivar tickets.
Os tickets que correspondem a determinados critérios podem ser marcados como arquivados. Esses tickets não serão acessados se você fizer uma pesquisa regular de tickets ou executar um trabalho de agente genérico. O sistema em si não precisa mais lidar com uma quantidade enorme de tickets, pois apenas os tickets mais recentes são levados em consideração ao usar o OTOBO. Isso pode resultar em um enorme ganho de desempenho em sistemas grandes.
Para usar o recurso de arquivamento:
Ative a configuração ``Ticket::ArchiveSystem``nas Configurações de Sistema.
Defina uma tarefa do agente genérico:
- Clique no botão Adicionar Tarega na tela Atendente genérico.
- Configurações da tarefa forneça um nome para o trabalho de arquivamento.
- Execução automática: selecione as opções apropriadas para agendar essa tarefa.
- Selecionar chamados: Pode ser uma boa ideia arquivar apenas os tickets em um estado fechado que foram fechados há alguns meses antes.
- Alterar/Adicionar Atributos do Chamado: defina o campo*Arquivar chamados selecionados* to Arquivar os chamados.
- Salve a tarefa no final da página.
- Clique no link * Executar esta Tarefa * na tabela de visão geral para ver os tickets afetados.
- Clique no botão Executar Tarefa.
Nota
Até 5000 tickets podem ser modificados executando esta tarefa manualmente.
Ao procurar tickets, o padrão do sistema é procurar tickets que não estão arquivados.
Para procurar tickets arquivados:
- Abra a tela de pesquisa de tickets.
- Defina Procurar Arquivo como Tickets não arquivados ou * Todos os tickets *.
- Realize a pesquisa.
Armazenamento em cache¶
Um módulo de cache rápido é uma grande ajuda em termos de desempenho. Recomendamos usar um servidor Redis Cache ou criar um ramdisk.
Instale um servidor de cache Redis¶
- Instale servidor Redis
Antes de tudo, você precisa instalar o mais novo servidor Redis. A maneira mais fácil é setup Redis no mesmo host que OTOBO esta instalado à sua porta padrão.
- Instale o módulo Perl Redis ou Redis::Fast
Você pode escolher qual módulo Redis usar: Redis ou`Redis::Fast` (que é compatível com Redis mas ~2x faster). Por favor use nosso otobo.CheckModules.pl --list
para escolher o pacote certo para você:
otobo> /opt/otobo/bin/otobo.CheckModules.pl
- Configurar OTOBO para Redis
Por favor, use o OTOBO SysConfig (Administração-> Configuração do sistema) para configurar o OTOBO corretamente:
| Setting | Description | Default value |
| ----------------------------- | -------------------------- | -------------- |
| Cache::Redis###Server | Redis server URL | 127.0.0.1:6379 |
| Cache::Redis###DatabaseNumber | Number of logical database | 0 |
| Cache::Redis###RedisFast | Use or not Redis::Fast | 0 |
| Cache::Module | Activate Redis Cache Module| DB (use Redis) |
Cache do RamDisk¶
O OTOBO armazena muitos dados de cache temporários no /opt/otobo/var/tmp
. Verifique se ele usa um sistema de arquivos e armazenamento de alto desempenho. Se você possui RAM suficiente, também pode tentar colocar este diretório em um ramdisk como este:
otobo> /opt/otobo/bin/otobo.Console.pl Maint::Session::DeleteAll
otobo> /opt/otobo/bin/otobo.Console.pl Maint::Cache::Delete
root> mount -o size=16G -t tmpfs none /opt/otobo/var/tmp
Nota
Adicione ponto de montagem persistente no /etc/fstab
.
Aviso
Este será um armazenamento não permanente que será perdido na reinicialização do servidor. Todas as suas sessões (se você as armazenar no sistema de arquivos) e os dados do cache serão perdidos.
Clustering¶
Para cargas muito altas, pode ser necessário operar o OTOBO em um cluster de vários servidores front-end. Esta é uma tarefa complexa com muitas armadilhas. É altamente recomendável entrar em contato com nossos especialistas antes de tentar implementar isso por conta própria.