Troubleshooting » History » Version 4
Luke Murphey, 04/09/2010 12:31 AM
1 | 1 | Luke Murphey | h1. Troubleshooting |
---|---|---|---|
2 | 1 | Luke Murphey | |
3 | 1 | Luke Murphey | h2. NSIA Runs Out of Memory |
4 | 1 | Luke Murphey | |
5 | 1 | Luke Murphey | To resolve this either: |
6 | 1 | Luke Murphey | * Reduce the rate of the scans (this is preferred) |
7 | 1 | Luke Murphey | * Increase the amount of memory available to NSIA |
8 | 1 | Luke Murphey | |
9 | 1 | Luke Murphey | Note that NSIA has a limit on the maximum amount of memory that it will use which is independent of the amount of memory that the server it if running on has. In other words, NSIA may be running out of memory even though the server has plenty of available memory. The maximum limit can be modified by changing the Java settings |
10 | 1 | Luke Murphey | |
11 | 1 | Luke Murphey | h3. Reducing the Scan Rate |
12 | 1 | Luke Murphey | |
13 | 2 | Luke Murphey | To reduce the scan rate, open the configuration page (i.e. http://127.0.0.1:8080/System/Configuration) and reduce the "Maximum HTTP Scan Threads" setting. By default, the system will allocate 10 threads to scanning at one time. Reducing the number of threads will reduce the memory and CPU usage of the system at any one time. |
14 | 2 | Luke Murphey | |
15 | 2 | Luke Murphey | Additionally, reducing the scan frequency of the individual rules may be necessary to reduce the load on the system. Finally, system load can be reduced by decreasing the number of resources to be scanned by lowering the depth or resource limit on HTTP Auto-Discovery rules. However, note that reducing the number of resources to scan reduces the chance that NSIA will detect a security problem. Generally, this option should be avoided. |
16 | 1 | Luke Murphey | |
17 | 1 | Luke Murphey | h3. Increasing Memory |
18 | 1 | Luke Murphey | |
19 | 1 | Luke Murphey | The Java Runtime Environment contains a setting that limits how much memory the application uses. To increase this value, edit the config.ini file and change the value of the JVM.Arguments option. The value of the argument should be "-Xmx" followed by the amount of mamoery you want allocated to the JRE. Below is a sample of a config.ini file that allocates up to 2 GB: |
20 | 1 | Luke Murphey | |
21 | 1 | Luke Murphey | <pre> |
22 | 1 | Luke Murphey | JVM.Arguments=-Xmx2g |
23 | 1 | Luke Murphey | </pre> |
24 | 3 | Luke Murphey | |
25 | 3 | Luke Murphey | Note that the config.ini file will only have an effect if the NSIA binaries are used (such as "ThreatFactor NSIA.exe" or "ThreatFactor NSIA Service.exe"). You'll need to set the options to the JVM if you are calling it directly. Note that the daemon script that is provided with NSIA will need to be modified to change the memory settings for the the daemon. |
26 | 4 | Luke Murphey | |
27 | 4 | Luke Murphey | h2. NSIA Terminates Indicating "invalid maximum heap size" |
28 | 4 | Luke Murphey | |
29 | 4 | Luke Murphey | NSIA may fail if the memory settings are incorrect with a message such as: |
30 | 4 | Luke Murphey | |
31 | 4 | Luke Murphey | <pre> |
32 | 4 | Luke Murphey | Invalid maximum heap size: -Xmx512m |
33 | 4 | Luke Murphey | Could not create the Java virtual machine. |
34 | 4 | Luke Murphey | </pre> |
35 | 4 | Luke Murphey | |
36 | 4 | Luke Murphey | The settings need to be changed to be more conservative such as: |
37 | 4 | Luke Murphey | |
38 | 4 | Luke Murphey | <pre> |
39 | 4 | Luke Murphey | JVM.Arguments=-Xms40m -Xmx256m |
40 | 4 | Luke Murphey | </pre> |