OK, so we’re moving from bottom-posting to top-posting… that’ll make it 
interesting for other readers ;-)

The output of free doesn’t look desperate, but it is starting to look a bit 
You’ve got about a gig of buffer/cache, which the kernel will evict if it needs 
You’ve got 200M of genuinely free memory.
What is potentially a little concerning is the gig of swap in use, that may or 
may not be a problem depending on what else is running on the box and how it’s 
memory use varies over time.

I’m not intimatley familiar with the internals of uacctd’s mysql plugins, but 
my advice would be:

- Monitor the memory usage. If it doesn’t vary much over time you could go on 
for years and be just fine. Keep a close watch on swap usage, if that varies a 
lot or grows over time you’ll want to do something about it.

- Read up on OOM Killer, what it does and how it behaves. If you see OOM Killer 
entries in your logs, it’s time to think again

- Can you put some more memory in the box? 8GB of RAM will cost you about £60. 
How much is your time worth ?


> On 25 Jun 2018, at 12:32, Alex K <rightkickt...@gmail.com> wrote:
> Thanx for the reply.
> The output of free is the following:
> free
>             total        used        free        shared     buff/cache   
> available
> Mem:        4046572     2832576      152012      784240     1061984      
> 204248
> Swap:       3906556     1086080     2820476
> While is as below when stopped:
> free
>               total        used        free      shared  buff/cache   
> available
> Mem:        4046572      520352     3223884       14916      302336     
> 3286952
> Swap:       3906556      485040     3421516
> Seems that mysql plugins are reserving quite some memory as they list first 
> in htop when sorted with memory.
> Thanx,
> Alex
> On Mon, Jun 25, 2018 at 2:22 PM, Dariush Marsh-Mossadeghi 
> <dari...@gravitas.co.uk <mailto:dari...@gravitas.co.uk>> wrote:
>> On 25 Jun 2018, at 11:54, Alex K <rightkickt...@gmail.com 
>> <mailto:rightkickt...@gmail.com>> wrote:
>> Hi all,
>> I have a setup with uacctd monitoring traffic of several interfaces through 
>> With uacctd stopped I see that the server (a relatively small device with 4 
>> GB of RAM) consumes 450MB of RAM. Once I start uacctd the mem usage goes up 
>> to 3.5 GB. I am using mysql plugin and this is running on Debian9 64 bit.
>> Is there any tweaks I can use to put a limit on the memory usage of uacctd.
>> Thanx,
>> Alex
>> _______________________________________________
>> pmacct-discussion mailing list
>> http://www.pmacct.net/#mailinglists <http://www.pmacct.net/#mailinglists>
> tldr; post the output of the free command when uacctd is running and I’ll do 
> my best to interpret it for you :-)
> Is it _really_ using it, or is it just not completely unused?
> The linux kernel generally does pretty good job of keeping stuff that might 
> be useful in memory, but getting rid of it very very quickly if the space is 
> needed for something else.
> The challenge you face is that most of the userspace tools come with a long 
> list of caveats about what they appear to report vs what’s really happening, 
> this is mainly due to the way the kernel shares memory between processes, and 
> its use of as much memory as possible for various caches.
> Some threads worth reading if you’re not familiar with the in’s and out’s of 
> linux kernel memory management...
> https://www.linuxatemyram.com/ <https://www.linuxatemyram.com/>
> https://stackoverflow.com/questions/4802481/how-to-see-top-processes-sorted-by-actual-memory-usage
> <https://stackoverflow.com/questions/4802481/how-to-see-top-processes-sorted-by-actual-memory-usage>
> https://stackoverflow.com/questions/3784974/want-to-know-whether-enough-memory-is-free-on-a-linux-machine-to-deploy-a-new-app/
> <https://stackoverflow.com/questions/3784974/want-to-know-whether-enough-memory-is-free-on-a-linux-machine-to-deploy-a-new-app/>
> Dariush
> _______________________________________________
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists <http://www.pmacct.net/#mailinglists>
> _______________________________________________
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

pmacct-discussion mailing list

Reply via email to