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 ckp
You 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
------------------------------

Original Message:
Sent: Thu January 06, 2022 05:17 AM
From: ZhiWei Cui
Subject: SDS TIMEOUT issue

I do not recommend that you set the SDS node updatable
onstat -g ckp
You 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
------------------------------

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

Original Message:
Sent: Thu January 06, 2022 07:12 AM
From: Art Kagel
Subject: SDS TIMEOUT issue

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