Status View/Queue View is loading very slowly, probably after merging tickets

Moderator: crythias

Post Reply
KaiHerlemann
Znuny Employee
Posts: 10
Joined: 15 Apr 2022, 20:34
Znuny Version: 6.4
Real Name: Kai Herlemann
Company: Znuny

Status View/Queue View is loading very slowly, probably after merging tickets

Post by KaiHerlemann »

Hi,

in our system is the Status View (AgentTicketStatusView) very slowly loading, it takes 17-23 seconds (in average 19 seconds, I activated performance log for that). AgentTicketQueue is loading faster, 9-18 seconds (but also slower than before).
In case of the medium/large view (AgentTicketStatusView;View=Medium and AgentTicketStatusView;View=Preview) it's much faster. Also in case of the small view we have the issue only in case of sort by age or ticket number and sorted ascending/newest at first.

We noticed it for the first time at the same day when this occured in the apache error log:

Code: Select all

[Thu Jul  7 12:09:09 2022] -e: Use of uninitialized value $MetaArticle{"SenderTypeID"} in hash element at /opt/otrs//Kernel/System/Ticket/Article/Backend/Invalid.pm line 97.
[Thu Jul  7 12:09:09 2022] -e: Use of uninitialized value $MetaArticle{"SenderTypeID"} in hash element at /opt/otrs//Kernel/System/Ticket/Article/Backend/Invalid.pm line 97.
ERROR: OTRS-CGI-10 Perl: 5.16.3 OS: linux Time: Thu Jul 7 12:09:09 2022

 Message: Need ChannelID or ChannelName!

 RemoteAddress: 131.173.181.2
 RequestURI: /otrs/index.pl?Action=AgentTicketArticleContent;Subaction=HTMLView;TicketID=18218;ArticleID=94801;FileID=;

 Traceback (32881): 
   Module: Kernel::System::CommunicationChannel::ChannelGet Line: 159
   Module: Kernel::Output::HTML::Article::Invalid::ArticlePreview Line: 137
   Module: Kernel::Output::HTML::Layout::Article::ArticlePreview Line: 106
   Module: Kernel::Modules::AgentTicketArticleContent::Run Line: 77
   Module: Kernel::System::Web::InterfaceAgent::Run Line: 1144
   Module: ModPerl::ROOT::ModPerl::Registry::opt_otrs_bin_cgi_2dbin_index_2epl::handler Line: 39
   Module: (eval) (v1.99) Line: 207
   Module: ModPerl::RegistryCooker::run (v1.99) Line: 207
   Module: ModPerl::RegistryCooker::default_handler (v1.99) Line: 173
   Module: ModPerl::Registry::handler (v1.99) Line: 32

[Thu Jul  7 12:09:09 2022] -e: Use of uninitialized value in concatenation (.) or string at /opt/otrs//Kernel/Modules/AgentTicketArticleContent.pm line 116.
[Thu Jul  7 12:09:09 2022] -e: Use of uninitialized value $Article{"SenderType"} in string ne at /opt/otrs//Kernel/Modules/AgentTicketArticleContent.pm line 138.
This error mesage occured after one of our agents merged one ticket (#1017515) with another one (#1016830). The merge was done at 12:08:51.
Probably she had the #1017515 ticket in two browser tabs open. In the second one, she clicked on some note after the merge was done – but this was not possible, because the notes of the #1017515 ticket now belonged to the #1016830 in the database.
Almost immediately after the merge was done, we had a message like this in the systemlog (AdminLog view):

Code: Select all

Thu Jul 7 12:12:30 2022 (Europe/Berlin)     notice     OTRS-CGI-10     Empty attachment part (2)
And same with "Empty attachment part (1)". This messages were repeatedly in our log. Then I restarted the server, after which we didn't have this message in our log for a longer time. But Znuny was still slow. Since yesterday we have the message in the log again (with a longer break from yesterday afternoon to today in the morning). Mails were sent and received in the meantime, but we didn't have error messages.

We have 153 open and 18,097 closed tickets in our system, no archived ones.
Database engine is MariaDB 10.4.25, operating system CentOS 7 with most recent updates, Znuny version is 6.3.4 (when the issue occured it was 6.3.3, I updated it in the meantime).
The VM has 7812 MiB memory and a 2 core CPU.

On our test system (cloned from the productive system on 22nd May, with 169 open tickets, 15,393 closed tickets and 2,251 archived one) it's fast as always, the StatusView is loading in 4 seconds. (Same CPU/memory, host is related)

Any help is appreciated.

Regards,
Kai
Post Reply