Last week we discussed in Tech support tools (/ blogs / 2012/02/03 / NetScaler-diagnosis-tech- support-tools /) to help whenever you post any question around NetScaler. Continuing on similar lines let us understand the memory usage on NetScaler and how can you use the diagnostic page to resolve memory-related problems.
The memory is expensive in the context 
and is for NetScaler. It becomes even important when we start using more and more memory-related features you must buffer data NetScaler or to the detection of special attack, etc. It is also essential to the scalability of the connection layer on the system, each time we see high memory usage on NetScaler, we are worried. The truth is that each symptom using high memory is not a problem (some may be) and probably an indication of the running system on resources. In other words, you must update the platform for better resources
To understand the artifacts and we have the "Using the Memory" tool "Troubleshooting", page diagnostic. This tool can you many details on the overall footprint memory usage in NetScaler. Let us in every part of it and to understand it better:
It begins:
TotalMEM (70980052/13344178176) Allocated: 1,958,819,924 (14.68% ) ActualInUse: 1262898384 (9.46%) Free: 11385358252
this gives you a summary of the amount of memory the device has, which is allocated in use and memory available in the system. In the model nCore we divide the entire memory in the foreground, packet engines start with minimum memory required to operate and maintain the allocation of memory depending on the need. Then it enters each individual memory pool allocation and show:
MemPool MaxAllowd CurAlloc ErrLmtFailed ErrAllocFailed ErrFreeFailed
Bytes (Own%) ( % overall)
-------------------------------------- -
MEM_PE 146800640 3775030 (2.57% to 0.03%) 0 0 0
MEM_LB_SERVER 30,064,771,065 16,757,580 (0.06% to 0.13%) 0 0 0
MEM_LB_SESSION 954,204,0 3,670,464 (0.38% to 0.03%) 0 0 0
MEM_LB_SERVICE 30,064,771,065 in 1792 (0.00% 0.00%) 0 0 0
MEM_CSWMEM 176 0 768 200 ( 0.01% 0.00%) 0 0 0
MEM_IOH 36,700,0 0 (0.00% 0.00%) 0 0 0
MEM_LOGGING 30,064,771,065 16,777,215 (0.06% to 0.13%) 0 0 0
MEM_CONN 30,064,771,065 524,302,848 (1.74% 3.93%) 0 0 0
MEM_SNMP 30064771065 118336 (0.00% 0.00%) 0 0 0
MEM_DEBUG 1835008 9632 (0.52% 0.00%) 0 0 0
MEM_MISC 30,064,771,065 15,598,450 (0.05% to 0.12%) 0 0 0
......
This is interesting because it shows the memory allocation details by internal pool and there is a long list of pools. The important thing to note is that each pool has a hat on "MaxAllowd" So there are rare chances of a pool affect overall utilization of system memory. The "CurAlloc" also shows the percentage of memory used from the pool clean over the entire system. Debugging and troubleshooting perspective that you are most interested is "ErrLmtFailed, ErrAllocFailed and ErrFreeFailed". "ErrLmtFailed" tell you the number of times that you have exceeded the sharing limit. "ErrAllocFailed" indicates the number of times the memory allocation failed for this pool. "ErrFreeFailed" indicates the number of times a memory operation failed for this pool. These 3 points of information can tell you if there is some kind of memory of crisis or issue in the system. . If you use a configuration command that returns a memory failure, then you need to check these counters for specific pool
Then you see the big picture of the pool and details on AllocFailed shared memory and FreeFailed events:
SHARED MEMORY POOL
MaxAllowd CurAllocd ErrAllocFailed ErrFreeFailed
---------- ---- -------------------
381681664 108294128 0 0
key buffer structures that play essential role in the framework and session establishment.
CONN_POOL_MEMBERS:
Name CurAllocd CurFree PgAllocd PgAllocFailed
------------ - ---------------
NSB 194666 147036 141 (2.2%) 0
PCB 28 83384 83196 (0.4%) 0
NATPCB 57344 57344 7 (0.1%) 0
B64 229376 22015 7 (0.1%) 0
B128 114688 114681 7 (0.1%) 0
B256 32768 32768 4 (0.1%) 0
SPCB 0 0 0 (0.0%) 0
...
These are database structures that are important for the type of connections and different sessions. The "CurAllocd" may continue to rise according to the requirement to run until the max button. "CurFree" indicates the number of buffers sitting in the pool free to use as you get more connections. "CurAllocd" will be further increased when "CurFree" down significantly and you need more traffic in progress. "PgAllocd" indicates the number of allocated memory pages and the system allocates more pages than "CurFree" down significantly. "PgAllocFailed" indicates the number of memory page allocation failure and it directly impacts the current and new operations. For example, if you hit the allocation failures for NSB and there is no free structure while NetScaler will not be able to pick up new connections or packets. Similarly, if you see failure for the SPCB block, it will impact SSL transactions and failures will be noticed.
Beyond what you see several other specific pool detailed related information. All that is structured to provide a single point to run through system-level details on the use of the entire memory. The coolest part is that you get all this information without NetScaler CLI or GUI 😉 Shell rock ...
0 Komentar