So, first, I'm going to remove this log line:

{{{
slapi_log_error(SLAPI_LOG_FATAL, "util_is_cachesize_sane", "Available pages %lu, requested pages %lu, pagesize %lu\n", (unsigned long)availpages, (unsigned long)cachepages, (unsigned long)pagesize);
slapi_log_error(SLAPI_LOG_FATAL, "util_is_cachesize_sane", "WARNING adjusted cachesize to %lu\n", (unsigned long)*cachesize);

}}}

I'm going to make these trace. That way when it happens, we don't this the "Resize -> fail" message that's pretty deceptive.

For autosizing, I think we have the right policy of how we manage it, so I'll leave that alone.

For manually set sizes, we have some issues. Because if we have a system, say 2GB of ram free, and we request 1.5GB cache for 2 dbs. If we accepted the resize we'll end up with backend A being set to 1.5GB, and backend B set to 375Mb. Totally not what we want!

We can't really resize every backend nicely here ... If we start to work out percentages, and stuff, we end up autosizing anyway.

So I think that the "error, you can't start" is the right answer.

Saying this, it might be a bit "jarring" and a shock to users.

I think for this release, we remove this line:

{{{
issane = util_is_cachesize_sane(&total_size);
if (!issane) {
/ Right, it's time to panic /
LDAPDebug( LDAP_DEBUG_ANY, "CRITICAL: It is highly likely your memory configuration will EXCEED your systems memory.\n", 0, 0, 0 );
LDAPDebug(LDAP_DEBUG_ANY,
"Total entry cache size: %llu B; "
"dbcache size: %llu B; "
"available memory size: %llu B; \n",

ifdef LINUX

          (PRUint64)total_cache_size, (PRUint64)li->li_dbcachesize, availpages * pagesize

else

          (PRUint64)total_cache_size, (PRUint64)li->li_dbcachesize, memsize

endif

);
LDAPDebug(LDAP_DEBUG_ANY, msg, 0,0,0);  
return SLAPI_FAIL_GENERAL; // THIS LINE

}

}}}

This way we still get the huge warnings, and the admin KNOWs it's invalid, but we start anyway.

Perhaps we add in a message, that in a future version this will prevent server start up. Then in say a version or two time, we re-add the fail.

What do you think?

{{{
[09/Jun/2016:12:55:28.688794018 +1000] 389-Directory/1.3.5.4 B2016.161.253 starting up
[09/Jun/2016:12:55:28.810957160 +1000] CRITICAL: It is highly likely your memory configuration of all backends will EXCEED your systems memory.
[09/Jun/2016:12:55:28.824474066 +1000] CRITICAL: In a future release this WILL prevent server start up. You MUST alter your configuration.
[09/Jun/2016:12:55:28.835668156 +1000] Total entry cache size: 10758389760 B; dbcache size: 10000000 B; available memory size: 8490463232 B;
[09/Jun/2016:12:55:28.847092913 +1000] This can be corrected by altering the values of nsslapd-dbcachesize, nsslapd-cachememsize and nsslapd-dncachememsize
[09/Jun/2016:12:55:29.157571757 +1000] slapd started. Listening on All Interfaces port 389 for LDAP requests
}}}

attachment
0001-Ticket-48873-Backend-should-accept-the-reduced-cache.patch

Hi William,

The fix looks good but I have a doubt about
change in ldbm_config_dbcachesize_set, the message reports an error in entrycache size setting although here the checking is done on the dbcache size.
in ldbm_config_dbncache_set, there is a call to util_is_cachesize_sane. According to the documentation it is more a flag (1 to 4) than a memory size. is it correct to call util_is_cachesize_sane in that routine ?

thanks

Replying to [comment:4 tbordaz]:

Hi William,

The fix looks good but I have a doubt about
* change in ldbm_config_dbcachesize_set, the message reports an error in entrycache size setting although here the checking is done on the dbcache size.

Excellent spot! I have fixed this to match nsslapd-dbcachesize.

• in ldbm_config_dbncache_set, there is a call to util_is_cachesize_sane. According to the documentation it is more a flag (1 to 4) than a memory size. is it correct to call util_is_cachesize_sane in that routine ?

I think you are right here. It was there before, I updated it recently. I've decided to drop this check, since it's irrelevant.

New patch attached.

thanks

attachment
0001-Ticket-48873-Backend-should-accept-the-reduced-cache.2.patch

Thanks William for your feedback. The patch looks great --> ack

commit 88bfd0aaf7b0d0c048660e33215d35d7066ea862
Writing objects: 100% (9/9), 1.51 KiB | 0 bytes/s, done.
Total 9 (delta 7), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
886a1ff..1b8baa8 master -> master

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1932

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.