12-19-2020, 10:23 AM
(12-18-2020, 10:51 AM)fitkoh Wrote: Webmin, in terms of ram usage is very minimal; about 20mb. It's also very easy to turn off from the command line, when it isn't needed. While webmin is not strictly required, and I've indeed left it off for days at a time, it's very useful in the situations that could arise. What are those situations? Could be a lot of things. Changing permissions. Creating users. Editing config files for...? If I wanted to add a webserver to the system, having webmin would allow me to perform the operation without googling specific terminal commands. I like it for the easy way to monitor traffic/load/resource consumption/logs. All of these things can be done by the command line, but webmin makes it easier.Its RAM usage should be proportional to the workload it's doing with intermittent spikes when it kicks-in; so having it off when not needed is a good idea.
(12-18-2020, 10:51 AM)fitkoh Wrote: It is swapping some but not bad, and not really not noticeable from a performance standpoint.Any bit of RAM is a breeze for systems that tight memory-wise. Besides, I hope you do realize that the portion of the RAM used by the buff/cache is critical(/needed) for improving I/O, especially for a database-dedicated system.
Although now that you mention it, I wonder if I could improve performance by adjusting swappiness.
(...)
Here is what memory usage looks like after $/etc/init.d/webmin stop
Code: (Select All)free -m
total used free shared buff/cache available
Mem: 481 174 62 0 244 294
Swap: 511 176 335
(edit)Looks like it's closer to 50mb for webmin, it definitely caches a bit better when webmin is off.(/edit)
(12-18-2020, 10:51 AM)fitkoh Wrote: Cyberpanel is also built with tools to monitor disk/bandwidh consumption, and real-time cpu/memory/drive usage, easy way to monitor traffic/access logs. It isn't quite as light as webmin, but still very fast.I never liked the idea of using third-party stuff (I know that's a recurring theme with me :-), thus I teamed up with a fellow member going by the username of 'manfer' back at FFS (FreeFTPSpace) to hack a decent server monitor for FFS hosting server. Actually, he did all the coding (so the credit is his), I did just review the front-end(/js) code and helped with few optimization around it.
For uptime I use statuscake.com - a simple uptime service that monitors up to 10 sites for free; I've scheduled checks for every 15 minutes.
I try to check on my solusvm panels once a day, but to be fair I miss a day here and there, just in case something slipped by somewhere else. I've heard stories of people losing a terabyte in band a day from ddos; thus far I've been able to stay well within my package limits according to what solus is telling me.
Right away, that exercise did motivate me into writing a quasi real-time module (updated every minutes via a websocket-backed Nodejs back-end), stuffed with more system state params that I felt to be important when I started to run my own VPSs.
I may post a topic on it in the Web development section down the road. It should be quite educational.
(12-18-2020, 10:51 AM)fitkoh Wrote: [edit] I started thinking not just about what you were asking, but also why you were asking. (...)The why is simply because of the limited system RAM for a database server. Database systems need as much RAM as you can through at them to perform better.