on 03-30-2021 6:56 PM
Hello,
Working on a sizing for a new BOBJ 4.3 SP1 install in which the content is primarily Crystal Reports.
Now the official sizing documentation is still based on 4.2 and in this, for the Crystal Reports 2016 processing server, there are calculations for the number of child processes that are spawned by the parent crystal process and the amount of memory these can consume. It is stated here that a child process can consume 500MB (1.25 per core) and the number of children are determined by the number of cores * 2.5. So with an 8 core system, the Crystal processing server supports 20 threads and consumes up to 10Gb.
Now this is all based on the 32-bit version of Crystal 2016 in 4.2 SP5+. In 4.3, the Crystal Reports 2020 Processing server is now 64-bit and doesn't have the same memory constraint, theoretically 64-bit, but realistically like any of the other java components or 64-bit C++ components we configure. The closest we see in 4.2 is in the Crystal Enterprise Processing Server in which the child processes can consume up to 3GB of RAM and the number of children is calculated by cores / 2. So an 8 core system supports 4 enterprise threads and can consume up to 12GB of RAM.
I understand Crystal Enterprise is not the same as Crystal 2016 or 2020, BUT it is the closest 64-bit component to compare against. Since there is no memory constraint in the 64-bit version like the 32-bit version, has there been any updated guidance on the sizing for the Crystal Reports 2020 processing server?
Thank you.
Hi Nathan,
It will look something like this:
"As discussed, since our internal P&R testing just shows ~30% of memory increase (private bytes) in 64bit CR proc server, for now we will recommend 2GB per core / 800M per child (60% increase compared to CR2016, 32 bit).
Crystal Reports 2020:
# of children = # of logical cores * 2.5 Each
child can use up to 800MB of RAM
2 GB per core"
The final info may change so check it...
Have a great day
Don
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Nathan,
I asked R&D to have a look at your post and the sizing guide and here's what they are going to update for calculating the memory size in the sizing Guide.
Check for the updates...
Thanks for pointing this out for us to update.
Don
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.