Question & Answer
Question
How do you get verbose GC output to another log besides native_stderr?
Cause
Verbose GC data is captured by default in the native_stderr.log for AIX®, Windows® and Linux® and native_stdout.log for Solaris and HP.
Note: For writing verbose gc to a specified log in Solaris and HP-UX, please see this link.
At present there is no capability to rotate native_stderr logs in WebSphere. Therefore you can use -Xverbosegclog to minimize the size/contents of the native_stderr log file.
Note: For writing verbose gc to a specified log in Solaris and HP-UX, please see this link.
At present there is no capability to rotate native_stderr logs in WebSphere. Therefore you can use -Xverbosegclog to minimize the size/contents of the native_stderr log file.
Answer
** Note: When using Verbose GC to analyze JVM problems, it is best to leave the verbose GC logging to the default location. When writing Verbose GC to a specified log, occasional error messages are omitted or not set inline with the data. This can make diagnosing the problem very difficult and prolong time to resolution.**
-Xverbosegclog[:<file>[,<X>,<Y>]]
Added to the Generic JVM arguments in WebSphere or jvm.options in Liberty, it causes -verbose:gc output to be written to the specified file. If the file cannot be found, -verbose:gc tries to create the file, and then continues as normal if it is successful. If it cannot create the file (for example, if an invalid file name is passed into the command), it will redirect the output to stderr.
| WebSphere Application Server 9.0, 8.5, 8.0, 7.0 |
-Xverbosegclog[:<file>[,<X>,<Y>]]
Added to the Generic JVM arguments in WebSphere or jvm.options in Liberty, it causes -verbose:gc output to be written to the specified file. If the file cannot be found, -verbose:gc tries to create the file, and then continues as normal if it is successful. If it cannot create the file (for example, if an invalid file name is passed into the command), it will redirect the output to stderr.
If you specify <X> and <Y> the -verbose:gc output is redirected to <X> files, each containing <Y> GC cycles.
The dump agent tokens can be used in the file name. See Dump agent tokens for more information. If you do not specify <file>, verbosegc.%Y%m%d.%H%M%S.%pid.txt is used.
example: -Xverbosegclog:${SERVER_LOG_ROOT}/verbosegc.log,10,10000
* This will create a maximum of 10 gc logs named verbosegc.log.001 through verbosegc.log.010 in the same directory as the JVM logs (SystemOut, SystemErr, native_stderr, native_stdout)
If you just set: -Xverbosegclog
you will get a new log each time with the naming convention:
verbosegc.yyyymmdd.hhmmss.pid#.txt and the logs to not rotate, so they will build up on your system until/unless you clean them off.
you will get a new log each time with the naming convention:
verbosegc.yyyymmdd.hhmmss.pid#.txt and the logs to not rotate, so they will build up on your system until/unless you clean them off.
If you set something like this: -Xverbosegclog:${SERVER_LOG_ROOT}\verbosegc-%Y%m%d-%H%M%S_%p.log,10,10000
You will get logs with the naming convention:
verbosegc-yymmdd-hhmmss-pid#.log.001, verbosegc-yymmdd-hhmmss-pid#.log.002, etc for each pid, and the logs will rotate for that pid only!
** When you restart the JVM, you will get a new sequence of logs for the new pid, so you will also get a buildup of logs on your system until/unless you clean them off.
You will get logs with the naming convention:
verbosegc-yymmdd-hhmmss-pid#.log.001, verbosegc-yymmdd-hhmmss-pid#.log.002, etc for each pid, and the logs will rotate for that pid only!
** When you restart the JVM, you will get a new sequence of logs for the new pid, so you will also get a buildup of logs on your system until/unless you clean them off.
You can have the logs directed to other drives. This causes the WebSphere collector tool to not pick up the logs, so you'll need to zip them up separately. You can redirect the gc logs to another directory with:
-Xverbosegclog:C:\waslogs\server1\<options>
-Xverbosegclog:C:\waslogs\server1\<options>
For AIX or Linux, use the JVM argument using the unix pathing convention, like:
-Xverbosegclog:${SERVER_LOG_ROOT}/verbosegc.log,10,10000
or
-Xverbosegclog:/opt/waslogs/server1/<options>
or
-Xverbosegclog:/opt/waslogs/server1/<options>
** Special notes:
1) Do NOT name the redirected verbosegc logs "native_stderr.log". System messages needed for diagnosis still get written to the native_stderr.log.
2) When you send logs to WebSphere support, we want all JVM logs SystemOut, SystemErr, native_stderr, native_stdout, verbosegc
- In the administrative console, click Servers > Server Types > WebSphere application servers > server_name. Then, under Server Infrastructure, click Java™ and process management > Process definition.
- Select Java Virtual Machine .
- Specify values for the JVM settings in the Generic JVM arguments field and click OK.
- Click Save on the console taskbar.
- Restart the application server.
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Component":"Java SDK","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"PF033","label":"Windows"}],"Version":"9.0;8.5;8.0;7.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
21 July 2023
UID
swg21384096