Status > Dashboard pretty CPU-intensive
-
Status > Dashboard with a traffic graph is pretty hungry.
last pid: 88174; load averages: 3.69, 2.64, 1.99 up 0+00:19:15 04:19:18
90 processes: 5 running, 85 sleeping
CPU: 68.3% user, 0.0% nice, 24.0% system, 1.1% interrupt, 6.6% idle
Mem: 370M Active, 230M Inact, 276M Wired, 211M Buf, 1076M Free
Swap: 4096M Total, 4096M FreePID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
40413 root 1 95 0 270M 45172K CPU3 3 0:22 74.46% php-fpm
24092 root 1 92 0 266M 38076K RUN 1 0:15 68.36% php-fpm
7287 root 1 89 0 266M 38204K CPU2 2 0:11 54.98% php-fpm
97850 root 1 86 0 266M 44520K CPU0 0 0:10 43.99% php-fpm2.3-BETA (amd64)
built on Sun Mar 20 00:15:33 CDT 2016
FreeBSD 10.3-RC3You are on the latest version.
Intel(R) Atom(TM) CPU D525 @ 1.80GHz
4 CPUs: 1 package(s) x 2 core(s) x 2 HTT threadsDon't recall seeing CPU Usage like that in 2.2.6
Widgets:
System Information
Interface Statistics
Interfaces
Traffic Graph (WAN)
Snort AlertsIt's a lot better without the traffic graph.
Interesting that Status > Traffic Graph is a lot lighter.
last pid: 51936; load averages: 0.52, 1.46, 1.75 up 0+00:26:56 04:26:59
87 processes: 1 running, 86 sleeping
CPU: 3.4% user, 0.0% nice, 1.2% system, 0.2% interrupt, 95.2% idle
Mem: 363M Active, 215M Inact, 273M Wired, 211M Buf, 1101M Free
Swap: 4096M Total, 4096M FreePID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
50809 root 1 33 0 266M 37856K accept 0 0:01 4.30% php-fpm
24863 unbound 4 20 0 59860K 37564K kqread 3 0:05 0.00% unbound
13497 root 1 20 0 46196K 7960K kqread 2 0:04 0.00% nginx
51443 root 1 20 0 21856K 3096K CPU1 1 0:03 0.00% top
-
Hi
I hope they include the new traffic graph and status graphs. The load will be, mostly for the client and not to the pFsense machine.https://forum.pfsense.org/index.php?topic=108290.msg604340#msg604340
Thanks for pointing that. Is one more reason to switch to the new graph.
-
Yeah jdillard indicated he was working on a replacement. I thought it was interesting that the dashboard was so needy while traffic graph wasn't.
-
I inspected the element and is generated with data on the path element. Is making a SVG with this data with the command M .
Don't know if the new method is better in performance CPU. A sample to teste would be great.
-
yeah I have 4 graphs open can tell a big difference in cpu
-
@mais_um:
Hi
I hope they include the new traffic graph and status graphs. The load will be, mostly for the client and not to the pFsense machine.https://forum.pfsense.org/index.php?topic=108290.msg604340#msg604340
Thanks for pointing that. Is one more reason to switch to the new graph.
Correct, more of the load will be on the client side. Although there are apparently optimizations we can make to how the interface data is gathered (at a later time) that will improve server-side performance.
The traffic graphs are dynamic now (and at a stage where I need to do some clean up):
In the end, you should be able to have multiple interfaces on one graph (although I don't recommend putting the lan and wan on the same graph…kind of pointless :))
-
If the graph is realtime the Date & time info is kinda pointless.
I ready to test it :)
-
@mais_um:
If the graph is realtime the Date & time info is kinda pointless.
Yea, the old one had the date/time there so I added it…when there was also more real estate up there. I may just change the X axis to be more clear (either add the hour, or a label).
-
Uhhh that's sooo cool :)
-
@mais_um:
I ready to test it :)
I am going to hold off on the traffic graphs for the 2.3.1 snapshots so there is plenty of time to test.
-
??? That hurts :P. x.x.1 should not be to long after a x.0 release, usually.
-
@mais_um:
Hi
I hope they include the new traffic graph and status graphs. The load will be, mostly for the client and not to the pFsense machine.https://forum.pfsense.org/index.php?topic=108290.msg604340#msg604340
Thanks for pointing that. Is one more reason to switch to the new graph.
I don't recommend putting the lan and wan on the same graph…kind of pointless :))
but , if i have squid , or another proxy , the traffic is going to be different, then I believe that having the two selected becomes something useful, please correct me if I'm wrong.
-
From my understanding wan (out) = lan (in) and lan (out) = wan (in). Although, I could be mistaken, especially in cases where cache/proxy is involved. Regardless, you will have the option to do so, so we can find out in testing if need be.
-
I have two WAN's, is useful have WAN1 WAN2 and LAN i can make some mentally calc and inverse the sides (in/ou) but better have the 3. Jdillard speaks for that particular case on the last picture he shows, i think.
-
From my understanding wan (out) = lan (in) and lan (out) = wan (in). Although, I could be mistaken, especially in cases where cache/proxy is involved. Regardless, you will have the option to do so, so we can find out in testing if need be.
For most this is true… but with a caching proxy, LAN might see something served from the cache rather than actually hitting WAN for the data... so the data would still go out the LAN interface, but there would be nothing coming in on WAN.
And then there are those with multi-WAN setups... How about a drop-down or widget setting to pick whatever interface you choose, and just show in/out for that interface? Want to see multiple interfaces, add the widget multiple times.
I think waiting for 2.3.1 isn't a bad idea at this point.
-
And then there are those with multi-WAN setups… How about a drop-down or widget setting to pick whatever interface you choose, and just show in/out for that interface?
It will be a multi-select box or similar that allows you to select any number/combination of interfaces (both in and out for each).
So far the options I have planned are: Select interface(s), invert outbound, and refresh interval.
Something else I was going to play with was a totals line, but that sounds more complicated than I originally thought.
Want to see multiple interfaces, add the widget multiple times.
There currently isn't code in place that allows a widget to be used multiple times and configured in multiple ways, so that would have to be implemented first and would also be useful for the monitoring widget (that doesn't exist…yet?)
