Skip to Content

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%. 

image

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. 

image   

 

 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. 

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply