SDS TIMEOUT issue

| view attached (4) Hello All, Every 1 or 2 months, SDS Secondary server loses connection due to sds timeout. Checkpoints take 99 seconds to as long as 347 seconds in some cases. Customers say it's not a network issue. Could it be solved by increasing the sds timeout value? Below are some of the error messages from the primary and secondary servers at the time the problem occurred. ** Primary Server online.log 12/11/21 06:56:49 Requesting SDS node topas_sec to shutdown due to SDS cycle timeout 12/11/21 06:56:50 Checkpoint Completed: duration was 187 seconds. ** SDS Secondary online.log 12/11/21 06:51:09 The SMX connection between high availability servers was closed because the peer server was unresponsive for the timeout period (60 seconds times the number of retries). 12/11/21 06:51:11 Updates from secondary currently not allowed ... 12/11/21 09:56:38 Encountered problem processing update on secondary : Cannot create new proxy transaction Or would adjusting the SMX_NUMPIPES or UPDATABLE_SECONDARY parameters work? The current VPCLASS and UPDATABLE_SECONDARY parameter settings are as follows. VPCLASS cpu,num=27,noage UPDATABLE_SECONDARY is 18 ------------------------------SangGyu Jeong Software Engineer Infrasoft Seoul Korea, Republic of ------------------------------ #Informix

I do not recommend that you set the SDS node updatable onstat -g ckpYou may see checkpoints triggered by IPL or HA I try to set it as follows: LOG_ INDEX_ BUILDS=0 DRIDXAUTO=0 I have many SDS clusters. Some SDS cluster checkpoints are short, but some are still long. Therefore, my real practice is that if the checkpoint time cannot be shortened, I will close the SDS node. In addition, can you tell me the version of IDS? ------------------------------ ZhiWei Cui GBASE ------------------------------

Thanks for the reply. Zhi Wei. My customer is using Informix 12.10.FC14 and has only 1 SDS node configured. The average checkpoint time is 1-3 seconds. I'll check if anything is marked as IPL or HA with the onstat -g ckp command. Currently, no suspicious information is found in the application log, so I'll try to periodically collect information from the sysmaster:sysptprof table. ------------------------------ SangGyu Jeong Software Engineer Infrasoft Seoul Korea, Republic of ------------------------------

The default for SMX_NUMPIPES is 1 which would be managed in the first CPU VP. That VP is also managing those long checkpoints. I would set SMX_NUMPIPES to the same value as UPDATEABLE_SECONDARY. I would also take a look at tuning SMX_PING_INTERVAL and SMX_PING_RETRY to make the timeout more forgiving. Increasing SDS_TIMEOUT can't hurt, but given that this tends to happen during a long checkpoint on the primary, I suspect that the primary is just too busy to check the ACK from the secondary. ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

Thanks for the advice. Art. Since SMX_NUMPIPES cannot be changed online, I will try tuning the SMX_PING_INTERVAL and SMX_PING_RETRY parameters. ------------------------------ SangGyu Jeong Software Engineer Infrasoft Seoul Korea, Republic of ------------------------------