During our first Unicode conversions (as I presented at TechEd 07 in Las Vegas), we worked on 1 R/3 system and our global BW system. We are currently planning the next (and last) Unicode conversions of our other R/3 instance, and our SCM. I focused on performance improvements, particularly how much to increase resources on our application servers.
One tip our Unicode consultant gave us was to increase application server buffers, to handle the change from UTF-8 to UTF-16 (8 to 16 bit character memory storage). He referred us to note 790099; part of that note says "When performing an Unicode conversion, all buffers that contain characters should be in a first phase adapted. If after production start some swaps in these buffers occur, you may have to increase them again accordingly." The guideline says to double memory sizes when going from single-byte systems to Unicode.
Below is a chart showing the parameters that we increased, based on our testing and experience. In some cases we doubled sizes; others were more or less.
| Parameter | Description | OLD - 2006 | New - 2007 |
|---|---|---|---|
| rsdb/cua/buffersize | CUA Buffer | 6,000 | 16,384 |
| zcsa/table_buffer_area | Generic Key Buffer | 65,000,000 | 120,000,000 |
| rtbb/buffer_length | Single Record Buffer | 30,000 | 60,000 |
| rsdb/obj/buffersize | Export/Import Buffer | 20,000 | 20,000 |
| rsdb/ntab/ftabsize | Field Description Buffer | 50,000 | 60,000 |
| rsdb/ntab/irbdsize | Initial Record Buffer | 8,000 | 16,384 |
| rsdb/esm/buffersize_kb | Export/Import - Shared Memory | 32,768 | 32,768 |
| rsdb/otr/buffersize_kb | Online Text Repository Buffer | 4,096 | 4,096 |
| abap/buffersize | ABAP Program Buffer | 800,000 | 800,000 |
The above was for our R/3 system; BW was similar.
These changes worked well for several months after the conversions, until we hit a glitch that I described in my ST10 blog. As a reaction to that performance hit, we decided to increase the generic key buffer from 120MB to 200MB, giving us more breathing space in case another table or tables went awry.
The increase took effect last weekend, so I've tracked the table buffer hit ratio in both R/3 systems -- Unicode and Non-Unicode. The results were surprising.
The Unicode system ranged from around 99.5% to 99.7% prior to the space increase. Afterwards we're seeing values between 99.7% and 99.9%.
The non-Unicode system was hitting over 99.8% (note the Y-axis difference below) prior to the space increase, and has been around 99.95% this week. While the systems are different in several ways, table buffer settings are similar, with full buffering switched to generic for any table over 5MB.
One surprise in both systems is that the hit ratio tends to decrease during the work week. Before I looked closely at the actual values, I would have predicted that the buffers would improve as common data was cached.
Based on the above results, we plan to increase the Unicode system table buffer memory another notch, with the expectation that the hit ratios will increase to the 99.9% range.
