[Glass] Statmonitor questions

[Dale Henrichs via Glass]

On 10/21/15 7:26 AM, Trussardi Dario Romano via Glass wrote:
> Ciao,
>
>> Ciao,
>>
>>
>>>> Another questions:
>>>>
>>>> i have a ubuntu server with 8GB of memory and the 
>>>> SHR_PAGE_CACHE_SIZE_KB set to 2097152.
>>>>
>>>> Now the system is load with some date and i think it used all 
>>>> the SHR_PAGE_CACHE.
>>> Why do you think that the full SHR_PAGE_CACHE is used? Are you 
>>> looking at statmonitor output with vsd?
>>
>> Into a development system i start the statmonitor command and after 
>> some web request,
>>
>> i looking the output with the vsd  interface.
>>
>> The FreeFrameCount go to 0 when i do some heavy query.
>>
>> This means that in this state all the SHR_PAGE_CACHE is used ?
>>
>>>>
>>>> But when do the login to the system the shell report:     memory 
>>>> usage: 9%
>>> I think it depends upon what command you get to see the memory usage 
>>> and on linux, I don't think there is a good way to get memory usage 
>>> information when shared memory is involved, some bits of memory can 
>>> get paged out and so on ....
>>>>
>>>> The memory usage don't consider the kernel.shm* parameter?
>>>>
>>>> The ipcs -lm    report:------ Limiti della memoria condivisa 
>>>> -------- numero massimo di segmenti = 4096 dimensione max seg 
>>>> (kbyte) = 6291456 max total shared memory (kbytes) = 6291456 
>>>> dimensione min seg (byte) = 1
>>>>
>>> I would say that you should run statmonitor and use vsd to look at 
>>> the results ...  once you've started the statmonitor, use vsd (an X 
>>> application) to look at the stat file and I recommend the "Template 
>>> > New Template Chart > CacheMix" to start with ... there are 100's 
>>> of stats, and I just don't have the bandwidth to coach folks on the 
>>> interpretation of the results, but you can check "Show Statistics 
>>> Info" which will give you documentation to read about each stat when 
>>> selected in the chart ...
>>
>> I have a gsDevKit 3.1.0.6 glass environment into deployment status.
>>
>> It's configured with daemontools service and the:gemstone_status report:
>>
>>
>> /etc/service/gs_maintenance: up (pid 498) 397012 seconds
>> /etc/service/gs_seaside-9060: up (pid 492) 397012 seconds
>> /etc/service/gs_seaside-9061: up (pid 496) 397012 seconds
>> /etc/service/gs_seaside-9062: up (pid 491) 397012 seconds
>> /etc/service/gs_seaside-9063: up (pid 497) 397012 seconds
>> /etc/service/gs_seaside-9064: up (pid 494) 397012 seconds
>> /etc/service/gs_seaside-9065: up (pid 490) 397012 seconds
>> /etc/service/gs_statmon-1: up (pid 1612) 396997 seconds
>> /etc/service/gs_statmon-60: up (pid 495) 397012 seconds
>>
>> Now if i think that gs_maintenance   manage the MFC   call  every hour.
>>
>> It's right ?
>>
>>
>> The statmon-1and statmon-60 i think manage the statmonitor   command.
>>
>> But with my surprise into 
>> the gsDevKitHome/gemstone/stones/***name***/stats  subdirectory i 
>> don't found any files.
>
> About it, i found that the gs_statmon*service  set the directory for 
> statmon data  to:/home/**user**/stats/x-second
>
> But it makes sense to store all this data?
> When and who clear this data?
Like tranlogs and backups it is up to you to decide what you keep and 
how long you keep it ... so yes you should schedule a job that cleans up 
the statmon directories periodically ... I would say that ideally you 
would keep both the 60-second and 1-second statmon files for the 
duration of a maintenance cycle and make it part of your tranlog/backup 
cleanup process ...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151021/a4393389/attachment-0001.html>