Pages/Lists Not Loading Completely

[jeffhochberg]

Hello,

I'm running Cacti 1.2.12 (with Spine) on Ubuntu 18.04 Server with Apache2 (2.4.29-1) and MariaDB 10.1.

As I navigate around the admin interface, most of the time things are OK but I've found there are pages that don't load entirely, or at all. I have to force reload the page before I see all of the content. This isn't happening with any one or two pages in particular. Actually, it's very inconsistent.

Additionally, any time I navigate to Management -> Devices, several of the devices are not displayed in the list. I have to click 'Go' at the top of the window, then the entire list of devices displays as expected. The search criteria are already set to 'Site: Any', 'Data Collector: Any', 'Template: Any', and 'Location: All'. All I need to do is click 'Go'.

Has anyone else run into similar issues before? If so, what was necessary to resolve these issues?

FYI - I have installed another application on the same server since having installed Cacti and it is not exhibiting these issues. This was happening before and continues to be the case.

Thank you,

-JeffH

[bmfmancini]

Hey There

Not seeing the same thing across my installs

it might be worth to do the following

go to devlopers tools in your browser and see where the delay is
Is you Server possibly under alot of load ?
Is your PHP memory set to the recomended Paramters ? Check the techsupport tab to make sure you are matching up
are your Mysql connections being exceeded ?

I would check with that first and of course check for any errors in cacti.log

[jeffhochberg]

Thanks for your response.

When looking at the page loads from within Chrome or FF Dev tools, neither show any indications of performance-related issues, or any other errors. All it looks like is the server isn't returning the content on a request to load the page.

The server has incredibly low utilization. Cacti and Zabbix are the only two applications running on the server and are only monitoring the server they're installed on and one other.

I did have some errors in the logs about SetUID on a ping check and about poller and cron being out of sync, but those have since been resolved. I was about to say there were no additional errors, but I just found these:

• 2020-07-06 21:58:01 - POLLER: Poller[Main Poller] WARNING: There are 2 processes detected as overrunning a polling cycle, please investigate

• 2020-07-06 21:58:01 - POLLER: Poller[Main Poller] WARNING: Poller Output Table not Empty. Issues: 8, DS[Cacti Stats - User Stats, Cacti Stats - User Stats, XXXX- Device I/O -vda, XXXX- Device I/O -vda1, XXXX- Load Average - 5 Minute, XXXX - Memory - Buffers] Graphs[Cacti Stats - User Logins, Cacti Stats - User Sessions, XXXX - Device I/O - Reads/Writes vda, XXXX - Device I/O - Reads/Writes vda1, XXXX - Load Average, XXXX- Memory Usage]

I'll have to research those and figure out the root cause.

Just for the heck of it, I build another Ubuntu server last night. Instead of building/installing Cacti and Spine from the source, I installed the default packages from the Ubuntu repository. The new server does seem to be running better.

I used this article as the basis for how I installed Cacti and Spine on the original server:

https://medium.com/make-it-easy/how-to- ... 290c2b3158

PHP 7.4 is configured as follows:

Code: Select all

memory_limit = 512M
max_execution_time = 60

MariaDB is configured as follows:

Code: Select all

collation-server = utf8mb4_unicode_ci
max_heap_table_size = 128M
tmp_table_size = 128M
join_buffer_size = 256M
innodb_file_format = Barracuda
innodb_large_prefix = 1
innodb_buffer_pool_size = 2048M
innodb_flush_log_at_timeout = 3
innodb_read_io_threads = 32
innodb_write_io_threads = 16
innodb_io_capacity = 5000
innodb_io_capacity_max = 10000
innodb_buffer_pool_instances = 21

Perhaps something's wrong with the settings that were recommended in aforementioned article?

Code: Select all

Alias /cacti /var/www/html/cacti
<Directory /var/www/html/cacti>
Options +FollowSymLinks
AllowOverride None
<IfVersion >= 2.3>
Require all granted
</IfVersion>
<IfVersion < 2.3>
Order Allow,Deny
Allow from all
</IfVersion>
AddType application/x-httpd-php .php
<IfModule mod_php.c>
php_flag magic_quotes_gpc Off
php_flag short_open_tag On
php_flag register_globals Off
php_flag register_argc_argv On
php_flag track_vars On
# this setting is necessary for some locales
php_value mbstring.func_overload 0
php_value include_path .
</IfModule>
DirectoryIndex index.php
</Directory>

Otherwise, Apache, PHP, and MariaDB are using the remaining default settings.

On the other hand, Zabbix has been running solidly! No issues. And, again, the new Cacti server that I installed from the Ubuntu repos seems to be behaving much better.

[netniV]

Hello,

I'm running Cacti 1.2.12 (with Spine) on Ubuntu 18.04 Server with Apache2 (2.4.29-1) and MariaDB 10.1.

As I navigate around the admin interface, most of the time things are OK but I've found there are pages that don't load entirely, or at all. I have to force reload the page before I see all of the content. This isn't happening with any one or two pages in particular. Actually, it's very inconsistent.

Additionally, any time I navigate to Management -> Devices, several of the devices are not displayed in the list. I have to click 'Go' at the top of the window, then the entire list of devices displays as expected. The search criteria are already set to 'Site: Any', 'Data Collector: Any', 'Template: Any', and 'Location: All'. All I need to do is click 'Go'.

Has anyone else run into similar issues before? If so, what was necessary to resolve these issues?

FYI - I have installed another application on the same server since having installed Cacti and it is not exhibiting these issues. This was happening before and continues to be the case.

Thank you,

-JeffH

I would take a look at the browser console window and see if any errors are occurring. Particularly when you have requested any action that may take some time. Unfortunately, PHP locks the session to a single use and this can cause temporary slowness if you have multiple requests occurring. We have tried to minimise these but there are still plenty of areas that could be refined given time.

[jeffhochberg]

Hello,

I wanted to circle back after encountering this several more times since my last post. The issue is quite simple - it's me! I think you hit the nail right on the head in terms of how PHP is locking sessions.

Unfortunately, PHP locks the session to a single use and this can cause temporary slowness if you have multiple requests occurring. We have tried to minimise these but there are still plenty of areas that could be refined given time.

The only time I ever seem to see the issue is if I'm in making a lot of configuration changes in rapid succession. I tend to click around very quickly and it's very likely I'm just not giving things enough time to finish processing on the server.

Any time I go back to the server after having not made any changes for a few minutes, everything loads just fine. I never have issues with graphs loading. It just works.

Thanks for the feedback!

-JeffH