+

Search Tips   |   Advanced Search

Intelligent Management: application placement controller logs

Use the log files to troubleshoot issues with the application placement controller, such as the placement of new instances.


apc.log file

The application placement controller logs information regarding application placement decisions the apc.log file. We can submit this file when you contact IBM support so that decisions that are made by the application placement controller can be understood.

We can enable the application placement controller logs with the apc.log.enablePlacementLog custom property. To change the size and number of log files, edit the apc.log.LogFileSize and apc.log.numHistoricalFiles custom properties.


SystemOut.log file

We can look for DCPC400 messages in the SystemOut.log file of the node that runs the application placement controller. These messages contain information regarding the input and result of a placement cycle. This information can be useful in understanding the decisions made by the placement controller. For example:
[7/23/08 10:42:12:086 EDT] 0000006f APCXDMapHelpe I   DCPC400I: Application Placement Controller Input is Cluster name is dc1:
 Cluster's properties: Type=DYNAMIC, Operational Mode=AUTOMATIC, Minimum Instances=2, Maximum Instances=2,     Isolation Preference=None, Vertical Stacking Number=Disabled, Lazy Start Time=Disabled,     Idle Stop Time=Disabled, Current Memory Size=371.2 MB, Maximum Heap Size=256.0 MB   Cluster's Demands: CPU Demand=0.0, Memory Demand=0.0
  Cluster's Utility: {UtilityFunctionLinear extantDemand=0.0, utility=1.0}
  Cluster's Node Membership: jpcammar01Cell01/elara11Node01, jpcammar01Cell01/elara11Node02, Cluster's Members: jpcammar01Cell01/elara11Node01/dc1_elara11Node01,     jpcammar01Cell01/elara11Node02/dc1_elara11Node02, Cluster's Placements: None [7/23/08 10:42:12:090 EDT] 0000006f APCXDMapHelpe I   DCPC400I: Application Placement Controller Output is Cluster name is dc1:
  Cluster's properties: Type=DYNAMIC, Operational Mode=AUTOMATIC, Minimum Instances=2, Maximum Instances=2,     Isolation Preference=None, Vertical Stacking Number=Disabled, Lazy Start Time=Disabled,     Idle Stop Time=Disabled, Current Memory Size=371.2 MB, Maximum Heap Size=256.0 MB   Cluster's Demands: CPU Demand=0.0, Memory Demand=0.0
  Cluster's Utility: {UtilityFunctionLinear extantDemand=0.0, utility=1.0}
  Cluster's Node Membership: jpcammar01Cell01/elara11Node01, jpcammar01Cell01/elara11Node02, Cluster's Members: jpcammar01Cell01/elara11Node01/dc1_elara11Node01,     jpcammar01Cell01/elara11Node02/dc1_elara11Node02, Cluster's Placements: elara11Node02/dc1_elara11Node02, elara11Node01/dc1_elara11Node01, 

If we look at the first DCPC400 message, we can see important information about the clusters:

By comparing the first DCPC400 message, which is the application placement controller input, to the second DCPC400 message, which is the application placement controller output, we can determine that the application placement controller started instances of the dc1 dynamic cluster on the elara11Node02 node and the elara11Node01 node. This conclusion was determined from the following data:

  1. From the Cluster's properties value in the first message, the minimum and maximum number of cluster instances is set to 2.

  2. From the Cluster's Placements value on the first message, we can conclude that no instances are running. Because no instances are running, a breach of the minimum and maximum number of cluster instances has occurred. As a result, two instances are started.

  3. From the Cluster's Placements value on the second message, we can see that two instances were started: one instance on the elara11Node1 node and one instance on the elara11Node2 node. The instance names are in the format of node/server_name.


Related information:

  • Intelligent Management: application placement custom properties