Can Cognos 8 be installed on the SQL Server 2005-same server?

[Ray]

Hi,

We have heard lots of positive things about Cognos, so we are planning to move to Cognos. But we do not have much experience. So we are hoping to get some help from the experts here.

Currently we have our data in MS SQL Server 2005. We are wondering if we could install Cognos on the same server, the server for SQL Server 2005?

Thank you,

Ray

[ducthcogtechie]

Both sql server 2005 and the C8 java stack are quite memory hungry.
In sql server allocate only 1 cpu and set the max memory to 1 gig or so.

[Ray]

Both sql server 2005 and the C8 java stack are quite memory hungry.
In sql server allocate only 1 cpu and set the max memory to 1 gig or so.

Thanks dutchcogtechie. So if the memory on the server is sufficient, there should not be any problem having both Cognos and SQL Server on the same server, right? I heard from a friend who had a little experience with Cognos 7, that we need to install windows active directory server before the installation of Cognos. Does this mean we need to install windows active directory server on the same server as well?

Thank you,

Ray

[ducthcogtechie]

Series 7 often requires authentication. Cognos includes a built of the Sun ONE directory server.
I think that this is what your firend was referring to.
In Cognos 8 you can authenticate to almost anything, without requiring the installation of anything. Just point to the authentication source via Cogos configuration.

[Ray]

Series 7 often requires authentication. Cognos includes a built of the Sun ONE directory server.
I think that this is what your firend was referring to.
In Cognos 8 you can authenticate to almost anything, without requiring the installation of anything. Just point to the authentication source via Cogos configuration.

Thanks dutchcogtechie!

[goose]

Hi Ray

Adding to what dutchcogtechie has already said the following points may help you:

• Consider hosting your sql server data etc on seperate disk if your box can accomodate this
• Make sure when you configure processing capacity for cognos you bear in mind that you are sharing resources with sql server so the cognos best practises default values may need some tweaking.
• Consider reducing the max memory size for the java process to 712MB (small config) or even less
• Consider reducing the default sort buffer size (we use 1MB)
• If your using IIS for gateway use the isapi dll

Good luck

Cheers
Angus

[ducthcogtechie]

• Consider reducing the default sort buffer size (we use 1MB)

The sort buffer runs inside the set java stack next to the servlets.
(about 2  x the max number of concurrent reports max. That makes even the default 4 an extremely safe number, as i always set the stack to small (768), and the sort buffer to 16. That leves 768 minus 128 for the servlets, which should be more then enough) Setting it to 1 mb is chooking your report buffer for no reason.

[goose]

Thanks dutchcogtechie I will check that out. My site ran into issues and after a week of late nights and load testing with cognos support they recommended this 1MB setting. I also experienced the scenario where the java process just started using more and more memory and eventually would hang and cognos would have to be bounced (8.1 site). I have stuck with the 1MB setting since then and havent had any issues. Best option is to always test, this setting is heavily dependent on amount of concurrent reports so no one value will be ideal.

Do you have any links for docs on architecture of components running in java process?

[goose]

Hi Guys - I found this nice response to a question on sort buffer sizing (from http://businessintelligence.ittoolbox.com/groups/technical-functional/cognos-reportnet-l/sort-buffer-size-in-configuration-1214749?cv=expanded)

The Important Bit

This parameter (sort buffer size) is only used by the layer that performs the relational query

Im not so sure the sort buffer lives as part of the java process, it makes more sense for it to be part of the bibuss process. Dutchcogtechie whats your take on this?

Full Response

This parameter is only used by the layer that performs the relational query.
Sort operations on xtab members is done by the dynamic cube that is
constructed from the relational datastream. In essence, as data is being
sorted the buffer is used and once full it spool out to temporary files and
data is paged in and out accordingly. Hence, the larger buffer may defer
smaller sorts from ever hitting the disk.

The side effect of this parameter is that there could n*sortmemory size
buffers allocated under the query engine. eg. three concurrent requests that
require internal sort processing = 3 * 16 meg.

Ideally, you want to ensure that any temporary file I/O performed for a
query is associated to your faster disks and ideally those devices are set
up for write-back caching. That is, the I/O request we make to write data is
done as a lazy write via memory that the O/S manages. Win2K sp3 had a
performance issue with SCSI devices that was fixed in SP4 that penalised the
write throughput.

One of the tuning parameters is the amount of memory used for sort batches.
When sorting large tables or results, SQL will sort them in parts, placing
intermediate results in temporary files. These files are then merged and
resorted until all rows are sorted. Increasing the batch size creates fewer
temporary files and often allows faster sorting. However, if the sort
batches are too large, they cause pageins because parts of the sort batch
get paged out to swap during sorting. In these cases, it is much faster to
use smaller sort batches and more temporary files, so again, swap pageins
determine when too much memory has been allocated. Keep in mind this
parameter is used for every backend performing a sort, either for ORDER BY,
CREATE INDEX, or for a merge join. Several simultaneous sorts will use
several times this amount of memory.

Also, many operating systems limit how much shared memory can be allocated.
Increasing this limit requires operating system-specific knowledge to either
recompile or reconfigure the kernel.

As a start for tuning, use 10% of RAM for cache size, and 2-4% for sort size
if you have just a few big sessions, and much smaller if you have lots of
small sessions. You can try increasing it to see if performance improves and
if no swapping occurs. If the shared buffers are oversized, you waste
overhead maintaining too many buffers, and it takes RAM that could be used
by other processes and as additional kernel disk buffer cache.

Sorting is considered healthy if there is sufficient heap space in which to
perform sorting and sorts do not overflow unnecessarily.

[ducthcogtechie]

As for looking into the java stack:

As from 8.2 you can start the cmtools.exe hidden deep in the bin directory.
That can read out the usage of the memory inside the stack, so you can adjust accordingly if neeeded.
(either a higher stack, or a smaller buffer size)

If you have set 768 maximum, and you see java.exe allocate a gig, or even over that, your
logic between the java and the bibus is having issues. In that case log a call with cognos support.


As for where the sorting lives; i was tought inside the stack space, so you can push the serlvets into a problem, when setting it to high.
If it lives in the bibus.exe memory, it can allocate up to 2 gig if needed (max mem per proces) and does not touch the java stack at all.

i will doublecheck with some cognos guys to rule out miscommunication.

[Ray]

Thanks dutchcogtechie and Angus Miller.

We would probably put Cognos on a separate server.

Really appreciate your help and all the information.

Ray

[ducthcogtechie]

Im not so sure the sort buffer lives as part of the java process, it makes more sense for it to be part of the bibuss process. Dutchcogtechie whats your take on this?

You are right. It's running in the bibus memory allocation.