389 DS memory growth
by Nazarenko, Alexander
Hello colleagues,
On March 22nd we updated the 389-ds-base.x86_64 and 389-ds-base-libs.x86_64 packages on our eight RHEL 7.9 production servers from version 1.3.10.2-17.el7_9 to version 1.3.11.1-1.el7_9. We also updated the kernel from kernel 3.10.0-1160.80.1.el7.x86_64 to kernel-3.10.0-1160.88.1.el7.x86_64 during the same update.
Approximately 12 days later, on April 3rd, all the hosts started exhibiting memory growth issues whereby the “slapd” process was using over 90% of the available system memory of 32GB, which was NOT happening for a couple of years prior to applying any of the available package updates on the systems.
Two of the eight hosts act as Primaries (formerly referred to as masters), while 6 of the hosts act as read-only replicas. Three of the read-only replicas are used by our authorization system while the other three read-only replicas are used by customer-based applications.
Currently we use system controls to restrict the memory usage.
My question is whether this is something that other users also experience, and what is the recommended way to stabilize the DS servers in this type of situation?
Thanks,
- Alex
6 months
Replication ends suddenly because of csn_time_difference?
by Harald Strack
Hi,
we experiencing sudden stops of replication with this message in the logs:
[27/Mar/2023:21:01:12.262842335+0200] - WARN - agmt="cn=IP"(xx-sso5:636)
- clcache_load_buffer - bulk load cursor(64063f010000006a0000) islower
than starting csn 6421e16e0000006a0000. Ending session.
The Relevant Code seems to be here
https://fossies.org/linux/389-ds-base/ldap/servers/plugins/replication/cl...
/* safety checking, we do not want to (re)start replication before 344 *
the inital computed starting point 345 */ 346 if (initial_starting_csn)
{ 347 csn_init_by_string(&limit_csn, initial_starting_csn); 348 if
(csn_compare(&limit_csn, buf->buf_current_csn) > 0) { 349 char
curr[CSN_STRSIZE]; 350 int loglevel = SLAPI_LOG_REPL; 351 352 if
(csn_time_difference(&limit_csn, buf->buf_current_csn) > (24 * 60 * 60))
{ 353 /* This is a big jump (more than a day) behind the 354 * initial
starting csn. Log a warning before ending 355 * the session 356 */ 357
loglevel = SLAPI_LOG_WARNING; 358 } 359
csn_as_string(buf->buf_current_csn, 0, curr); 360
slapi_log_err(loglevel, buf->buf_agmt_name, 361 "clcache_load_buffer -
bulk load cursor (%s) is lower than starting csn %s. Ending session.\n",
curr, initial_starting_csn); 362 /* it just end the session with
UPDATE_NO_MORE_UPDATES */ 363 rc = CLC_STATE_DONE; 364 } 365 }
The loglevel is only set to SLAPI_LOG_WARNING if the replica is more one
day (!) behind... However that is not the case, and there is also no
time glitch between the servers. Do you have any idea what is causing
the problem?
br
Harald
1 year, 1 month
