Contains information on Packet Capture Buffers and Memory Usage
The PacketCapture process stores packets in memory buffers until it has all of the packets for a message. Once the message is complete, it is written out to disk and the memory buffers are freed up for reuse. If PacketCapture runs out of memory buffers it will drop the oldest incomplete message and free up the associated memory buffers. The dropped message packets will increment the discarded packet count.
The number of packets is defined on the Advanced Server Details page. There are three directives, depending on the size of the packets.
The default is 200,000.
Mid size packets
The default is 600,000.
The default is 1.
Most traffic will be mid-sized; therefore, the PacketCapture.NUMBER_BUFFER_POOL_PACKETS is the first number that should be adjusted. The PacketCapture.NUMBER_BUFFER_POOL_PACKETS value is the number of standard sized preallocated packet buffers used to buffer and sort incoming traffic. This number can be increased, but at the cost of memory, since the extra packets will be in memory.
These settings control the size reserved for each buffer in the pool, and total footprint is NUMBER * SIZE. Attached is a spreadsheet to sanity check settings versus process limits with some overhead reserved for PacketCapture's typical memory footprint.
There is a hard maximum size for memory:
*By default, on Windows 2003 Server a process is limited to 2GB of virtual program-accessible address space. This limit may be increased to 3GB using the /3GB kernel option to change the kernel/user space address split dynamic.
See the attached Packet Capture Buffer Calculator:
TECH221091: Why Are Packets Discarded
The /3GB split (per http://technet.microsoft.com/en-us/library/bb124810(EXCHG.65).aspx ) has the following implications per http://msdn.microsoft.com/en-us/windows/hardware/gg487508 :
The virtual address space of processes and applications is still limited to 2 GB unless the /3GB switch is used in the Boot.ini file. When the physical RAM in the system exceeds 16 GB and the /3GB switch is used, the operating system will ignore the additional RAM until the /3GB switch is removed. This is because of the increased size of the kernel required to support more Page Table Entries. The assumption is made that the administrator would rather not lose the /3GB functionality silently and automatically; therefore, this requires the administrator to explicitly change this setting.
The /3GB switch allocates 3 GB of virtual address space to an application that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address 1 GB of additional virtual address space above 2 GB.
If they want to utilize the larger memory as well as increase the maximum process size, they would need to go to 64 Bit. This is not due to a Symantec DLP but due to Windows limitations and how Windows operates.
Also to note, Microsoft does not support user settings of the /userva switch that are not recommended or done by Microsoft. On http://support.microsoft.com/kb/316739 it states
Note Microsoft Product Support Services strongly recommends using a range of memory for the /userva=xxxx switch that is within the range of 2900 to 3030. This range is wide enough to provide a pool of system PTEs that is large enough for all currently observed issues. Typically, a value of 2800 for the xxxx placeholder will provide close to the maximum available number of system PTEs possible.
Note Microsoft Product Support Services (PSS) does not support arbitrary /userva settings; customers should add this setting to the Boot.ini file only per a manufacturer's recommendation.