ASO option and exec_cmds_per_timeslice config param

[Former Member]

Hi,

I have some doubts regarding configuration parameter "exec_cmds_per_timeslice".

In earlier version of RS, this has a default value of 10.

Now, using RS 15.7.1, the default is 2147483647- which is the max value -

Now, RepAgent User thread in RS does 4 major functions: 

• EXEC – Executor – RepAgent executes commands from LTL stream
• PRS – Parser – parses LTL into table/columns/values
• NRM – Normalizer
• PAK – Packer

Keeping "exec_cmds_per_timeslice" set to its default value 2147483647 will instruct the RepAgent User to process 2147483647
LTL command before yielding the CPU. This affects the remaining tasks (Parser, Normalizer, Packer) since they will be waiting for the RepAgent User to stop executing commands from LTL stream in order to process their tasks.

In a typical SRS, this is a single thread. To rectify this, ASO option may be used which allows multiple threads to be used.

My question is:

If we are not using ASO, shouldn't we decrease the value for "exec_cmds_per_timeslice" to let's say 100 000 in order to give some room for other RA thread tasks and to decrease the time for the ACK to reach the RepAgent?

One more clarification needed.... We still need to explicitly cache RSSD system tables using 'configure replication server set "sts_full_cache_xxxx" to "on"' even if we have sts_cachesize set to a high value.

setting sts_cachesize to a high value does not assure that RSSD tables will be cached.

Regards,

Marc

[former_member182259]

You have asked several questions....

#1) exec_cmds_per_timeslice is deprecated - hence the 2B value.   The original goal was to try to get the RepAgent User thread to yield back to OpenServer the CPU to provide more time to DIST, DSI & other threads thinking that it might help latency.  When enable_smp was fully implemented, this became essentially useless as thread scheduling was more up to OS than it was to OpenServer.    Keep in mind that this caused RepAgent User thread to yield - which as noted - impacts PRS & NRM (including PAK) when running without ASO as a single thread (or more accurately, the library functions are all running on a single thread).   However, note that this doesn't mean that PRS & NRM is waiting on the RepAgent User when a single thread - it means there is a single thread "RepAgent User" which is invoking 4 libraries - EXEC, PRS, NRM & PAK.....and without ASO, the ack for a LTL buffer doesn't even go back to ASE until it hits the SQM write request queue (after PAK).   So PRS & NRM are affected due to the thread yielding - but they are not "waiting" - they are simply modules/libraries that all run on the RepAgent User thread that was yielding the CPU to provide time for the SQM, SQT, DIST, DSI, etc. threads.    Note that the intent of this param was not to set it to 100 or 1000 - but to reduce it from the original default of 5 (I think) to 3, or 2.     However, remember, when doing so, it restricts the throughput of RepAgent which can have a significant impact on primary transaction log.   Best bet is to simply leave it at 2B currently as even non-ASO option SRS's have SMP.

#2)  If you are NOT using table repdefs/table subscriptions (e.g. MSA with database repdef/subscriptions only) - then sts_full_cache_xxxxx or some key RSSD tables can benefit - e.g. if SRS gets a new LTL record and doesn't find it in the STS cache, it does a lookup in the RSSD to see if there is a repdef.   If sts_full_cache_rs_objects is enabled, then if the object doesn't exist in cache, then SRS knows that the RSSD doesn't have it either.   There is a penalty in that if you add/remove a repdef/subscription and sts_full_cache_xxxx is enabled, the operation takes orders of magnitude longer.   As a result, if you have ANY table level repdefs (or procs), you are best setting the STS cache fairly high (20000) and leave sts_full_cache_xxx as per the defaults.   In other words, this works best when being used for a strict MSA/WS system with no other replication.

[Former Member]

Hi Jeff,

Thanks for the quick reply.

In fact, I have some RS latency issue.

During End of Months  (End of Quarter) the queues are building a lot  (reached 120 GB) and Production transaction log is getting almost full.

I have attached some reports generated during this activity. (RS counters and monitors - Provided by one of the best RS evangelist .... guess who )

Would you have time to provide some comments about the attached reports?

Regards,

Marc

rs_perf_details_phoenix.txt.zip

corresponding_sysmon.dat.zip

rs_perf_summary.txt.zip

[former_member182259]

Everytime I try replying with any details, SCN wigs out and crashes (wimpy interface meant for preschoolers vs. real work).   Send me a private email at jeff.tallman@sap.com