All,

We just recently added two new distributed nodes to our Cognos 10.1.1 (yes, I know) infrastructure.

We have a geographically distributed installation (different datacenters for each server) with two hardware based solaris 10 machines (1 processor, 16 cores, 8gb ram, 100mb/s lan, slow disk) and just added two new solaris 11 virtual machines (1 processor, 8 cores), 24gb ram, 1gb/s lan, fast disk).

We have the application tier and content manager tier split, but resident on the same server listening on different ports.

Normally on the older machines, it takes ~15 minutes to startup the JVM (maximum memory in mb 768), and another 10 minutes to start the cognos services after the JVM is completed) for the primary content manager, and a similar timeframe for all the application tier dispatchers (1158mb JVM). 

On the new machines, our application tier components start up in about 3 minutes with the same 1158 mb (much much faster).

However, when attempting to fail over the content manager from the older machines to the newer machines, it took much much longer -- we stopped the entire platform when we hit 45 minutes of essentially amounted to inactivity.  Based on tuning recommendations, we increased the memory allocation on the backup content manager to 2gb prior to this failover. 

The current primary content manager co-exists with the content store in the same DC and thus has very little latency, but the other DCs have < 100 ms database latency as well, despite being geographically distributed.

Can anyone provide any tips/ setttings to get the JVM to be built faster (java startup params) so that the JVM build doesn't take 20 minutes to start?  The startup times seem to be excessive, and the downtime associated with a content manager failover is prohibitive.

I don't think the java engine is your issue, but the connection between standby CM in DC2, where as the CM database still resides in DC1.
Trying to find network bandwidth and latency architecture statements for CA came up short, for for the old BI I found this:

https://www.ibm.com/support/knowledgecenter/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.crn_arch.10.2.2.doc/c_adgplnnfrastrct.html
"IBM Cognos BI server components should be connected by a network with 100 Mb of available capacity"

If replicating the CM database to your DC2 is not in scope, i would suggest to create a support call with IBM and label it "information request" and ask them if the statement for BI still stands for CA.

All,

We just recently added two new distributed nodes to our Cognos 10.1.1 (yes, I know) infrastructure.

We have a geographically distributed installation (different datacenters for each server) with two hardware based solaris 10 machines (1 processor, 16 cores, 8gb ram, 100mb/s lan, slow disk) and just added two new solaris 11 virtual machines (1 processor, 8 cores), 24gb ram, 1gb/s lan, fast disk).

We have the application tier and content manager tier split, but resident on the same server listening on different ports.

Normally on the older machines, it takes ~15 minutes to startup the JVM (maximum memory in mb 768), and another 10 minutes to start the cognos services after the JVM is completed) for the primary content manager, and a similar timeframe for all the application tier dispatchers (1158mb JVM). 

On the new machines, our application tier components start up in about 3 minutes with the same 1158 mb (much much faster).

However, when attempting to fail over the content manager from the older machines to the newer machines, it took much much longer -- we stopped the entire platform when we hit 45 minutes of essentially amounted to inactivity.  Based on tuning recommendations, we increased the memory allocation on the backup content manager to 2gb prior to this failover. 

The current primary content manager co-exists with the content store in the same DC and thus has very little latency, but the other DCs have < 100 ms database latency as well, despite being geographically distributed.

Can anyone provide any tips/ setttings to get the JVM to be built faster (java startup params) so that the JVM build doesn't take 20 minutes to start?  The startup times seem to be excessive, and the downtime associated with a content manager failover is prohibitive.

I don't think the java engine is your issue, but the connection between standby CM in DC2, where as the CM database still resides in DC1.
Trying to find network bandwidth and latency architecture statements for CA came up short, for for the old BI I found this:

https://www.ibm.com/support/knowledgecenter/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.crn_arch.10.2.2.doc/c_adgplnnfrastrct.html
"IBM Cognos BI server components should be connected by a network with 100 Mb of available capacity"

If replicating the CM database to your DC2 is not in scope, i would suggest to create a support call with IBM and label it "information request" and ask them if the statement for BI still stands for CA.

All,

We just recently added two new distributed nodes to our Cognos 10.1.1 (yes, I know) infrastructure.

We have a geographically distributed installation (different datacenters for each server) with two hardware based solaris 10 machines (1 processor, 16 cores, 8gb ram, 100mb/s lan, slow disk) and just added two new solaris 11 virtual machines (1 processor, 8 cores), 24gb ram, 1gb/s lan, fast disk).

We have the application tier and content manager tier split, but resident on the same server listening on different ports.

Normally on the older machines, it takes ~15 minutes to startup the JVM (maximum memory in mb 768), and another 10 minutes to start the cognos services after the JVM is completed) for the primary content manager, and a similar timeframe for all the application tier dispatchers (1158mb JVM). 

On the new machines, our application tier components start up in about 3 minutes with the same 1158 mb (much much faster).

However, when attempting to fail over the content manager from the older machines to the newer machines, it took much much longer -- we stopped the entire platform when we hit 45 minutes of essentially amounted to inactivity.  Based on tuning recommendations, we increased the memory allocation on the backup content manager to 2gb prior to this failover. 

The current primary content manager co-exists with the content store in the same DC and thus has very little latency, but the other DCs have < 100 ms database latency as well, despite being geographically distributed.

Can anyone provide any tips/ setttings to get the JVM to be built faster (java startup params) so that the JVM build doesn't take 20 minutes to start?  The startup times seem to be excessive, and the downtime associated with a content manager failover is prohibitive.

I don't think the java engine is your issue, but the connection between standby CM in DC2, where as the CM database still resides in DC1.
Trying to find network bandwidth and latency architecture statements for CA came up short, for for the old BI I found this:

https://www.ibm.com/support/knowledgecenter/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.crn_arch.10.2.2.doc/c_adgplnnfrastrct.html
"IBM Cognos BI server components should be connected by a network with 100 Mb of available capacity"

If replicating the CM database to your DC2 is not in scope, i would suggest to create a support call with IBM and label it "information request" and ask them if the statement for BI still stands for CA.

All,

We just recently added two new distributed nodes to our Cognos 10.1.1 (yes, I know) infrastructure.

We have a geographically distributed installation (different datacenters for each server) with two hardware based solaris 10 machines (1 processor, 16 cores, 8gb ram, 100mb/s lan, slow disk) and just added two new solaris 11 virtual machines (1 processor, 8 cores), 24gb ram, 1gb/s lan, fast disk).

We have the application tier and content manager tier split, but resident on the same server listening on different ports.

Normally on the older machines, it takes ~15 minutes to startup the JVM (maximum memory in mb 768), and another 10 minutes to start the cognos services after the JVM is completed) for the primary content manager, and a similar timeframe for all the application tier dispatchers (1158mb JVM). 

On the new machines, our application tier components start up in about 3 minutes with the same 1158 mb (much much faster).

However, when attempting to fail over the content manager from the older machines to the newer machines, it took much much longer -- we stopped the entire platform when we hit 45 minutes of essentially amounted to inactivity.  Based on tuning recommendations, we increased the memory allocation on the backup content manager to 2gb prior to this failover. 

The current primary content manager co-exists with the content store in the same DC and thus has very little latency, but the other DCs have < 100 ms database latency as well, despite being geographically distributed.

Can anyone provide any tips/ setttings to get the JVM to be built faster (java startup params) so that the JVM build doesn't take 20 minutes to start?  The startup times seem to be excessive, and the downtime associated with a content manager failover is prohibitive.

I don't think the java engine is your issue, but the connection between standby CM in DC2, where as the CM database still resides in DC1.
Trying to find network bandwidth and latency architecture statements for CA came up short, for for the old BI I found this:

https://www.ibm.com/support/knowledgecenter/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.crn_arch.10.2.2.doc/c_adgplnnfrastrct.html
"IBM Cognos BI server components should be connected by a network with 100 Mb of available capacity"

If replicating the CM database to your DC2 is not in scope, i would suggest to create a support call with IBM and label it "information request" and ask them if the statement for BI still stands for CA.

All,

We just recently added two new distributed nodes to our Cognos 10.1.1 (yes, I know) infrastructure.

We have a geographically distributed installation (different datacenters for each server) with two hardware based solaris 10 machines (1 processor, 16 cores, 8gb ram, 100mb/s lan, slow disk) and just added two new solaris 11 virtual machines (1 processor, 8 cores), 24gb ram, 1gb/s lan, fast disk).

We have the application tier and content manager tier split, but resident on the same server listening on different ports.

Normally on the older machines, it takes ~15 minutes to startup the JVM (maximum memory in mb 768), and another 10 minutes to start the cognos services after the JVM is completed) for the primary content manager, and a similar timeframe for all the application tier dispatchers (1158mb JVM). 

On the new machines, our application tier components start up in about 3 minutes with the same 1158 mb (much much faster).

However, when attempting to fail over the content manager from the older machines to the newer machines, it took much much longer -- we stopped the entire platform when we hit 45 minutes of essentially amounted to inactivity.  Based on tuning recommendations, we increased the memory allocation on the backup content manager to 2gb prior to this failover. 

The current primary content manager co-exists with the content store in the same DC and thus has very little latency, but the other DCs have < 100 ms database latency as well, despite being geographically distributed.

Can anyone provide any tips/ setttings to get the JVM to be built faster (java startup params) so that the JVM build doesn't take 20 minutes to start?  The startup times seem to be excessive, and the downtime associated with a content manager failover is prohibitive.

I don't think the java engine is your issue, but the connection between standby CM in DC2, where as the CM database still resides in DC1.
Trying to find network bandwidth and latency architecture statements for CA came up short, for for the old BI I found this:

https://www.ibm.com/support/knowledgecenter/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.crn_arch.10.2.2.doc/c_adgplnnfrastrct.html
"IBM Cognos BI server components should be connected by a network with 100 Mb of available capacity"

If replicating the CM database to your DC2 is not in scope, i would suggest to create a support call with IBM and label it "information request" and ask them if the statement for BI still stands for CA.

All,

We just recently added two new distributed nodes to our Cognos 10.1.1 (yes, I know) infrastructure.

We have a geographically distributed installation (different datacenters for each server) with two hardware based solaris 10 machines (1 processor, 16 cores, 8gb ram, 100mb/s lan, slow disk) and just added two new solaris 11 virtual machines (1 processor, 8 cores), 24gb ram, 1gb/s lan, fast disk).

We have the application tier and content manager tier split, but resident on the same server listening on different ports.

Normally on the older machines, it takes ~15 minutes to startup the JVM (maximum memory in mb 768), and another 10 minutes to start the cognos services after the JVM is completed) for the primary content manager, and a similar timeframe for all the application tier dispatchers (1158mb JVM). 

On the new machines, our application tier components start up in about 3 minutes with the same 1158 mb (much much faster).

However, when attempting to fail over the content manager from the older machines to the newer machines, it took much much longer -- we stopped the entire platform when we hit 45 minutes of essentially amounted to inactivity.  Based on tuning recommendations, we increased the memory allocation on the backup content manager to 2gb prior to this failover. 

The current primary content manager co-exists with the content store in the same DC and thus has very little latency, but the other DCs have < 100 ms database latency as well, despite being geographically distributed.

Can anyone provide any tips/ setttings to get the JVM to be built faster (java startup params) so that the JVM build doesn't take 20 minutes to start?  The startup times seem to be excessive, and the downtime associated with a content manager failover is prohibitive.

I don't think the java engine is your issue, but the connection between standby CM in DC2, where as the CM database still resides in DC1.
Trying to find network bandwidth and latency architecture statements for CA came up short, for for the old BI I found this:

https://www.ibm.com/support/knowledgecenter/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.crn_arch.10.2.2.doc/c_adgplnnfrastrct.html
"IBM Cognos BI server components should be connected by a network with 100 Mb of available capacity"

If replicating the CM database to your DC2 is not in scope, i would suggest to create a support call with IBM and label it "information request" and ask them if the statement for BI still stands for CA.

All,

We just recently added two new distributed nodes to our Cognos 10.1.1 (yes, I know) infrastructure.

We have a geographically distributed installation (different datacenters for each server) with two hardware based solaris 10 machines (1 processor, 16 cores, 8gb ram, 100mb/s lan, slow disk) and just added two new solaris 11 virtual machines (1 processor, 8 cores), 24gb ram, 1gb/s lan, fast disk).

We have the application tier and content manager tier split, but resident on the same server listening on different ports.

Normally on the older machines, it takes ~15 minutes to startup the JVM (maximum memory in mb 768), and another 10 minutes to start the cognos services after the JVM is completed) for the primary content manager, and a similar timeframe for all the application tier dispatchers (1158mb JVM). 

On the new machines, our application tier components start up in about 3 minutes with the same 1158 mb (much much faster).

However, when attempting to fail over the content manager from the older machines to the newer machines, it took much much longer -- we stopped the entire platform when we hit 45 minutes of essentially amounted to inactivity.  Based on tuning recommendations, we increased the memory allocation on the backup content manager to 2gb prior to this failover. 

The current primary content manager co-exists with the content store in the same DC and thus has very little latency, but the other DCs have < 100 ms database latency as well, despite being geographically distributed.

Can anyone provide any tips/ setttings to get the JVM to be built faster (java startup params) so that the JVM build doesn't take 20 minutes to start?  The startup times seem to be excessive, and the downtime associated with a content manager failover is prohibitive.

All,

We just recently added two new distributed nodes to our Cognos 10.1.1 (yes, I know) infrastructure.

We have a geographically distributed installation (different datacenters for each server) with two hardware based solaris 10 machines (1 processor, 16 cores, 8gb ram, 100mb/s lan, slow disk) and just added two new solaris 11 virtual machines (1 processor, 8 cores), 24gb ram, 1gb/s lan, fast disk).

We have the application tier and content manager tier split, but resident on the same server listening on different ports.

Normally on the older machines, it takes ~15 minutes to startup the JVM (maximum memory in mb 768), and another 10 minutes to start the cognos services after the JVM is completed) for the primary content manager, and a similar timeframe for all the application tier dispatchers (1158mb JVM). 

On the new machines, our application tier components start up in about 3 minutes with the same 1158 mb (much much faster).

However, when attempting to fail over the content manager from the older machines to the newer machines, it took much much longer -- we stopped the entire platform when we hit 45 minutes of essentially amounted to inactivity.  Based on tuning recommendations, we increased the memory allocation on the backup content manager to 2gb prior to this failover. 

The current primary content manager co-exists with the content store in the same DC and thus has very little latency, but the other DCs have < 100 ms database latency as well, despite being geographically distributed.

Can anyone provide any tips/ setttings to get the JVM to be built faster (java startup params) so that the JVM build doesn't take 20 minutes to start?  The startup times seem to be excessive, and the downtime associated with a content manager failover is prohibitive.