GoAccess taking huge RAM allocations & running long times

[aFrI]

TITLE

GoAccess taking huge RAM allocations & running long times

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.79 Update #4 (on Debian Linux 12.15)

PROBLEM DESCRIPTION

Good day,

As GoAccess was introduced as the new stats tool, I was switching from the former configured AWStats. As I was checking our monitorings I recognized periods of huge RAM allocations since then - today I went to the server and found GoAccess seems to be running a bit wild, screenshot of htop:

As I have absolutely no experience with GoAccess, I would like to ask if that may be considered normal - or if the set parameters are producing the situation.

I would believe a statistics-tool running on a daily basis should possibly not have so much hunger for RAM..

I am switching back to AWStats for now - I am open for delivering more exact details if needed or test mitigations.

STEPS TO REPRODUCE

Switch from AWStats to GoAccess for a Plesk site.

ACTUAL RESULT

High allocations in RAM from the GoAccess process & steadily allocating one core with 100% for hours.

EXPECTED RESULT

I can just go from my expectations, but little knowledge of the GoAccess product: I would believe such tooling should not use such amounts of RAM.

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Help with sorting out

 

[aFrI]

I just tested to give a sigterm, but none of the two running processes are considering it..

short strace on the one process which seems to still iterate over a log file:



Update: And I am stupid, and just did find the other similar topic (GoAccess taking huge RAM allocations & running long times) - so this can be closed as a duplicate - sorry for me not realizing this before posting.. *sigh

 

[Sebahat.hadzhi]

Hello, @aFrI . We indeed had a similar complaint recently under this thread. I am assuming that's the one you had in mind in your second reply. Could you please confirm if you also have website(s) with dynamic URLs (e.g. search, filtering, e-commerce)? We do have an existing task to review the behavior, I just want to determine if the usage spike is caused by the same reason in your case. Thank you in advance.

 

[aFrI]

Yes, our site has PHP functionality working on different GET parameters to offer content, so I would consider us having dynamic URLs. It is an online forum.