Customers are inadvertently turning on bcrypt as the default hashing algorithm for the password storage scheme. Bcrypt is by design slow and as DS does not currently hand off the computational effort of creating and verifying/comparing hashes; load, extensive number of BINDs at the same time and other such behaviour can fully saturate DS's CPUs leading to non responsive instances and in worst cases an outage.
This is especially relevant when DS is used as a userstore - where each AM will create a number of connections to each DS using a service account and then BIND again as each user as part of the AuthN process. Under enough load DS will exhaust all CPU load resulting in an outage (failed AuthN).
The same is true where DS is used as a CTS store due to each AM again creating a number of pooled connections using a service account (who's password will by hashed by bcrypt). Furthermore as CTS only hashes the service account passwords and the rest of the data is token data, bcrypt should not be recommended for use in the CTS context.
Please update the documentation to be far more explicit on bcrypt impact to service.