AnsweredAssumed Answered

Installation of P03 for 7.0.2 stalls for appliance SuSE 11 SP3

on Oct 23, 2017
Latest reply on Oct 23, 2017 by Vassilis Boulogiorgos

Like • Show 0 Likes0
Comment • 7

Version 7.0.2

Appliance, OS SuSE 11 SP3

Appliance updater Q3-2017 is applied

Customer did a fresh installation of 7.0.2 GA HF02 RSA provided appliance OS SuSE 11 SP3. Next, they restored from backup of 7.0.1 Patch 1. Next, they migrated the schema from the UI. This process finished successfully. Now customer is trying to apply/install Patch 3 for 7.0.2 in this same appliance, however the installation stalls.

Note:that the customer is not using/running AFX module. Based on what I see in the oracle 12 EM console it appears that memory is an issue during deployment of patch 3.

Has anyone see this issue?

Thanks,

Nasreen

No one else has this question

Outcomes

7 Replies

Chitra Anilkumar Oct 23, 2017 2:06 PM
Mark Correct
Correct Answer
I had this exact same issue with 7.0.2 P03 installation, a few days back, but on Redhat 6.9.

I worked around it by setting the Java MaxPermSize to 512M in /etc/init.d/aveksa_server file and restarting the app server and then reapplying the patch.

May I ask if yours is a remote-database setup and how much RAM is made available on the app server?
Like • Show 1 Like1
Actions
- Philip Martinez @ Chitra Anilkumar on Oct 23, 2017 3:33 PM
  Mark Correct
  Correct Answer
  We had the same issue and it's due to RSA (you guys) changing the Java heap requirements to needing at least 2048M for (-Xmx). Opened up Case 01043584 and in the end we just added up adding an additional 8 GB of memory to each of our VMs.
  
  What we were seeing
  
  If you look at aveksa_server file you'll see that you need over 16 GB in order for JAVA_OPTS to be as follows
  
  JAVA_OPTS="-Xmx${WILDFLY_HEAP_MEM}m -XX:MaxPermSize=${WILDFLY_PERM_MEM}m"
  
  From aveksa_server
  
  # compute JAVA_OPTS based on total system memory
  # MEM will be in kb
  MEM=$(($(grep MemTotal /proc/meminfo|grep -o -E '[0-9]+')/1024))
  # 5% to OS
  OS_MEM=$(($MEM * 5 / 100))
  # 65% to Oracle
  [ -d /u01 ] && ORACLE_MEM=$(($MEM * 65 / 100)) || ORACLE_MEM=0
  # 3GB to AFX if installed
  [ -f /etc/init.d/afx_server ] && AFX_MEM=$((3 * 1024)) || AFX_MEM=0
  WILDFLY_MEM=$(($MEM - $OS_MEM - $AFX_MEM - $ORACLE_MEM ))
  WILDFLY_HEAP_MEM=$(($WILDFLY_MEM * 85 / 100))
  WILDFLY_PERM_MEM=$(($WILDFLY_MEM * 15 / 100))
  # uncomment the below line to visualize what settings are expected to be allocated
  #echo $((MEM)) $WILDFLY_HEAP_MEM $WILDFLY_PERM_MEM $ORACLE_MEM $AFX_MEM $OS_MEM
  if [ -f /home/oracle/build/clover/clover.db ]; then
  # Clover build...always run with 6G because of Clover memory leak
  JAVA_OPTS="-Xmx6g -XX:MaxPermSize=512M -Dclover.pertest.coverage=diff"
  elif [ "${MEM}" -lt $((16 * 1024)) ] && [ -f /etc/init.d/afx_server ]; then
  # Below recommended minimum with AFX
  # <=16G configuration
  JAVA_OPTS="-Xmx1024m -XX:MaxPermSize=256M"
  echo ""
  echo "The server's installed RAM seems to be below the minimum requirement"
  echo "for $prog, and AFX is installed on this system,"
  echo "which can potentially cause memory unavailable messages."
  echo "Hardcoding Wildfly to use $JAVA_OPTS heap settings ..."
  echo ""
  elif [ "${MEM}" -le $((4 * 1024)) ]; then
  # <=4G configuration
  JAVA_OPTS="-Xmx1024m -XX:MaxPermSize=256M"
  elif [ "${MEM}" -le $((128 * 1024)) ]; then
  # <= 128G configuration
  JAVA_OPTS="-Xmx${WILDFLY_HEAP_MEM}m -XX:MaxPermSize=${WILDFLY_PERM_MEM}m"
  else
  # > 128 GB
  JAVA_OPTS="-Xmx32768m -XX:MaxPermSize=3072M"
  fi
  # If memory values need to be increased above these levels set them as needed
  # Becareful to ensure any database needs for memory are not effected
  # Uncomment out the line below with the necessary values.
  #JAVA_OPTS="-Xmx1024m -XX:MaxPermSize=512M"
  Like • Show 1 Like1
  Actions
  - Philip Martinez @ Philip Martinez on Oct 23, 2017 3:34 PM
    Mark Correct
    Correct Answer
    Also, please note while I know you can change the aveksa_server file like mentioned abvove, I prefer not making a config file change and then potentially running into this the next time we patch or upgrade.
    Like • Show 0 Likes0
    Actions
  - Nasreen Mathias @ Philip Martinez on Oct 23, 2017 4:07 PM
    Mark Correct
    Correct Answer
    @philip
    
    I am sorry to hear that. I did adjust the JAVA_OPTS but it didn't help since during installation of the patch I noticed that I need more than 13GB. In my case it is an appliance and not a VM. Based on my testing the values of heap committed and heap used don't make sense. I have applied the latest appliance updater to my environment so I am not sure if there is a OS parameter that would need to looked at.
    Like • Show 0 Likes0
    Actions
    - Nasreen Mathias @ Nasreen Mathias on Oct 23, 2017 4:10 PM
      Mark Correct
      Correct Answer
      did you find any message with text "unable to create new native thread" in the server.log?
      
      Like • Show 0 Likes0
      Actions
- Nasreen Mathias @ Chitra Anilkumar on Oct 23, 2017 3:40 PM
  Mark Correct
  Correct Answer
  @ Chitra
  
  I tried in redhat as well, but didn't have much luck. In my case this is an appliance(local DB) R720 that has been upgraded from 7.0.1.
  Like • Show 0 Likes0
  Actions
Vassilis Boulogiorgos Oct 23, 2017 4:16 PM
Mark Correct
Correct Answer
Have you checked the patch installation log?
There should be an error that may help you identify the root cause.
The log should be in the patch directory. Maybe you can share it here so we can have a look.
Like • Show 0 Likes0
Actions

Installation of P03 for 7.0.2 stalls for appliance SuSE 11 SP3

Outcomes

Related Content

Recommended Content