Actually, quite a few customers run with that many engines/memory. In fact, it is difficult these days to even buy a server with less than 128GB of memory and 16 cores/32 threads. Pretty much the only time we see less is when the install is in a VM. Interestingly, we had comments from the first version suggesting the numbers were not realistic given the typical size of systems being deployed were much larger.... In addition, in my experience with customers on SAP systems, they were not aware of how much memory was necessary to really support medium to large systems based on the configurations they were attempting.
I am sorry that you feel some of the examples are contradictory. You are correct in pointing out that the text refers to 16 engines and the example configures 32.... So yes, for that specific example, it should have been 16.
Secondly, not having seen ADM540, but I think there is a bit of a problem if they suggest that. I my opinion (and I have spent a lifetime tuning ASE), the idle timeout for ERP and BW should likely both be 1000+ and 2000 is not unreasonable. The comment in ADM540 is likely due to if ASE and a NW CI are sharing the same cores - e.g. you have a 4 core box and ASE is running on 2 cores (we will ignore threads for this discussion) and you have 30 NW worker processes - which obviously will need to bump ASE off the cpu in order to run. This may be fine in a test/dev or even a solution manager system, but bumping ASE off the core is NOT a good thing for a production system. In fact, I would encourage using numactl or similar to fence off the the cores used for ASE from NW worker processes if at all possible. We have seen cases of overloaded NW installations with multiple CI instances with hundreds of worker processes each starving cpu away from ASE......sooo....I would tend to actually be a bit more than firm on suggesting that 100 is a very bad starting point. Given the number of client side joins that SAP uses to avoid [DBMS proprietary] temp tables, it is critical that ASE's (or any DBMS) response time be minimized as much as possible.....having ASE yield the core practically as soon as it gets done processing one task (and puts it to sleep pending an IO) just really causes things to run slow. Think of a typical query that returns 10 rows - say wide enough that each row fills 1 packet. If the packet transmit time (and client ACK) takes more than 100 microseconds on CPU (almost a given for network interactions...as clock ticks are in nanoseconds and networking is minimally milliseconds - 1000 microseconds), ASE would yield the CPU every time it sent a packet. When the client wanted the next packet, the OS would have to wake up the ASE process (an interrupted sleep) which is a nasty heavy weight operation. Hence it is best for ASE to hang out on the CPU until reasonably sure that nothing more is going to happen very soon....and on current cpus...and having it run for 1-2ms (1000-2000 microseconds) shouldn't be a hardship. If you created a separate thread pool for batch worker processes, then I could see maybe using a lower idle timeout such as 200 or 250......100 is just plain too low in my mind...it is like saying ASE is expecting an odd query every few seconds vs. a steady workload. Basically at that level, there had better be a task in the ASE job queue or one on the way on the network already, or that engine is going to sleep.
While I state that with regards to ADM540 itself, I have not seen the class (perhaps)...one customer did show me the notebook of a class (ASE Sys Admin) they went to and it was really targeted at non-SAP installations more than SAP installations - from a reality/experience aspect. Part of the issue with the class the customer showed me was it borrowed liberally from the old SY classes as a starting point, but at the point the class was developed there was not a lot of experience with running SAP installations on ASE to really point out the fine tweaking areas such as idle timeout.
However, the document was really aimed primarily at Business Suite vs. BW systems or a Solution Manager install (which are much smaller) - there are a lot of other considerations for BW the guide doesn't get into - although some of the sizing is a better start than the defaults provided by SAPINST
The former runtime guide essentially was just merged in to the Post-Migration Steps section.
May do a quick refresh in the near-future (due to some recent experiences), so if you have other specific examples of the text and SQL not aligning - please let me know.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.