From vmstat, the sr (scan rate) is better indicator - if you see sr column > 0, 
it means the kernel is spending time searching for usable memory pages, and if 
this does happen often, it is time to review the memory consumers/add more RAM.

Toomas

> On 8. Jul 2021, at 17:55, Richard L. Hamilton <rlha...@smart.net> wrote:
> 
> Because of the way swap is implemented on Solaris and descendants (on SVR4 
> in general, maybe), the vmstat "swap" column is very misleading; check output 
> of swap -l (lower-case L option) instead, and if the free column is the same 
> as the blocks column, no real swap is actually being used.
> 
> Likewise, all block disk I/O (including filesystem) goes though the paging 
> mechanism, so the vmstat "pi" column just reflects reads or access via mmap. 
> Given that the "po" column is zero, I doubt that you're actually paging out 
> just to make room, although that's not a great indication, as file or block 
> disk writes or pages written due to msync() would also probably count there.
> 
> I suspect some of the misleading "swap" column change may also be due to 
> files being created and written, or deleted, in tmpfs filesystems like /tmp 
> and /var/run.
> 
>> On Jul 8, 2021, at 10:40, russell <str...@willows7.myzen.co.uk> wrote:
>> 
>> Hi,
>> 
>> I am running Hipster 2021.04 with illumos-3f770aab81 and running System 
>> Monitor 1.24.2.
>> System monitor is reporting Memory utilisation of 17.5GiB (27.5%) of 
>> 63.9GiB, however it is reporting 115.7MiB (0.7%) of 15.9GiB of swap it being 
>> used.
>> I have always thought that swapping occurred when there is insufficient 
>> memory for an application so another application or pages of an application 
>> could be swapped to disk to free RAM.
>> Given that there at least 32GB of RAM free, surely it would not need to page.
>> 
>> $ vmstat 30
>> kthr      memory                             page disk                       
>>    faults      cpu
>> r b w    swap          free       re   mf    pi po   fr de sr ro   s0 s1 s2  
>>  in       sy           cs   us sy id
>> 0 0 0 68532576 60872200 33 244   41 0  0   0  55   8   4   4 -0   4516   
>> 11765  6689    1 0 99
>> 0 0 0 49794916 48173452 1   431 344 0  0   0    0 49 23 25   0 18812 119079 
>> 53181   9 3 88
>> 0 0 0 49782568 48159484 2   725 300 0  0   0    0 32 16 17   0 16908 121531 
>> 53655 10 3 87
>> 0 0 0 49762892 48139892 0   754 218 0  0   0    0 33 17 17   0 20269 118644 
>> 52612 10 3 87
>> 0 0 0 49735940 48112244 3   595 407 0  0   0    0 54 28 27   0 19599 119165 
>> 53390 10 3 87
>> 0 0 0 49712360 48086132 2   476 244 0  0   0    0 37 19 19   0 19248 119117 
>> 53090 10 3 87
>> 0 0 0 49692084 48064828 17 444 435 0  0   0    0 43 22 21   0 19950 119938 
>> 53753 10 3 87
>> 
>> While it is only around 100MB can I tweak the system to avoid paging when 
>> there is so much ram?
>> 
>> TIA
>> 
>> Russell
>> 
>> 
>> 
>> 
>> _______________________________________________
>> openindiana-discuss mailing list
>> openindiana-discuss@openindiana.org
>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>> 
> 
> 
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss

_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Reply via email to