reports page loading to slow

[tharsan]

Hello everyone !

First of all, please apogolize for my english, i'm not fluent in English.

I have a bug with my EFA, the reports page is taking lot of time for loading (many minuts in some cases). The problem is only when i'm logged as an user. As admin, the page is loaded immediatly. When i examine the process when the page is loading, I noticed the "MYSQLD" process is using 100% of the CPU.

Does anyone know how i can solve this problem ?

Best regards,

Tharsan

[shawniverson]

Firstly, what version of EFA are you running?

(Look in /etc/EFA-Version)

[tbuchanan]

I'm having this same problem on one of my 3 EFA-Project mail scanners. CentOS 6.8, EFA 3.0.1.1, MySQLd 5.1.73. I'm logging in as admin and when I click on a message to view the spamassassin scoring or message contents, only the first 10-12 lines of the header appear and then it just stops displaying more. I can't go to any other link/tab at that point. I can restart the httpd service and go back to pretty much anything else other than a message report. htop shows 1 or 2 mysqld processes taking up 100+ percent of cpu usage -- 8 cores on the server with 16 gig of ram. Restarting MailScanner does not help. The other identical server does not exhibit this problem and both have about the same total message load. Both servers are VMs running on ESXi. Thanks for any ideas.

[shawniverson]

Have you run a yum update for giggles?

Also, did the EFA experiencing the problem ever have suffer from a mail loop issue from a service crash recently. i.e. the table is full of redundant and bogus reports?

[tbuchanan]

All RPM packages are up to date as of July 1, 2016. I do not believe there have been any problems with the mail processing nor have there been any crashes. When reports are run, they look accurate. The server has been rebooted. Thanks for your reply.

[shawniverson]

I wonder if this is a rendering problem specific to a character set. Which language are your emails primarily?

[tbuchanan]

US English is the primary language. If you are looking for a more specific answer, please tell me where to look or how to obtain the most helpful answer and I will be glad to provide it. If I find that going into message details is hanging, I can restart the httpd process and avoid looking at messages in detail and it will eventually sort itself out and I can again view message details. This sometimes takes 2-3 hours. It seems like regular message processing carries on normally.

[shawniverson]

MYSQLD process pegged out...hmm..

Find another one of these messages, and take note of the message ID (no need to share it here).

I will then dive into the SQL Query that MailWatch is creating and send it to you try try from the command line.

Maybe the SQL query/response might offer a clue. There might be something awry in the mailwatch db tables...

[tbuchanan]

Unfortunately, it does not seem to be tied to any particular message. Once the high cpu usage recovers, I can go into any message details without problem. I'm just wondering why, periodically, the mysqld process (there are usually 2 of them) takes 95% or more of each core available. And also why this does not seem to occur on the clone VM. I don't see anything irregular in the logs -- at least the ones I look at. I can not yet tie the condition to any event that I'm aware of. That is why it is so difficult to troubleshoot. I just thought perhaps those who are more experienced/knowledgeable with all the components might be able to give hints. Thanks for the replies thus far. The EFA-Project servers are working much better than the Barracuda 600 they replaced.