cancel
Showing results for 
Search instead for 
Did you mean: 

Tuned Profile Settings for Adaptive Server Linux

james_morrison
Explorer
0 Kudos
195

i ,

We are preparinng to Migrate our ASE servers  to upgraded Linux Hosts running RHEL 8.8.  We ran into a performance in writing to Disk . Issues related to this kba : https://me.sap.com/notes/2585416/E

The recommendation  change:

kernel.sched_min_granularity_ns = 10000000
kernel.sched_wakeup_granularity_ns = 15000000

to

kernel.sched_min_granularity_ns = 3000000
kernel.sched_wakeup_granularity_ns = 4000000

We made those changes and saw major improvements .  Now the question ---By default Linux servers  are using  the tuned profile throughput-performance -- which  has the original kernel settings , along with others.  Looking at docs  it seems that the settings in this profile do not work well with SAP products   There are profiles provided by RedHat specifically for Hana /NetWeaver / SQL server / oracle /Postgres.   Nothing for ASE/IQ/Rep Server.  So long winded question  are there any recommended settings to add/replace in the tuned profile specifically for ASE /IQ  /Replication  Server  ?  We have been working with Both SAP Support and RedHat --with no luck. 

 

Thanks

Jim

tilman_model-bosch
Product and Topic Expert
Product and Topic Expert
0 Kudos
Dear Mr Morrison
tilman_model-bosch
Product and Topic Expert
Product and Topic Expert
0 Kudos
Dear Mr Morrison I was not aware that there were issues with the above default settings (did not know the KBA you posted) . There are Linux parameter recommendations for ASE but these settings were unknown to cause issues. Ill try to follow up on this . Regards
sladebe
Active Participant
0 Kudos
The web page:

Accepted Solutions (1)

Accepted Solutions (1)

tilman_model-bosch
Product and Topic Expert
Product and Topic Expert
0 Kudos

I followed up on these two parameters. 
I am still waiting for some input from colleagues but it seems that these default parameter settings apply to Redhat 8.x (not sure whether all 8x release are affected or not). Redhat 9.x seems not to be affected - have been told these parameters don't exist in 9.x.  
We also discussed whether or not to put these settings in default SAP tune configuration. As your report of this issue is the only one we are aware of, we decided to not put it to some tune configuration for now. 
But if this turns out to be a widespread issue the topic will be re-discussed again. 
HTH 

Tilman  

Answers (1)

Answers (1)

sladebe
Active Participant
0 Kudos

The web page: https://access.redhat.com/solutions/177953 says:

"sched_latency_ns is the initial value for the scheduler period. The scheduler period is a period of time during which all runnable tasks should be allowed to run at least once. While CFS has no concept of time slices, you can think of the period as the initial chunk of time which is then divided evenly into timeslices, one for each runnable process. Note that this tunable only specifies the initial value. When too many tasks become runnable the scheduler will use kernel.sched_min_granularity_ns instead ."

"sched_min_granularity_ns specifies the target minimum scheduler period in which a single task will run. This tunable is used only when running load is high. Unlike sched_latency_ns, this tunable specifies the target period allocated for each task to run rather than the time in which all tasks should be run once."

So by decreasing these numbers you are essentially let a busy process get back the CPU faster when it's kicked off

The ASE db server currently uses native threads in Linux.  Those threads are not full processes.  I wonder if these scheduling parameters apply to Linux threads, probably yes (but that's just a guess)

I've seen slowness with Sybase backups for decades.  The backupserver read read is an order of magnitude slower than a bulk sequential read of the underlying device (eg. using the "dd" utility).  Some detailed research showed that the backupserver is doing single block I/O calls instead of large sequential reads.  It seems reasonable that letting the backup server back to the CPU after it was kicked off might improve things if multiple threads are involved.   Note that moving to SSDs made backups run significantly faster (ie., reading from those SSDs).   This might also be evidence that the backupserver is doing random I/O type calls.

As noted by others, these parameters disappear in newer versions of Linux.  Has the scheduling algorithm changed?  Or are these parameters just no longer tunable? (ie., hardcoded)

Also, see this old discussion about tuning ASE for high I/O SSD environments:
https://community.sap.com/t5/technology-q-a/things-to-tweak-for-ase-running-on-ssds/qaq-p/12516190

Ben

sladebe
Active Participant
0 Kudos
Also, according to https://lore.kernel.org/lkml/20230328110354.426388922@infradead.org min_granularity has been renamed to base_slice
sladebe
Active Participant
0 Kudos
Also, on our Linux systems, we changed the scheduler algorithm to "deadline" for hard drives and "none" for SSDs. See /sys/block/*/queue/scheduler files for your current settings