Qlik Community

QlikView Deployment

Discussion Board for collaboration related to QlikView Deployment.

bgarland
Contributor III

Server Performance Stats

Can someone give me a quick lesson on how to interpret these stats? The documentation didn't really help me too much.

error loading image

1 Solution

Accepted Solutions
Employee
Employee

Server Performance Stats

Well, it's a little hard to talk about virtual memory without getting technical. But basically, you have to distinct between reservation, allocation and commit in this case.

Reservation is performed by QVS to have a memory area to work within.

Allocation is performed when QVS needs to actually extend it's usage within the reserved memory area.

Commit is when data is placed within the allocated area of memory.

The reservation, in a QVS case, is basically "invisible", since it does not directly consume any resources. The final call when reserving memory is up to Windows, and the returned reservation might be smaller than requested by QVS. The reserved memory area can be seen in the QVS event logs (high/debug/verbose logging required) at proccess startup, and are defined by the Working Set limits, inheriting in the QVS settings.

The allocation and commit values, if placed on a curve, will follow each other closely if the memory usage is healthy, with allocation just above commit. Differences or "split curves" in this case can indicate memory leaks, but will show significantly.

The VMFree and VMLargestFreeBlock values are only useful on 32 bit systems, since on a 64 bit system returns the size that Windows reports - and that number is, for some reason I don't know, the total possible memory size of the system. And that is not the same thing as actual free memory. I would disregard these numbers on x64, which is your case.

If interpreting memory statistics, you do have to have some knowledge of memory usage, unfortunately. I hope this helps you though.

7 Replies
vgutkovsky
Honored Contributor II

Server Performance Stats

Brian,

This is directly from the server manual:

  • CPULoad: Average CPU load from QlikView Server during interval
  • VMCommitted: Size in MB of virtual memory actually used by QlikView Server at the end of the interval. This number is part of VMAllocated(MB) and should not exceed the size of the physical memory in order to avoid unacceptable response times
  • VMAllocated: Size in MB of virtual memory allocated by QlikView Server at the end of the interval. VMAllocated(MB)+ VMFree(MB) = total maximum virtual memory space available to the QlikView Server process.
  • VMFree: Size in MB of unallocated virtual memory available to QlikView Server
  • VMLargestFreeBlock: Size in MB of the largest contiguous block of unallocated virtual memory available to QlikView Server. This number is part of VMFree(MB)
  • UsageCalBalance: '-1.00' denotes no Usage CALs exist

Regards,

bgarland
Contributor III

Server Performance Stats

"The documentation didn't really help me too much."

Can anyone translate into non-technical English for me?

Employee
Employee

Server Performance Stats

Well, it's a little hard to talk about virtual memory without getting technical. But basically, you have to distinct between reservation, allocation and commit in this case.

Reservation is performed by QVS to have a memory area to work within.

Allocation is performed when QVS needs to actually extend it's usage within the reserved memory area.

Commit is when data is placed within the allocated area of memory.

The reservation, in a QVS case, is basically "invisible", since it does not directly consume any resources. The final call when reserving memory is up to Windows, and the returned reservation might be smaller than requested by QVS. The reserved memory area can be seen in the QVS event logs (high/debug/verbose logging required) at proccess startup, and are defined by the Working Set limits, inheriting in the QVS settings.

The allocation and commit values, if placed on a curve, will follow each other closely if the memory usage is healthy, with allocation just above commit. Differences or "split curves" in this case can indicate memory leaks, but will show significantly.

The VMFree and VMLargestFreeBlock values are only useful on 32 bit systems, since on a 64 bit system returns the size that Windows reports - and that number is, for some reason I don't know, the total possible memory size of the system. And that is not the same thing as actual free memory. I would disregard these numbers on x64, which is your case.

If interpreting memory statistics, you do have to have some knowledge of memory usage, unfortunately. I hope this helps you though.

bgarland
Contributor III

Server Performance Stats

Thank you. Yes, that does help. I assume the numbers are in MBs? And does the CPU load represent a percentage?

Employee
Employee

Server Performance Stats

Yes, you are correct on both points. The CPU load is an average of the values under the time interval, representing all CPU cores included in teh process affinity.

bgarland
Contributor III

Server Performance Stats

Thanks Stefan!

Not applicable

Re: Server Performance Stats

Hi, i have a question.

can someone tell me how VM commited and VM allocated are related with RAM performance???

appreciate your help